Sun ЕРС Information Server предоставляет доступ к значимым бизнес-собы­тиям, сгенерированным Sun ЕРС Event Manager. Кроме того, он служит объ­единяющим слоем архитектуры, который предлагает несколько способов интеграции Sun ЕРС Event Manager с существующей КИС или корпоратив­ными продуктами внутренней разработки. Прямое подключение слоя Sun ЕРС Event Manager к приложениям уровня предприятия может привести к появлению в компании «информационного мусора». Задействовав Sun ЕРС Information Server в роли посредника между Sun ЕРС Event Manager и при­ложениями заднего плана, вы добьетесь максимально возможной гибкости при смене требований самого бизнеса или замене корпоративных систем. Применение программных средств и интерфейсов программирования в со­ставе Java Enterprise System позволит разработчикам быстро и гибко инте­грировать данные ЕРС в приложения организации.

Данные из Sun ЕРС Event Manager поступают в Sun ЕРС Information Server, где хранятся и откуда, сохраняя свою непротиворечивость и целостность, доступны любому приложению, которое в них нуждается. Этот подход повы­шает надежность и гибкость системы в целом при сокращении издержек со­провождения и поддержки. Также сервер является удобной точкой соотнесе­ния событий ЕРС и бизнес-логики фирмы. Еще одно преимущество состоит в том, что Sun ЕРС Information Server может использоваться в целях реали­зации дополнительных функций, например, смены формата данных и орга­низации их хранения.

Java System Application Server предоставляет три варианта интеграции с КИС, то есть подключения к ней сервера Savant, по принципу «точка — точка»:

• J2EECA;

• асинхронные сообщения с гарантированной доставкой по Java Message Service;

• собственную поддержку веб-сервисов.

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

При работе с J2EE СА собственная или промышленно выпускаемая кор­поративная система тесно связана с приложением. Это значит, что посред­ством технологии JDBC запрос в адрес КИС может быть сделан во многом так же, как запрос к базе данных. С точки зрения использующих архитектуру J2EE СА веб-приложений или веб-сервисов, КИС выглядит как локальный ресурс — знакомая парадигма, упрощающая ведение разработки. В дополне­ние Java System Application Server может решать такие задачи по обслужива­нию базовой программной системы, как создание связного пула, поддержка служб безопасности и обработка транзакций.

Недостаток тесной интеграции в том, что нередко ее применение неоп­равданно. Так, выполнение обновлений в КИС, в отличие от баз данных, может занять довольно долгое время. К примеру, объединение с системой заказов поставщикам может потребовать вмешательства оператора перед получением отклика на заказ, а это потенциально означает необходимость держать соеди­нение открытым несколько дней. Если подключения не закрываются на про­тяжении длительного периода, более уместно слабое связывание с отправкой и построением очереди из сообщений, передаваемых в КИС асинхронно.

Для нужд слабосвязанной интеграции очередь сообщений Java System Message Queue, входящая в состав Java System Application Server, реализует стандартный асинхронный JMS-механизм гарантированной доставки сооб­щений, предназначенный для стыковки веб-приложений или веб-сервисов с корпоративной средой Message-Oriented Middleware (MOM). Он позволяет приложениям Java Enterprise System вести обмен сообщениями с КИС.

Третий вариант интеграции — поддержка платформой собственных Web - служб, в силу своей природы легко пересекающих программные и аппарат­ные границы, а потому прекрасно подходящих для решения задач объедине­ния компонентов. Поскольку КИС и веб-сервис, выполняемый на сервере Java System Application Server, воспринимают друг друга в виде веб-сервисов, они могут взаимодействовать, используя такие стандарты, как протокол Simple Object Access Protocol (SOAP), язык Web Services Description Language (WSDL) и система Universal Description, Discovery, and Integration (UDDI).

Эти подходы обеспечивают гибкие возможности интеграции КИС с сер­верами Savant по принципу «точка — точка» с учетом узко обозначенной, а то и единственной цели. Чтобы связать вместе несколько корпоративных систем, используя ранее описанные способы интеграции, разработчик может встроить логику рабочих процессов в способный управлять параметрами своего состояния компонент сессии Enterprise JavaBeans (EJB) или в сервлет. Если бизнес-процесс компании прямолинеен и довольно статичен, этот под­ход является превосходным.

