По дисциплине: ” Автоматизированные системы управления предприятием” Технологии интеграции информационных систем на предприятии: ole, corba, Web-решения и др - Реферат

Федеральное государственное образовательное учреждение высшего профессионального образования

«СИБИРСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

Институт космических и информационных технологий

Кафедра «Системы автоматики, автоматизированное управление и проектирование»

Реферат

По дисциплине: ” Автоматизированные системы управления предприятием”

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

Руководитель С.В. Ченцов

Студент группы ПУ06-02 Д.А. Тюхтев

Красноярск 2010

Содержание:

Введение ……………………………………………………………………………………..3

Взаимодействие подсистем………………………………………………………………….4

Основные стандарты поддержки промежуточного программного слоя OMG OMA.….5

Технология CORBA…………………………………………………………………………5

Object Management Architecture……………………………………………………………..8

Object Request Broker…………………………………………………………………….….8

Microsoft DCOM/COM+…………………………………………………………………….11

OLE……………………………………………………………………………………….…..13

Интеграция в Web……………………………………………………………………………18

XML…………………………………………………………………………………….…….18

Web сервисы…………………………………………………………………………………..19

Web – система хранения данных……………………………………………………………20

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

Microsoft.NET как платформа интеграции…………………………………………………29

Список использованных источников сети Internet……………………………………….30

Введение

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

Основная сложность построения многослойных систем заключается в разнообразии платформ реализации различных слоев. За последние 30 лет развития этой области человеческой деятельности создано огромное количество программ, немалая часть которых до сих пор играет жизненно-важную роль в информационном обеспечении процессов, происходящих и в мелких частных фирмах и в крупных мультинациональных корпорациях. 15-20 лет назад основной аппаратной платформой для программного обеспечения были мэйнфремы, языком программирования COBOL, а СУБД IMS.

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

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

Взаимодействие подсистем.

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

Возникает проблема интеграции с современными ИС. Вытекающий логически более общий вопрос взаимодействия подсистем сам по себе весьма интересен.

Взаимодействие подсистем базируется на трех принципах:

1) Идеология открытых систем, которая позволяет интегрировать ПО разных производителей. Требования к открытой информационной системе:

отсутствие ограничений по стандартам входящих и выходящих потоков

инвариантность относительно технологий описания системы

отсутствие ограничений с точки зрения эволюции системы

гибкость и самоадаптацию при взаимодействии с другими большими системами и информацией различной природы.

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

2) Создание промежуточного программного слоя как основной метод интеграции ИС. Промежуточный слой (Middleware) - слой программного обеспечения , который расположен между операционной системой и средствами управления компьютерными сетями снизу и прикладными системами сверху. В 7-уровневой модели ISO/OSI это находится на 6-7 уровнях (представления и прикладного).

3) Архитектура распределенных компонентов-объектов как продолжение идеи промежуточного программного слоя.

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

Основные стандарты поддержки промежуточного программного слоя

OMG OMA

Потребность в создании единых промышленных стандартов промежуточного программного слоя стала одной из основных причин создания консорциума Object Management Group (OMG). Этот консорциум был основан в апреле 1989 года 11 компаниями, среди которых 3Com Corporation, American Airlines, Canon, Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems и Unisys Corporation. На сегодняшний день его членами является более 800 компаний, среди которых такие гиганты ИТ-индустрии как IBM, Oracle, Microsoft.

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

На этой иделогической платформе была разработана спецификация OMA - Object Management Architecture (Архитектура Управления Объектом). Ее ключевыми составляющими являются:

CORBA (Common Objects Request Broker Architecture - общая архитектура объектных запросов) - отвечает за базовые механизмы взаимодействия объектов в сети

Object Services (Объектные сервисы) - системные службы для поддержки разработки приложений

Common Facilities (универсальные средства) - поддержка пользовательских приложений

Application Objects (Объекты Приложений) - собственно прикладные приложения

Технология CORBA.

Введение в CORBA

В конце 1980-х и начале 1990-х годов многие ведущие фирмы-разработчики были заняты поиском технологий, которые принесли бы ощутимую пользу на все более изменчивом рынке компьютерных разработок. В качестве такой технологии была определена область распределенных компьютерных систем. Необходимо было разработать единообразную архитектуру, которая позволяла бы осуществлять повторное использование и интеграцию кода, что было особенно важно для разработчиков. Цена за повторное использование кода и интеграцию кода была высока, но ни кто из разработчиков в одиночку не мог воплотить в реальность мечту о широко используемом, языково-независимом стандарте, включающем в себя поддержку сложных многосвязных приложений. Поэтому в мае 1989 была сформирована OMG (Object Managment Group). Как уже отмечалось, сегодня OMG насчитывает более 700 членов (в OMG входят практически все крупнейшие производители ПО, за исключением Microsoft).

Задачей консорциума OMG является определение набора спецификаций, позволяющих строить интероперабельные информационные системы. Спецификация OMG -- The Common Object Request Broker Architecture (CORBA) является индустриальным стандартом, описывающим высокоуровневые средства поддерживания взаимодействия объектов в распределенных гетерогенных средах.

