2. Группы стандартов средств интеграции приложений в ис уровня предприятия.

При создании и развитии ИС их проектировщикам, системным интеграторам, приходится решать сложные задачи, связанные с использованием существующих (унаследованных) приложений, уже функционирующих на предприятии, приложений, приобретаемых в виде готовых пакетов прикладных программ, и приложений, специально разрабатываемых для данной системы. Необходимо обеспечить интеграцию приложений, реализующих заданные прикладные функции ИС, таким образом, чтобы было обеспечено их взаимодействие по управлению, когда для выполнения какой-либо прикладной функции одного приложения требуется вызов на исполнение другого приложения, и по данным, когда необходим обмен данными между разными приложениями или использование ими общей базы данных предприятия. Поэтому вопрос о том, какие программные средства следует использовать для интеграции приложений в ИС, является центральным при проектировании таких систем. По оценке аналитиков Gartner Group, за счет рационального использования средств интеграции приложений можно сократить расходы предприятия на создание и эксплуатацию прикладного программного обеспечения ИС уровня предприятия примерно на одну треть. Исследования, проведенные Gartner Group, также показали, что предприятия тратят около 35-40% своего бюджета, отводимого на поддержку информационных технологий, на работы по организации обмена данными между приложениями и системами управления базами данных (СУБД). Столь высокий процент этой доли затрат объясняется с несовместимостью форматов данных между унаследованными приложениями и стандартами применяемых СУБД.

Потребность в средствах интеграции приложений уровня предприятия (Enterprise Application Integration – EAI) создала условия для бурно развивающегося рынка EAI-услуг. По оценке IDC объем этого сектора рынка уже в 2000 г. составлял 5 млрд. долл., а прогноз на 2005 г. составляет 21 млрд. долл.

Под средствами EAI понимается комбинация процессов, программных средств, стандартов и аппаратуры, благодаря которой обеспечивается “бесшовная” интеграция приложений в пределах одной ИС или двух и более ИС уровня предприятия, позволяющая им функционировать как единой системе. Хотя средства EAI, как правило, рассматриваются применительно к построению ИС для какого-либо одного предприятия, в настоящее время эти средства требуются и для интеграции ИС, принадлежащих нескольким предприятиям. Например, они нужны при создании систем класса B2B (Business-to-Business), когда необходимо обеспечить единые бизнес-транзакции в виде цепочек приложений, выполняемых в нескольких системах.

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

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

2. Интеграция приложений на основе предоставления функций или данных, свойственных одному какому-либо приложению, в распоряжение другого приложения с тем, чтобы их взаимодействие на стадии исполнения (runtime) обеспечило бы выполнение определенной прикладной функции ИС. Как правило, средствами интеграции приложений в данной группе средств выступают службы программного обеспечения промежуточного слоя (middleware). Такие службы иногда называют связующим программным обеспечением. Они обеспечивают прозрачную работу приложений в неоднородной сетевой среде, предоставляя им услуги в виде интерфейсов прикладного программирования (API), чтобы обеспечить взаимодействие частей приложений, распределенных по разным узлам корпоративной сети. К службам middleware, прежде всего, относятся службы вызова удаленных процедур, обмена сообщениями, посредники (брокеры) запросов к объектам, мониторы транзакций. В качестве этих средств далее рассматриваются серверы приложений.

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

4. Интеграция платформ. Системотехническая структура современных ИС уровня предприятия отражает их построение на основе распределенной клиент-серверной архитектуры, в решениях последних лет - трехзвенной или многозвенной. Такая структура представляет собой совокупность рабочих мест пользователей ИС (клиентов) и серверов, объединенных корпоративной сетью. Узлы этой сети - клиенты и серверы могут быть реализованы на базе неоднородных аппаратно-программных платформ, то есть опираться на разные машинные архитектуры и операционные системы. Это определяет необходимость иметь средства интеграции неоднородных платформ, предоставляемые их поставщиками, например, средства интеграции систем, базирующихся на Windows NT или Windows 2000 и на Unix.

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

Потребность в разработке приложений ИС, включающих в себя распределенные серверные и клиентские компоненты, привела к созданию интегрированных сред разработки и исполнения распределенных компонентов (Distributed Component Platform – DCP), поддерживающих сложившиеся “де-факто” стандарты компонентов. Среди этих стандартов известны спецификации: COM / DCOM (Component Object Model / Distributed Component Object Model) фирмы Microsoft, Enterprise Java Beans – EJB (основной конкурент DCOM) с протоколом Java Remote Method Invocation (RMI) фирмы Sun Microsystems, спецификации компонентов в архитектуре CORBA, поддерживаемые консорциумом OMG, а также стандарты компонентной разработки Web-приложений, предложенные консорциумом World Wide Web Consortium (W3C).

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

Согласно результатам опроса, проведенного корпорацией Cutter в 1999 г., среди компаний, разрабатывающих программное обеспечение ИС, более 60% уже применяют компонентный подход. Из них о применении модели COM / DCOM заявили 33% крупных компаний, EJB - 40%, CORBA - 18%, причем отмечено, что применение спецификаций компонентов в архитектуре CORBA растет.

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