Глава 2 архитектуры взаимодействия

Java Business Integration

JBI определяет архитектуру, которая позволяет конструировать интеграционные системы с гибкой структурой. Основа такой системы – промежуточная среда, позволяющая обмениваться сообщениями. Модель обмена сообщениями основана на языке описания веб-сервисов WSDL 2.0 [2].

Рисунок 1 Архитектура динамического подключения JBI

Рисунок 1 показывает концепцию динамического подключения (plug-in) JBI на абстрактном уровне. JBI предоставляет определенные интерфейсы для механизма plug-in. Компоненты не взаимодействуют напрямую друг с другом, а пользуются механизмом, ориентированным на работу с сообщениями, описанный с помощью стандартного языка. Это все составляет самодостаточную модель взаимодействия сервисов, которая позволяет подключать и вызывать компоненты.

Все сообщения, которые используются для обмена информацией, описаны с помощью WSDL версии 1.1 или 2.0 [3]. WSDL основан на декларативной модели обмена сообщениями, которая базируется на двух уровнях:

· Модель абстрактного сервиса. Сервис определен как абстрактная модель обмена сообщениями, без указания определенного протокола или формы передачи данных.

·   Конкретная модель. Абстрактный сервис связывается с определенным протоколом и способом представления данных.

JBI использует модель абстрактного сервиса, как основу взаимодействия компонентов. Компоненты могут играть одну из двух ролей:

· Поставщик Сервиса. Компонент выполняет заданный сервис (либо напрямую, либо как прокси для внешнего провайдера);

·   Потребитель Сервиса. Компонент, который вызывает данный сервис (либо напрямую, либо как прокси для внешнего потребителя).

Существует несколько имплементаций, которые выполнены на основе JBI стандарта: OpenESB, Apache ServiceMix, Mule, OW2 PEtALS.

SPCoop

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

Рисунок 2 Компоненты SPCoop

Модель, предложенная SPCoop, основывается на следующих принципах: [4]:

· ГУ взаимодействуют при помощи и посредством сервисов приложений; эти сервисы предлагаются через уникальный (логический) элемент, принадлежащий к его собственной информационной системе – Шлюз Домена (Domain Gateway). В этом случае полная автономия каждой администрации гарантирована. Что касается разработки и управления предлагаемых сервисов, то они могут быть основаны на любой платформе, созданы с нуля или усовершенствованы. Вызов сервисов приложений проводится посредством обмена сообщениями, основанных на стандарте, известным как электронный конверт (e-Gov Envelop). Такой стандарт представляет собой расширение SOAP;

· Сервис работает на основании соглашения между двумя субъектами (поставщик и клиент); такое соглашение имеет под собой как техническую основу, так и юридическую силу. Соглашения должны быть формализованы для того, чтобы обеспечить разработку и жизненный цикл сервисов в (полу-)автоматическом режиме. Спецификация соглашения называется Соглашение Сервисов (Service Agreement) и основывается на языке XML.

· Несколько администраций, которым необходимо кооперировать друг с другом для предоставления составного сервиса, образуют Домен Кооперации (Cooperation Domain); сервисы, поддерживаемые таким доменом, внешне описаны с помощью Соглашения Сервисов, и внутренне - Соглашением Кооперации.

Для того, чтобы поддержать выше изложенные принципы SPCoop имеет следующие компоненты:

· Хранилище Соглашений это программный компонент, используемый для регистрации и поддержки Соглашения Сервисов\Кооперации. Он может быть рассмотрен, как база данных для кооперации. Хранилище Соглашений предлагает функционал по регистрации, доступу, обновлению и поиску соглашений. Основанием данного хранилища является UDDI (Universal Description, Discovery and Integration) стандарт, однако данный стандарт не имеет полного набора требуемого функционала, вследствие чего он был программно расширен;

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

· Федеративное Управление Паролями используется для авторизации и контроля доступа к сервисам приложений SPCoop; федеративное управление необходимо для повторного использования паролей региональных и национальных уровней. Интеграция реализована через SAML (Security Assertion Markup Language) v2.0.

· Сервис Мониторинга служит для наблюдения за тем, как различные сервисы соблюдают Соглашения Сервисов. Ее разработка запланирована на будущее (таким образом, она не была включена в текущую версию).

Соглашение сервисов это точно определенный XML документ, который регламентирует отношения между поставщиком и клиентов в следующих аспектах:: (i) интерфейс сервиса, (ii) диалоги, поддерживаемые сервисом, (iii) точку доступа, (v) Уровень Соглашения Сервиса, (v) характеристики безопасности и (vi) семантическое описание сервиса. Формальная и четко заданная природа соглашения сервисов была сделана для поддержки разработки и функционирования сервисов в (полу-)автоматическом режиме. Более того, открытая архитектура соглашения сервисов делает проще разработку доменных онтологий, которые позволяют объединить сервисы со схожей семантикой. Наконец, в контексте набора государственных учреждений, сервисы могут быть соединены и организованы, образовывая другие сервисы с помощью соглашений.

Соглашение Сервисов описывает двухсторонние отношения с целью предоставления и вызова сервисов. Множество административных процессов не могут ограничивать использованием ресурсов одной администрации, и поэтому вовлекают в свои процессы другие. Домен Кооперации – формализации желания различных субъектов объединиться для образования композиционного сервиса, который позволит автоматизировать административные процессы. Внутри Кооперационного Домена можно выделить ответственного координатора, задачей которого является координация вовлеченных субъектов, а также композитных приложения, образованных посредством Домена Кооперации. Домен Кооперации можно рассматривать как проводник сервиса, действующий как обычный домен какой-либо администрации. Главное различие в способе, которым эти сервисы были спроектированы и разработаны: в Домене Кооперации они построены композицией и интеграцией простых сервисов, предложенных вовлеченными администрациями, тогда как для обычного домена поддержка сервиса полностью связана с приложением, которое полностью под контролем одной администрации.