ППО (промежуточное программное обеспечение - middleware) как технология, облегчающая создание распределенных систем, появилась довольно давно - ее корни прослеживаются уже в первых мониторах обработки транзакций конца 60-х. Первоначально элементы ППО использовались при создании конкретных программ, продолжая в значительной части оставаться скрытыми. До тех пор пока не возникла необходимость в создании крупномасштабных систем, поддерживающих больше пользователей, чем способен обеспечить отдельный компьютер, этот подход не рассматривался как независимая технология. К середине 80-х стало ясно, что более экономично создать распределенную, способную справиться с новыми запросами систему, чем строить мощную автономную машину. Однако только в середине 90-х стало очевидным решающее значение ППО в интегрировании распределенных систем. С другой стороны, быстрый рост сопровождался и отрицательными последствиями. Огромное разнообразие программных продуктов приводит в замешательство архитекторов информационных систем. В результате, неточное понимание возможностей ППО ведет иногда к неэффективным решениям.
Знание основных принципов технологии промежуточного программного обеспечения весьма необходимо сегодня для решения задач информатизации бизнеса и для осмысленной оценки соответствующих программных продуктов. [1-5]
Классификация ППО
Общая классификация средств ППО (рис. 1) позволяет определить несколько областей, соответствующих главным задачам, для решения которых оно предназначено [6, 7].
Три ключевых типа ППО - коммуникации, базы данных и платформные средства - условно показаны в виде трех осей (рис. 1). Они не образуют абсолютных границ, которые бы выделяли в технологии ППО три независимые области, а указывают три характерных признака. ППО коммуникаций, состоящее из процедур удаленного вызова (RPC - remote procedure call) и систем передачи и обработки сообщений (MOM - message oriented middleware) [8], специализируется в обеспечении механизмов передачи информации между программами, выполняющимися на одном или разных компьютерах. ППО баз данных обеспечивает механизмы доступа к удаленным источникам данных. Платформное ППО, включающее серверы приложений, мониторы обработки транзакций (TPM - transaction processing monitor), объектно-ориентированные мониторы транзакций (OTM - object transaction monitor) и объектно-ориентированные брокеры запросов (ORB - object request broker), помимо простой коммуникации, поддерживает дополнительные службы: управление процессами и памятью, восстановление при ошибках, балансировку загрузки и обработку транзакций. Кроме того, оно преодолевает ограниченность конкретными типами баз данных, свойственных собственно ППО баз данных.
В верхнем левом углу диаграммы показаны примеры интегрирующего ППО. В то время как три другие типа ППО относятся к системным программам и потому универсальны, интегрирующее ППО часто специфично для конкретного приложения. Оно может брать на себя некоторые из функций, обычно выполняемых прикладными программами, например, автоматизацию документооборота.
Типы ППО
|
| Рис. 2. Система без ППО |
Схематичное представление общего контекста применения ППО дано на рис. 2, где показана исходная система, состоящая из прикладной программы, СУБД, предоставляемого операционной системой сетевого ПО и самой операционной системы. Приложение непосредственно взаимодействует с СУБД, сетевым программным обеспечением и операционной системой. В свою очередь, СУБД и сетевое ПО непосредственно взаимодействуют с операционной системой.
ППО образует промежуточный слой между приложением и программным обеспечением более низкого уровня (СУБД, сетевым программным обеспечением и/или операционной системой). Оно предоставляет средства более высокого уровня абстракции, сформированные над механизмами низшего уровня, эффективно заменяющие собой код, который в противном случае располагался бы внутри приложений.
ППО коммуникаций
|
| Рис. 3. ППО коммуникаций |
ППО коммуникаций (рис. 3) - основа всех других средств промежуточного слоя, обеспечивающая механизмы более высокого уровня, чем в сетевом ПО, что очень важно для связи между процессами, исполняющимися на различных компьютерах. Оно также может использоваться для обмена информацией между программами, выполняющимися на одном и том же компьютере. Одно из отличительных преимуществ этого типа ППО - фактически, сокрытие точного физического местоположения участвующих во взаимодействии процессов. Когда одна программа посылает сообщение другой, ей не нужно знать, где находится получатель. В некоторых логических моделях, используемых ППО коммуникаций, например, в модели <публикация-и-подписка>, процесс-отправитель может вообще не знать, кто именно собирается получить сообщение и сколько будет получателей.
ППО коммуникаций подразделяется на две группы: процедуры удаленного вызова и системы передачи сообщений.
Процедуры удаленного вызова - это механизм, позволяющий прикладному программисту вызывать процедуру, которая фактически выполняется на удаленной машине. Факт, что выполнение процедуры происходит на компьютере, физически отличном от того, на котором эта процедура вызывалась, остается скрытым и с точки зрения приложения неотличим от вызова любой другой локальной процедуры. Концептуальная простота RPC привлекательна при разработке распределенных систем, позволяя создать единую виртуальную систему, незаметно для разработчика приложения распределенную на множестве физически различных компьютеров.
RPC часто входят в состав современных операционных систем. Например, в продуктах от Sun Microsystems имеется RPC сетевой файловой системы NFS, RPC платформы открытых сетевых вычислений (Open Network Computing - ONC) и транспортно-независимые RPC (Transport-Independent - TI). Имеются также продукты, основанные на стандарте RPC распределенной вычислительной среды DCE (Distributed Computing Environment) от Open Group (ранее OSF). Есть и другие производители, предлагающие продукты, включающие RPC, например, Rogue Wave, Inprise, Gradient, и Proginet, причем, продукты, основанные на стандарте RPC DCE, являются наиболее полными. Чтобы помочь в разработке распределенных систем, DCE предлагает службы защиты, распределенных файлов, каталогов, поточной обработки и синхронизации времени.
Системы передачи сообщений предоставляют прикладным программам возможность обмениваться сообщениями. MOM гарантирует их надежную передачу и, кроме того, берет на себя заботу о многих трудных сопутствующих задачах типа маршрутизации, одновременной доставки сообщения нескольким получателям, поддержки приоритетов сообщений, повторной передачи и преобразования данных в гетерогенной вычислительной среде. Некоторые продукты MOM используют бинарные записи, внутренняя структура которых должна быть согласована между процессом-отправителем и процессом-получателем. В этом случае инструкции для MOM по преобразованиям, если в работе сети участвуют машины с разной архитектурой, хранятся во внешнем конфигурационном файле, а размеры бинарных записей, поэтому не намного больше, чем те данные, которые они содержат. Другой формат записи, который требует немного больше накладных расходов в смысле полной длины сообщения, включает описание типа каждого поля (например, строка, целое число, массив символов, и т.д.) и, возможно, его длины. Тогда MOM может просмотреть сообщение и определить, является ли преобразование необходимым, основываясь на описаниях типов полей. Третья схема, которая использует самые длинные сообщения, включает также имена полей. Их обычно называют сообщениями с самоописанием, потому что они включают всю информацию, необходимую, для того чтобы полностью проанализировать содержание: имя поля, тип, длина, значение.
Первыми продукты MOM еще во время пика популярности RPC предложили компании Talarian и PeerLogic. В Talarian SmartSockets впервые была реализована передача сообщений по схеме <публикация-и-подписка> для платформ Unix и Windows NT, а теперь компания также предлагает балансировку нагрузки и автоматическое восстановление (failover). Pipes от PeerLogic - масштабируемый продукт, который в состоянии прозрачным образом работать с целым рядом несопоставимых операционных систем и протоколов (например, SNA и TCP/IP). Однако самый популярный сегодня программный продукт данной категории - это IBM MQSeries [9], который выполняется на почти любой платформе, частично благодаря усилиям самой IBM, а частично - программным продуктам третьих фирм (например, Level 8 Systems). Известен также продукт MSMQ от Microsoft. Среди других тяжеловесов следует назвать, в частности, компании BEA Systems, Iona Technologies, Progress Software [10], NetSys Technology.
ППО баз данных
|
| Рис. 4. ППО баз данных в распределенной системе |
ППО баз данных обеспечивает доступ к локальному или удаленному ресурсу данных (рис. 4) и включает некоторые низкоуровневые средства ППО коммуникаций, необходимые для связи клиента и сервера. Основная задача ППО баз данных - скрыть сложное расположение распределенного ресурса данных. ППО баз данных включает шлюзы, концентраторы, универсальные API-интерфейсы СУБД, процессоры преобразования данных, также как и инструментальные средства передачи изменений между несколькими экземплярами баз данных.
Шлюзы и концентраторы баз данных обеспечивают доступ на языке SQL к разнотипным источникам данных. Когда источники не поддерживают SQL, шлюзы транслируют SQL-запросы, полученные от приложения, в запросы, понятные целевой базе данных. Концентратор базы данных аналогичен шлюзу, но может иметь дело с несколькими источниками данных одновременно.
В зависимости от конкретного продукта преобразование выполняется либо на уровне API-интерфейса, либо на уровне протоколов коммуникаций, либо на обоих уровнях сразу. Наиболее популярны концентраторы Enterprise Data Access/SQL и Data Joiner от IBM, а также OmniConnect от Sybase.
Универсальный API-интерфейс - интерфейс к источнику данных, отрывающий приложение от определенной базы данных, обеспечивая единообразный интерфейс независимо от специфической архитектуры используемой СУБД. Три наиболее известных стандарта универсальных API-интерфейса СУБД: Open Database Connectivity (ODBC), Java Database Connectivity (JDBC) и Object Linking and Embedding Database (OLE DB).
Помимо Microsoft, имеется множество поставщиков, предлагающих программные продукты, которые реализуют эти, ставшие де-факто, стандартными API-интерфейсы, включая Merant (ранее MicroFocus и Intersolv) и International Software Group.
Инструментальные средства тиражирования данных (database replication) позволяют осуществлять синхронизацию баз данных, имеющих одинаковые схемы построения. Обычно они связываются с конкретным типом СУБД, однако некоторые третьи фирмы (Sybase, DataMirror) предлагают независимые от СУБД решения.
|
| Рис. 5. Платформное ППО в распределенной системе |
Инструменты распространения баз данных (database propagation) могут использоваться, чтобы поддерживать несколько копий одной и той же информации, сохраняемой в базах данных, которые имеют различные схемы или даже различные архитектуры (скажем, реляционные и нереляционные). Все изменения, которые необходимо выверить, определяются по журналам регистрации базы данных (например, в IBM DataPropagator) или путем выполнения SQL-подобного запроса в исходной базе данных (Platinum InfoPump).
Процессор преобразования данных (transformation engine - TE) предоставляет средства для сокращения сложности интегрирования данных и поддерживает использование альтернативной платформы для выполнения такой обработки при реализации хранилища. TE обеспечивает многозадачную архитектуру, реализуя асинхронно и параллельно функции, которые обычно выполняются приложениями последовательно. Это еще не устоявшаяся технология, доступная пока скорее как элемент инструментария разработчика, а не как готовый к использованию продукт.
Архитектура процессоров преобразования данных весьма разнообразна: некоторые из них выступают как интерпретаторы (Informatica), другие генерируют программный код (Apertus), а третьи являются гибридами обоих этих подходов (Sagent Technologies и IBI). Есть инструментальные средства, основанные на объектных моделях (Sagent), в то время как другие основаны на реляционной модели (Constellar и VMark/Ardent Software). Некоторые инструменты используют определенную базу данных в качестве рабочей области для временного хранения и преобразования данных (Constellar), а другие оставляют это решение разработчику.
Платформное ППО
Данный тип программного обеспечения (рис. 6) представляет собой ППО коммуникаций с рядом дополнительных функций, которые обычно относятся к операционной системе. Оно отделяет приложение от сетевого программного обеспечения и ОС, не только обеспечивая API-интерфейс более высокого уровня для коммуникации, но и помогая сделать прозрачными и ряд других задач: управление памятью, управление процессами (включая их автоматический запуск и завершение), обнаружение ошибок, и, иногда, даже автоматическое восстановление (например, включение дублирующей системы). Также доступны некоторые дополнительные услуги наподобие балансировки загрузки и управления транзакциями. Платформное ППО включает серверы приложений, мониторы обработки транзакций, брокеры объектных запросов.
Серверы приложений обеспечивают доступ к элементам выполняющимся на сервере алгоритмов бизнес-логики приложения. Серверы приложений начального уровня просто гарантируют готовность исполняемой программы, которая осуществляет требуемую бизнес-функцию. Их основная задача - облегчить начало выполнения, остановку и рестарт после неудачи серверных модулей приложений. Более мощные обеспечивают доступ к бизнес-функциям, несмотря на отказы аппаратуры или программного обеспечения, а также увеличение нагрузки. Наиболее продвинутые серверы приложений перехватывают все взаимодействие между клиентами-инициаторами запроса и серверами, предоставляя приложению модель программирования высокого уровня.
В сфере технологий серверов приложений доминируют два стандарта. Первый - Enterprize JavaBean (EJB), разработанный Sun Microsystems, определяет модель для разработки и развертывания Java-компонентов многократного использования, а второй - Microsoft ActiveX. Технология EJB представляет собой часть более общего стандарта JavaBean, опирается на OMG CORBA и обеспечивает связь между объектами. Для ActiveX требуется сервер транзакций Microsoft Transaction Server. В свою очередь, MTS зависит от объектной модели программных компонентов COM.
Мониторы обработки транзакций были пионерами на арене ППО как неотъемлемая часть механизма исполнения транзакций в базах данных на больших компьютерах. Навязывая применение семантики транзакций при всех операциях, TPM обеспечивают совместимость и целостность информации.
История развития мониторов обработки транзакций и их текущее состояние частично объясняет один из самых больших парадоксов - неожиданно широкое распространение унаследованных систем. Одним из основных производителей здесь была IBM со своим продуктом IMS. Этот созданный 30 лет назад монитор для ОС MVS способен обрабатывать десятки миллионов транзакций в день и легко приспосабливается к увеличению и колебаниям рабочих нагрузок. Самый серьезный конкурент для IMS - CICS TS для S/390, используемый с 70-х годов и в настоящее время способный поддерживать 5-7,5 тыс. пользователей одновременно. IBM пробовала предложить для платформы Unix продукт Encina (впоследствии переименованный в Transaction System, а теперь вошедший в семейство WebSphere), но он пока с переменным успехом конкурирует с монитором Tuxedo от BEA Systems. Эта мощная технология, первоначально разработанная как часть СУБД UNITS в Bell Laboratories в начале 80-х годов, стала лучшим решением для больших корпоративных приложений, хотя зачастую рассматривается как слишком сложное и дорогое. В число популярных мониторов входят Open TP1 от Hitachi Computer Products и openUTM от Siemens; оба основаны на стандарте X/Open DTP.
Брокеры объектных запросов предоставляют основной механизм взаимодействия объектов независимо от их расположения. Клиент ничего не знает ни о механизме взаимодействия или активизации другого объекта, ни о реализации объекта, ни о его расположении: ORB формирует основу для проектирования приложений, созданных из распределенных объектов.
Первый брокер объектных запросов был разработан в корпорации Digital Equipment в 1989 году - это было еще до CORBA или любых других ORB, доступных сегодня. Сначала он был лишь вариацией RPC и, главным образом, использовался как ППО коммуникаций (ОС и язык программирования непосредственно обеспечивали большинство сервисов управления ресурсами). Однако этот первый брокер от DEC (также как и другие ранние) уже имел способность запустить программу с самого ее начала, особенность, которая отличала его от большинства продуктов категории RPC. Сегодняшние брокеры объектных запросов намного больше похожи на мониторы обработки транзакций, и другие серверы приложений.
ППО интеграции
В то время как все другие типы ППО позволяют связывать программы, данный инструментарий используется как средство соединения других средств ППО [11]. На рис. 6 приведены два примера ППО интеграции. Слева показана ситуация, при которой функциональные возможности промежуточного программного обеспечения X расширены при помощи ППО интеграции (например, теперь поддерживается другая, более мощная модель связи). Справа - ситуация, при которой ППО интеграции используется для трансляции между различными протоколами коммуникации: протоколом, связанным с X, и протоколом, связанным с Y.
ППО интеграции можно разделить на пять категорий: шлюзы, абстрактные посредники, упаковщики, брокеры интеграции, адаптеры.
Шлюз (gateway) - механизм преобразования потоков данных, удовлетворяющих разным протоколам связи с целью преодоления несовместимости, происходящей вследствие использования продуктов ППО различных основных типов. Например, шлюз может использоваться между платформным ППО и ППО коммуникаций. Фактически он заменяет протокол связи, который использует конкретный продукт платформенного ППО.
Абстрактный посредник (abstraction layer) - сильно связанная часть программного обеспечения, отделяющая приложение от средств ППО, путем предоставления API-интерфейса более высокого уровня. Абстрактные посредники позволяют переносить приложение на платформу с иным ППО и могут расширять существующие функциональные возможности основного инструментария ППО за счет функций более высокого уровня.
Упаковщики (wrapper) подобны шлюзам за исключением того, что они способны выполнять преобразование информации на специфическом для приложения уровне с учетом содержания данных. Упаковщики иногда называются также перехватчиками консоли (screen scraper) и используют для обеспечения взаимодействия с унаследованными или закрытыми системами.
В то время как упаковщики, не являющиеся одновременно брокерами интеграции, встречаются реже, например EntireX от Software AG или HP Changengine, средства, работающие в составе инструментальных средств порождения приложений, доступны более широко. Два основных производителя перехватчиков консоли - Fujitsu и Siemens.
Брокер интеграции - независимый посредник, облегчающий взаимодействие между прикладными системами. Он действует как многоцелевой упаковщик многократного использования, способный обрабатывать множество специфических для приложений форматов данных. Упаковщик - просто прямой двухполюсный преобразователь, а брокер основан на модели коммуникации <многие-ко-многим>. Кроме того, брокеры предоставляют многократно используемое ядро динамических программных модулей, которое выполняет некоторые универсальные функции и, в этом отношении, действительно является системным программным обеспечением. Специфические для приложения аспекты наподобие конкретных форматов данных могут быть включены в брокер при помощи инструментария визуальной разработки.
Среди главных производителей брокеров интеграции можно назвать компании Metaserver, IBM с продуктом MQSeries Integrator, ObjectSwitch, Vie Systems с продуктом Copernicus, а также Active Software, New Era of Networks, TSI Software и SAGA Software.
Адаптеры используются для соединения брокера интеграции с приложением или ППО. Адаптер может включать динамические средства ППО (например, шлюз или службы типа абстрактного посредника), средства разработки и некоторые шаблоны (например, для преобразования или автоматизации потока). Один адаптер обычно предлагает несколько интерфейсов к одному и тому же целевому приложению.
Тенденции развития ППО
Развитие ППО происходило от простой модели синхронного соединения <один-к-одному>, используемой в RPC, к модели асинхронной связи <многие-ко-многим> без установления соединения, с управляемой событиями обработкой, которая поддерживается системами передачи сообщений. Программа, которая не должна ждать (синхронно) удаленную процедуру, чтобы завершить свою работу, может делать другую полезную работу во время ожидания ответа. Когда ответ прибывает, программа уведомляется об этом и сможет обработать данные при первой возможности.
Концептуальная простота RPC была столь привлекательной, что ее основные идеи получили развитие в намного более сложной технологии платформного ППО, а именно, в брокерах объектных запросов. В сущности, это переделанная модель RPC, где вызов метода приводит к исполнению некоторого фрагмента программного кода на локальном или удаленном компьютере. Как и в случае RPC, точное место, где это происходит, остается скрытым от вызывающего процесса. Но, в отличие от RPC, брокеры объектных запросов поддерживают асинхронную модель связи и способны запускать программы <по требованию> (локально или удаленно), что гарантирует существование объектов (данных и методов), когда это необходимо. Именно эти свойства заставляют отнести брокеры к платформному ППО, в отличие от ППО коммуникаций, которому принадлежат сами процедуры удаленного вызова.
Однако вместе с мощью, которую предоставляют MOM и ORB, они также приносят и некоторые сложности для прикладных программистов. Продукты MOM предоставляют готовые блоки для соединения компонентов распределенной системы, но они не предписывают способа, как это сделать. В некоторых случаях выбор неочевиден и может отличаться в разных частях системы.
ORB, с другой стороны, предполагают, что все состоит из объектов. Эту технологию лучше всего использовать при создании системы с нуля. В этом случае, естественно применить сначала объектно-ориентированный анализ, сопровождаемый объектно-ориентированным проектированием, и последующим объектно-ориентированным воплощением в коде. Но даже в этом случае, хотя некоторые из объектно-ориентированных CASE-средств могут облегчить процесс разработки, использование распределенных объектов при программировании есть, главным образом, прерогатива искушенных разработчиков приложений. Кроме того, ORB могут чрезвычайно усложнить дело, когда насущная задача - интеграция или модификация существующих приложений, ни одно из которых не соответствует объектно-ориентированной парадигме. К сожалению, именно это обычно имеет место для большинства унаследованных приложений.
Для специализированных приложений, в которых главное - разделение данных, решение может быть в том, чтобы использовать ППО баз данных. В некоторых случаях, разделение достигается путем поддержки нескольких копий базы, в то время как в других его обеспечивают несколько каналов доступа к одним и тем же источникам данных (шлюзы баз данных, концентраторы и универсальные API-интерфейсы). Эта технология устраняет некоторые из трудностей, возникающих при попытках приспособить друг к другу основные блоки, используемые при создании распределенных систем (MOM, RPC, ORB), предписывая определенную стратегию разделения данных на уровне протоколов коммуникаций или обработки. Но она также привносит и проблемы, среди наиболее серьезных - неспособность разделять элементы деловой логики, специфические для конкретного приложения. Это важно: разнообразные приложения, способные обновлять одну и ту же информацию, могут применять разные правила для проверки достоверности данных. В свою очередь, это может вести к наличию противоречивых с прикладной точки зрения данных в одной и той же базе данных (шлюзы, концентраторы, API-интерфейсы), или производить противоречивые копии одной и той же информации (репликация и распространение).
В некоторых случаях создание распределенной системы может быть упрощено, если используется сервер приложений или монитор обработки транзакций. Если приложение основано на многозвенной архитектуре, любой из них может использоваться в качестве среднего звена. В этих случаях, эта технология обеспечивает полную инфраструктуру для создания новых и интеграции существующих приложений, что позволяет совместно использовать общие элементы бизнес-логики (например, правила проверки достоверности), избегая производства данных, противоречивых на уровне приложений.
Серверы приложений и мониторы обработки транзакций все более сближаются, так что их становится все труднее отличить друг от друга. В сущности, они превращаются в хранилища разделяемых удаленно исполняемых элементов бизнес-логики, разделяемых каналов доступа к прикладным данным и разделяемых каналов связи с внешними системами. Часто они вообще обеспечивают полноценную вычислительную среду для реализации бизнес-логики распределенных прикладных систем. Хотя брокеры объектных запросов в целом также следуют парадигме <погруженного> выполнения прикладного кода (т.е. реализуют вычислительную среду, где <живут> распределенные объекты), они не смогли достичь подобного же уровня концептуальной простоты.
Сегодня становится ясно, что основные типы ППО уже не могут обеспечить адекватного решения сами по себе - центр разработки современных распределенных систем переместился от создания полностью новых приложений к интеграции существующих. Для этого может весьма эффективно использоваться ППО интеграции, особенно вместе с платформным ППО. Здесь наиболее продвинуты брокеры интеграции, которые могут быть настроены для осуществления даже специфической для приложения бизнес-логики. Брокеры интеграции - не просто средство объединения нескольких приложений, но и способ размещения <интеллекта> прикладной системы непосредственно в канале коммуникации. Использование сервера приложений или монитора обработки транзакций, работающих вместе с брокером интеграции, может обеспечить мощную инфраструктуру для роста корпоративной распределенной вычислительной среды, поэтому некоторые современные брокеры интеграции постепенно смещаются к <полному решению>, приобретая некоторые характеристики платформного ППО (например, отказоустойчивость, обработка транзакций, балансировка нагрузки и т.д.).
Заключение
Сегодня имеется много мощных инструментов, которые облегчают создание сложных распределенных систем и помогают объединить широкий диапазон существующих приложений. Но быстрый рост ППО привел также к появлению большой путаницы - проектировщикам систем и разработчикам предлагается более сотни продуктов данного класса. Скажем, есть много различных компиляторов для каждого конкретного языка программирования, но каждый компилятор обеспечивает поддержку языка в соответствии с некоторым стандартом (например, ANSI C). Точно так же имеется много реляционных СУБД, но все они стараются поддерживать общепринятый интерфейс (прежде всего, SQL). В случае с ППО это не так - за очень немногими исключениями здесь очень мало стандартов.
Литература
[1] Gartner Group's Introduction to Middleware Vendors and Products, Gartner Group, March 1999
[2] Ed Acly, Middleware: Worldwide Market & Trends, IDC, 1998
[3] David S. Linthcum, Enterprise Application Integration, Addison Wesley, 2000
[4] Л. Розенкранц. Промежуточное ПО, , 2000, № 39
[5] Д. Слейтер. Промежуточное ПО без мистики, <Директор информационной службы>, 2000, № 11
[6] Ф. Бернштейн. Middleware - модель сервисов распределенной системы, <Системы управления базами данных>, 1997, № 2
[7] Н. Дубова. Все про промежуточное ПО, <Открытые системы>, 1999, № 7-8
[8] Л. Черняк. МОМ, второе рождение, <Открытые системы>, 2001, № 10
[9] Н. Игнатович. IBM MQSeries: архитектура системы очередей сообщений. <Открытые системы>, 1999, № 9-10
[10] В. Коржов. Почтальон для приложений, <Открытые системы>, 2001, № 10
[11] Е. Карташева. Средства интеграции приложений, <Открытые системы>, 2000, № 1-2
Евгений Кузнецов (eugene.kuznetsov@hotmail.ru) - старший научный сотрудник Института проблем управления РАН. Алексей Кононов (aik762@hotmail.com) - сотрудник компании Lucent, один из разработчиков системы обеспечения отказоустойчивости в программном обеспечении Tuxedo компании BEA Systems.
Логические модели ППО
Модель связи <один-к-одному> (или <точка-точка>) предполагает наличие только двух взаимодействующих процессов и одной линии связи, используя которую приложения могут передавать сообщения в обоих направлениях.
Модель связи <многие-к-многим> (или ее вариант <один-ко-многим>) служит для обеспечения механизмов совместного использования данных многими приложениями. До недавнего времени модель <многие-к-многим> могла быть реализована только средствами ППО коммуникаций. При этом средства ППО (или, в их отсутствие, код приложения) отвечали за отправку одного и того же сообщения столько раз, сколько имелось получателей. При большом числе получателей отправка даже одного широковещательного сообщения шла бы очень долго. Сегодня все больше операционных систем включает поддержку модели <многие-к-многим> (например, возможность широковещания - multicast - в Sun Solaris).
Модели синхронной и асинхронной связи. Синхронная связь - это связь между двумя процессами, от которых требуется, чтобы они выполнялись параллельно. Асинхронная связь - <непараллельная> связь между двумя процессами (процесс-отправитель не зависит от процесса-получателя, а задержка доставки сообщения позволяет процессу-инициатору продолжать выполнение). В случае связи с блокировкой выполнение процесса-отправителя останавливается до тех пор, пока не получит подтверждение о получении сообщения. При связи без блокировки процесс-отправитель может продолжать выполнять другую работу, пока не поступит подтверждение о получении сообщения.
Модель связи на основе соединения относится к ситуации, когда приложения устанавливают соединение между собой, обмениваются большим количеством сообщений в любом направлении и затем разрывают соединение. Соответствующие стороны знают друг о друге и на уровне приложений <говорят> непосредственно между собой.
Связь без установки соединения означает, что не имеется никакого соединения на прикладном уровне. Вместо этого, процессы отправитель и получатель говорят с посредником, который отвечает за обеспечение связи, в частности, за маршрутизацию.
Обработка, управляемая событиями, - это тип взаимодействия, при котором основная программа приложения в бесконечном цикле ждет появления одного из следующих событий: внутреннего события, сгенерированного самой программой (прерывания, контролируемые по времени события); внешнего события, сгенерированного извне (прибытие сообщения или подтверждения). Когда событие обнаружено, программа вызывает обработчика события и снова входит в цикл ожидания, пока не наступит следующее событие. Кроме того, основная программа может запустить отдельный поток, в котором вызывается обработчик события, в этом случае, основная программа возвращается в цикл ожидания еще до окончания обработки события. Последний подход обычно предпочтительнее, поскольку позволяет обрабатывать одновременно множество сообщений.
Многие средства ППО, особенно типа MOM, обеспечивают <основной цикл> программы. В рамках этого подхода реализация программы сводится к написанию обработчиков событий, которые присоединяются к основной программе во время компиляции. Так как тип события (например, окончание периода ожидания или приход сообщения определенного типа) распознается циклом события в ППО, он может вызывать соответствующую обрабатывающую событие процедуру непосредственно. При этом основные усилия программистов могут концентрироваться на создании обработчиков событий, и нет нужды заботиться собственно о получении сообщений или распознавании событий. Кроме того, программы с циклами событий распознают некоторые административные команды (в том числе, временные остановы и выключения), что позволяет стандартизировать управление системой.
Схемы коммуникаций
Схемы коммуникаций определяют основные типы взаимодействия между приложениями и образуют набор образцов взаимодействия, описывающих логические отношения между процессами. Типовые схемы коммуникаций могут быть разделены на две большие категории - односторонние и двусторонние связи.
При односторонней связи имеется одно приложение-источник, которое посылает одно сообщение одному или большему количеству приложений-получателей. В зависимости от конкретной реализации, источник может получать подтверждение от механизма - средства связи, но не ожидает никакого ответа от самого получателя. Наопротив, типовые схемы двусторонней связи относятся к ситуации, где два или больше приложения обмениваются сообщениями.
К односторонним относят следующие модели связи (Рис. I).
A) Прямая передача сообщений. Простая ситуация, когда один процесс посылает сообщение одному или более процессам. Этот метод (его также называют <выдал-и-забыл>) используют, чтобы достичь максимальной скорости передачи информации за счет отказа от записи событий в журнал регистрации. Но, будучи быстрым, он может быть менее надежным.
B) <Передача сообщений с организацией очереди> (messaging-and-queuing). Этот метод также иногда называют <передачей с промежуточным хранением>. Часто, процесс отправитель может указать срок доставки или использовать систему приоритетов, чтобы определить, как скоро сообщение должно быть доставлено по назначению. Передача сообщений с организацией очереди - это преимущественно связь типа <один-к-одному>.
C) <Публикация-и-подписка>. Отправитель передает сообщение посреднику, который затем распределяет сообщение среди <заинтересованных> получателей. Это освобождает приложение - источник от необходимости знать о потенциальных получателях. Процесс отправитель называется издателем, а процессы получатели - подписчиками. Данный тип связи требует сложной инфраструктуры ППО, способной физически передавать сообщения от одного или большего количества издателей к одному или большему количеству подписчиков. По каждому сообщению этот механизм должен быть способен правильно определить заинтересованные стороны (т.е. подписчиков). Обычная схема - адресация по теме сообщения, когда издатель указывает рубрику, в которой сообщение следует издать. Другая схема - адресация по содержанию. Она обычно медленнее (потому что посреднический механизм должен быть способен анализировать и понимать каждое сообщение), но эффективно переносит часть прикладной логики в ППО. Кроме того, издатели и подписчики могут динамически изменять темы публикации сообщений или критерии подписки.
Типовые схемы двухсторонних моделей связи (рис. II), всегда являются коммуникациями типа <один-к-одному>.
A) Схема запрос/ответ. Один процесс посылает сообщение другому и ожидает от него ответ. Наиболее часто этот тип связи используется тогда, когда программа передает (поручает) некоторую элементарную часть работы другой программе (например, единичный поиск в базе данных). Вообще говоря, это операция с блокировкой. Если же блокировки нет, то, теоретически, операция становится эквивалентной двум независимым операциям передачи сообщений: одной, содержащей запрос, и другой - ответ. Тогда, запрашивающему приложению придется проводить парное соответствие запросов и ответов. В этом случае, уровень ППО, видимый приложению, выполняет блокировку, в то время как более низкий уровень выполняет сопоставление. Для реализации этого сопоставления в сообщение внедряется скрытый уникальный идентификатор (типа счетчика), который должен возвратиться с ответом.
B) Диалоговая схема. Два процесса участвуют в диалоге, неоднократно обмениваясь сообщениями. Эта модель требует синхронной связи, и, как правило, связи с блокировкой. Данный тип связи обычно реализуется системным программным обеспечением нижнего уровня, где он используется, когда требуется организовать какие-либо переговоры. Он более редко встречается на уровне приложений и обычно связывается с выполнением сложных транзакций с условным содержанием.
OSI как эталонный перечень протоколов коммуникаций
Одна из наиболее распространенных моделей компьютерных коммуникаций - стек протоколов OSI, где каждый слой в пределах стека осуществляет связь на все более высоком уровне абстракции. Однако усилия Всемирной организации по стандартизации не привели к желаемым результатам. Источник трудности заключался в неоднозначной спецификации каждого слоя в стеке OSI, что оставляло слишком много степеней свободы и вело к несовместимым реализациям. Однако стек OSI все еще жизнеспособная модель для оценки ППО коммуникаций, где конкретный продукт соотносится с одним или более слоев в стеке. Например, протоколы коммуникаций TCP/IP и UDP могут быть помещены на уровне транспортного слоя, потому что они осуществляют независимые от конкретной сети механизмы связи. Аналогично ППО коммуникаций изображено поверх транспортного слоя, но предоставляет также функции из слоя представления данных и сеансового слоя. Некоторые продукты ППО поддерживают проблемно-зависимые протоколы коммуникаций (например, SWIFT, FIX или HL7) и, таким образом, их функциональность простирается в слой приложения.
SWIFT (Society for Worldwide Interbank Financial Telecommunications) - стандарт передачи сообщений, разработанный в соответствии с законом Бельгии в 1977 году, который предоставляет средства коммуникации для международного банковского сообщества. Сегодня он используется в 174 странах.
FIX (Financial Information Exchange) - стандарт передачи сообщений для электронного обмена информацией об операциях с ценными бумагами в режиме реального времени. Является открытой общественной спецификацией, поддерживаемой организацией FIX, которую субсидируют, главным образом, брокерские фирмы США и Европы.
HL7 (Health Level 7) - стандарт передачи сообщений для электронного обмена данными в области охраны здоровья, предложенный в 1987 году. Хотя он был предназначен, прежде всего, для информационных систем в больницах и клиниках, его также приспособили для фармацевтической и биомедицинской промышленности.
Обычно, нижние уровни стека коммуникации соответствуют асинхронной модели без блокировки. Когда изменяется состояние линии связи (например, поступают новые данные, или сетевая плата готова послать следующую порцию данных), аппаратные средства генерируют прерывание, которое активизирует соответствующие сетевые драйверы ОС. Но сетевое программное обеспечение может реализовывать как синхронную, так и асинхронную модели (или даже обе), в зависимости от особенностей реализуемого протокола коммуникации. Реализация более высоких уровней стека (модулями ППО или прикладной программы) может сохранять ту же самую модель или сменить ее на другую, от синхронной перейдя к асинхронной с блокировкой или без блокировки или наоборот.
