Архитектура коннектора J2EE™

Интеграция Java™ приложений с существующими коммерческими приложениями

Краткое резюме
Архитектура коннектора J2EETM , как часть платформы JavaTM 2, Enterprise Edition (J2EETM)
1.3 точно определяет стандартную архитектуру, позволяющую получать доступ к
различным ресурсам EIS (Enterprise Information Systems - Коммерческих
Информационных Систем). В нее входят такие ERP-системы, как SAP R/3, основные
системы обработки транзакций (например IBM CICS), существующие приложения и
независимые системы баз данных.
На сегодняший день JDBCTM Data Access API обеспечивает Java-приложениям хорошую
интеграцию с реляционными системами баз данных. Подобным образом Архитектура
Коннектора упрощает интеграцию Java-приложений с неоднородными EIS-системами.
В данной статье описана спецификация Connector Architecture версии 1.0 на высоком
уровне, включая:

• Согласованность работы сервера приложений на основе платформы J2EE и

адаптера ресурсов EIS. При этом обеспечивается безопасность, организация
связного пула и управление транзакциями.

• Общепринятый клиентский интерфейс (Common Client Interface (CCI)) для связи

адаптера ресурсов EIS и компонентов приложения или утилит.

• Упаковка и развертывание адаптеров ресурсов в среде сервера приложений.

В спецификации Архитектуры Коннектора (Connector Architecture) содержится подробная
информация о самой архитектуре. Вы всегда сможете найти самую свежую информацию
по данной тематике на странице http://java.sun.com/j2ee/connector/.

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

Проблемы, встречающиеся при интеграции с системами EIS

При интеграции с системами EIS встречается много сложностей.

1
 • Сервера EIS очень сложны и неоднородны. Модели программирования
приложений широко варьируются между этими системами, увеличивая при этом
сложность и интенсивность интеграции приложений. Критическими являются
инструментальные средства приложения, которые могут упростить процесс
интеграции.

• Управление транзакциями и режимами безопасности усложняет интеграцию с

серверными системами EIS.

• Web-архитектуре требуется значительная масштабируемость, то есть

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

Платформа J2EE и архитектура коннектора

Архитектура коннектора адресует эти сложности напрямую. Платформа J2EE
обеспечивает компонентную модель многократного использования, используя при этом
технологии Enterprise JavaBeansTM и JavaServer PagesTM для проектирования и
развертывания многозвеньевых приложений, независящих от платформы и поставщиков.
Платформа J2EE разделяет общеизвестный подход стандартной платформы Java
«Написанное один раз работает везде™» и имеет значительную промышленную
поддержку.
Архитектура коннектора добавляет к платформе J2EE упрощенную интеграцию EIS.
Необходимо увеличить мощность платформы J2EE, включая компонентные модели,
транзакции и инфраструктуры безопасности, что позволит обратиться к проблеме EIS
интеграции.
Архитектура коннектора определяет общий интерфейс между серверами приложений и
системами EIS, реализованный в специальных адаптерах ресурсов EIS, которые
встраиваются в сервера приложений. В результате мы получаем упрощенную
коммерческую интеграцию приложения, использующую масштабируемую стандартную
архитектуру, которая преумножает преимущества платформы J2EE.

Рисунок: Использование архитектуры коннектора, где каждая EIS только записывает

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

• Поставщикам EIS нужно лишь создать один открытый интерфейс (реализованный в

адаптере ресурсов) для системы EIS. Данный адаптер ресурсов может быть
использован с любым совместимым сервером приложений J2EE и обеспечивать
стандартный интерфейс для поставщиков утилит и EAI (Enterprise Application
Integration – Интеграция Коммерческих Приложений). Поддержка единого
интерфейса сокращает ресурсы, затрачиваемые на разработку поставщиками EIS,
которые на сегодняшний день должны проектировать отдельные решения
нацеленные на индивидуальных поставщиков и проверять системы, сделанные
индивидуально, на совместимость.