CORBA специфицирует инфраструктуру взаимодействия компонент (объектов) на представительском уровне и уровне приложений модели OSI. Она позволяет рассматривать все приложения в распределенной системе как объекты. Причем объекты могут одновременно играть роль и клиента, и сервера: роль клиента, если объект является инициатором вызова метода у другого объекта; роль сервера, если другой объект вызывает на нем какой-нибудь метод. Объекты-серверы обычно называют "реализацией объектов". Практика показывает, что большинство объектов одновременно исполняют роль и клиентов, и серверов, попеременно вызывая методы на других объектах и отвечая на вызове извне. Используя CORBA, тем самым, имеется возможность строить гораздо более гибкие системы, чем системы клиент-сервер, основанные на двухуровневой и трехуровневой архитектуре [6].

IDL

Язык OMG IDL (Interface Definition Language -- Язык Описания Интерфейсов) представляет собой технологически независимый синтаксис для описания интерфейсов объектов. При описании программных архитектур, OMG IDL прекрасно используется в качестве универсальной нотации для очерчивания границ объекта, определяющих его поведение по отношению к другим компонентам информационной системы. OMG IDL позволяет описывать интерфейсы, имеющие различные методы и атрибуты. Язык также поддерживает наследование интерфейсов, что необходимо для повторного использования объектов с возможностью их расширения или конкретизации.

IDL является чисто декларативным языком, то есть он не содержит никакой реализации. IDL-спецификации могут быть откомпилированы (отображены) в заголовочные файлы и специальные прототипы серверов, которые могут использоваться непосредственно программистом. То есть IDL-определенные методы могут быть написаны, а затем выполнены, на любом языке, для которого существует отображение из IDL. К таким языкам относятся C, C++, SmallTalk, Java и Ada.

Рисунок 5: CORBA IDL отображения в модели Клиент/Сервер

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

Структура CORBA IDL файла выглядит следующим образом:

module <identifier> {

<type declarations>;

<constant declarations>;

<exception declarations>;

interface <identifier> [:<inheritance>] {

<type declarations>;

<constant declarations>;

<attribute declarations>;

<exception declarations>;

[<op_type>]<identifier>(<parameters>)

[raises exception] [context]

[<op_type>]<identifier>(<parameters>)

[raises exception] [context]

}

interface <identifier> [:<inheritance>]

}

Репозитарий Интерфейсов (Interface Repositary), содержащий определения интерфейсов на IDL, позволяет видеть интерфейсы доступных серверов в сети и программировать их использование в программах-клиентах.

Object Management Architecture

Осенью 1990 года OMG впервые опубликовала документ Object Management Architecture Guide (OMA Guide). Он был подкорректирован в сентябре 1992. Детали Common Facilities (Общие средства) были добавлены в январе 1995. Следующий рисунок показывает четыре основные элемента этой архитектуры:

Рисунок 6: OMG's Object Management Architecture

Object Request Broker определяет объектную шину CORBA.

Common Object Services представляют собой коллекцию служб, снабженных объектными интерфейсами и обеспечивающих поддержку базовых функций объектов [7].

Common Facilities образуют набор классов и объектов, поддерживающих полезные во многих прикладных системах функции. Прикладные объекты представляют прикладные системы конечных пользователей и обеспечивают функции, уникальные для данной прикладной системы [7].

Application Objects -- это прикладные бизнес-объекты и приложения, которые являются основными потребителями всей CORBA инфраструктуры.

Object Request Broker

ORB (Object Request Broker, то есть брокер объектных запросов) -- это объектная шина. Она позволяет объектам напрямую производить и отвечать на запросы других объектов, расположенных как локально (на одном компьютере, но в разных процессах), так и удаленно. Клиента не интересуют коммуникационные и другие механизмы, с помощью которых происходит взаимодействие между объектами, вызов и хранение серверных компонент. CORBA-спецификации затрагивают лишь IDL, отображение в другие языки, APIs для взаимодействия с ORB и сервисы, предоставляемые ORB.

CORBA ORB предоставляет широкий набор распределенных middleware услуг. Шина ORB позволяет объектам находить друг друга прямо в процессе работы и вызывать друг у друга различные службы. Она является гораздо более тонкой системой, чем другие клиент/сервер middleware-системы, такие как RPC (Remote Procedure Calls) или MOM (Message-Oriented Middleware).

От RPC к ORB

Чем механизм вызовов CORBA отличается от механизма RPC? Да, эти механизмы похожи, но тем не менее между ними есть серьезные различия [5]. С помощью RPC можно вызвать определенную функцию. А с помощью ORB можно вызвать метод у определенного объекта. Разные объекты классов могут по-разному отвечать на вызов одного и того же метода. Так как каждый объект управляет своей собственной (в добавок личной) информацией, то метод будет вызван на сугубо конкретных данных.

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

Достоинства ORB

