Технология программ-«переходников» — это одновременно и важнейший элемент интегрированной системы предприятия, и минное поле из жаргонизмов

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

Что такое промежуточное ПО?

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

Зачем оно нужно?

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

Одним из требований электронного бизнеса является интеграция более высокого, чем обычно, уровня. Заказчики, работающие через Web, хотят, как правило, видеть самую свежую информацию: данные о выпускаемом фирмой продукте и его доступности, предполагаемое время доставки и состояние счета. «Чтобы ответить на все эти вопросы, сотрудники центров обработки телефонных звонков подключаются одновременно к нескольким приложениям. Попытки дать клиентам самостоятельный доступ к этой информации не оправдывают себя — такой способ ее получения становится чересчур сложным», — считает Карен Буше, исполнительный вице-президент компании Standish Group. В этом случае нужно связать все приложения с помощью промежуточного ПО и подключить к Web-системе, служащей для связи с заказчиками.

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

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

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

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

Почему возникает путаница?

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

Типы промежуточного ПО

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

RPC и шлюзы баз данных

Описание

Это не совсем типичное промежуточное ПО в обычном его понимании, однако для полноты картины о нем тоже следует сказать. И RPC, и шлюзы БД представляют собой старые способы организации взаимодействия приложений, в частности в распределенной среде.

RPC расшифровывается как «удаленный вызов процедур» (remote procedure call). Этот метод предусматривает наличие кода внутри клиентского приложения, способного запускать процедуры, работающие на серверном приложении. С точки зрения сегодняшних представлений о промежуточном ПО RPC не вполне является таковым. Этот метод связи хотя и не потерял сегодня своей ценности, все же вытесняется современным промежуточным ПО, поскольку при интеграции новых приложений с уже существующими требуются усилия программистов. С ростом числа интегрируемых приложений другие методы организации промежуточного ПО нередко оказываются более эффективными.

Более соответствуют понятию промежуточного ПО шлюзы БД, так как они представляют собой независимые продукты, помогающие обеспечивать доступ к данным. Шлюзы БД позволяют подсоединить приложения к конкретным типам СУБД. Многие современные прикладные системы дают возможность работать с такими распространенными системами, как Oracle или Sybase, однако они становятся беспомощными, когда нужно подсоединиться к более старой системе TurboImage, работающей на HP 3000. Типичный повод для использования шлюза БД.

Промежуточное ПО, ориентированное на передачу сообщений (MOM)

Примеры

MQSeries — IBM

MSMQ — Microsoft

SmartSockets — Talarian

Описание

Промежуточное ПО, ориентированное на передачу сообщений (message-oriented middleware, MOM), берет на себя передачу данных от приложения к приложению, переводя эти данные в формат сообщений подобно тому, как это делается в системах электронной почты. В самом деле, еще до того, как получили распространение готовые MOM-продукты, компания Cargill, например, построила собственное MOM-средство для интеграции приложений, использовав для передачи данных почтовую систему Hewlett-Packard OpenMail.

Если вы понимаете, как работает электронная почта, вы поймете и принцип работы MOM. И в том и в другом случае данные забираются из приложения А и помещаются в очередь, откуда позже при необходимости могут быть извлечены приложением B. Такой способ «общения» защищает данные от потерь, которые могут возникнуть, например, когда приложение В зависает и требуется его перезагрузка в тот самый момент, когда приложение А пытается передать информацию. Сервер промежуточного ПО обеспечивает асинхронную связь: он дождется момента, когда приложение В заработает снова, и передаст ему данные из очереди в нужной последовательности.

Типичные способы использования

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

Мониторы транзакций

Примеры

CICS, OpenCICS — IBM

BEA Tuxedo — BEA Systems

Описание

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

Мониторы транзакций проникают в приложение намного «глубже», чем промежуточное ПО, основанное на MOM. Чтобы ощутить их преимущество, возможно, придется внести в приложение существенно больше изменений. Кроме того, эти мониторы поддерживают дополнительные функции по защите данных и по обеспечению целостности.

Способы использования

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

«Когда вы пишете новое приложение, вам не нужно вручную программировать всю функциональность, — говорит Буше. — Вместо этого вы пользуетесь готовыми приложениями, которые общаются друг с другом посредством этого промежуточного ПО».

Брокеры объектных запросов и их архитектуры

Примеры архитектур

Common Object Request Broker Architecture (CORBA) — Object Management Group

Enterprise JavaBeans (EJB) — Sun Microsystems

Component Object Model (COM+) — Microsoft

Описание

Брокеры объектных запросов (object request brokers, ORB) располагаются между приложениями и сетевыми службами (службами обеспечения безопасности, мониторинга производительности, серверами печати и др.). Они представляют собой ключевой элемент более широкого класса стандартов на архитектуру построения служб и взаимно-совместимых приложений. Три перечисленные выше архитектуры — это попытки трех основных игроков рынка предложить единый стандарт. Как пример пакета промежуточного ПО, разработанного на базе одной из упомянутых архитектур, можно назвать Orbix 2000 фирмы Iona Technologies. Эта система базируется на последней версии 3.0 стандарта CORBA.

