Технологии интеграции информационных систем на предприятии: OLE, CORBA, Web-решения и др

Web-cервисы

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

Если говорить кратко, web-сервис - это совокупность открытого интерфейса, кода реализации и служебного ПО, которая позволяет  осуществлять обмен данными с  веб-сервисом на базе XML-сообщений.

Технология web-сервисов, соответственно, включает в себя как стандарты обмена сообщениями на основе XML (SOAP), так и стандарты описания и публикации самих интерфейсов web-сервисов на базе все того же XML (WSDL, UDDI).

Как уже было сказано, XML, предоставляя собой оболочку над уже существующими системами, обеспечивает высочайший уровень абстракции. Web-сервисы – это шлюзы, через которые могут сообщаться различные по своей реализации и архитектуре приложения. Фактически, web-сервис полностью абстрагируется от реализации, представляя средства для надстройки над любой системой и оставляя лишь понятный и доступный интерфейс. В силу мощи XML-технологий, обобщение данных на базе XML в каждом конкретном случае может быть произведено без каких бы то ни было проблем. Считается, что web-сервис стал существенным шагом на пути от конкретики реализации в сторону абстрагирования. И, благодаря консорциуму W3C и усилиям отдельных поставщиков ПО, уже сложился ряд общепринятых стандартов, обеспечивающих каркас этой технологии.

Основой транспорта данных между web-сервисами стал стандарт SOAP (Simple Object Access Protocol). Он определяет общий формат XML-сообщений для передачи данных и поддерживает два традиционных способа вызова функционала web-сервиса - это RPC и обмен сообщениями, которые на самом деле отличаются идеологией XML-представления типов данных. Обмен сообщениями основывается на XML Schema и не имеет никаких ограничений на структуру сообщения, а RPC основан на формальной структуре сообщений запроса и ответа. Сейчас RPC постепенно вытесняется методикой обмена сообщениями, как более гибкой и не накладывающей на разработчика ограничений. В рамках этого протокола web-сервис идентифицируется своим URI (Uniform Resource Indicator), который, по сути, является псевдонимом вызываемой службы, а в рамках RPC-подхода еще и определяет NS (NameSpace) документа по умолчанию.

Также мы должны быть уверены в том, что наши сообщения  будут правильно поняты. Ведь в  силу гибкости XML формат сообщений, которые  ожидают различные сервисы, может  быть совершенно разным. Для этой цели был создан язык WSDL (Wev Services Description Language), который представляет собой типичный XML-подобный язык «под задачу». WSDL-файл содержит полное описание всего того, что можно послать сервису и получить от него в ответ, т.е. для правильного взаимодействия с сервисом обе стороны должны иметь WSDL-файл, который гарантирует, что стороны будут разговаривать на одном языке, строя «грамматически» верные предложения.

Если доступ к web-сервису планируется дать вовне, а не использовать его только для  нужд внутрикорпоративной интеграции, то встает вопрос о необходимости публикации данных о нем в рамках какого-нибудь глобального реестра. Эту задачу призван решать, к примеру, проект UDDI (Universal Description, Discovery and Integration), разработанный консорциумом OASIS (www.oasis-open.org), который предоставляет собственные интерфейсы для регистрации и поиска сервисов (подробнее - на www.uddi.org).

Web-системы хранения данных

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

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

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

Задача удобного и дешевого обеспечения доступа  к данным Хранилища из броузера решена в Web-системе путем создания нескольких относительно независимых слоев.

Рисунок – WEB-система хранения данных.

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

2. Слой бизнес-объектов. Web-система основано на особенностях самого хранилища. Система предназначена для хранения деловой и финансовой информации и содержит в себе предопределенные классы бизнес-объектов. Это: Субъекты (клиенты, партнеры, сотрудники), Организационно-штатная структура (филиалы, департаменты, отделы, штатные должности), Бизнес-операции (финансовые, хозяйственные, организационные операции), Документы (произвольные формы документов, портфели документов, многостраничные и табличные документы), Счета и показатели (произвольное количество планов бухгалтерских счетов и наборов финансовых показателей подразделений, автоматическая консолидация учетных данных корпорации) и т.д.

