#web-services #jms #soa #esb
#веб-сервисы #jms #soa #esb
Вопрос:
Предположим, что в инфраструктуре SOA настроены 2 веб-службы A и B.
Веб-службы A зависят от информации, доступной из локально установленного настольного приложения (это устаревшее приложение, основанное на программировании на C и предоставляющее C API для предоставления информации, необходимой веб-службе A).
Сценарий таков: Человек-исполнитель (который может рассматриваться как потребитель веб-службы B) входит на веб-сайт и нажимает кнопку, которая запрашивает услугу, предоставляемую веб-службой B. Как часть этого запроса отправляется его идентификатор. Веб-служба B отправляет запрос веб-службе A с этим идентификатором. Веб-служба A использует этот идентификатор, чтобы каким-то образом определить способ взаимодействия с локально установленным настольным приложением пользователя, отправившего запрос.
Основная проблема, как веб-служба A может подключиться к настольному приложению и получить информацию надежным способом, используя инфраструктуру SOA.
Предположим, что все в этом SOA основано на Java, за исключением настольного приложения.
Настольное приложение в основном похоже на CRM-приложение со своей собственной внутренней базой данных, а не традиционной базой данных, такой как MySQL. Он предоставляет только базовую текстовую информацию об исполнителе-человеке и о клиентах этого исполнителя-человека в его установленном настольном приложении CRM.
Я действительно хочу использовать технологии, связанные с SOA, хотя это может быть сложнее.
Приведенные выше подробности:
Как я могу использовать JMS для решения этой проблемы?
Если JMS не является правильным решением, как насчет ESB и как я могу использовать ESB для решения этой проблемы?
Ответ №1:
Взаимодействие с настольным приложением будет в значительной степени определяться тем, какие различные методы способно выполнять приложение. Если приложение имеет серверную часть базы данных, ESB может облегчить обмен данными с предопределенными адаптерами для конкретной используемой базы данных. Если приложение имеет API, который можно использовать программно, это тоже метод. Я не уверен, что JMS была бы подходящим решением, поскольку, учитывая ваш вариант использования, вы хотели бы синхронный ответ. Помещение JMS в середину (каким-то образом) нарушит этот ответ и скорее вернет асинхронный ответ.
Я бы рекомендовал подробнее изучить функциональность, доступную в настольном приложении, и с учетом ваших выводов начать с оценки функциональности ESB. ESB может быть излишним для этого варианта использования, но если вы планируете выполнять больше подобных операций, это может оказаться полезным.
Комментарии:
1. Учитывая это, мой ответ остается в силе. Я также хотел бы добавить, что использование веб-службы поверх этого настольного приложения может предоставить сведения, необходимые для подключения веб-службы A при вызове. Это ограничит доступ к приложению, но предоставит необходимые данные. Имея в виду федеративный SOA, вы можете затем предоставить этот веб-сервис из центральной реализации SOA, если ваша реализация окажется достаточно большой. Я все еще не верю, что JMS следует использовать.
Ответ №2:
Я думаю, проблема сводится к веб-службе Java A, требующей взаимодействия с настольным приложением C для получения сведений о пользователе.
Если настольное приложение может использовать JMS с помощью Stomp и т.д., Возможно, используется ActiveMQ или HornetQ. Это также позволяет масштабировать A в несколько экземпляров на многих компьютерах и использовать JMS для запроса информации о пользователе из настольного приложения.
Другой вариант — предоставить простой API (REST, TCP и т.д.) В настольном приложении и сделать веб-службу взаимодействующей с настольным приложением, используя это. Опять же, вы могли бы распространить A на несколько экземпляров для масштабируемости.
Вы можете использовать ESB для преобразования вызова REST в TCP или SOAP в JMS и т.д. В основном преобразование любого в любое. Бесплатный ESB UltraESB с открытым исходным кодом [http://adroitlogic.org ] содержит много примеров и имеет небольшой вес (~ 35 МБ), поэтому «излишество» будет минимальным по сравнению с ESB, требующими более 300 МБ ресурсов