Доставка различных видов протоколов в архитектуре SOA - PullRequest
Новая
       26

Доставка различных видов протоколов в архитектуре SOA

0 голосов
/ 21 сентября 2011

У меня есть проект, который в настоящее время находится в производстве и предоставляет некоторые веб-сервисы с использованием подхода REST. Сейчас мне нужно доставить некоторые из этих веб-сервисов также в SOAP (это означает, что мне нужно будет доставлять одни и те же веб-сервисы в SOAP, а другие немного по-другому), поэтому я прошу вас:

  1. Должен ли я включить в существующий проект стек SOAP (библиотеки, файлы конфигурации и т. Д.), Создав еще один слой, который доставляет данные в виде конвертов (некоторые называют это «антикоррупционным уровнем»)?

  2. Должен ли я построить другой проект, используя только общую каноническую модель (стать в разделяемой библиотеке)?

  3. ... Или как вы поступаете в подобных ситуациях?

Пожалуйста, рассмотрите нашу идеальную цель как архитектуру SOA.

Спасибо.

Ответы [ 3 ]

0 голосов
/ 21 сентября 2011

То, как я думаю о системе SOA, у вас есть сообщения и pub / sub. Сообщение является интерфейсом. Получение этих сообщений в систему и из нее - это деталь реализации. Я создаю конечную точку, которая принимает необработанный документ сообщения (более похожий на REST, но не совсем REST), а также конечную точку, которая принимает сообщение как отдельный параметр для вызова SOAP. Код, обрабатывающий входящее сообщение, является отдельной задачей от включения конечной точки HTTP.

0 голосов
/ 22 сентября 2011

Вы можете использовать ESB для этого.Где ESB получает мыльные сообщения и отправляет запрос на отдых на серверную часть.WSO2 ESB обеспечивает эту функциональность.Пожалуйста, посмотрите на этот образец [1].

[1] http://wso2.org/project/esb/java/4.0.0/docs/samples/proxy_samples.html#Sample152

0 голосов
/ 21 сентября 2011

В наших проектах у нас есть фасадный слой, который предоставляет сервисы и карты бизнес-объектам, и бизнес-уровень, на котором выполняется бизнес-логика.

Таким образом, чтобы добавить конечную точку SOAP для существующего сервиса, мы просто создаем новый фасад и обращаемся к той же бизнес-логике.

Во многих случаях это даже проще, поскольку мы используем WCF, у нас может быть конечная точка http SOAP для внешних клиентов и двоичная конечная точка tcpip для внутренних клиентов. Новая конечная точка может быть добавлена ​​путем изменения конфигурации без необходимости изменения кода.

...