В теории, CORBA представляется как лучшая клиент/сервер middleware-система, но на практике она хороша лишь настолько, насколько хороши продукты, ее реализующие. К основным коммерческим ORB относятся: Orbix от фирмы IONA Technologies; DSOM от IBM; ObjectBroker от Digital; JOE от Sun; Visibroker от Visigenic и Netscape; ORB+ от HP.

Небольшой список тех выгод, которыми обладает каждая CORBA ORB [5]:

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

Отображение в языки высокого уровня. CORBA ORB позволяет вызывать методы у серверных компонент используя любой из некоторого списка языков высокого уровня -- C, C++, SmallTalk, Java и Ada. Совершенно неважно, на каком языке написаны объекты. CORBA отделяет интерфейсы от реализации и предоставляет языково-независимые типы данных, что позволяет осуществлять вызов методов, минуя границы какого-то конкретного языка программирования и конкретной операционной системы.

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

Прозрачность. ORB может выполняться как сам по себе (например на портативном компьютере), так и в окружении целого мира других ORB, с которыми она взаимодействует путем CORBA 2.0 IIOP (Internet Inter-ORB Protocol) протокола. ORB может осуществлять меж-объектное взаимодействие и для одного процесса, и для нескольких процессов, выполняющихся на одной машине, и для процессов, чье выполнение происходит в сети, под разными операционными системами. Реализация этих взаимодействий, однако, нисколько не затрагивает сами объекты. В общих чертах, при использовании технологии CORBA, разработчик не должен беспокоиться ни о таких вещах как расположение серверов, запуск (активирование) объектов, выравнивание размера переменных в зависимости от платформы и операционной системы, ни и о том, как осуществляется передача сообщений. Решение всех этих задач берет на себя продукт, поддерживающий стандарт CORBA.

Встроенная безопасность. Все свои запросы ORB дополняет некоторой контекстной информацией которая обеспечивает сохранность данных.

Полиморфизм при вызове методов. Как уже говорилось, ORB не просто вызывает удаленный метод -- ORB вызывает метод на удаленном объекте. То есть выполнение одних и тех же функций на разных объектах будет приводить к различным действиям, в зависимости от типа объекта.

Object Services

CORBA Object Services представляет собой набор сервисов системного уровня, представимых в виде компонент с некоторыми определенными IDL-интерфейсами. Эти компоненты, в некотором смысле, дополняют функциональность ORB. Их можно использовать для создания, именования компонент и многого другого. На сегодняшний день OMG определил четырнадцать стандартных сервисов.

К сожалению, практически все коммерческие ORB не поддерживают ни один из сервисов, и лишь немногие (Visibroker) -- один, два.

Common Facilities

Common Facilities (общие средства) заполняют пространство между ORB и объектными службами с одной стороны, и прикладными службами, с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Object Services -- фундаментальные объектные интерфейсы, а задача Common Facilities -- поддержка интерфейсов сервисов высокого уровня, которые, впрочем, могут включать специализацию Object Services. Таким образом, операции, представляемые Common Facilities, предназначены, в частности, для использования Object Services и прикладными объектами. Реализуется это посредством наследования стандартных Интерфейсов [7].

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

Application Objects

Объекты, если они участвуют в обмене с ORB, должны определятся с помощью IDL. Обычно приложения состоят из нескольких взаимодействующих бизнес-объектов. И, как правило, приложения-объекты строятся поверх предоставляемых ORB, Common Facilities и Object Facilities сервисов. Суть для заказчиков (или системных интеграторов) заключается в том, чтобы собрать разные бизнес-объекты в одну систему, при том, вне зависимости от производителя.

CORBA - наиболее развитая на сегодняшний день объектная технология распределенного программирования (www.corba.org). CORBA позволит Вам создавать распределенные в пространстве Сети компоненты, причем эти компоненты могут быть написаны на различных языках программирования (например, С и Java), работать на различных операционных системах (например, Linux и Windows NT), просто определяя интерфейсы друг друга и удаленно вызывая открытые методы объектов, из которых состоят Ваши компоненты. Стандарт CORBA разрабатывается крупнейшим на планете консорциумом OMG (www.omg.org) и есть достаточно много хороших реализаций стандарта для различных платформ и языков (часть реализаций представляются с открытыми исходными текстами (www.opensource.org), напр. www.OpenORB.org (Java), ORBit (C)). CORBA может стать основой для будущей технологии компонентного программирования.

CORBA включает в себя простой язык описания интерфейсов объектов - IDL (Interface Definition Language), что позволяет отделять описания интерфейсов от их реализации и обертывать в CORBA существующие приложения. Также следует сказать, что любой компонент может быть как клиентом, так и сервером одновременно. Можно вызывать методы объектов, расположенных в этой же программе (напр. в параллельном потоке (thread)), в программе на этом же хосте в Сети, на любом хосте или устройстве в Сети (напр. в сотовом телефоне или автомобиле). Вообще, чтобы вызывать методы удаленного объекта, нужно иметь как минимум описание его на IDL и так называемую объектную ссылку на него.

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

