Выбор технологии для интеграции прикладных систем предприятия (EAI) - JCA, JMS или Web-сервисы?

Введение

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

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

По мере увеличения сложности информационной системы разработка должна упрощаться. Это вызывает интерес к технологии интеграции прикладных систем предприятия ( Enterprise Application Integration , EAI). При этом предприятиям приходится дополнять EAI бизнес-сервисами и гибким методом доступа к результирующей, интегрированной прикладной системе.

В настоящее время растущая потребность в гибком доступе к бизнес-сервисам и независимости клиентов удовлетворяется за счет архитектур, построенных на интерфейсах. Среди архитектур на основе интерфейса можно назвать такие технологии, как Web-сервисы , архитектура коннектора J2C J2C Connector Architecture (JCA) и сервис обмена сообщениями Java Java Message Service (JMS). Эти технологии также включают все варианты шаблонов команд, изолирующих клиентский код от реализации бизнес-сервиса. Кроме того, описанные инфраструктуры вызова можно вызвать из связующего ПО EAI, и наоборот.

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

Характеристики Web-сервисов, JCA и JMS

В этом разделе описываются указанные интерфейсные технологии и их подробные характеристики.

Web-сервисы

Web-сервис представляет собой реализацию сервис-ориентированной архитектуры (Services Oriented Architecture, SOA). Архитектура SOA состоит из трех компонентов: поставщика, брокера и инициатора запросов, слабо связанных между собой. Поставщик предлагает бизнес-сервис, представляющий собой конкретную реализацию, которая для инициатора запросов не является непосредственно видимой. Инициатор запросов получает от брокера структуру информации, которую он должен использовать для отправки и получения от поставщика, и протокол, который необходимо использовать для доступа к этому сервису. Инициатору запросов неизвестен способ реализации бизнес-сервиса поставщиком.

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

• Могут быть жестко связанными, а разработка Web-сервисов может строиться на использовании инфраструктур вызова;
• Могут выполняться либо в синхронном режиме запрос/ответ, либо в асинхронном режиме;
• Могут предоставляться поставщиками J2EE или другими поставщиками;
• Могут предоставлять или не предоставлять поддержку транзакций и безопасности.

JCA

Архитектура коннектора Java (Java Connector Architecture) удовлетворяет, главным образом, потребность в жестко связанном доступе к бизнес-логике информационной системы предприятия ( Enterprise Information Systems , EIS). Архитектура коннектора поддерживает адаптацию ресурсов, при которой безопасность, транзакции и коммуникации J2EE преобразуются в соответствующие технологии EIS.

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

Некоторые определяемые пользователями варианты коннекторов являются более сложными и работают в режиме логического подключения. Они могут демонстрировать поведение инфраструктуры вызова, выбирая соответствующее физическое назначение EIS и бизнес-операции таким же способом, как это делается в Web-сервисах.

JMS

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

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

Независимость ритмов работы. Инфраструктуры JMS работают в асинхронном режиме, но предлагают также возможность имитации синхронного режима запрос/ответ. Это дает возможность исходной и целевой системе работать одновременно, без вынужденных ожиданий противоположной системы.

Гарантия доставки информации. Инфраструктуры JMS могут управлять сообщениями в транзакционном режиме и гарантировать доставку сообщений (но никаких гарантий относительно своевременности доставки не предоставляется).

Функциональная совместимость между разнородными инфраструктурами. Исходная и целевая прикладные системы могут работать в разнородных средах, не сталкиваясь с проблемами связи и исполнения из-за особенностей противоположной инфраструктуры.

Большая гибкость обмена информацией. Переход в режим обмена сообщениями делает возможным более детализированный обмен информацией.

Выбор интерфейсных технологий

Метод, который вы уже использовали для реализации бизнес-логики в вашей системе, естественным образом поможет вам выбрать одну из технологий. Выбирая технологию, сначала проанализируйте существующую инфраструктуру. Используется ли в ней система обмена сообщениями или традиционная система, например, CICS или IMS?

Во многих случаях самым естественным способом доступа к интегрированной информационной системе предприятия (EIS) CICS или IMS является использование архитектуры коннектора Java (JCA). Напротив, если вам необходим доступ к приложениям .NET, вы, вероятно, выберете интерфейс Web-сервиса. В каких-либо иных случаях, возможно, вы решите использовать интерфейс JMS, который позволит осуществлять обмен сообщениями с небольшими ограничениями в отношении языка реализации.

Для принятия решений пользуйтесь следующими ориентирами:

У вас уже есть прикладные Java-системы или вы планируете внедрить подобную систему: используйте JMS или JCA.

Необходимо организовать взаимодействие с партнерами: используйте для транспорта и подключения Web-сервисы.

