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

Рис.: Выбор 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:\DELPHI\DEMOS\OLE2 и X:\DELPHI\DEMOS\DOC\OLE2). Более полным является второй, который, кроме всего прочего является примером построения 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.

Достаточно интересной является возможность применения техники 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;

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) является объектной оболочкой над реляционными таблицами и хранимыми процедурами СУБД. Она описывает все классы объектов, которые могут существовать в Хранилище. Каждый конкретный объект является воплощением одного из классов библиотеки и имеет свойства - сами данные и методы - действия над ними. Эта библиотека является центральным звеном решения. При ее помощи очень легко загрузить или получить любые данные хранилища, даже если структура хранилища непрерывно развивается.