Библиотека прикладных классов ACL (Application Class Library) является объектной  оболочкой над реляционными таблицами  и хранимыми процедурами СУБД. Она описывает все классы объектов, которые могут существовать в Хранилище. Каждый конкретный объект является воплощением одного из классов библиотеки и имеет свойства - сами данные и методы - действия над ними. Эта библиотека является центральным звеном решения. При ее помощи очень легко загрузить или получить любые данные хранилища, даже если структура хранилища непрерывно развивается.

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

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

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

Классы метаданных библиотеки ACL позволяют создавать  динамические интеллектуальные страницы.

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

3. Слой доступа. Существуют возможности доступа к бизнес-объектам для платформ Windows NT(IIS) и UNIX(Apache и т.д.):

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

Вариант 2. Использование  в качестве скриптового языка- Python , который очень для этого удобен. Кроме того именно на Python реализована  библиотека ACL и программист получает непосредственный доступ к ее объектам.

Вариант 3. Применение специально разработанного Java-скрипт для передачи XML-запросов к библиотеке ACL и получения от нее XML-ответов.

4. Слой транспорта. Запросы к Хранилищу, полученные  данные и служебная информация перемещается между слоем интерфейса и слоем доступа в виде XML-документов.

5. Слой интерфейса. Интерфейс создается дизайнером  сайта как совокупность страниц,  обращающихся к объектам на  языке XML. При этом доступны  все данные Хранилища, но не требуется знание его физической структуры. Никакое изменение структуры данных не приводит к необходимости изучения новых схем таблиц, или изменения существующих страниц, за счет изоляции базы данных при помощи библиотеки XML.

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

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

Классификация технологий интеграции

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

1) Системы интеграции  корпоративных приложений (Enterprise Applications Integration, EAI) — технологии, ориентированные на решение проблем интеграции различных систем, приложений и данных внутри отдельной организации. Иногда для этих технологий используется аббревиатура A2A (Application-to-Application — приложение-приложение).

2) Системы интеграции  между организациями Business-to-Business (Business-to-Business Integration, B2Bi) — технологии, ориентированные на обеспечение безопасного, надежного информационного обмена между различными организациями и их информационными системами. Эти технологии обеспечивают пересылку информации за пределы сетевых экранов (firewall) и дают возможность автоматизировать бизнес-процессы в рамках «расширенных организаций», которые включают поставщиков, партнеров, потребителей продуктов и услуг и т. д.

3) Технологии  управления бизнес-процессами (Business Process Management, BPM), являющиеся результатом естественной эволюции классических систем документооборота и делопроизводства (workflow systems) и систем класса EAI и B2Bi. Традиционные системы управления документами ориентировались в основном на пересылку информации между людьми, выполнявшими определенные действия. В отличие от технологий B2Bi, которые ориентированы на интеграцию данных в межведомственной среде, технологии BPM интегрируют данные, приложения и людей через единые бизнес-процессы. Это отражает современную точку зрения, что основой интеграции должны быть бизнес-процессы. Причина здесь состоит в том, что бизнес-процессы организации «пересекают» границы различных приложений, департаментов и организаций.

Следующая таблица  показывает разницу между упомянутыми  классами систем.

Традиционные  технологии интеграции корпоративных  приложений EAI и межворганизационной интеграции B2Bi основаны на использовании так называемого брокера (узла пересылки, шлюза) сообщений. Технологическим фундаментом брокера сообщений является, как правило, программное обеспечение промежуточного слоя пересылки сообщений (Messaging-Oriented Middleware, MOM), которое обеспечивает транспорт доставки информации и данных между прикладными системами. Примером такого программного обеспечения является «сервер очередей сообщений» MSMQ (Microsoft Message Queuing). Продукты этого класса обеспечивают транспорт гарантированной доставки сообщений между приложениями в территориально распределенной среде. Подход к интеграции приложений на основе продуктов класса MOM стал стандартным в области интеграции корпоративных информационных систем в конце 90-х годов.

Базовая идея этой технологии заключается в следующем. Пусть имеется несколько приложений, связанных некоторой коммуникационной средой, но, возможно, не очень надежной. Одно приложение (например, система документооборота A) должно переслать информацию/документ другому приложению (системе документооборота B). Система A передает документ серверу пересылки сообщений и «забывает» о нем. Сервер пересылки сообщений обеспечит гарантированную и однократную доставку информации в систему B.

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

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