Необходимо преодолеть языковой барьер: используйте JMS или Web-сервисы.

Следующим важным для принятия решения фактором является зона сети: Интернет, интранет или экстранет. Зона определяет, какую степень гибкости вы можете себе позволить при выборе транспортного протокола. Развертывание в сети Интернет, скорее всего, потребует использования слабо связанных через протокол HTTP Web-сервисов. Это будет сеть с уже имеющимся межсетевым экраном и инфраструктурой демилитаризованной зоны (DMZ); при этом вы сможете минимизировать расходы. JMS и JCA больше подходят в качестве протоколов сетей интранет или экстранет. JMS больше подходит для асинхронного режима или имитации синхронного режима, а JCA - для более жесткой связи.

Что общего у этих вариантов?

Web-сервисы - это не синоним сервисов, предлагаемых через SOAP. Любой фрагмент кода с Web services Description Language (WSDL) можно считать описанием функций и протоколов доступа к Web-сервису. Для каждого такого сервиса можно предусмотреть доступ через несколько транспортных протоколов и протоколов прикладного уровня.

Следовательно, вы можете применить подход на основе WSDL, который описывается и реализуется инфраструктурой вызова Web-сервисов Web services Invocation Framework (WSIF). Это позволит вам объединить ваши варианты интеграции независимо от зоны сети - интранет, экстранет или интернет.

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

• Сделать доступным в различных протоколах, например, SOAP и RMI-IIOP, через нотацию привязок для входящей информации . RMI означает Java remote Message Invocation (Протокол удаленного вызова сообщений Java). IIOP (Internet Inter-ORB protocol) - это протокол CORBA для проводной связи;
• Реализовать с использованием разных типов компонентов, например компонентов на основе JCA или JMS, через нотацию привязок для исходящей информации .

В контексте этого подхода JMS и JCA представляют собой протоколы, которые поставщик сервиса может использовать для реализации бизнес-компонентов. Поэтому различные сетевые и интерфейсные технологии влияют только на нефункциональные характеристики, такие как безопасность, производительность, время отклика и доступность. Если одни и те же компоненты доступны в сетях интранет и Интернет, то эти две сети будут различаться требуемым уровнем безопасности, ожидаемым уровнем производительности и требуемой доступностью.

Использование подхода на основе WSDL для Web-сервисов предоставляет возможность отделить абстрактный интерфейс от реального стека протоколов. Этот подход можно реализовать двумя способами, каждый из которых использует WSIF:

1. При помощи IBM Web services Gateway (WSGW) можно выполнить развертывание существующих описаний WSDL и сделать их доступными через SOAP-каналы. Привязкой для входящей информации служит SOAP, а для выходящей информации - существующее описание реализации WSDL;
2. При помощи программного продукта IBM WebSphere Studio Application Developer Integration Edition (WSAD-IE) существующие описания WSDL перерабатываются и становятся доступными через модули доступа SOAP или RMI-IIOP.

Шаблоны взаимодействий

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

Управляемая событиями модель доставки данных без запроса

Модули-слушатели, ожидающие наступления событий, представляют собой стандартную модель доставки данных без запроса в зависимости от наступления событий, которая имеет особое значение в EAI. Для автоматизации бизнес-процессов часто бывает необходимо использовать перехват событий приложений для передачи данных другим интегрированным приложениям.

Стандартные слушатели для бизнес-сервисов часто используют серверы JMS или HTTP. Управляемые событиями bean-компоненты в EJB используют JMS, тогда как Web-сервисы используют HTTP.

В этой модели доставки данных без запроса доставляемые события запускают процессы. Сообщество разработчиков и пользователей Web-сервисов проделало большую работу по формализации координации (хореографии) этого процесса взаимодействия. Организацию данной последовательности событий, в частности, описывают стандарты Web services Flow Language (WSFL, язык потоков для Web-сервисов) и Business Process Execution Language for Web services (BPEL4WS, язык исполнения бизнес-процессов для Web-сервисов).

• В WSFL механизм организации потоков может выполнить новый экземпляр потока в ответ на входящее сообщение (помеченное породившей его операцией жизненного цикла). Поддержка этим механизмом одностороннего взаимодействия обеспечивает поддержку уведомлений;
• В BPEL4WS, деятельности receive (получить) или pick (выбрать) могут неявным образом запускать бизнес-процессы в ответ на входящее сообщение; деятельности pick могут выбирать процессы для выполнения на основе одного из наборов событий.

Синхронный режим запрос/ответ

На предприятии требования производительности могут диктовать выбор реализации JCA, особенно в том случае, если большая часть бизнес-логики в настоящее время размещается в существующей информационной системе предприятия (EIS). Однако коннекторы не могут быть доступными всей системе, поэтому в таких случаях единственным возможным решением может стать создание дополнительного уровня сообщений с JMS.

