Интерфейс веб-службы

Question

Я хочу добавить интерфейс веб-сервисов к существующему серверному приложению. Набор предоставляемых служб неизвестен во время компиляции и может изменяться в течение срока службы сервера.

С технической точки зрения все конечные точки сервера / веб-службы будут в Windows.

В нашем серверном приложении пользователь может зарегистрировать рабочие процессы как «вызываемые веб-сервисы». Это создаст WSDL, определяющий эту конкретную службу рабочего процесса.

Для вызывающей конечной точки я имею в виду HttpModule, который принимает входящий запрос веб-службы, распаковывает запрос и преобразует типы данных XML в «домен» наших серверных приложений, вызывает сервер и, наконец, преобразовывает выходные данные сервера обратно в XML для возврата по http-соединению.

Имеет ли это смысл?

Критические комментарии приветствуются.

Answer 1

По сути, вы пишете свой собственный движок WS. Очевидно, выполнимо, но довольно много работы, чтобы получить право с нуля. Я предполагаю, что если вы найдете какую-то реализацию с открытым исходным кодом, то адаптация должна быть возможной.

Более грязная альтернатива, но я видел применение в другом контексте - использовать интерфейс WSG

String call( String workkFlowName, String payload)

Полезная нагрузка и ответ - это строки, содержащие любой XML. Таким образом, вызывающая сторона должна понимать схемы для этих XML. С точки зрения клиента количество усилий по написанию кода не сильно отличается. Я думаю, что ваши усилия по написанию кода будут значительно сокращены.

Answer 2

HttpModule, который принимает входящие запрос веб-службы, распаковывает запрашивать и преобразовывать данные XML вводит в наши серверные приложения "домен", вызывает сервер и, наконец, преобразует выходные данные сервера в XML для возврата вниз по http подключение.

Это то, что делают все платформы веб-сервисов (например, Metro, Axis). Так что я не вижу твоей проблемы. Какое у вас отношение к этому подходу?

Недостатком для клиента является то, что, насколько я понимаю, доступность ваших услуг может со временем меняться. Таким образом, вы должны рассмотреть способ информирования клиента, если услуга доступна (кроме получения ошибки тайм-аута, потому что ее там нет), например, WS-ResourceLifetime или UUDI .

Answer 3

В итоге я создал класс C #, который реализует интерфейс IHttpHandler. Реализация обслуживает WSDL сервисов, предоставляемых нашим приложением, и принимает сообщения SOAP для вызова сервисов. В итоге большая часть работы была направлена ​​на преобразование типов SOAP в наши типы и наоборот.