Как спроектировать сервис, который может предоставлять интерфейс в виде веб-сервиса JAX-WS, или через JMS, или как локальные вызовы методов в среде Java EE? - PullRequest
1 голос
/ 20 мая 2010

Используя типичную среду Java EE, как мне разработать и развернуть сервис, который можно назвать веб-сервисом (с интерфейсом WSDL), вызываться через сообщения JMS, или вызывается напрямую из другого сервиса в том же контейнер

Вот еще немного контекста:

В настоящее время я отвечаю за услугу (назовем это Service X) со следующим Свойства:

  • Определение интерфейса доступно для чтения человеком документ обновляется вручную.
  • Принимает запросы в формате HTTP на один URL.
  • Отправляет простые старые XML-ответы (без схемы).
  • Использует Apache для приема запросов + a собственный сервер приложений (не сервлет) или EJB), содержащий всю логику, которая работает на отдельном уровне.
  • интенсивно использует реляционную базу данных.
  • Вызывается как внутренними приложениями написано на разных языках и также небольшим количеством третьих лиц.

Я хочу (или, по крайней мере, мне сказали!):

  • Переключиться на хорошо известную (предпочтительно с открытым исходным кодом) Java EE стек, такой как JBoss, Glassfish и т. д.

  • Разделить Сервис X на Сервис A и Сервис B чтобы мы могли отключить Сервис B для технического обслуживания не влияя на Сервис А. Обратите внимание, что Сервис B будет зависеть от (то есть нужно делать запросы) Служба А.

  • Упрощение обеих услуг для третьих лиц. интегрироваться с, предоставляя как минимум стиль WS-I интерфейс (WSDL + SOAP + XML + HTTP) и, возможно, интерфейс JMS тоже. В будущем мы могли бы рассмотреть более легкий API тоже (REST + JSON? Google Буферы протокола?) Но это приятно иметь.

Дополнительные соображения:

  • При меньшем развертывании, Сервис A и Сервис B скорее всего, будет работать на той же машине, и это Казалось бы, глупо использовать HTTP или шина сообщений для общения; лучше бы они могли запустить в том же контейнере и сделать вызовы метода друг друга.

  • Обратная совместимость с существующими ad-hoc Интерфейс Service X не требуется, и мы не планирование повторного использования слишком большого количества существующего кода за новые услуги.

  • Я доволен первым контрактом (я полагаю, WSDL) или (аннотированная) разработка кода сначала.

Извиняюсь, если моя терминология немного туманна - я довольно опытный с Java и веб-программированием в общем, но мне трудно вставать ускорить все эти корпоративные / SOA вещи - это Кажется, мне есть чему поучиться! Я тоже не очень привык использовать фреймворк, а не просто писать код это вызывает некоторые пакеты, чтобы сделать вещи.

Я дошел до загрузки Glassfish, стучит простой файл WSDL и немного используя wsimport + фиктивный код, чтобы превратить его в файл WAR, который я развертывается.

1 Ответ

1 голос
/ 24 мая 2010

Страница 2 этой статьи: Архитектура Lean-сервисов с Java EE 6 говорит об использовании шаблона Facade для предоставления сервиса как удаленным, так и локальным пользователям. Я не знаком с использованием JMS, поэтому я не уверен, как это будет соответствовать.

...