Тесная интеграция. Как было сказано выше, J2EE СА описывает стандартную архитектуру подключения платформы J2EE к разнородным корпоративным системам и заказным приложениям. Также СА решает ключевые проблемы и позволяет соблюсти важнейшие требования по интеграции КИС, описывая набор масштабируемых и безопасных транзакционных механизмов стыков­ки таких систем с контейнерами служб и корпоративными приложениями.

Благодаря совместной работе контейнера служб, коннектора (а также кор­поративной ИС) все системные механизмы удаленного доступа, обслуживания транзакций, поддержания безопасности и создания связного пула могут с помощью J2EE СА сохранять свою прозрачность для приложения. Архитек­тура J2EE СА реализует прямую интеграцию Sun ЕРС Information Server с корпоративной системой, в результате которой возникает их сильное связы­вание, способное обеспечить высокую производительность и надежность. Слабая интеграция. Средством реализации асинхронной службы сообщений с гарантированной доставкой является Java System Message Queue, которая координирует работу следующих основных компонентов:

• объектов администрирования,

• клиента времени выполнения,

• службы Java Message Service.

Объекты администрирования. Объекты администрирования инкапсули­руют характерные для конкретных поставщиков сведения, относящиеся к ре­ализации и конфигурированию, в объектах, используемых клиентскими при­ложениями. Эти объекты создаются и конфигурируются администратором, хранятся в службе имен; доступ же к ним клиентских приложений ведется через стандартный код просмотра Java Naming and Directory Interface (JNDI), после чего работа идет в независимом от поставщика системы ключе.

Java System Message Queue предоставляет два типа объектов админист­рирования: ConnectionFactory и Destination. Оба содержат специфичные данные поставщиков, однако, совершенно по-разному используются при­ложениями клиентов. Объекты ConnectionFactory служат для создания под­ключений к Java Message Service, объектом же Destination идентифицирует физический адресат. Объекты администрирования упрощают контроль и управление службой сообщений в силу того, что для контроля поведения подключений можно потребовать, чтобы для доступа к предварительно скон­фигурированным объектам ConnectionFactory клиентские приложения поль­зовались функциями просмотра JNDI API.

Распространением физических адресатов можно управлять, требуя от приложений-клиентов обращения лишь к тем объектам категории Destina­tion, которые соответствуют имеющимся физическим адресатам. Подобное соглашение обеспечивает тонкий контроль над конфигурацией Java Message Service и в то же время позволяет клиентским приложениям не зависеть от фирмы-поставщика. Так, они вовсе не обязаны знать конкретный синтаксис, правила именования объектов или свойства конфигурации, которые пред­лагает производитель.

Клиент времени выполнения. Выступая в роли второго главного компо­нента системы отправки и получения сообщений, клиент времени выпол­нения (Client Runtime) предоставляет клиентским приложениям интерфейс к службе Java Message Service, предлагая объекты для программирования под ней. Он поддерживает все необходимые действия для отсылки адресатам сообщений клиента и получения ответных сообщений от них.

Java Message Service. Служба Java Message Service реализует базовую функ­циональность асинхронной системы сообщений с гарантированной достав­кой и содержит следующие важнейшие компоненты:

• Брокер. Обеспечивает работу службы доставки сообщений в рамках системы. Сама доставка при этом базируется на нескольких вспомо­гательных компонентах, которые имеют дело со службами поддержки соединений, маршрутизацией и доставкой сообщений, живучестью архитектуры, безопасностью и журнализацией операций. В конфигу­рации Java Message Service может использоваться один или несколько брокеров.

• Физический адресат. Доставка сообщения — процесс, производимый в две фазы: осуществляемая брокером доставка со стороны клиента-от­правителя физическому адресату письма и следующая за ней доставка письма от физического адресата одному или нескольким клиентам — получателям сообщения. При этом физические адресаты представляют собой участки физической памяти и устройств постоянного хранения брокера.