Проектируются распределенные компоненты

Описываются интерфейсы открытых объектов этих компонентов на языке IDL

Создаются реализации компонентов (объекты и их клиенты)

Тестирование компонентов в распределенной среде

Распределяются компоненты по нужным точкам в Сети

Microsoft DCOM/COM+

Модель распределенных объектов DCOM (Distributed Component Object Model) - это объектное связующее ПО, предложенное корпорацией Microsoft. Оно было разработано на основе созданных ранее и весьма популярных технологий этой компании - OLE (Object Linking and Embedding), COM и ActiveX. Технология объектной компоновки увидела свет в конце 80-х годов и первоначально предназначалась для поддержки широко известной ныне прикладной модели, ориентированной на данные и строящейся на базе составных документов. В начале 90-х годов вышла редакция OLE 2.0, в которой была представлена модель объектов-компонентов (Component Object Model, COM). Эта редакция вскоре стала именоваться просто OLE и в конечном итоге включила в себя широкий спектр технологий, реализуемых поверх COM.

В рамках модели COM был предложен стандарт двоичного интерфейса, позволившего организовывать службы (в виде динамически компонуемых библиотек или приложений) на разных языках программирования. Однако возможности этой модели существенно ограничивались тем, что она не поддерживала распределенные среды. В модели DCOM этот недостаток устранен: клиентам разрешено обращаться к имеющимся службам с удаленных компьютеров через сеть.

Модель DCOM изначально разрабатывалась с целью обеспечить возможность интеграции приложений. Идея поддержки распределенной обработки появилась позднее. Характер этой объектной модели отражает историю ее создания. DCOM поддерживает объектно-ориентированную модель, но такую, которая кардинально отличается от классических образцов. Объект DCOM предоставляет сервис посредством одного или нескольких отличающихся друг от друга интерфейсов. Он может использовать все свои интерфейсы самостоятельно, а может прибегнуть к так называемому методу агрегирования и передать один или несколько интерфейсов в распоряжение других объектов DCOM. Агрегирование позволяет строить приложение из повторно используемых компонентов DCOM.

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

Узел-клиент может запросить объект DCOM (используя стандартные методы интерфейсов, реализуемые всеми объектами DCOM) через какой-либо конкретный интерфейс, идентифицируемый уникальным номером (UUID). Интерфейс считается постоянным: после того как он опубликован, его не разрешается изменять. Добавление новых функций в объект DCOM может производиться только путем создания новых интерфейсов.

В дальнейшем на базе технологий COM, DCOM, ActiveX и MTS (Microsoft Transaction Server) была создана технология COM+. Из-за того что эта технология не была по настоящему кросс-платформенной по причине привязанности к продуктам Microsoft (в частности, MTS), был создан протокол SOAP (Simple Object Access Protocol), который позволил компонентам общаться через Internet.

Хотя между технологиями CORBA и COM/DCOM имеются существенные различия, обе они поддерживают интеграцию компонентов. И COM/DCOM, и CORBA основываются на собственных языках определения интерфейсов (IDL - Interface Difinition Language). Несмотря на одинаковые названия, эти языки различны и несовместимы. Многие другие разработчики также предлагали свои стандарты для работы с распределенными объектами, но те не получили столь широкого распространения.

К сожалению, технологии, обеспечивающие платформу для создания связующего ПО, не решали всех поставленных задач, т.к. не были универсальными и требовали дополнительных усилий для взаимной интеграции. Различные форматы передачи сообщений и зависимость от платформы (в случае с COM+) ограничивали развитие распределенных систем. Но все это не столь важно в сравнении с принципиальными проблемами, порождаемыми распределенными системами - одни и те же сущности по-разному понимаются и представляются различными частями распределенной системы. Таким образом, переход к распределенной системе требует наличия неких общепринятых определений. Решением всех этих проблем стал язык XML.

OLE

Обзор

Из статьи Вы узнаете основные сведения об OLE, некоторые вещи относительно OLE 2 и OLE Automation. В статье рассказывается об использовании объекта TOLEContainer для построения OLE приложения в Delphi.

Основы OLE

Прежде, чем перейти к рассмотрению основ OLE, потребуется изучить терминологию.

Аббревиатура OLE обозначает Objects Linked and Embedded (Присоединенные И Встроенные Объекты - ПИВО J). Данные, разделяемые между приложениями называются OLE объектом. Приложение, которое может содержать OLE объекты, называют OLE контейнером (OLE Container). Приложение, данные из которого можно включить в OLE контейнер в виде OLE объекта, называют OLE сервером.

Например, MicroSoft Word может включать в документ графические объекты, аудио- и видеоклипы и множество других объектов (такой документ иногда называют составным документом - compound document).

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

OLE является дальнейшим развитием идеи разделяемых между приложениями данных. Если с помощью DDE можно было работать с текстом, то OLE позволяет легко встроить в приложение обработку любых типов данных. Как и в случае с DDE, для правильной работы приложения-клиента (OLE контейнера) требуется наличие приложения OLE сервера. Каждый раз, когда в программе-клиенте пользователь обращается к OLE объекту с целью просмотра или редактирования данных (обычно двойной щелчок мышкой на объекте), запускается приложение-сервер, в котором и происходит работа с данными.