Перечислим предпосылки использования ORB. Для многих приложений требуется доступ к одним и тем же услугам или к другим приложениям. Реальность нынешнего дня — это неоднородная аппаратная и программная среда: разные платформы, разные операционные системы, приложения, написанные на разных языках с помощью разных средств разработки. Чтобы все эти составляющие могли общаться друг с другом, необходима последовательно выполненная объектно-ориентированная архитектура.

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

Исторически стандарт CORBA более тесно связан со средой Unix, в то время как архитектура Enterprise JavaBeans больше подходит компаниям, ведущим разработки на Java. К счастью, оба эти предложения по стандартизации прекрасно совмещаются друг с другом. Для специалистов, имеющих опыт работы с CORBA, подключение к проекту разработки на Java не вызовет особых затруднений.

Однако, как отмечает Буше, серверные объекты, составленные в рамках модели CORBA, не могут сегодня легко интегрироваться с серверными объектами, созданными в рамках модели COM+, и наоборот. Это означает, что многие большие организации лишены возможности применять две модели одновременно и вынуждены выбирать только одну из них. Вероятно, пользователи, у которых стоят серверы под Windows NT/2000, получат большую отдачу от применения COM+, а потребителям, имеющим дело с Unix (пусть даже с клиентскими местами с ПО от Microsoft), подойдет CORBA.

Особое замечание

Архитектура промежуточного ПО Microsoft продолжает развиваться, а вместе с ней меняется и используемая корпорацией терминология. Это может ввести в заблуждение любого новичка. Первоначально архитектура носила название COM. Затем появилось сокращение DCOM, то есть «распределенный COM». По словам Буше, сегодня Microsoft перестала использовать термин DCOM, перейдя на — COM+, который является частью более обширного архитектурного замысла Microsoft, получившего название DNA — «архитектуры распределенной сети». Концепция DNA включает продукты и службы, выходящие за границы определения промежуточного ПО.

Объектные мониторы

Примеры

IBM Component Broker

VisiBroker Integrated Transaction Server — Inprise

Microsoft Transaction Server

Описание

Объектные мониторы, называемые также объектными мониторами транзакций, — это усовершенствование версии TP-мониторов, о которых уже говорилось. Данная категория продуктов только появилась, и характеризуется она тем, что обеспечивает функциональность TP-мониторов, но строится на основе объектно-ориентированных спецификаций вроде моделей брокеров объектных запросов. Благодаря этому имеется больше возможностей для модификации предоставляемых служб, чем при использовании TP-мониторов, и отпадает необходимость вносить изменения в приложение.

Способы использования

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

Интеграция приложений предприятия

Примеры

ActiveEnterprise — Tibco Software

NEON Impact — New Era of Networks

e-Gate — Software Technologies Corpоration (STC)

BusinessWare — Vitria Technology

Geneva Enterprise Integrator (EI) — Level 8 Systems

(и многие другие)

Описание

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

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

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

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

Очень интересным свойством продуктов для интеграции приложений является поддержка XML и BizTalk (набор стандартов для протоколов взаимодействия типа «бизнес - бизнес», разработку которого курирует Microsoft), а также стандартов, выдвигаемых консорциумом RosettaNet, работающим над протоколами сообщений для электронной промышленности. (Более подробно о RosettaNet рассказывалось в статье «Присвойте себе метку», опубликованной в № 7-8 журнала «Директору ИС». — Прим. перев.)

Большинство продуктов для интеграции приложений устроено так, что пользователь покупает один центральный модуль и набор необходимых ему интерфейсов. Так, например, в продуктовую линейку e-Way компании STC входят самостоятельные «переходники» для систем SAP, Siebel, Lotus Notes и целой серии СУБД. Большинство поставщиков систем интеграции приложений имеют специальное подразделение по обслуживанию, способное выполнить работы по созданию «переходника» к приложению заказчика. «Они как бы придерживаются правила 80:20, имея в виду, что 80% ваших интерфейсов будут уже заранее готовы, а остальные 20% программируются на заказ», — поясняет Джон Кэмпенейл, вице-президент консалтинговой компании ARC.

Способы использования

Методология интеграции приложений подходит для больших компаний, которым приходится объединять в единое целое множество прикладных систем. Например, фирма Cargill использует систему продуктов eLink производства BEA Systems для связывания множества различных приложений, включающих ERP-приложения, системы управления обслуживанием, складские, бухгалтерские и прочие системы.

Что выбрать?

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

Дерек Слейтер — исполнительный редактор журнала CIO. Ему можно написать по адресу dslater@cio.com

Поделитесь материалом с коллегами и друзьями