Желательно ли создавать веб-сервис поверх других веб-сервисов? - PullRequest
2 голосов
/ 03 октября 2008

Я унаследовал эту действительно странную кодовую базу, где они построили внешний веб-сервис поверх набора внутренних веб-сервисов, просто чтобы добавить аутентификацию / авторизацию с использованием WS -Безопасность , WS-шифрование и др. Менее чем через месяц после этого участия я уже чувствую боль от соединения летучих компонентов через жесткий WSDL, особенно учитывая, что некоторые из них используют WCF, а другие предпочитают сначала использовать WSDL. Управление различными версиями сгенерированных прокси и оболочек на разных уровнях - это кошмар!

Я признаю, что дизайн слишком сложен и мог бы быть намного лучше, но мой вопрос по существу таков:

  • Будете ли вы когда-нибудь создавать веб-сервис только для того, чтобы обеспечить сквозную заботу о множестве сервисов?
  • Будет ли это лучше реализовано как обработчики веб-служб?

и наконец ...

  • Вы бы классифицировали это по шаблону шлюза веб-службы?

Ответы [ 2 ]

3 голосов
/ 03 октября 2008

Я видел, как эта штука строилась год назад. Я чуть не заплакал, когда команде потребовались месяцы для создания 4 веб-сервисов, 2 из которых просто обернули другие внутренние, используя WCF и серьезное шифрование. Единственная причина, по которой они обернули внутренние, состояла в том, чтобы изменить числа потенциальных ошибок, возвращающихся.

Так, я бы когда-нибудь намеренно сделал это? Нет.

Будет ли это лучше реализовано, как почти все остальное? Угу.

Могу ли я классифицировать его по шаблону WTF? совершенно.

UPDATE:

Одна вещь, которую я только что вспомнил, это то, что существует архитектура, называемая Enterprise Service Bus. Ее цель - предоставить общий интерфейс для других систем SOA. Таким образом, не имеет значения, что различные приложения используют для своих механизмов конечных точек (WCF, WSE 1/2/3, RESTful и т. Д.).

BizTalk является одним из примеров ESB, и есть много других готовых программ, которые можно использовать. По сути, ваше приложение передает сообщение в ESB, и оно надежно обрабатывает его отправку в другие системы, а также отправляет ответы обратно.

Это также означает, что вы можете изолировать другие приложения от множества типов изменений в конечных точках. Конечно, если новые конечные точки требуют дополнительной информации, вам придется изменить вызывающих абонентов. Однако, если все, что они меняют, это механизм, то хороший ESB сможет справиться с этими изменениями, не влияя на ваше приложение.

0 голосов
/ 03 октября 2008

Я видел аналогичные реализации, если вы предоставляете сервисы внешнему миру и если вам нужно ужесточить меры безопасности ... отметьте этот столбец MSDN ..

...