• Поставщикам серверов приложений (поставщикам любых совместимых J2EE

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

• Поставщики EAI и инструментальных средств используют общепринятый

клиентский интерфейс CCI для упрощения доступа к ресурсам EIS на уровне
стандартного программного интерфейса.

• Разработчики программных компонент защищены от сложностей, возникающих

при транзакции, соединении и безопасности связи во время доступа к данным или
функциям EIS, вместо этого они могут сконцентрировать усилия на разработке
самой логики приложения.
Архитектура коннектора является продуктом программы Java Community Process™ и
осуществляет свой вклад в работу поставщиков утилит, серверов и систем EIS.

Обзор архитектуры коннектора

Архитектура коннектора реализована на сервере приложений и адаптере ресурсов EIS.
Адаптер ресурсов – это системная библиотека системы EIS, обеспечивающая ей связь.
Адаптер ресурсов аналогичен драйверу JDBC. Интерфейс между адаптером ресурсов и
EIS индивидуален для каждой EIS; им может быть и родной интерфейс такой системы.
Архитектура коннектора имеет три основных компоненты:

• Соглашения системного уровня между адаптером ресурсов и сервером

приложений.

• Общий клиентский интерфейс (CCI), который позволяет клиентским API для Java-
приложений и инструментальным средствам получать доступ к адаптеру ресусов.

• Стандартные приспособления адаптеров ресурсов для упаковки и развертывания.

3
Рисунок: Архитектура коннектора определяет системные соглашения между сервером
приложений и адаптером ресурсов. Она так же определяет клиентский API между
адаптером ресурсов и компонентами приложения. Описания данных соглашений
представлены в этой статье чуть позже.
Сервер приложений может содержать, как Web-контейнеры (обслуживающие JSP™
страницы и сервлеты), так и EJB™ контейнеры. Сервер приложений обеспечивает набор
сервисов характерной реализации. Такие сервисы включают в себя менеджер транзакций,
менеджер сервисов безопасности и механизм связного пула. Архитектура коннектора не
определяет того, как сервер приложений реализует различные сервисы.

• Поставщик сервера приложений расширяет сервер для поддержки системных

соглашений, определенных архитектурой коннектора. Системные соглашения
могут рассматриваться, как Интерфейс Поставщика Сервисов (Service Provider
Interface (SPI)). SPI обеспечивает стандартный способ для расширения контейнера
с целью поддержки связи с многочисленными системами EIS.

• Поставщик EIS (или ISV третьей стороны) создает адаптер ресурсов для EIS,
используя специальный интерфейс EIS для связи с самой системой EIS и
поддержки системных соглашений для сервера приложений. Кроме того, адаптер
ресурсов обеспечивает клиентский API под названием Common Client Interface или
просто CCI, определенный архитектурой коннектора. Инструментальные средства
приложения или компоненты приложения используют CCI для прямого
взаимодействия с адаптером ресурсов.
Адаптер ресурсов запускается в адресном пространстве сервера приложений и управляет
доступом к ресурсам EIS. Адаптер ресурсов совместимый с архитектурой коннектора
может работать с любым J2EE совместимым сервером.

Соглашения системного уровня

Архитектура коннектора версии 1.0 обеспечивает следующие системные соглашения,
которые реализуются адаптером ресурсов и сервером приложений:

• Управление соединениями

• Управления транзакциями

• Управление системами безопасности

4
В версии 1.0 данные соглашения охватывают подавляющее большинство функций для
интеграции корпоративных приложений, они включают в себя: транзакции, безопасность
и масштабируемость. В будущих версиях данной спецификации системные соглашения
будут расширены для включения в них поддержки Java Message Service (JMS) и
управления потоками. Совместимость с JMS позволит добавить поддержку для
асинхронной связи, базированной на сообщениях.
В данных параграфах представлен краткий обзор этих соглашений.

Соглашение об управлении соединениями

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

• Создания новых соединений с EIS

• Конфигурирования фэктори соединений в пространстве имен JNDI

• Нахождения требуемого соединения из существующего набора организованных

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

Соглашение об управлении транзакциями

Организация доступа транзакций к EIS является важным требованием для коммерческих
приложений. Архитектура коннектора поддерживает концепцию транзакций – число
операций, которые должны быть переданы вместе или вообще не быть переданы, для того
чтобы данные оставались согласованными и для сохранения целостности данных.
Во многих случаях транзакция (обозначенная как локальная транзакция) ограничена
отдельной EIS системой, а менеджер ресурсов EIS сам управляет такой транзакцией. Не
смотря на то, что XA транзакция (или глобальная транзакция) может охватывать многие
менеджеры ресурсов, данная форма транзакции требует координации внешним
менеджером транзакций, обычно поставляемым с сервером приложений. Менеджер
транзакций использует двухфазный протокол транзакций для управления транзакцией,
которая охватывает многочисленные менеджеры ресурсов (EIS). Однофазная оптимизация
5
используется в том случае, если в XA транзакции принимает участие только один
менеджер ресурсов.
Архитектура коннектора определяет соглашение об управлении транзакциями между
сервером приложений и адаптером ресурсов (и его основным менеджером ресурсов).
Соглашение об управлении транзакциями расширяет соглашение об управлении
соединениями и обеспечивает поддержку для управления локальными и глобальными
транзакциями. В соглашение об управлении транзакциями входит две части, в
зависимости от типа транзакции.

• Соглашение на основе JTA XAResource между менеджером транзакций и

менеджером ресурсов EIS

• Соглашение об управлении локальными транзакциями

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

• Вообще никакой поддержки транзакций – это типично для наследных приложений

и многих серверных систем.

• Поддержка только для локальных транзакций.

• Поддержка и для локальных, и для глобальных транзакций

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

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

• Идентификацию и авторизацию пользователей с целью подтверждения своей

личности.

• Авторизацию и контроль доступа для проверки прав доступа пользователя к

данному серверу приложений и/или EIS.

• Безопасность соединения сервера приложений и EIS. Связь через незащищенные

каналы может быть ограничена благодаря использованию протокола (например,

6
 Kerberos), обеспечивающего аутентификацию, чистоту информации и ее
конфиденциальность. Линию связи можно так же защитить через протокол
безопасных каналов (например SSL).
Архитектура коннектора расширяет модель безопасности J2EE с целью включения
поддержки для безопасной связи с EIS.
Соглашение об управлении безопасностью определено как независящее от механизмов и
технологий безопасности. Это позволяет серверам приложений и EIS с различными
уровнями поддержки технологии безопасности поддерживать соглашение о безопасности.
Например, соглашение об управлении безопасностью может поддерживать основную
аутентификацию, базированную на входе через пароль, или сквозную среду безопасности
Kerberos. Так же поддерживаются механизмы безопасности характерные для EIS.
Вход в систему EIS
Создание нового физического соединения требует входа в систему EIS. Изменение
контекста безопасности в текущем физическом соединении также требует подтверждения
от EIS, это считается как повторная аутентификация. Вход в систему EIS обычно влечет за
собой один или несколько шагов:

• Определение пользователя, устанавливающего физическое соединение с системой.

• Аутентификация пользователя, если он еще не аутентифицирован.

• Установление безопасного соединения между сервером приложений и системой

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

• Контроль доступа к ресурсам EIS.

Архитектура коннектора поддерживает возможность единого входа сразу в несколько
систем EIS. Преимущества единого входа применимы в приложениях, требующих доступ
к ресурсам во многих системах EIS. К примеру, приложение, обслуживающее служащих,
может открыть им доступ к записям HR и Payroll, для чего пользователям необходимо
аудентифицироваться лишь один раз.
Соглашение о безопасности расширяет соглашение об управлении соединениями для
поддержки повторной аутентификации связного пула в EIS.

Общий клиентский интерфейс

CCI определяет стандартный клиентский API для компонентов приложения. CCI
позволяет компонентам приложения и средам EAI ( Enterprise Application Integration -
Интеграции Коммерческих Приложений ) управлять взаимодействиями между
разнородными EIS, используя общий клиентский интерфейс API.
Целевыми пользователями CCI являются поставщики коммерческиъх утилит и EAI. Сами
компоненты приложений могут так же писать для API, но CCI это тот же API, только
более низкого уровня. В спецификации рекомендовано, чтобы CCI был основой для
большей функциональности, обеспечиваемый поставщиками утилит, а не программным

7
интерфейсом на уровне приложений, используемым большинством разработчиков
приложений.

Сложности Client Tool Integration

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

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

Общий клиентский интерфейс

CCI определяет удаленный интерфейс вызова функций, который фокусируется на
выполнении функций в EIS и получении результатов. CCI не зависит от конкретной EIS;
например: типы данных, характерные для EIS. Однако, CCI может управляться
специальными метаданными EIS из хранилища.
CCI позволяет приложениям создавать и управлять соединениями с EIS, осуществлять
соединение и управлять записями данных на входе, выходе или в качестве возвращенных
значений. CCI спроектирован так, чтобы быть настраиваемым соответственно архитектуре
JavaBeans и среде Java Collection.
В версия Архитектуры Коннектора 1.0 рекоммендовано, чтобы адаптер ресурсов
поддерживал CCI, как свой клиентский API, в то же время требуется, чтобы адаптер
ресурсов реализовывал соглашения системы. Адаптер ресурсов может выбрать
клиентский API из различных CCI, таких как клиентский API на основе JDBC™ API.

8
Коннекторы и JDBC™ API
Отношения между JDBC API и коннекторами должны быть видны из перспектив
соглашений приложения и системных соглашений.

• JDBC API определяет стандартный клиентский API для получения доступа к

реляционным базам данных, а CCI определяет независящий от EIS клиентский API
для EIS, не являющихся реляционными базами данных. JDBC API является
рекомендованным интерфейсом API для получения доступа к реляционным базам
данных, а CCI – это рекомендованный клиентский API для других типов EIS.

• На уровне соглашений системы Connector SPI может рассматриваться как

обобщение и расширение соглашений JDBC 2.0. Будущие спецификации JDBC
могут сравняться с Connector SPI, предлагая его как опцию с JDBC 2.0 SPI. Другой
опцией для поставщиков сервера приложений является упаковка драйверов JDBC
под соглашениями системы коннектора.

Упаковка и развертывание
Архитектура коннектора обеспечивает интерфейсы упаковки и развертывания, так что
различные адаптеры ресурсов могут легко встраиваться в совместимые сервера
приложений J2EE модульным образом.

Поставщик адаптера ресурсов разрабатывает набор Java-интерфейсов и классов, как часть

их реализации в адаптере ресурсов. Данные Java-классы реализуют характерные
соглашения Архитектуры Коннектора и EIS-функциональность, обеспечиваемые
адаптером ресурсов. Разработка адаптера ресурсов может также потребовать
использование родных библиотек, характерных для основных EIS.
Java-интерфейсы и классы упакованы вместе (включая родные библиотеки, файлы
помощи и другие полезные ресурсы) с дескриптором развертывания, что позволяет
создать Модуль Адаптера Ресурсов. Дескриптор развертывания определяет соглашение
9
между поставщиком адаптера ресурсов и разработчиком для развертывания адаптера
ресурсов.
Модуль адаптера ресурсов может быть развернут как общий, уединенный модуль или
упакованный как часть J2EE приложения. Во время развертывания распаковщик
инсталлирует модуль адаптера ресурсов на сервере приложений, после чего
конфигурирует его в целевую операционную среду. Конфигурация адаптера ресурсов
основана на его свойствах определенных в дескрипторе развертывания, как часть модуля
адаптера ресурсов.

Архитектура коннектора и Интеграция Коммерческих Приложений

(Enterprise Application Integration)
Для иллюстрации потенциальных преимуществ Архитектуры Коннектора в данном
разделе представлены два сценария, показанные с различных позиций.

Интеграция EIS с многочисленными утилитами и серверами

Поставщики программного обеспечения обеспечивают систему ERP ориентированную на
промышленные компании средних масштабов. Такие клиенты начинают проектировать
многоярусные Java-приложения, где им требуется тесная интеграция между этими
приложениями и системой ERP поставщика.
Хотя поставщики ERP и могут публиковать API, не все поставщики серверов приложений
его поддерживают. Так же пользователи системы ERP используют различные сервера
приложений, представляющие потенциальную логическую проблему для поставщиков
ERP.
Вместо того чтобы проектировать или сертифицировать интерфейсы для каждой системы,
поставщики ERP создают единый адаптер ресурсов, используя для этого Архитектуру
Коннектора. Этот адаптер ресурсов реализует определенные соглашения о соединении,
безопасности и транзакциях Архитектуры Коннектора. Затем поставщик делает этот
адаптер доступным и информирует клиентов о том, что они могут работать с любым
совместимым сервером приложений J2EE. Поставщик ERP так же реализует CCI в своем
адаптере ресурсов, открывая доступ непосредственно к компонентам клиентов или
большому диапазону утилит разработки приложений или EAI.
Использование Архитектуры Коннектора значительно уменьшает силы, затрачиваемые
поставщиками ERP на разработку, позволяя осуществлять непосредственную интеграцию
и сопутствующие операции с большим множеством утилит и серверов приложений
совместимых с J2EE.

Коммерческое решение B2B (Business-to-Business)

Следующий сценарий иллюстрирует использование Архитектуры Коннектора в Business-
to-Business поддержке звеньевого решения.
Корпорация Wombat является производителем, реализующим решение для электронной
коммерции В2В, которое улучшает взаимодействия со своими поставщиками. Как
большинство поставщиков, Wombat имеет громадные инвестиции в свои EIS системы,
включая систему ERP и серверную систему обработки транзакций.

10
Wombar покупает J2EE совместимый сервер приложений (в данном примере он носит
название сервер B2B), который поддерживает взаимодействия с многочисленными
покупателями/поставщиками, используя XML и HTTL/HTTPS. Wombat интегрирует
доступ к своим EIS системам используя для этого готовые адаптеры ресурсов, которые
встраиваются в сервер B2B. Wombat может развертывать столько адаптеров ресурсов,
сколько у него есть систем EIS для интеграции. Сервер приложений может встраивать
многочисленные адаптеры ресурсов для систем, требуемых приложением.
Данный сценарий иллюстрирует важный аспект: архитектура коннектора была создана
для реализации тесной интеграции, обычно в пределах корпорации. Операции между
различными компаниями, например промышленная компания и ее поставщик, обычно
слабо связаны между собой. В этом случае более уместно использовать XML.

Эволюция архитектуры коннектора

Архитектура коннектора является продуктом программы Java Community Process, это
открытый процесс, используемый сообществом Java для разработки и проверки Java
технологии и спецификаций. Партнерами Sun в работе по данному направлению являются
поставщики EIS, поставщики инструментальных средств и поставщики EAI. Главными
участниками проекта являются BEA, Fujitsu, IBM, Inline, Inprise, iPlanet, Motorola, Oracle,
SAP, Sybase, Tibco, и Unisys. На данный момент идет проверка промышленной поддержки
данного стандарта, так как все заинтересованные стороны хотят извлечь как можно
больше выгоды из этого нововведения.
Спецификация архитектуры коннектора версии 1.0 не относится ко всем интерфейсам и
системным соглашениям, которые могут быть потенциально востребованы. Целью версии
1.0 было удовлетворить самые острые нужды таким образом, чтобы ускорить
промышленное внедрение этого стандарта. Например, версия 1.0 точно определяет три
соглашения на системном уровне, описанные выше. Это обязательные компоненты
интерфейса. Будущие соглашения системного уровня могу адресовать управление
потоками и передачу сообщений через Сервис передачи сообщений (Java Message Service
JMS).
Общий клиентский интерфейс (CCI) является опциональным (не обязательным) в
реализации 1.0. Архитектура Коннектора не адресует выход мета-данных для
представления данных и соответствия типов, что конечно же будет важным в случае
использования CCI. На выходную информацию безусловно будет обращено внимание в
следующих версиях.

Краткое резюме
Так же как JDBC API расширяет платформу Java для интеграции с реляционными базами
данных, Архитектура Коннектора расширяет платформу J2EE для интеграции и
расширения систем EIS, которые управляют ценными процессами и данными в
корпорации. Архитектура коннектора позволяет осуществить масштабируемый и
упрощенный доступ к ценным коммерческм ресурсам без потерь в целостности данных
или безопасности в системах EIS.

11