В природе существует несколько видов OLE, отличающихся по способу активации OLE сервера. OLE версии 1 запускает сервер в отдельном окне. OLE 2 реализует то, что называется in-place activation and editing. В данном случае сервер запускается "внутри" приложения-клиента, модифицирует вид системного меню, линейки инструментов и др. Развитие идеи OLE привело к появлению OLE automation - приложение-клиент может выполнить часть кода сервера. Тип OLE объекта, помещенного в программу-клиент, определяется тем, какую версию OLE поддерживает сервер.

Объект TOLEContainer

Объект TOLEContainer находится на странице System Палитры Компонент и нужен для создания приложений OLE-контейнеров. TOLEContainer скрывает все сложности, связанные с внутренней организацией OLE и предоставляет программисту достаточно простой интерфейс. Построим простейшее приложение с использованием OLE объекта. Создайте новый проект и поместите на форму TOLEContainer, в Инспекторе Объектов дважды щелкните мышкой на свойство ObjClass или ObjDoc - появится стандартный диалог Windows "Insert Object" (см. рис.1)

Рис.: Стандартный диалог Windows для определения OLE объекта.

В этом диалоге есть список всех зарегистрированных в системе OLE-серверов (регистрация происходит при инсталляции программы). Тип OLE-объекта определяется как раз тем сервером, который Вы укажете. Если Вы создаете новый объект (Create New), то при нажатии кнопки OK запустится программа OLE-сервер, в которой и формируется новый объект. После выхода из программы-сервера новый OLE объект включается (embedded object) в программу. OLE объект можно создать используя уже имеющийся файл в формате одного из OLE-серверов. Для этого нужно выбрать пункт Create from File (см. рис.2)

Рис.: Выбор OLE-объекта, хранящегося в файле.

Выбранный объект можно как включить в приложение, так и присоединить, отметив пункт Link.