Обмен сообщений не является наилучшим вариантом для взаимодействий типа запрос/ответ. Реализация таких взаимодействий при помощи связующего ПО для обмена сообщениями предохраняет координацию транзакций между вызывающим и вызываемым компонентами вследствие изоляции, являющейся неотъемлемым свойством механизма обмена сообщениями. Кроме того, простоями в ожидании ответа управляет программная логика вызывающего приложения, а не предоставляемая реализация коннектора.

Асинхронная модель

Все три интерфейсные технологии - Web-сервисы, JMS и даже JCA - могут работать в асинхронном режиме. Запросы или события будут в этом случае пересылаться целевой системе; при этом ожидается получение только следующего ответа: "Сообщение было доставлено корректно." Этот стиль взаимодействий относится к типу "запустил и забыл".

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

В Web-сервисах имеется поддержка асинхронных взаимодействий, хотя инструменты обычно не приспособлены для этой ситуации. Web-сервисы на основе SOAP поддерживают не только синхронный режим взаимодействий RPC, но и асинхронный режим взаимодействий при помощи обмена сообщениями. Его основой служит документ-ориентированная модель, в которой и инициатор запросов, и поставщик должны выполнять форматирование SOAP-конвертов и синтаксический анализ.

Документ-ориентированная модель является методом реализации подлинно одностороннего взаимодействия.

Требования и соображения при выборе технологии

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

Слабая или жесткая связанность

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

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

Слабосвязанные системы могут быть организованы следующими способами:

• Посредством создания открытого контракта, описывающего отношения между потребителем/клиентом и создателем/сервером; при этом вы можете спокойно создавать и интегрировать свое приложение, не сообщая другим сотрудникам его технических деталей (и о его изменениях с течением времени). По той же причине вы можете использовать открытые контракты других разработчиков, чтобы потреблять их приложения, не вдаваясь в детали реализации;
• Посредством предоставления стека протоколов, которые будут работать с взаимодействиями без создания подключения к анонимным серверам; при этом вы сможете безопасным образом взаимодействовать с компонентами через отказоустойчивые механизмы;
• Посредством предоставления независимых от полезной нагрузки каналов связи, в частности через системы сообщений на основе брокера.

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

JCA - это технология для жесткосвязанных систем.

• JCA представляет собой стандарт J2EE, который объединяет запрос и связанную информационную систему предприятия при помощи контейнера. Контейнер представляет собой соединитель, обеспечивающий управляемую поддержку безопасности, транзакций, распространения управления подключением и взаимодействий с целевой системой;
• Соединительный интерфейс JCA строго определен через стандартный клиентский интерфейс Common Client Interface;
• Контракты для системы и компонентов контейнеров являются скрытыми от компонентов прикладных систем, но при этом они жестко связывают вызывающий компонент с вызываемым компонентом;
• Пока в JCA не решаются такие бизнес-задачи, как биллинг и аудит. Реализация этих требований остается задачей бизнес-архитектуры прикладной системы.

JMS - это метод для слабосвязанных систем. Например, JMS не предоставляет механизма безопасности или привязки транзакций к целевым системам, только к связующему ПО для обмена сообщениями. Обмен сообщениями, как правило, является слабосвязанным по следующим причинам:

• Создатели и потребители сообщения взаимодействуют через транспорт обмена сообщениями (брокер сообщений) в рамках модели издатель/подписчик;
• Технический заголовок обычно предоставляется независимо от полезной бизнес-нагрузки.

JMS хорошо подходит для следующих ситуаций:

• Интеграция систем/компонентов, являющихся участниками бизнес-событий;
• Интеграция компонентов с замедленным откликом;
• Интеграция имеющихся систем.

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

В случае Web-сервисов связанность основана и на определении интерфейса, и на привязке протоколов.

• Контракт публикуется в документе WSDL и определяет интерфейс, описывающий доступные операции;
• Для доступа к Web-сервисам могут использоваться различные протоколы. Эти протоколы называются протоколами привязки для входящей информации; они определяют механизм получения артефактов реализации;
• Способы доступа к реализации также могут быть самыми разными. Этот протокол называется протоколом привязки для исходящих сообщений; он определяет артефакт, реализующий открытый контракт. Примеры: JavaBeans, EJB и JCA.

Стиль объединения в Web-сервисах обеспечивает достаточную гибкость и предлагает два типа привязки: статическую и динамическую.

