Все новости от 6 октября 2003 г.

Создание новых композитных приложений

В последнее время набирает популярность проведение интеграции еще в одном слое -- на серверах Web-приложений.

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

Серверы Web-приложений стали активно использовать в 90-х годах как промежуточный слой между СУБД и Web-серверами. Дело в том, что на создание одного подключения к СУБД требуется масса системных ресурсов, и нагрузка на сервер СУБД становится неподъемной, если к сайту, который она обслуживает, подключаются одновременно сотни или даже тысячи человек.

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

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

Сейчас они позволяют управлять транзакциями на уровне контейнеров Enterprise Java Beans (EJB), через интерфейсы Java Transaction API (JTA) создавать объекты, способные участвовать в распределенных транзакциях, вызывать транзакционные системы типа CICS и IMS при помощи Java Transaction Service (JTS), обращаться к системам гарантированной доставки сообщений через интерфейсы Java Messaging Services (JMS), подключать унаследованные платформы через коннекторы Java Connector Architecture (JCA) и, наконец, создавать Web-сервисы.

Например, Sun ONE Application Server 7 предлагает комплект средств создания и разработки Web-сервисов Java Web Services Developer Pack, включающий API Java XML, а также обеспечивающий поддержку протокола SOAP и языка WSDL.

Им поддерживаются и такие стандарты, как Java API for XML Messaging (JAXM), Java API for XML Processing (JAXP), Java API for XML Registries (JAXR), Java API for XML-based RPC (JAX-RPC). Этот продукт стыкуется с Sun ONE Message Queue, одной из самых развитых реализаций стандарта JMS.

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

Некоторые платформы интеграции на основе серверов приложений содержат средства управления бизнес-логикой. Так, BEA WebLogic Integration Platform содержит среду разработки, позволяющую описывать бизнес-процесс с позиций аналитика, манипулирующего терминами потоков данных.

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

Аналогичным образом на высоком уровне бизнес-процесс описывается и в ряде других систем -- в частности, в Oracle 9iAS это делается при помощи инструмента iStudio, входящего в состав Oracle9i Integration, а сама реализация осуществляется на основе модуля workflow.

Уровни архитектуры КИС на базе сервера приложений J2EE (модель Sun Microsystems)

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

Эти методы реализует адаптер ресурса -- компонент J2EE, "открывающий" функциональность КИС программистам на Java. Благодаря JCA вендор прикладной системы может написать один адаптер и затем использовать его в СП разных поставщиков.

Адаптер JCA взаимодействует с СП J2EE посредством системных контрактов, позволяющих распространить на унаследованную КИС контекст обращения к адаптеру.

Этот контекст включает управление соединениями (Connection management), транзакциями (Transaction management) и безопасностью (Security). При этом JCA никак не регулирует протоколы взаимодействия с КИС.

Важной особенностью JCA является то, что она (с точки зрения прикладного программиста) предлагает аналог JDBC, но только ориентированный на доступ к КИС, -- этот набор интерфейсов называется CCI (Common Client Interface).

Именно он осуществляет упомянутую выше стандартизацию. CCI предлагает набор API, предназначенный для установления связи с КИС (интерфейсы Connection), API для выполнения команд КИС (интерфейсы Interaction), интерфейсы для получения результатов запросов (Record/ResultSet) и метаданных КИС (т. е. определения типов, он называется Metadata).

Но следует иметь в виду, что у JCA есть ряд недостатков. Абсолютно все имеющиеся на сегодня серверы приложений поддерживают лишь версию JCA 1.0. А в ней не предусмотрены асинхронный механизм обращений к КИС, обращения могут исходить только в Java-объект в КИС, нет отображения (mapping) данных (оно определяется на уровне контейнера EJB через механизм Container Managed Persistence), все компоненты коннектора сосредоточены на сервере (т. е. нет стандартного способа деления на агентский и серверный компоненты), не разработан стандарт на протоколы связи между агентом со стороны КИС и серверной частью.

Иначе говоря, коннекторная архитектура серверов приложений имеет существенные ограничения по сравнению с интеграционными шинами.

Создание бизнес-процесса для BEA WebLogic Integration Platform

Многие вендоры, например BEA, пытаются решить эти проблемы за счет частных расширений. BEA WebLogic Application Server позволяет делать вызовы к КИС через асинхронные обращения JCA, а получать уведомления из КИС через очередь сообщений и механизм JMS.

Аналогичным образом действует и компания Oracle, которая предлагает в своей платформе Oracle 9iAS расширения JCA для обеспечения двунаправленных взаимодействий, асинхронной передачи сообщений и доступа к интерфейсам работы с метаданными КИС.

Кроме того, спецификация JСA 1.0 не обязывает поставщика адаптера поддерживать CCI. Он может приложить свой набор API, и даже, если адаптер поддерживает CCI, в нем могут присутствовать специфические для конкретного адаптера интерфейсы.

Тот факт, что JCA 1.0 не диктует единообразных интерфейсов CCI, оставляя их определение на откуп вендорам СП, делает адаптеры непереносимыми между серверами приложений, что не способствует популярности спецификации.

Ряд подобных ограничений должен быть устранен в JCA 2.0, сейчас находящейся в процессе утверждения и известной как JSR (Java Specification Request) 112. Она описывает интерфейсы асинхронного доступа, интеграцию JMS c JCA, слой CCI для работы с метаданными и использование XML в слое CCI.

В другой версии JCA, имеющей номер 1.5 и уже включенной в состав J2EE 1.4 (правда, она пока не поддерживается ни одним сервером приложений, даже продукт Sun Microsystems, наиболее "продвинутый" в смысле поддержки Java, опирается только на J2EE 1.3), также есть ряд расширений, например определены новые типы контрактов.

Скажем, контракт управления работой (Work Management Contract) позволяет определить, какие системные ресурсы (в частности, число потоков исполнения) можно выделить коннектору. Имеются также расширения, позволяющие инициировать транзакцию со стороны КИС с распространением контекста транзакции в сервер приложений и далее -- на другие КИС.

Стоит также учесть, что написание адаптера JCA -- очень трудоемкое дело, и если к вашей КИС на рынке нет готового адаптера, ее будет сложно интегрировать. Разумнее создать свой коннектор, используя не JCA, а какие-то другие способы, скажем, шину данных или вызовы "родного" кода.

Итак, преимущества описанного подхода в том, что с помощью сервера приложений можно создать абсолютно новое бизнес-ПО. Недостаток -- необходимость хорошего знания Java и отсутствие в СП многих возможностей, доступных пользователям MOM.