Итак, давайте при создании нашего проекта создадим новый объект, выбрав для этого, например, Microsoft Word Document (рис.1). Нажмите OK и после того, как запустится MS Word, наберите там любой текст ("Это OLE-объект Microsoft Word document"). Для завершения работы в меню есть специальный пункт "File|Close and Return to Form1" (Win'95+MS Word 7.0). Запустите проект, он будет выглядеть примерно так:

Рис.: Простое приложение с OLE-контейнером.

Щелкните дважды мышкой на OLE-контейнер - запустится MS Word с документом из OLE-объекта, который можно редактировать, при этом все изменения сохраняются в OLE-объекте.

!!! Если во время дизайна Вы выбираете объект для включения в OLE-контейнер, то он полностью записывается в файл формы (FORM1.DFM) и в дальнейшем прикомпилируется к EXE файлу. В случае очень больших объектов это может привести во время дизайна к длительным паузам и даже к возникновению ошибки "Out of resource". Поэтому рекомендуется большие объекты делать присоединенными (linked).

TOLEContainer позволяет отображать в программе объект в его непосредственном виде (с различной степенью увеличения или уменьшения - свойство Zoom) или в виде пиктограммы, определяемой в диалоге на рис.1 (Display as Icon).

Выбор OLE-объекта может происходить не только во время дизайна, но и во время выполнения программы (об этом чуть ниже). Результаты работы с этим объектом можно сохранить в виде файла и в следующий раз восстановить его оттуда, для этого TOLEContainer имеет два метода SaveToFile и LoadFromFile.

Пример OLE приложения

Среди демонстрационных примеров, входящих в Delphi есть два, относящихся к работе с OLE-объектами (в директориях X:DELPHIDEMOSOLE2 и X:DELPHIDEMOSDOCOLE2). Более полным является второй, который, кроме всего прочего является примером построения MDI приложения. Данная программа демонстрирует все основные возможности TOLEContainer и позволяет:

создавать новый OLE контейнер во время выполнения программы;

инициализировать OLE объект либо в стандартном диалоге Windows "Insert Object", либо с помощью Clipboard, либо с помощью техники "перенести и бросить" (drag-and-drop);

сохранить OLE объект в файле и восстановить его оттуда;

Рис.4: MDI OLE приложение.

На рис.4 показан пример MDI приложения, содержащий два дочерних окна с OLE объектами. Для создания нового OLE объекта нужно выбрать пункт меню File|New и далее Edit|Insert Object. Появится стандартный диалог Windows для инициализации OLE объекта (см. рис.1). Если приложение OLE-сервер имеет возможность сохранять информацию об OLE объекте в Clipboard, то проинициализировать объект можно с помощью пункта меню Edit|Paste Special.

Достаточно интересной является возможность применения техники drag-and-drop в применении к OLE объектам. Запустите MS Word (разместите его окно так, чтобы было видно и OLE приложение), наберите какой-нибудь текст, выделите его и с помощью мышки перетащите и бросьте на главное MDI окно приложения. Появится новое дочернее окно с OLE контейнером, содержащим этот текст. Программирование данной возможности достаточно сложно. Полное описание техно

логии построения данного OLE приложения есть в документации в коробке с Delphi (User's guide), этому посвящена отдельная глава.

Сохранение OLE объекта в базе данных

Иногда необходимо хранить OLE объекты не в файлах, а в базе данных (BLOB поле в таблице). Конечно, в данном случае OLE объект должен быть присоединенным (embedded) в целях переносимости. К сожалению, в стандартной поставке Delphi нет специального объекта типа TDBOLEContainer для данных целей, но OLE объект можно сохранять и восстанавливать с помощью методов SaveToStream и LoadFromStream. Например:

procedure TOLEForm.SaveOLE(Sender: TObject);

var

BlSt : TBlobStream;

begin

With Table1 do

BlSt:=TBlobStream.Create(BlobField(FieldByName('OLE')),

bmReadWrite);

OLEContainer.SaveToStream(BlSt as TStream);

BlSt.Free;

Рис.4: MDI OLE приложение.

На рис. показан пример MDI приложения, содержащий два дочерних окна с OLE объектами. Для создания нового OLE объекта нужно выбрать пункт меню File|New и далее Edit|Insert Object. Появится стандартный диалог Windows для инициализации OLE объекта (см. рис.1). Если приложение OLE-сервер имеет возможность сохранять информацию об OLE объекте в Clipboard, то проинициализировать объект можно с помощью пункта меню Edit|Paste Special.

Сохранение OLE объекта в базе данных

procedure TOLEForm.SaveOLE(Sender: TObject);

var

BlSt : TBlobStream;

begin

With Table1 do

BlSt:=TBlobStream.Create(BlobField(FieldByName('OLE')),

bmReadWrite);

OLEContainer.SaveToStream(BlSt as TStream);

BlSt.Free;

end; end;

Интеграцияв Web.

Параллельно с развитием средств автоматизации бизнес-процессов на базе традиционных приложений, шло бурное развитие электронной коммерции. Со временем электронная коммерция сама по себе стала эффективным средством ведения бизнеса, и понятие web-приложения ушло от обычного web-сайта, сместившись по своей функциональности в область привычных «классических» приложений. С той лишь разницей, что web-приложения исторически и по самой своей сути удовлетворяют принципам многоуровневой архитектуры - разделения хранилища информации, бизнес-логики и представления данных, а средства оформления интерактивных пользовательских сред, доступные web-разработчикам, уже давно и по возможностям, и, самое главное, по дешевизне разработки превосходят средства, доступные в обычных настольных приложениях. Причем все клиенты обладают лишь самым необходимым средством отображения - браузером. Фактически, отображение посредством браузера (и все связанные с этим принципы организации приложения) и является основной чертой, по которой мы можем отличить web-приложение. Развитие средств интернет-коммерции естественным образом потребовало создания средств коммуникации между web-приложениями. То есть с этого момента развитие web-технологий влилось в общее русло развития индустрии IT, столкнувшись с проблемами интеграции, перед которыми стояла и вся индустрия в целом. И именно типичный для web-технологий (под web-технологиями в данном случае я понимаю технологии, выросшие из гипертекста) подход в итоге привел к созданию web-сервисов, которые являются универсальным решением для интеграции гетерогенных сред. Ниже мы более подробно рассмотрим технологии интеграции на базе web, которые получают все большее распространение.

XML

Датой рождения XML принято считать 1998 год, когда консорциумом W3C была утверждена соответствующая спецификация. Однако, идеи, заложенные в XML, не были новы. Технология XML основывается на языке SGML (Standart Generalized Murkup Language - Стандартный обобщенный язык разметки), который, фактически, представляет собой мета-язык для написания языков разметки. Из-за своей сложности данный язык не получил широкого распространения, однако он сыграл не последнюю роль в развитии web-технологий. Именно на SGML был основан всем известный язык разметки HTML. Но необходимо было существенно расширить возможности HTML, не впадая в крайность SGML. Простым увеличением числа стандартных тегов данную проблему решить было не возможно. Единственным разумным решением этой задачи стало использование концепции иерархически-структурированных самописательных документов, что и было реализовано в рамках XML. На данный момент XML чаще понимается не как конкретный язык разметки, а как совокупность технологий работы со структурированными данными, которые способны стать неким общим знаменателем для представления данных в распределенных системах. В состав этого набора входят такие технологии, как, собственно, язык XML, XSLT – язык, определяющий способы представления элементов XML-документа, XML Schema – возможность формального описания элементов XML-документа с целью верификации на соответствие некоторому шаблону, XPath, используемый для адресации элементов XML-документа, SOAP (Simple Object Access Protocol), используемый как транспортный уровень распределенных систем на основе сервисов, WSDL - язык описания web-сервисов и др. Все эти технологии были созданы как ответ на возникшую необходимость в едином стандарте описания данных, передаваемых между частями разнородных систем. Эти технологии стали своеобразным каркасом, на котором может быть основано взаимодействие в распределенных системах. Собственно, именно так XML-технологии и используются - в качестве оболочек программ среднего уровня для преодоления противоречий, созданных стремлением к распределенным вычислениям и, в то же время, отсутствием универсальных технологий построения распределенных систем. В силу специфики своего появления и изначального предназначения, XML еще теснее связал web-технологии с традиционными приложениями, обеспечив достаточные средства для коммуникации различных сред и предоставив необходимый базис для интеграции приложений предприятия (Enterprise Application Integration). Если говорить упрощенно, то XML как надстройка над ПО среднего уровня помимо собственно коммуникации между элементами распределенных систем, значительно упрощает представление благодаря естественной интеграции с web-приложениями. То есть браузер становится необходимым и достаточным средством отображения, а XML - связующим звеном между 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 интегрируют данные, приложения и людей через единые бизнес-процессы. Это отражает современную точку зрения, что основой интеграции должны быть бизнес-процессы. Причина здесь состоит в том, что бизнес-процессы организации «пересекают» границы различных приложений, департаментов и организаций.

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

Технология	Кто принимает решение об использовании	Решаемая проблема
Workflow	Руководитель департамента, отдела	Управление документами и пересылка документов
EAI и B2Bi	Руководитель департамента информационных технологий	Интеграция данных
BPM	Высшее руководство организации (бизнес-руководство)	Улучшение выполнения бизнес-процессов и повышение эффективности работы за счет большей гибкости процессов

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

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

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

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

Компоненты брокера сообщений

Сегодня брокеры сообщений могут объединять большое количество взаимодействующих систем. Результатом этого является так называемая «Корпоративная нервная система», т.е. инфраструктура брокера сообщений, к которой легко могут быть подключены по сути дела любые приложения и которая обеспечивает взаимодействие между ними в режиме, близком к реальному времени.

Рисунок - Брокер сообщений

Брокер сообщений интегрирует гетерогенные приложения и хранилища данных и предоставляет три типа служб:

1) Пересылка сообщений и перемещение данных обеспечивает физический транспорт доставки сообщений между приложениями. Это может быть сделано на основе таких Интернет-протоколов, как Hypertext Transfer Protocol (HTTP) и традиционных систем пересылки сообщений, например Microsoft Messaging Queuing и IBM MQ Series. Первые поколения этих технологий использовали собственные закрытые форматы для своих сообщений. В последнее время языком описания сообщений все больше становится XML.

2) Интеллектуальная маршрутизация, которая определяет для каждого сообщения то, к какому приложению оно должно попасть. Маршрутизация часто включает механизмы публикации и подписки, когда серверное приложение один раз «публикует» некоторое бизнес-событие для брокера сообщений, а определенное количество других бизнес-приложений, заинтересованных в данном событии, «подписываются» на него.