• Статическая привязка подразумевает жесткую связанность: инициатор запросов использует реализацию сервиса, полученную на этапе разработки; частные или общие реестры не используются;
• Динамическая привязанность предполагает слабую связанность: инициатор запросов обнаруживает реализацию, которую он будет использовать в качестве вызываемого сервиса, в процессе выполнения; в процессе выполнения он может даже определить вызываемый интерфейс.

В реальном мире большинство современных Web-сервисов в качестве протокола для входящей информации использует SOAP. Если не поддерживается класс сервиса, то SOAP скорее является слабосвязанным протоколом. Класс сервиса решает задачи безопасности, надежности и доступности.

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

В настоящее время для Web-сервисов доступны некоторые вспомогательные бизнес-функции, например функции биллинга и аудита.

Переносимость и функциональная совместимость

Web-сервисы не накладывают ограничений на использование языков программирования или операционных систем между вызывающим и вызываемым компонентами. Вероятно, в ближайшем будущем будут решены некоторые проблемы SOAP, например ликвидированы различия между реализацией Apache и другими реализациями. После решения этой проблемы все платформы, поддерживающие Web-сервисы, будут функционально совместимыми (включая платформы .NET и J2EE). Но даже в этом случае код клиентской или серверной реализации Web-сервиса не будет обладать переносимостью между решениями различных производителей. Код реализации, написанный для .NET, конечно, не будет работать в среде J2EE.

JMS и JCA предназначены только для Java-сред. В JCA переносимость достигается на стороне клиентского кода, а функциональная совместимость ограничивается определенной целевой платформой. JMS для обеспечения функциональной совместимости на техническом уровне необходимо наличие Java-среды на обоих концах; однако рабочая нагрузка сообщения является независимой, поэтому JMS может нести рабочие нагрузки Web-сервисов JAXM, SOAP.

Поддержка транзакций

JCA не во всех случаях обеспечивает сквозную поддержку транзакций для EIS. Как уже отмечалось ранее, поставщик коннектора реализует контейнер, который передает контекст транзакции целевым системам. Это осуществляется через контракт для систем управления транзакциями, в котором контейнер действует как диспетчер транзакций, управляющий EIS как диспетчером ресурсов. Такое поведение основано на стандарте XA (дополнительную информацию см. в разделе Ресурсы).

На данный момент Web-сервисы не обеспечивают поддержку транзакций. Разработчики стандартов работают над способами предоставления поддержки транзакций в рамках слабосвязанной модели, соответствующей стандартам WS-Coordination и WS-transaction. В будущем будут доступны и слабосвязанная модель с использованием компенсации, и жесткосвязанная модель с использованием XA-подобной модели транзакций.

В модели обмена сообщениями после доставки сообщения в очередь клиент не может контролировать его пересылку. Поэтому JMS может поддерживать транзакции только до точки входа в очередь, но не до целевого приложения.

Надежность

В настоящее время гарантия доставки обеспечивается только через JMS (хотя в отношении задержки сообщения гарантии не предоставляется). В будущем корпорации IBM, Microsoft, BEA и TIBCO планируют совместную работу по разработке стандартных механизмов для обеспечения безопасности обмена сообщениями, надежности обмена сообщениями в среде Web-сервисов. С этими стандартами можно ознакомиться на Web-сайте организации, занимающейся разработкой Web-сервисов. Надежность подключений JCA всегда будет специфичной для каждого коннектора, поэтому JCA по сути своей не предполагает обеспечения надежности.

Безопасность

Безопасность представляет собой наименее стандартизованную область. В спецификации JMS явным образом декларируется, что безопасность должна обеспечиваться реализацией поставщика JMS, которая должна соответствовать остальным стандартам J2EE. К счастью, IBM также придерживается этого стандарта. В случае JCA поддержка обеспечения безопасности будет зависеть от функций контейнера коннектора и целевой реализации информационной системы предприятия.

Поддержка HTTPS может обеспечить определенный уровень безопасности Web-сервиса на транспортном уровне. Однако после того, как Web-сервер дешифрует и аутентифицирует запрос, он оказывается уязвимым, и только некоторые реализации Web-сервисов, использующие расширения безопасности SOAP Security Extensions (SOAP-SEC), поддерживают доступный на данный момент уровень безопасности. Работы по стандартизации ведутся и для стандарта WS-Security, который в будущем должен обеспечивать полную функциональную совместимость сквозной модели безопасности.

Заключение

Как вы могли убедиться, выбор конкретной технологии интеграции - Web-сервисы, JMS и JCA - осуществляется по нескольким критериям. Сравнивая требования для конкретных решений и расставляя приоритеты для этих требований, архитекторы в каждом конкретном случае могут выбрать правильную реализацию.

В следующей таблице обобщается все, сказанное до сих пор, и подчеркиваются критерии принятия решения: