Реализация обратного вызова в XML-RPC или SOAP
Если мы серьезно относимся к ответу на этот вопрос как группа.
я, к сожалению, полагаю, что нам нужны больше, чем строка случайного хорошо умышленного сообщения!
я знаю, это звучит скучным, получение вещи, делавшейся часто!
Мы Написали список мощных идей в области вычислений
, Возможно, мы должны определить несколько категорий для разделения каждого, потому что видеоконференция так или иначе не соответствует хорошо объектно-ориентированному программированию.
идеи Наблюдения категориями помогает генерировать их без дублирования. Слишком легко к запасному пути в телепортации, если квантовые вычисления не держатся отдельно от летающих автомобилей.
Попытка приписать каждого из них дата
Это уладит перед/после того, как 1980 и ограничит дебаты о каждой идее его собственному. Это будет забава вырыть для самой ранней ссылки, сначала известная реализация, и т.д.
Плюс это позволит людям как я, которые было 2 года в 1980, чтобы иметь лучшую идею того, что было общим знанием программирования в 1980 (ничто не бьет быть там в то время)
Попытка приписать каждого из них текущее состояние их реализации
хорошо, некоторая идея была научно-фантастической в 1850 с ранней разработкой в и серьезном прорыве улучшения 1970 года в 1990.
Некоторые идеи только начинают двигаться. О некоторых почти забывают.
, Вероятно, вещью Wiki является хорошая идея.
я думаю, что это могло действительно добраться где-нибудь, если немного организовано.
я не проверял, но возможно эта целая вещь уже уже существует в сети (я обычно нахожу, что, если Вы думаете о чем-то, кто-то уже сделал это).
, Что Вы думаете?
За Ваше здоровье!
3 ответа
Есть два способа делать уведомления в системе RPC: модель push и модель получения. В модели pull клиент будет периодически запрашивать сервер, доступны ли какие-либо уведомления. Сервер должен хранить их до тех пор, пока клиент не получит их (или пока срок их действия не истечет). Как вариант, клиент может иметь блокирующий вызов RPC, который блокируется до тех пор, пока не станет доступным следующее событие, а затем сразу же возвращается. Это прекрасно работает с CORBA, но не так хорошо с SOAP или XML-RPC, поскольку реализации HTTP обычно не готовы оставлять соединение открытым на несколько часов.
В модели push производитель вызывает RPC на потребителе, превращая потребителя в сервер. Это также не очень хорошо работает с SOAP или XML-RPC, поскольку клиент обычно не готов взять на себя роль сервера, а брандмауэры могут препятствовать выполнению обратного вызова. Таким образом, периодическое вытягивание - это наиболее реалистичный подход.
PS, возможно, вы заметили, что я не следовал вашей терминологии: вы не можете проталкивать события . Событие - это то, что происходит. Вы можете только отправить уведомление, которое является информацией о том, что событие действительно произошло.
Вы можете сделать это с помощью WCF. Однако я не знаю, сможете ли вы сделать это совместимым образом. Посмотрите Duplex Services .
Хорошо, в конечном итоге решение сделано, чтобы иметь дело с обратными вызовами как с API, которые не возвращаются немедленно.
В основном, будет отправлен запрос RPC-XML с просьбой уведомить вас о заданном списке событий. Наш сервер будет ждать, пока не произойдет одно из событий, а затем сообщит об этом как ответ или тайм-аут по прошествии определенного времени, уведомляя, что ничего не произошло. Вызывающий абонент сможет повторить попытку отправки запроса, чтобы продолжить ожидание.