3) Трансформирование обеспечивает мапирование (определение соответствия) данных между потенциально различными семантиками одного приложения или разных приложений. Так, если одно приложение использует в формате своих данных буквы «М» и «Ж» для описания пола человека, а другое приложение использует для такого кодирования «1» и «0», то уровень трансформации брокера сообщений может мапировать информацию между приложениями, не меняя логику каждого из них. В более сложных ситуациях, когда одно приложение может ожидать 5 атрибутов в записи о клиенте, а другое приложение обеспечивает эти же атрибуты в двух различных записях баз данных, уровень трансформации может обеспечить мапирование между такими различными структурами данных.

Архитектура брокера сообщений может включать две дополнительных высокоуровневых службы:

1) Управление бизнес-процессами (оркестрирование бизнес-процессов) доводит уровень интеллектуальной маршрутизации до возможностей автоматизации потоков работ (workflow), которые полностью обслуживают внутренние и внешние процессы;

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

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

- адаптеры к веб-службам;

- адаптеры к мониторам транзакций;

- адаптеры к различным реляционным СУБД;

- API-адаптеры для популярных коробочных приложений.

Наличие указанных дополнительных высокоуровневых служб, а также средств для моделирования процессов (графических средств описания и модификации процессов), по сути дела, превращает системы EAI и B2Bi в системы класса BPM (системы управления бизнес-процессами).

Сервер Microsoft BizTalk Server представляет собой именно такую систему управления бизнес-процессами (BPM), которая обеспечивает широкий набор средств для определения сложных бизнес-процессов, в которых могут участвовать внешние организации.

Microsoft BizTalk Server включает в себя:

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

- средства визуального определения структурированных бизнес-документов;

- средства мапирования (определения соответствия) между различными форматами бизнес-документов, включая возможности задания правил трансформации;

- средства управления (консоль) для определения организаций, вовлеченных в бизнес-процесс, и средства определения правил взаимодействия и обработки сообщений;

- средства анализа, отслеживания и хранения документов для последующего анализа;

- средства мониторинга и управления работой интеграционного шлюза.

Базовые принципы интеграции с использованием XML и веб-служб

