2.1. Способы интеграции корпоративных приложений
Интеграция "каждый с каждым". Это традиционный подход к интеграции прикладных программ. Он состоит в создании специализированных интерфейсов обмена данными для каждой пары обменивающихся приложений. Такой подход хорош для небольшого числа приложений. При большом их числе он практически не работает. Кроме того, он не позволяет строить качественно новые запросы к обьединенным данным, т.е. качественного выигрыша от объединения данных нет.
Интеграция на уровне пользовательских интерфейсов. Подход основан на том, что приложения могут использовать друга так же, как их используют люди, а именно (с помощью специальных инструментов) через пользовательский интерфейс (screen scraping). Наиболее распространенный вариант - HTML-scraping, при котором специальный инструмент (например, Composite Application Platform предприятия CrossWeave), идентифицирует компоненты HTML-документа, полученного в результате работы веб-приложения, и предоставляет эти компоненты для повторного использования и интеграции. Такой подход может успешно применяться для сравнительно простых Web - приложений, но в последнее время он все больше вытесняется Web- сервисами (см. ниже «Интеграция при помощи WEB-сервисов»).
Интеграция на уровне данных. Один из самых распространенных в настоящее время подходов - создание хранилищ данных (datawarehouses). Подразумевает поддержку данных в специальных хранилищах независимо от бизнес-логики, их породившей. Доступ к хранилищам могут получать различные приложения. При этом подходе очень важное значение принимает наличие хорошо документированной (и редко изменяющейся) модели данных. Есть у этого подхода и свои недостатки, связанные в первую очередь с:
повышенными требованиями (а значит, стоимостью решения) к аппаратному обеспечению серверов хранилища.
необходимостью переделывать существенную часть приложений ‑ всю работу с БД,‑ и, следовательно, увеличение стоимости и возможность внесения ошибок.
необходимостью единой схемы данных для разнородных приложений, что существенно ограничивает гибкость и развитие систем.
Интеграция на уровне информационных ресурсов. Такую методику интеграции обеспечивают ECM-технология, Они позволяет быстро объединять разрозненные информационные системы предприятия, связывая их на уровне потоков информации, связывающих рабочие (бизнес-) процессы. При этом каждый исполнитель таких процессов вовремя получает свои задания и уведомления (в случае нарушения регламента), а руководители имеют возможность контролировать ситуацию. Однако мало только дать задание человеку, нужна еще информация для принятия решений. Более того, часто недостаточно только оперативной информации, например, по конкретному заказу — требуется доступ к информационному хранилищу, чтобы, например, просмотреть документы по прошлым заказам, переписку с клиентом, поднять текст договора и т.п. Ни аналитики, ни тем более сама система не смогут догадаться, какие именно документы вам понадобятся в конкретный момент; их нельзя просто прикрепить к заданию и доставить сразу весь пакет. Вот почему вместе со средствами автоматизации бизнес-процессов в ECM-системах активно используются системы управления документами и другие компоненты общей системы.
В российской практике ближе всего к понятию ECM находятся системы электронного документооборота (СЭД). С другой стороны, в качестве ECM можно рассматривать многофункциональные платформы для разработки решений в области управления информацией, такие как Lotus Notes или EMC Documentum.
Интеграция на уровне корпоративных приложений. Интеграция на уровне приложений (EAI, Enterprise Application Integration) подразумевает совместное использование исполняемого кода, а (в отличие от предыдущего подхода) не внутренних данных приложения. Программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего ПО. При таком подходе из этих компонентов создается универсальное программное ядро, которое используют все приложения. Для каждого приложения создается только один интерфейс для связи с этим ядром, что существенно облегчает задачу интеграции. Полученную в результате систему легче поддерживать и расширять. Повторное использование функций в рамках имеющейся среды позволяет значительно снизить время и стоимость разработки приложений. Кроме того, EAI интегрирует приложения, не внося в них каких-либо модификаций, что гарантирует отсутствие ошибок в их работе. Недостатком этого подхода является сложность (заранее точно не оцениваемая) и, соответственно, стоимость работ.
Интеграция при помощи Web-сервисов (SOA). Самый современный и быстро развивающийся подход к интеграции приложений. Он основан на обеспечении стандартного для Web-служб интерфейса доступа к приложениям и данным. Например, используя стандартный протокол доступа к объектам SOAP (Simple Object Access Protocol), браузер пользователя может сравнить цены на нескольких сайтах и предоставить клиенту сравнительный отчет. Web-сервисы напоминают подход EAI, но с одним существенным отличием - они существенно более стандартизованы. В большинстве случаев EAI -решения разрабатываются как частные для связи конкретных продуктов. Соответственно, подключить к существующему EAI -решению еще одну систему - большая, трудная и долговременная задача. Поскольку Web-сервисы основаны на общих для W3C -консорциума стандартах, они могут работать всюду, где можно использовать WWW-технологии.
Результаты построения КИС на основе интеграции:
Возможность осуществлять оперативное управление компанией.
Сохранение инвестиций в обучение персонала, имеющиеся системы и оборудование.
Возможность осуществлять планомерное развитие общекорпоративной информационной системы, интегрируя в нее функциональные компоненты, исходя из приоритетов развития бизнеса предприятия и потребностей функциональных подразделений, т.е. возможность синхронизировать развитие системы с развитием бизнеса.
Возможность при необходимости заменить любой функциональный компонент другим, более соответствующим текущим бизнес-потребностям.
Возможность инвестировать в развитие информационных технологий не сразу, а поэтапно, на каждом этапе соотнося вложенные средства с полученным бизнес-эффектом.
Возможность снижения общей стоимости автоматизированного рабочего места, включая затраты на создание системы, поддержку рабочих мест и обучение пользователей.
Резкое снижение времени сбора информации, необходимой для принятия управленческих и бизнес - решений.
Ликвидация противоречивости данных от различных служб.
Сокращение времени и трудозатрат на ведение учетных операций.
Ведение консолидированного управленческого учета по нескольким филиалам.
Снижение затрат рабочего времени на формирование промежуточных отчетов, на сверку информации между подразделениями.
Интеграция с использованием промежуточного ПО. Большинство предприятий не могут позволить себе отказаться от существующей инфраструктуры и заново реализовать интеграцию. Как правило, не следует отказываться от многих наследованных приложений (даже от мэйнфреймов), но их можно существенно улучшить, если интегрировать присущие им деловую логику и данные с другими приложениями. Один из способов объединения различных наследованных приложений предлагает специальное промежуточное ПО. С его помощью формируется интерфейс (мост) между двумя разными системами. Такое ПО объединяет два или несколько изолированных приложения, позволяя им взаимодействовать между собой, а также свободно обмениваться данными (рис. 2.1). В его состав могут входить программы, написанные программистами предприятия, либо готовые модули. Существуют несколько видов подобных систем. Одним из важных приложений промежуточного ПО является объединение клиента и сервера в процессе клиент-серверных вычислений, а также улучшение связи web-сервера с данными, хранящимися на другом компьютере. Благодаря этому пользователи могут запрашивать данные из компьютера, в котором они хранятся, используя формы, отображаемые на экране web-браузера, в результате чего web-сервер может возвращать динамические web-страницы, выполняя запросы пользователей.
Рис. 2.1. Промежуточное ПО для связи корпоративных приложений
Одна из ключевых проблем при создании КИС и ВК (Виртуальных Корпораций)— интеграция объектно-ориентированного подхода и распределенных вычислений. Этим занимаются многие разработчики, среди которых выделяется международный консорциум OMG (Object Management Group). Им была предложена архитектура управления объектами ОМА (Object Management Architecture), лежащая в основе стандарта CORBA (Common Object Request Broker Architecture), которая обеспечивает совместимость и возможность взаимодействия объектов в компьютерной сети. Основная идея этой архитектуры заключается в представлении любой задачи в форме взаимодействия объектов, распределенных по различным компьютерам. Объектная модель CORBA определяет порядок взаимодействия между клиентами и серверами (рис. 2.2).
Клиенты – это приложения, запрашивающие услуги, а серверы – приложения, предоставляющие эти услуги. Роль CORBA-технологии для КИС и ВК заключается в том, что с ее помощью определяется система, которая обеспечивает «прозрачное» взаимодействие между объектами в неоднородной распределенной среде.
Рис. 2.2. Архитектура CORBA
2.2. EAI - Технология интеграции корпоративных приложений
Технологию интеграции корпоративных приложений (Enterprise Application Integration, EAI) определяют как процесс связывания нескольких приложений организационной системы для того, чтобы, по возможности, максимально упростить и автоматизировать её бизнес-процессы, избегая в то же время радикальных изменений в существующих приложениях или структурах данных [3]. Аналитики Gartner Group определили EAI как “неограниченное разделение данных и бизнес-процессов между связываемыми приложениями или источниками данных на предприятии”.
Сложная и многогранная технология EAI, которая охватывает все уровни корпоративной системы - ее архитектуру, аппаратное и программное обеспечение и процессы, означает проведение интеграции на следующих уровнях, [4]:
Интеграция бизнес-процессов (Business Process Integration, BPI)
При интеграции бизнес-процессов предприятие должно определять, реализовывать и управлять процессами обмена корпоративной информацией между различными бизнес-системами. Благодаря этому организация может упростить операции, сократить расходы и улучшить реагирование на запросы клиентов. Элементы включают управление процессами, моделирование процессов и технологический процесс, который охватывает различные задачи, процедуры, архитектуры, требуемую входную и выходную информацию, а также средства, необходимые для каждого шага в бизнес-процессе.
Интеграция приложений (Application Integration)
На этом уровне интеграции целью является объединение данных или функций одного приложения с другим, благодаря чему обеспечивается интеграция, близкая к реальному времени. Интеграция приложений используется - и это далеко не полный список - для интеграции B2B, внедрения CRM-систем, которые интегрированы с корпоративными серверными приложениями, web-интеграции и построения web-сайтов, которые поддерживают многочисленные бизнес системы. Кроме того, может потребоваться проведение специальной интеграции, особенно когда требуется интегрировать существующее приложение с вновь устанавливаемым ERP-приложением.
Интеграция данных (Data Integration)
Залогом успешной интеграции приложений и бизнес-процессов является интеграция данных и систем баз данных. Прежде чем приступать к интеграции, необходимо идентифицировать (определить местонахождение) и каталогизировать данные, построить модель данных. По завершении этих трех шагов данные можно совместно использовать/распространять в системах баз данных. Уже разработаны и находят применение в КИС такие технологии интеграции данных, как Хранилища и Витрины Данных, федерализация данных.
Стандарты интеграции (Standards of Integration)
Для обеспечения интеграции данных необходимо выбрать стандартные форматы для данных. Стандартами интеграции являются те форматы, которые поддерживают использование и распространение информации и бизнес данных, т.е. стандарты являются основой для проведения интеграции корпоративных приложений. К ним относятся COM+/DCOM, CORBA, EDI, JavaRMI и XML.
Интеграция платформ (Platform Integration)
Чтобы завершить интеграцию систем - базовой архитектуры, аппаратного и программного обеспечения - необходимо интегрировать разнесенные части гетерогенной сети. Интеграция платформ касается процессов и инструментов, с помощью которых эти системы могут осуществлять безопасный и оптимальный обмен информацией. В результате, данные могут беспрепятственно передаваться по различным приложениям. Например, определение того, как нужно надежно передавать информацию с NT- на UNIX-машину, является чрезвычайно непростой задачей по интеграции всей корпоративной системы.
EAI можно использовать для следующих целей:
Интеграции данных (информации): для обеспечения непротиворечивости информаци в нескольких системах. Это также называют интеграцией информации предприятия (Enterprise Information Integration, EII).
Интеграция процессов: связывания бизнес-процессов через приложения.
Независимость от поставщика: извлечение бизнес-политик или правил из одного приложения и реализация их во всех остальных приложениях EAI-системы, так что, даже если одно из бизнес-приложений будет заменено приложением другого поставщика, бизнес-правила не нужно будет реализовывать заново для этого приложения.
Общий интерфейс: EAI-система может стать фронтальной частью группы приложений, обеспечивая единый непротиворечивый интерфейс доступа к этим приложениям и ограждая пользователей от необходимости изучать взаимодействие с различными приложениями.
Шаблоны EAI. В EAI-системах используются шаблоны трёх типов:
шаблоны интеграции (integration patterns)
шаблоны доступа (access patterns)
шаблоны «времени жизни» (lifetime patterns)
Шаблоны интеграции имеют две разновидности:
Посредничество (Mediation): EAI система действует как посредник или брокер (интерфейс или коммуникатор) между множеством приложений. Всякий раз, когда в одном из приложений происходит интересное событие (например, создаётся новая информация, завершается новая транзакция и т.д.), модуль интеграции в EAI-системе получает соответствующее уведомление. Затем этот модуль распространяет эти изменения на другие приложения.
Федерация (Federation): EAI-система действует как покрывающий фасад для множества приложений. Все доступы из 'внешнего мира' до любого из приложений проходят через фронтальную часть EAI-системы. EAI-система конфигурируется так, чтобы предъявлять внешнему миру только уместную информацию и интерфейсы соответствующих приложений, и исполнять все взаимодействия с этими приложениями от имени запросчика.
Оба шаблона часто используются одновременно. Одна и та же EAI-система может поддерживать синхронизацию множества приложений (посредничество), одновременно обслуживая запросы от внешних пользователей этих приложений (федерация).
В EAI-системах используется два вида шаблонов доступа – асинхронный и синхронный. Первый используется с шаблонами посредничества, второй – с шаблонами федерации.
Интеграционные операции могут быть коратковременными (например, синхронизация данных в двух приложениях может быть закончена в течение секунды) или долговременными (например, взаимодействие EAI-системы с workflow-приложением при оформлением банковской ссуды может занимать часы или даже дни до своего завершения).
Топология EAI-систем. В EAI-системах используется два основных вида топологий: на базе концетратора (hub-and-spoke) и на базе шины (bus). Каждая имеет свои преимущества и недостатки. В модели с концетратором EAI система является центром (концентратором, hub-ом), и взаимодействует с приложениями через отводы концентратора. В модели шины EAI система является шиной (bus) (реализуется как резидентный модуль в уже существующей шине передачи сообщений или как промежуточное ПО передачи сообщений (message-oriented middleware).
Реализация EAI-технологий наталкивается на существенные трудности, поэтому в настоящее время ни одна из компаний-разработчиков не сумела поставить на рынок комплексного решения проблем интеграции на всех вышеуказанных уровнях. Они предлагают продукты, в которых реализуется только часть задач интеграции. Лидерами на рынке EAI-технологий являются BEA Systems, CrossWorlds Software, IONA Technologies, Level 8 Systems, Mercator Software, NEON (в 2001г. этот поставщик был приобретен компанией Sybase), SeeBeyond, Software AG, TIBCO, Vitria Technology и webMethods. Среди компаний, занимающихся интеграцией крупных систем, можно выделить IBM Global Services, Accenture, PricewaterhouseCoopers, CSC и EDS. За последние годы за рубежом наблюдается устойчивый рост поступлений от реализации программного обеспечения, предназначенного для решения интеграционных задач.
Общая схема интеграции (GIF) и методология общей интеграции бизнеса (TBI). Для решения проблем и разработки стандартов в области интеграции корпоративных систем в июле 2001г. был основан Консорциум по интеграции информационных систем (Integration Consortium, IC) Это международная, некоммерческая организация, объединила в своих рядах более 50 компаний из различных стран мира, являющихся лидерами в области интеграции. В работе IC принимают участие не только поставщики программного и аппаратного обеспечения и системные интеграторы, но и потребители технологий интеграции, представители научных кругов. Поскольку IC задумывался как сообщество, целью которого является единение отрасли интеграции, все члены консорциума могут совместно определять проблемы и разрабатывать решения.
Организационно IC состоит из ряда комитетов, которые занимаются различными направлениями интеграционных технологий. Ими ведётся разработка общей схемы интеграции (Global Integration Framework, GIF), и методологии общей интеграции бизнеса (Total Business Integration, TBI).
Основными элементами GIF являются, [5]:
Единая терминологическая база для интеграции.
Эталонная архитектура, независимая от поставщиков.
Интеграционная методология, включающая нормативные шаблоны и стандарты.
Центральный регистр интерфейсов, совместимых с общей схемой интеграции (GIF).
Программная оболочка (возможно с открытым исходным кодом) интеграционных услуг.
Интеграционная модель данных и взаимодействующих инструментов.
Образовательные программы.
Сертификационный процесс, целью которого является оценка навыков и знаний отдельных специалистов, проверка соответствия требованиям продуктов и определение "зрелости" организаций.
Методология общей интеграции бизнеса (TBI) ‑ это методика, ориентированная на бизнес-процессы и разработанная для проектов, целью которых является интеграция корпоративных данных, приложений и процессов, охватывающих многочисленные бизнес подразделения предприятия, в которой используются гетерогенные системы, [6]. Достоинство данного подхода заключается в его общности, в том, что он позволяет максимально задействовать шаблоны и процессы, которые задействованы в других проектах предприятия.
Пример успешно функционирующей EAI-системы принадлежит американской компании Quicken Loans (7). Она используется для интеграции корпоративных приложений при извлечения данных из систем-источников в реальном времени. В момент совершения некоторого события, например транзакции извлечения данных, в системе-источнике EAI-система этой компании создает его копию, которая затем передается в опорную сеть передачи сообщений. Любое приложение в этой опорной сети может «подписаться» на определенное событие или сообщение, извлекать соответствующие данные из опорной сети и использовать их на локальном уровне.
2.3. SOA - Сервис-ориентированные технологии
Дальнейшее совершенствование технологий интеграции связано с переходом к сервис-ориентированной архитектуре (Service Oriented Architecture, SOA) корпоративных приложений, [8].
Приложения с традиционной «модульной» архитектурой состоят из жёстко связанных программных модулей. SOA-архитектура позволяет ослабить эти связи и организовать коллективное использование этих модулей.
SOA-приложения состоят из набора слабосвязанных неоднородных компонентов, которые называют сервисами.
Сервис – это относительно небольшой автономный программный модуль, который хранятся отдельно от приложения в специальном репозитории (обычно – на web-сервере интранет-сети предприятия) и обладает следующими свойствами:
каждый сервис реализует элементарную бизнес-функцию, которая является компонентом одного или нескольких бизнес-процессов предприятия;
сервис могут многократно использовать сразу несколько корпоративных приложений;
SOA- приложение обычно использует сразу несколько сервисов, поэтому его принято называть композитным или составным;
для доступа к сервису можно использовать несколько технологически независимых интерфейсов;
выделенные приложению сервисы слабо связаны между собой, но используемые при их вызове коммуникационные протоколы обеспечивают некоторую возможность их взаимодействия.
Архитектурный стиль SOA преобразует модульную структуру программ так, что она может расширяться или изменяться по требованию, т.е. способна включать в себя любой дополнительный набор существующих сервисов и в любой момент изменять свой состав. Его очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена или модернизация одной из компонент не сказывается на остальных. Следует также подчеркнуть, что SOA-приложения компонуются из уже готовых к использованию сервисных модулей, не зависимо от того, на каких языках программирования и на каких программно-аппаратных платформах они разрабатывались, так что и сами SOA-приложения считаются также «языково» и «платформенно» независимыми.
Известны и другие технологии реализации сервисов в информационных системах - CORBA, DCE, DCOM, Java RMI. Архитектуры, реализованные с использованием данных технологий можно также назвать ориентированными на сервисы, но при этом каждая из них определяет свои собственные форматы данных, протоколы обмена этими данными, программные интерфейсы. Поэтому они не являются универсальными, что значительно сужает сферу их применимости.
Использование Web-сервисов. Более универсальной и хорошо освоенной является сервисная архитектура, базирующаяся на использовании Web-сервисов. Она может функционировать практически в любой программно-аппаратной среде, поэтому нашла широкое применение в корпоративных информационных системах, функционирующих в инфраструктуре интранет-сетей.
Web-сервис (Web service) — это программная система, хранящаяся на Web-сервере и идентифицируемая URI-строкой, чьи общедоступные интерфейсы определены на языке XML. Описание этой системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию с помощью сообщений, основанных на XML, и передаваемых с помощью интернет-протоколов. Архитектура системы, предоставляющей доступ к Web-сервисам, показана на рис. 2.3.
Рис. 2.3. Схема доступа к Web-сервисам
Архтектура Web-сервисов включает три компонента:
Провайдер сервисов (Service Provider), который является владельцем репозитория Web-сервисов.
Потребитель сервисов (Service Requestor), которым в нашем случае является любое корпоративное приложение (вновь созданное или унаследованное).
реестр сервисов (Service Broker), в котором провайдер регистрирует каждый сервис своего репозитория.
Система доступа к Web-сервисам использует три протокола:
UDDI - определяет способ описания и регистрации каждого сервиса в репозитории (для провайдеров) и способ поиска требуемого сервиса (для потребителей). UDDI-реропозитории выступают в качестве посредника (брокера) в архитектуре SOA;
SOAP - протокол, обеспечивающий обмен данными между провайдером веб-сервисов и их потребителями. Его можно сравнить с конвертом, в который потребители вкладывают свои запросы на услугу;
WSDL - язык описания Web-сервисов, ссылки на которые хранятся в UDDI-репозитории;
Система доступа работает так: Провайдер регистрирует все свои сервисы в репозитории. Пользователь (заказчик) посылает Провайдеру запрос на поиск нужного ему сервиса в репозитории. Найдя запрошенный сервис, Провайдер возвравщает заказчику его адрес в репозитоии. Используя этот адрес, пользователь обращается к нужному сервису и подключает его к своему приложению (выполняя правила пользования данным сервисом, описанные стандартным образом на этом же ресурсе).
Характеристики SOA. К основным характеристикам SOA, отличающим ее от других архитектур, следует отнести:
Распределенность - функциональные элементы приложений могут быть расположены в различных вычислительных системах и взаимодействовать между собой через локальные сети и Интернет;
Слабосвязанные интерфейсы (отсутствие жестких связей между элементами системы), что упрощает конфигурирование системы и координирование работы ее элементов;
Архитектура базируется на международных открытых стандартах;
Возможность динамического поиска и подключения нужных функциональных модулей;
Система строится с расчетом на процессы с использованием сервисов, ориентированных на решение определенных бизнес - задач.
SOA представляет собой не только основу для новых информационных технологий, но также и новую системную философию. Постепенный переход от мэйнфреймов к конфигурациям типа "клиент-сервер" и далее к SOA означает глубокие изменения в функциональности систем, и, следовательно, создает новые возможности для бизнеса. SOA имеет все шансы заменить со временем монолитные корпоративные системы, сложные как во внедрении, так и в модернизации. Практика показывает, что при внедрении новой корпоративной системы, затраты на ее интеграцию с существующими приложениями в 2-3 раза превышают стоимость программного обеспечения и лицензий.
Классификация корпоративных сервисов. Весь набор сервисов (услуг), которые могут быть предоставлены корпоративными информационными системами с SOA-архитектурой, показан на рис. 8.8 в форме эталонной SOA-архитектуры (SOA Reference Architecture). Сервисы сгруппированы в две больших категории:
Сервисы инноваций и оптимизации бизнеса
Сервисы взаимодействий
Сервисы процессов
Информационные сервисы
Партнёрские сервисы
Сервисы разработки бизнес- приложений
Сервисы доступа
Сервисы ИТ-инфраструктуры
Сервисы разработки ПО
Сервисы организации обслуживания ИТ
Все типы сервисов объединяет сервисная шина предприятиия (Enterprise Service Bus, ESB), которая является центральным интеграционным компонентом SOA-систем (рис 2.4). Она устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов.
Рис. 2.4. Эталонная модель SOA-архитектуры
Сервисная шина предприятия. Обязательным условием построения и внедрения архитектуры системы на основе SOA является использование единой инфраструктуры описания репозитория сервисов, разрешенных протоколов доступа и обмена сообщениями, форматов сообщений.
Такая инфраструктура образует так называемую сервисную шину предприятия (СШП) (Enterprise Service Bus, ESB) (рис. 2.5), которая является центральным интеграционным компонентом систем с SOA-архитектурыой [8]. Она устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов.
Каждая из служб взаимодействует не с остальными службами напрямую, а только с шиной. СШП образует однородную среду информационного взаимодействия и является фундаментом для интеграции информационных систем, функционирующих в различных учреждениях и ведомствах. СШП определяет, кем, где, каким образом, и в каком порядке должны обрабатываться запросы.
Если сервис (информационный ресурс) не поддерживает эти правила, необходимо создавать промежуточный модуль-адаптер, который предоставляет системе необходимый интерфейс и обеспечивает взаимодействие с ресурсом.
Рис.
2.5.
Операционная среда систем с SOA-архитектурой
(IBM
ODOE1)
От развертывания систем на базе SOA пользователи получают следующие преимущества:
Возможность взаимодействия корпоративных приложений с широким кругом программных продуктов, реализованных на различных программно аппаратных платформах;
Упрощение и ускорение процесса разработки бизнес-приложений ‑ приложения строятся, как система взаимосвязанных компонентов и при этом используются наиболее подходящие компоненты из имеющихся на рынке;
Легкая интеграция новых функций в действующую корпоративную систему;
Возможность гибкого изменения и постоянного совершенствования бизнес-процессов предприятия;
Оптимизация процессов управления предприятием за счет упрощения процедур объединения информационных потоков и бизнес-процессов;
Поэтапное совершенствование корпоративной информационной инфраструктуры без привлечения крупных инвестиций.
С учетом современных тенденций перехода к бизнесу "реального времени" и созданию так называемых "расширенных предприятий", объединяющих само предприятие, его поставщиков, партнеров и клиентов в единую систему, становится очевидно, что технологии web-cервисов найдут свое применение на всех уровнях корпоративных информационных систем. Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием механизма web-cервисов, так что достаточно критическими становятся вопросы согласованной работы и управления этими сервисами. Для описания согласованной работы сервисов были предложены специальные термины – "хореография" и "оркестровка" (очевидно, по аналогии с управлением оркестром из различных инструментов или ансамблем разных исполнителей). При этом, если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.
SOA-архитектура хорошо зарекомендовала себя при построении крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (платформы SAP NetWeaver, IBM WebSphere, ИВК Юпитер и др.).
По данным Gartner Group ("Predicts 2007: SOA Advances", 17 ноября 2006 года): "К 2008 году SOA станет господствующей архитектурой построения ИТ-систем, что приведет к окончанию 40-летней эры господства архитектуры монолитных приложений".
Управление информацией SOA. К домену управления информацией относятся данные и информация, распределенные по SOA в виде корпоративных информационных активов, и то, как эти активы взаимодействуют с другими частями SOA.
Управление информацией обосновывает SOA, поскольку имеет дело с самыми важными типами информационных активов - активами, являющимися собственностью корпорации. Без четкого и надежного управления информацией SOA давала бы гораздо меньше возможностей для сквозной интеграции и трансформаций в бизнесе. Особое внимание здесь уделяется информационной интеграции предприятия (enterprise information integration, EII) - процессу интегрирования источников структурированной и неструктурированной информации в единый источник информации.
Структурированной информацией обычно называют реляционные данные, XML-данные и таблицы (электронные таблицы и базы данных), где данные упорядочены и для них указаны конкретные допустимые типы. Управление структурированной информацией относится к традиционному управлению данными (data management). К неструктурированной информации относятся отчеты, документы, Web-страницы, биологические данные, аудио и видеоданные, которые сложно представить в виде упорядоченного набора жестко определенных типов. Управление неструктурированной информацией часто выделяют в категорию под названием управление содержанием (content management).
Службы управления информацией. Управление информацией в SOA, и в частности ЕII, предлагает абстрактный уровень между приложениями и источниками информации с целью уменьшения общей стоимости владения и сложности интеграции приложений и информации. Часто это реализуется в промежуточном программном обеспечении, например в WebSphere Information Integrator, который создает абстрактный информационный уровень, отделяющий уровень приложений от уровня данных.
Абстрактный информационный уровень крайне важен для SOA, поскольку он способствует прозрачности продуктов поставщиков баз данных, платформ операционных систем, местоположения информации, формата данных и физической модели данных. Таким образом, вы можете отделить источники информации от приложений. Управление информацией в SOA осуществляет доступ и выполняет агрегацию гетерогенных данных и источников информации (процесс, называемый федерацией (federation)) таким образом, что для пользователя они выглядят как одна база данных или источник информации. Поскольку управление информацией в SOA действует как промежуточный уровень между приложениями и источниками данных, правила обращения к данным, трансформации и соответствия можно определять централизованно и применять многократно для разных запросов к службам.
Более того, управление информацией в SOA предоставляет возможности расширения, давая приложениям и пользователям доступ к информации не только в пределах одного предприятия, но и в пределах разных предприятий и отраслей промышленности. Это позволяет завершить сквозную горизонтальную интеграцию бизнеса и информации, давая бизнесу восприимчивость и гибкость.
Управление реорганизацией информации в службах. До появления информационных стандартов, таких, как XML, Unicode, UML и MOF, большинство источников данных характеризовались своими собственными частными форматами данных, метаданных и метамоделей. Интеграция разных источников данных требует огромных усилий, особенно при передаче данных от точки к точке и интеграции приложений. Очень много труда было вложено в создание инструментов типа Извлечение-Трансформация-Загрузка (Extract-Transform-Load, ETL). ETL - это распространенная схема решения в масштабе предприятия, используемая для извлечения данных из источника, их трансформации и загрузки в систему назначения.
В области содержания (контента) проблемы столь же устрашающи. Решения для управления содержанием исторически создавались в виде нескольких параллелей, и большинство из них являются решениями, основанными на вертикали или на разбивке по подразделениям (управление документами для юридического отдела. управление знаниями для IT-отдела и управление Web-содержимым для отдела маркетинга). На современном рынке управления содержанием эти решения предлагаются в разных продуктах от множества разных производителей. Даже в пределах продукции одного поставщика функциональности продуктов часто и в значительной мере перекрываются. Это часто приводит к нескольким одновременно существующим хранилищам содержимого, каждое из которых предназначено для своего вертикального решения.
Однако границы этих решений все более размываются и мы видим тенденцию к сближению различных аспектов. Например, сближение интеграции данных и интеграции содержания, сближение ETL и федерации, сближение управления знаниями и управления Web-содержимым. SOA помогает уйти от вертикального представления и деления по подразделениям, поскольку предлагает модель для достижения следующих целей:
преобразование существующих функций по управлению информацией в многократно используемые службы;
интеграция большого числа гетерогенных источников информации;
уменьшение стоимости разработки;
быстрое расширение возможностей.
На рис. 2.6 показан стек управления информацией, т. е. логическое представление или каркас для деления служб, связанных с управлением информацией, по категориям на основе их назначения: безопасность, сотрудничество, доступность, управление и потребление информации.
Рис. 2.6. Стек управления информацией в SOA
В целом эти службы могут создать полную основу для управления информацией в SOA. Каждая из этих служб в отдельности заслуживает отдельной главы, но мы можем здесь дать только их краткое описание. Система безопасности - это входная точка для приложений, обращающихся к гетерогенному источнику данных, на основе политик, определяющих, кто и что может видеть. Взаимодействие - это очень важная категория в групповой среде, где нужен контроль рабочего процесса и управление версиями.
Федерация, ETL и репликация данных предназначены для того, чтобы сделать информацию доступной, когда она понадобится пользователю. Поскольку информация заключает в себе логику и сложность организации, для того, чтобы сделать информацию более управляемой, применяются моделирование (структурное и семантическое), профилирование (данных), индексирование (содержимого) и средства обеспечения качества. Кроме того, главная цель - позволить заданным в модели действующим субъектам (акторам) получать информацию с вершины стека. И наконец, управление метаданными связывает различные компоненты-службы вместе.
Cлужбы, которые входят в домен управления информацией, как правило, предоставляются промежуточным программным обеспечением. Пользователи всегда могут встраивать эти службы в свои приложения «с нуля». Однако временные и денежные затраты часто не позволяют это сделать. На практике лучшим методом будет понять требования бизнеса, выбрать поставщика, который предлагает единую систему интеграции информации и наиболее полное решение по управлению информацией, выбрать наиболее стандартные интерфейсы и создать небольшую группу избранных служб, компенсирующих упущения, или даже передать создание некоторых сложных служб стороннему поставщику по механизму аутсорсинга.
Управление метаданными. Когда реализуется управлением метаданными, в качестве формата метаданных по умолчанию обычно выбирается XML, поскольку это де-факто универсальный формат данных. В пределах одной фирмы-производителя программного обеспечения или одной организации централизованный подход к стимулированию повторного использования активов метаданных, снижению трудозатрат на разработку и уменьшение сложностей, как правило, более эффективен, чем децентрализованный. Использовать стандартизованные метаданные также весьма полезно.
Компания IBM использует каркас с открытым исходным кодом Eclipse Modelling Framework (EMF) во многих своих инструментах в качестве технологии интеграции метаданных. EMF обеспечивает интеграцию метаданных для инструментов и объектов времени выполнения, и это способствует тому, что все программное обеспечение, разрабатываемое на основе EMF, имеет общее представление обо всех других приложениях. В идеале все артефакты-метаданные могут храниться в одном хранилище метаданных. Службы, связанные с управлением информацией (SSO, ETL, федерация, качество, поиск, контроль версий и рабочего процесса) могут вызываться по мере необходимости для управления данными, содержанием или метаданными. Иными словами, «напишите один раз и используйте везде».
Что касается XML-хранилищ, то существует два популярных механизма для хранения метаданных XML реляционная система управления базами данных (РСУБД) или исходная база данных XML Оба имеют свои преимущества и свои недостатки. К некоторым факторам, которые определяют то, какой из них будет доминировать на рынке в будущем, относятся производительность, гибкость, полоса пропускания, возможность взаимодействий, поддержка пользовательских типов данных и обеспечение качества данных (например, межсхемная проверка и трансформация).
Подход с федерациями - это более практичный метод управления метаданными для разных поставщиков, предприятий и отраслей промышленности. При таком подходе объединенное виртуальное хранилище метаданных размещает весь доступ к приложениям и гетерогенным источникам метаданных позади одного API. Физические артефакты-метаданные можно хранить либо в их исходном местоположении, либо в виртуальном - с помощью комбинации ETL, репликации и кеширования для повышения производительности и доступности метаданных. Автоматический поиск, установление соответствий и трансформации для разных источников метаданных очень важны для обеспечения управляемости метаданных.
Интеграция метаданных в SOA. Интеграция метаданных может оказаться более проблемной, чем интеграция реальных данных и содержимого, которое эти метаданные представляют. Такая интеграция весьма существенна для SOA, поскольку разделяются модели бизнес-данных. Метаданные - это «мозг» интеграции информации. Более того, интеграция информации способствует интеграции бизнеса. Она позволяет SOA распространяться на разные подразделения предприятия, на все сложные системы масштаба всего предприятия. Интеграция метаданных делает следующее:
обеспечивает единое и полное представление о клиентах, партнерах и бизнесе через хранилища данных или федерацию данных;
упрощает управление производительностью бизнеса, с применением аналитических служб;
дополняет бизнес-приложения широким доступом к информации;
позволяет осуществлять трансформацию бизнес-процесса при помощи информационных служб непрерывного действия.
2.4. ECM-технологии интеграции информационных ресурсов
Технологии интеграции информационных ресурсов реализуются в системах управления (информационными) ресурсами (контентом) предприятия ‑ Enterprise Content Management (ECM), [9]. По определению аналитиков Gartner ECM ‑ это стратегическая инфраструктура и техническая архитектура для поддержки единого жизненного цикла неструктурированной информации (контента) различных типов и форматов. ECM-системы состоят из приложений, которые могут взаимодействовать между собой, а также использоваться и продаваться самостоятельно. В современных ECM-системах реализуются следующие ключевые компоненты:
Управление документами — экспорт/импорт, контроль версий, безопасность и службы библиотек для деловых документов.
Управление образами документов (Document Imaging) — захват, преобразование и управление бумажными документами.
Управление записями (или, в соответствии с последним переводом стандарта IEEE 15489, "управление документами",[83], — долгосрочное архивирование, автоматизация политик хранения и соответствия нормам регулирующих органов, обеспечение соответствия законодательным и отраслевым нормам.
Управление потоками работ (Workflow) — поддержка бизнес-процессов, передача контента по маршрутам, назначение рабочих задач и состояний, создание журналов аудита.
Управление веб-контентом — автоматизация роли веб-мастера, управление динамическим контентом и взаимодействием пользователей.
Документо-ориентированное взаимодействие — совместное использование документов пользователями и поддержка проектных команд.
Логическая структура ECM-систем представлена на рис. 2.7, [10].
Рис. 2.7. Логическая структура ECM
Далее приводится краткое описание ключевых элементов этой схемы.