Рассмотрим базовые принципы интеграции ПО с использованием XML и веб-служб на примере государственной межведомственной интеграции.

Итак, основой межведомственной интеграции может служить интеграционное программное обеспечение и системы управления бизнес-процессами (BPM), такие как, например, Microsoft BizTalk Server. При этом XML претендует на роль универсального формата данных при такой интеграции. А сами ведомственные системы, как вновь разрабатываемые, так и унаследованные, могут быть реализованы в виде так называемых веб-служб или могут сделать свои интерфейсы доступными в виде веб-служб.

Рисунок - Гипотетическая система выдачи водительских прав, использующая XML

Чтобы прояснить суть этих подходов к организации межведомственного взаимодействия и интеграции информационных систем, рассмотрим простые базовые понятия, связанные со стандартами XML и веб-службами. Первое и главное, что следует отметить, — это то, что все описываемые ниже стандарты являются открытыми, а в их разработке принимают участие такие ведущие ИТ-компании, как Microsoft и IBM, а также органы стандартизации Интернет-сообщества в лице консорциума World Wide Web Consortium (W3C) и организации UDDI.org. Это имеет особую важность, поскольку государство должно ориентироваться на открытые стандарты интеграции.

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

По своей сути XML — это мета-язык для представления данных. Термин «мета» используется потому, что XML-документ не только содержит в себе данные, но также несет информацию, описывающую эти данные. XML является такой же универсальной и базовой технологией для представления, трансформации и обмена данными, как транспортный протокол Transmission Control Protocol/Internet Protocol (TCP/IP) для Интернета.

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

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

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

Таким образом, XML предлагает единое решение как для интеграции корпоративных приложений (EAI или A2A), так и для межведомственной B2Bi-интеграции.

Одна из тенденций состоит в том, что наиболее передовые продукты интеграции класса систем управления бизнес-процессами (BPM), такие как Microsoft BizTalk Server, не только используют XML как формат обмена данными, но также используют синтаксис языка XML для описания бизнес-логики и контроля маршрутов и потоков прохождения сообщений и документов. В частности, Microsoft, IBM и ряд других поставщиков разработали язык Business Process Execution Language for Web Services (BPEL4WS) в качестве стандартного XML-языка описания бизнес-процессов. Это обеспечивает то, что новые приложения будет еще легче интегрировать в общие бизнес-процессы, а сама логика бизнес-процессов может быть легко доступна для модификации. Это также дает возможность создания репозитария стандартных государственных бизнес-процессов, что лежит в основе электронных административных регламентов.

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

В этом плане системы управления бизнес-процессами (BPM) и технология веб-служб прекрасно дополняют друг друга. Интегрируемые прикладные системы и их модули могут быть реализованы в качестве четко определенных служб. Системы BPM обеспечивают выполнение потоков работ как цепочек взаимосвязанных служб, «склеивая» вместе службы в единые бизнес-процессы.

Рассмотрим вкратце процесс взаимодействия приложений в децентрализованной, распределенной среде. Приложение, которому требуется доступ к другому приложению как к веб-службе, использует регистр (каталог) UDDI для обнаружения нужной ему веб-службы (информация в регистре UDDI предварительно должна быть опубликована организацией, желающей сделать свою веб-службу публично доступной). В этом же регистре приложение определяет необходимые для взаимодействия интерфейсы. Интерфейсы публикуются с использованием стандарта WSDL. После этого с помощью интерфейса WSDL приложение вызывает веб-службу и применяет SOAP и XML как конверты и форматы для передачи информации, а протоколы HTTP и SMTP — в качестве транспорта для ее доставки.

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

Базовые принципы применения XML и веб-служб для межорганизационного взаимодействия.

Ниже перечислены основные принципы применения XML и веб-служб для межорганизационного взаимодействия:

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

2) XML как стандарт обмена данными;

3) Возможность создания общедоступных регистров ведомственных систем на федеральном, региональном и местном уровнях с помощью универсального стандарта UDDI;

4) «слабое связывание» информационных систем на основе инфраструктуры пересылки сообщений в виде XML-документов.

Рисунок - Техническая модель веб-служб XML как технологии интеграции.

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

На рисунке 3 приведена техническая модель интеграции ведомственных информационных систем на основе веб-служб XML. При этом интеграционный шлюз может обеспечивать не только маршрутизацию сообщений (брокер сообщений), но и реализовывать функции коллективного UDDI-регистра доступных организационных информационных систем, а также реализовывать функции «брокера веб-служб», то есть обеспечивать механизм взаимодействия между организационными информационными системами как веб-службами.

Microsoft .NET как платформа интеграции

Microsoft сформулировала достаточно передовую концепцию архитектуры информационных систем под названием .NET, которую можно определить кратко следующим образом: «Microsoft .NET — это программное обеспечение для интеграции информации, людей, систем и устройств на основе технологий XML и веб-служб».

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

Список использованных источников сети Internet:

Слов:	8811
Символов:	70186
Размер:	137.08 Кб.