Рис.1. Программное обеспечение промежуточного слоя
Г. Ладыженский, Jet Infosystems системы ( gleb@jet.msk.su)
Middleware: основные понятия
Сервисы ПО промежуточного слоя
Интегрированная среда
Мониторы обработки транзакций
Интеграция сервисов ПО промежуточного слоя
Тенденции
Серверы в локальных вычислительных сетях (ЛВС) обычно поддерживают обработку файлов и приложения, опирающиеся на модель файлового сервера - например, электронную почту, доски объявлений, подготовку документов и сетевую печать. Локальные серверы поддерживают службу каталогов и обеспечивают пользователям возможность поиска интересующих их сервисов и подключения к ним. Серверы в глобальной сети обычно поддерживают доступ к базам данных, корпоративным каталогам, электронным библиотекам, или приложения обработки транзакций. Некоторые серверы обеспечивают шлюзы к сервисам, которые предлагаются вне рамок организации - например, к услугам туристических фирм, информационно-поисковым службам, службам новостей (погода, котировки ценных бумаг) или службам, поддерживающим электронный обмен документами с деловыми партнерами. Ряд компаний реорганизуют бизнес-процессы таким образом, чтобы максимально эффективно использовать указанные возможности и объединить прежде изолированные друг от друга источники информации.
Современные вычислительные средства организаций - пока только некоторое приближение к модели информационных служб. Во многих организациях существует множество разнородных компьютерных платформ, включая персональные компьютеры, рабочие станции, мини-компьютеры и мэйнфреймы. Эти компьютеры работают под управлением различных операционных систем (ОС) и опираются на различные сетевые архитектуры. Как следствие - интеграция сложна и ее результаты оказываются неполными.
Проблемы, возникающие при построении корпоративных информационных систем, заставляют их разработчиков усиливать прессинг на производителей компьютерных платформ и программного обеспечения, с тем чтобы последние оказали им помощь в интеграции распределенных систем на основе разнородных платформ.
Один из способов решения проблем - это поддержка стандартных программных интерфейсов. Они облегчают задачу переноса приложений на серверы различных типов, предоставляя потребителю некоторую независимость от производителей.
В прошлом было достаточно поддержки стандартного языка программирования, например, COBOL или С. Сегодня же типичное приложение может использовать базы данных, коммуникации, представления и другие сервисы, и их интерфейсы не являются компонентами языка программирования. Условием успешного переноса приложения на другую платформу является поддержка соответствующих интерфейсов на этой другой (целевой) платформе.
Стандартные интерфейсы важны и для самих производителей серверов. Потребители покупают приложения, а не серверы. Они выберут любой сервер, на котором можно запускать необходимые им приложения. Поддерживая множество стандартных интерфейсов, производитель увеличивает число приложений, которые работают на его серверах, что делает серверы более привлекательными для потребителей.
Другой способ, применяемый производителями для разрешения проблемы разнородности - поддержка стандартных протоколов. Стандартные протоколы делают возможным взаимодействие программ. Говоря о взаимодействии (interoperate), мы имеем в виду, что программа в составе одной системы имеет доступ к программам и данным в составе другой системы. Взаимодействие возможно только тогда, когда две системы используют один и тот же протокол, то есть те же форматы сообщений и их последовательности.
Чтобы помочь потребителям решить проблемы разнородности и распределенности и сделать возможной реализацию информационных служб, производители предлагают сервисы распределенной системы которые обладают стандартными программными интерфейсами и протоколами. Такие сервисы называются сервисами промежуточного (среднего) слоя (middleware services), поскольку располагаются "в середине", занимая промежуточный уровень между операционными системами и сетевым программным обеспечением с одной стороны, и приложениями, ориентированными на конкретную прикладную область - с другой стороны.
Подобно менеджерам и администраторам корпоративных информационных, разработчики программного обеспечения также сталкиваются с проблемами разнородности и распределенности. Разработчики стремятся к тому, чтобы их приложения опирались только на стандартные программные интерфейсы и могли работать на большинстве популярных платформ.
Разработчикам необходимы высокоуровневые интерфейсы, которые скрывают неоднородность сетей и протоколов, и позволяют им (разработчикам) сконцентрировать внимание на решении специальных проблем прикладной функциональности - на той области деятельности, где они сильны и реально создают дополнительную стоимость.
Для многих вновь разрабатываемых приложений компоненты ПО промежуточного слоя становятся более важными, чем операционные системы и сетевые сервисы, от которых раньше зависело приложение. Так, вновь разрабатываемые приложения в большинстве случаев опираются на сервис реляционных СУБД (нежели на файловый сервис ОС), на механизм RPC (нежели на механизм передачи сообщений). В общем, ПО промежуточного слоя заменяет "нераспределенную" функциональность операционных систем на "распределенную" функциональность, которая строится на основе компьютерной сети (распределенные базы данных, удаленный доступ к файлам, RPC).
Для многих приложений программный интерфейс, предоставляемый ПО промежуточного слоя, фактически определяет вычислительную среду. Например, многие приложения трактуют таким образом языки четвертого поколения (4GL), мониторы обработки транзакций (TP) (IBM CICS, Digital ACMSxp), и офисные интегрированные системы ( Lotus Notes, LinkWorks).
Унаследованные приложения (legacy applications), разработанные еще до того, как мобильное ПО промежуточного слоя стало фактическим стандартом, также могут воспользоваться его сервисами. Можно определить унаследованное приложение как набор функций и воспользоваться коммуникационными сервисами ПО промежуточного слоя для обеспечения удаленного доступа к этим функциям. Для этой цели можно, например, воспользоваться реализацией Common Object Request Broker Architecture (CORBA) консорциума Object Management Group (OMG).
В основе этого и других возможных решений лежит принцип максимального использования функциональности ПО промежуточного слоя. На практике этот принцип означает существенную экономию рабочего времени разработчиков и повышение производительности их труда. Причина проста - ПО промежуточного слоя берет на себя большую часть системной функциональности, оставляя разработчикам программирование в прикладной области. Производители ПО промежуточного слоя обладают ресурсами для развития и поддержки системной функциональности, существенно превосходящими возможности прикладных программистов. С другой стороны, максимальное применение в разработках сервисов ПО промежуточного слоя значительно увеличивает надежность разрабатываемых систем, придает им промышленный характер, так как система строится на стандартизованном и апробированном фундаменте.
Сервис ПО промежуточного слоя (middleware service) - сервис общего назначения, который располагается между платформами и приложениями (см. рис. 1). Под платформой мы подразумеваем набор низкоуровневых сервисов и элементы обработки, определяемые парой: архитектурой процессора и API операционной системы, например, Intel x86 и Win32, Sun SPARCstation и SunOS, IBM RS/6000 и AIX, Alpha AXP и OpenVMS, или Alpha AXP и Windows NT.
Сервис ПО промежуточного слоя определяется интерфейсами прикладного программирования и протоколами, их поддерживающими. Сервис может иметь множество реализаций, соответствующих спецификациями его интерфейса и протокола, как, например, различные реализации DCE RPC и протокола IBM 3270. Как и многие системные категории, ПО промежуточного слоя трудно точно определить в техническом смысле. Тем не менее, компоненты ПО промежуточного слоя обладают рядом свойств, которые, взятые в совокупности, свидетельствуют о том, что данный компонент не является сервисом, специфичным для приложения или платформы. Компоненты ПО промежуточного слоя являются общими для различных приложений и прикладных областей; они функционируют на разных платформах, распределены и поддерживают стандартные интерфейсы и протоколы. Ниже мы опишем каждое из этих свойств.
Сервис ПО промежуточного слоя отвечает потребностям широкого ряда приложений многих прикладных областей. Например, коммутатор сообщений, транслирующий сообщения в разные форматы, рассматривается в качестве ПО промежуточного слоя в том случае, если он позволяет добавлять новые форматы, и его можно использовать во многих приложениях. Если он работает с форматами только одной прикладной области (например, обеспечение информационной безопасности торговых операций) и (или) встроен в отдельное приложение (например, в систему обслуживания сделок на бирже), то мы имеем дело не с ПО промежуточного слоя.
Сервис ПО промежуточного слоя должен иметь реализации для разных платформ. В противном случае это - специфический сервис платформы. Например, системы управления реляционными базами - это ПО промежуточного слоя. Многие программные продукты из семейства реляционных СУБД работают на нескольких платформах. Напротив, файловые системы рассматриваются как специфический сервис платформы.
Если сервис является распределенным, это также усиливает интероперабельность, поскольку приложения на разных платформах могут использовать его для коммуникаций и/или обмена данными. Чтобы охватить как можно больше платформ, сервисы ПО промежуточного слоя разрабатывается как переносимые (portable). Это означает, что их можно перенести (портировать) на другую платформу, предприняв при этом небольшие и заранее предсказуемые действия.
Сервис ПО промежуточного слоя является распределенным. Это означает, что к нему возможен удаленный доступ (например, сервис СУБД), либо он обеспечивает удаленный доступ к другим сервисам и приложениям (например, коммуникационный сервис). Сервис ПО промежуточного слоя, к которому возможен удаленный доступ, обычно включает клиентскую часть, которая содержит API сервиса, функционирующий в адресном пространстве приложения, и серверную часть, которая содержит главные функции сервиса и может функционировать в другом адресном пространстве (например, в другой системе). Допускается множество реализаций каждой части.
В идеале, сервис ПО промежуточного слоя поддерживает стандартный протокол (например, TCP/IP или семейство протоколов ISO OSI), или, по крайней мере, опубликованный протокол (например, SNA LU62 корпорации IBM). Таким образом можно разработать множество реализаций сервиса, и все они будут взаимодействовать между собой. Однако, если сервис ПО промежуточного слоя действительно работает на всех популярных платформах, его можно рассматривать как стандартный, даже если его протоколы не опубликованы. Такое свойство имеет, например, большинство СУБД.
Сервис ПО промежуточного слоя должен поддерживать стандартный API. Он (сервис) является прозрачным (transparent), по отношению к API, если к нему обеспечен доступ посредством API, но при этом не требуется модификация самого API.
Если производитель ПО обеспечивает широкий охват платформ и обладает значительной долей рынка, то поддерживаемый им API и протокол можно рассматривать как фактический стандарт, даже если ни API, ни протокол не поддерживают другие производители. Например, в реляционных СУБД ORACLE и SYBASE поддерживаются собственные диалекты языка SQL, и даже при этом рассматриваются большинством потребителей как фактический стандарт. Аналогично монитор обработки транзакций CICS корпорации IBM использует собственные API и протокол (LU6.2), и, тем не менее, является фактическим стандартом.
Вопрос о том, относится ли данный сервис к ПО промежуточного слоя, со временем решается по-разному. Компонент, который в данный момент рассматривается как часть платформы, может в будущем стать ПО промежуточного слоя. В результате реализация ОС упростится, а сервисы, предоставляемые данным компонентом, станут общедоступными для всех платформ. Например, мы рассматривали традиционную файловую систему как стандартный компонент операционных систем, каковой она несомненно была во всех коммерческих ОС, разработанных до 1980 года. Однако сегодня мы часто рассматриваем файловую систему как ПО промежуточного слоя - имея в виду, например, реализации, соответствующие стандарту API X/Open C-ISAM.
Напротив, ПО промежуточного слоя может встроено в платформу, чтобы улучшить ее производительность и повысить коммерческую ценность платформы. Например, интерфейсы протоколов транспортного уровня часто рассматривались как продукты, обеспечивавшие доступ к коммуникационным сервисам, как продукты, независимые от ОС. Теперь они обычно включаются в ОС.
Ввиду того значения, которое имеют стандартные интерфейсы для переносимости приложений, а стандартные протоколы - для их взаимодействия, По промежуточного слоя стало объектом усилий по стандартизации. Некоторые из них были предприняты организациями, вырабатывающими стандарты - например, ISO и ANSI, некоторые - консорциумами производителей, такими как X/Open, OSF и OMG, а некоторые спонсировались компаниями, имеющими значительную долю рынка ПО - например, архитектура Windows Open Services Architecture (WOSA) стала результатом усилий корпорации Microsoft. Иногда отдельный сервис получает гигантское распространение и поэтому становится фактическим стандартом, как, например, PostScript (Adobe), монитор транзакций CICS (IBM) и Network File Service (Sun Microsystems).
Следующие компоненты ПО являются или могли бы быть сервисами ПО промежуточного слоя:
Сервисы ПО промежуточного слоя обеспечивают интерфейс прикладного программирования, не зависящий от платформы, так что приложения будут работать на многих платформах. Они скрывают детали сетевых протоколов и распределенных систем. Они разрабатываются таким образом, чтобы встроить общеупотребительные функции в независимые компоненты, которые затем можно распределить по различным платформам и программным средам.
Но сервисы ПО промежуточного слоя нельзя рассматривать как панацею. Во-первых, существует определенное расхождение между принципами и практикой. Многие популярные сервисы ПО промежуточного слоя используют собственные API. Из-за этого приложения обычно оказываются зависимы от программного продукта одного производителя. Кроме того, они (сервисы) в ряде случаев опираются на закрытые, неопубликованные протоколы. Из-за этого производителям платформ сложно перенести сервис на собственную платформу так, чтобы он взаимодействовал с реализациями того же сервиса, но на других платформах. Например, как указывалось выше, во многих реляционных СУБД поддерживаются собственные диалекты SQL и собственные протоколы. Некоторые из них недоступны на многих популярных платформах, что ограничивает потребителя в выборе платформ и сужает его возможности при работе в неоднородных системах. Это замечание относится, например, к реляционным СУБД Rdb корпорации Oracle (ранее система принадлежала DEC) и DB2 (IBM).
Даже если сервис ПО промежуточного слоя является высокотехнологичным программным продуктом, разработчик приложения, которое опирается на данный сервис, принимает на себя новую форму риска - риск, что этот сервис не сможет идти в ногу с технологией. Например, многие приложения, использовавшие сетевые СУБД (стандарт CODASYL) пришлось переписывать, чтобы воспользоваться преимуществами реляционных СУБД, которые пришли на смену сетевым в качестве фактического стандарта.
Во-вторых, препятствием к использованию сервисов ПО промежуточного слоя является их огромное количество. Использование даже небольшого числа сервисов ПО промежуточного слоя может привести к существенному усложнению разработки- если рассматривать полный API каждого сервиса, имея в виду не только вызовы сервиса, но и особенности использования сервиса в различных языках программирования, системные интерфейсы и средства определения данных. Чтобы сохранить среду программирования простой, управляемой и обозримой, разработчики выбирают небольшое число сервисов, которые отвечают их требованиям к функциональности и спектру платформ.
В-третьих, хотя сервисы ПО промежуточного слоя повышаю уровень абстракции при программировании распределенных приложений, они по-прежнему оставляют разработчика приложения перед лицом серьезных проблем проектирования. Например, разработчик по-прежнему должен решать, какую функциональность включить в клиентскую, а какую - в серверную часть распределенного приложения. Обычно бывает оправданным расположить сервис представления в клиентской части приложения ("ближе к экрану"), а сервисы, ответственные за обработку данных - в серверной части ("ближе к базе данных"). Однако такое решение далеко не всегда будет идеальным, и в любом случае остается открытым вопрос о том, где расположить другие функции приложения.
Рис.2. Интегрированная среда
Иногда сервисы ПО промежуточного слоя расширяются до масштабов ИС. Так произошло с инструментарием для работы с реляционными СУБД. Иногда набор сервисов интегрирован в такой степени, чтобы фактически превращается в ИС. Например, в OSF DCE интегрированы сервис RPC, сервис имен, сервис аутентификации, служба времени, сервис идентификации и файловый сервис. Отметим, что в DCE нет как такового обобщенного интерфейса пользователя, и весь интерфейс прикладного программирования DCE - это, собственно, API упомянутых выше сервисов. Тем не менее, DCE поддерживает контекст вызовов (по идентификатору пользователя), и обеспечивает прозрачный вызов сервисов для упрощения некоторых операций.
Поскольку ИС опирается на сервисы ПО промежуточного слоя, постольку ИС является потребителем услуг ПО промежуточного слоя. Точно также приложение, которое опирается на ИС, является ее клиентом, и, опосредовано - потребителем сервисов ПО промежуточного слоя. Приложения уходят от непосредственного вызова сервисов ПО промежуточного слоя и опираются в основном на ИС. Эта тенденция аналогична другой, имевшей место в прошлом тенденции, когда приложения уходили от прямого использования сервисов, предоставляемых платформой, и опирались на сервисы ПО промежуточного слоя.
Один из методов, при помощи которого упрощается API ИС - сохранение контекста вызова различных сервисов. Например, в большинстве ИС вызовы сервисов требуют в качестве параметров идентификатор пользователя (для контроля доступа) и идентификатор устройства (для установления связи). ИС трактует эти идентификаторы как контекст приложения, но не как параметры, упрощая таким образом API. Например, CASE-система COHESIONworX поддерживает контекст, включающий имя пользователя, имя дисплея и рабочую область, содержащую каталоги файлов и указатели на объекты. Поддержка контекста не является уникальным свойством ИС. Сервис тоже может поддерживать контекст, хотя этот контекст обычно бывает локальным по отношению к данному сервису. Например, DCE RPC сохраняет идентификатор пользователя между вызовами RPC.
ИС может предоставлять упрощенный API, имея в своей основе модель, которая не требует вызова всех функций сервисов ПО промежуточного слоя. Например, CASE-система может предложить упрощенный интерфейс для управления конфигурацией разрабатываемого программного обеспечения, который затрагивает далеко не все функции менеджера репозитария.
ИС может поддерживать собственные, приватные сервисы ПО промежуточного слоя. Обычно это происходит потому, что интегрированной среде необходим сервис, а такого стандартного сервиса ПО промежуточного слоя не предоставляет. Например, многие мониторы транзакций используют частную реализацию RPC, однако при наличии DCE, некоторые из них заменяют свои собственные реализации RPC стандартной.
Интегрированные среды включают инструментарий, который представляет собой набор специализированных приложений, упрощающих использование ИС. Инструменты предназначаются для конечных пользователей, программистов или системных администраторов, их может предоставлять производитель ИС или третьи фирмы. Примерами могут послужить различного рода редакторы, средства помощи, менеджеры форм, компиляторы, отладчики, средства мониторинга производительности.
Управление транзакциями предполагает наличие операций начала, фиксации и отката (прерывания) транзакции, а также интерфейсов к менеджерам ресурсов. В TPM реализован двухфазный протокол фиксации транзакций, гарантирующий одновременное успешное завершение или откат транзакции несколькими вовлеченными в нее менеджерами ресурсов.
TPM поддерживают традиционные возможности межпроцессного взаимодействия, когда один процесс передает некоторый фрагмент своего контекста другому процессу - и все это в рамках одной транзакции. Это, как правило, либо взаимодействие по схеме "равный-с-равным" ("отправить сообщение", "получить сообщение", или стандартный либо несколько модифицированный механизм RPC ("отправить запрос", "получить ответ").
Менеджер очереди - это специализированный менеджер ресурсов, обеспечивающий хранение запросов в долговременной памяти (на диске) с целью гарантированной поддержки надежного межпроцессного взаимодействия и гарантированного выполнения транзакций. Основные операции менеджера очередей - помещение запроса в очередь и выборка запроса из очереди. Менеджер распределенных очередей обеспечивает гарантированную передачу запросов из одной очереди в другую.
Традиционно в TPM эти функции были реализованы как специальные сервисы интегрированной среды, которые, в свою очередь, опираясь только на сервисы платформы. Сегодня многие из этих сервисов ИС определены как сервисы ПО промежуточного слоя. Разрабатываемые сегодня TPM обращаются к таким стандартным сервисам, как менеджеры записей, менеджеры транзакций и менеджеры очередей.
Делаются попытки стандартизации API и протоколов всех описанных выше сервисов. Так, например, консорциум X/Open работает над стандартами API для управления транзакциями и коммуникациями (стандарт X/Open ATMI - Application - Transaction Management Interface), а ISO - над стандартным протоколом для управления очередями.
Традиционно большинство TPM зависели от платформы, для которой и были созданы. Современные мониторы обработки транзакций опираются на сервисы ПО промежуточного слоя и обладают большей переносимостью, так как в их основу положены сервисы ПО промежуточного слоя, которые переносимы сами по себе.
TPM интегрируют сервисы таким образом, чтобы они были доступны через упрощенные или унифицированные API. Один из способов упрощения API - поддержка контекста. TPM обычно поддерживает контекст, связанный с текущими запросом, транзакцией и пользователем. Большинству функций приложения не нужно специфицировать эти сведения. Вместо этого TPM специфицирует необходимые параметры при трансляции запроса, поступившего от приложения в вызов базового сервиса ПО промежуточного слоя. Например, приложение потребовать поместить сообщение в очередь, и TPM добавит в качестве параметров идентификатор текущей транзакции и идентификатор пользователя.
TPM обычно включает инструментарий прикладного программирования. Например, в него может входить словарь данных, используемый менеджером форм, приложениями и СУБД. Digital использует для этой цели собственный словарь данных Common Data Dictionary/Repository (для интеграции TPM ACMS, реляционной СУБД Rdb, менеджера форм DECforms).
TPM также включает средства системного управления и мониторинга. Они позволяют отображать состояние транзакции или запросов, следить за показателями производительности системы и настраивать ее параметры. Функции управления и мониторинга могут быть реализованы в обособленной ИС. Она объединяет средства управления и мониторинга TPM и средства управления платформой и СУБД. Тогда мы имеем единообразный способ мониторинга и контроля за всеми доступными ресурсами.
Допустимы самые различные критерии оценки приложений и ПО промежуточного слоя и вообще программных систем. Среди них - удобство в использовании, степень распределенности и интегрируемости, соответствие стандартам, расширяемость, возможности интернационализации, управляемость, производительность, переносимость, надежность, масштабируемость и безопасность. Мы называем эти параметры общими свойствами системы (pervasive attributes), поскольку они применимы ко всей системе в целом, а не только к ее компонентам.
Разумеется, пользователи хотели бы иметь информационные системы с высокими показателями по каждому из свойств. Этой цели можно достичь, разрабатывая приложения на основе сервисов ПО промежуточного слоя. При этом системные проектировщики могут предпринять усилия по улучшению качественных показателей системы за счет специальных стандартизованных решений.
Сегодня системное проектирование - по преимуществу деятельность, определяемая конкретной ситуацией. Для некоторых общих свойств системы, например, производительности и надежности, существуют известные методы измерения и анализа. К большинству общих свойств теоретические или технические методы плохо применимы, здесь уместны здравый смысл и рациональные процессы проектирования.
Современное ПО промежуточного слоя недолго будет оставаться разнородным. Поэтому, разрабатывая новую сервис ПО промежуточного слоя, производитель должен немедленно найти способ сделать этот сервис стандартом де-факто. Разработчики приложений не станут использовать сервис, не будучи уверены в том, что он станет фактическим стандартом.
Крупные организации уже опираются на ПО промежуточного слоя в своем движении к развитым информационным службам. Тенденции упрощения ПО промежуточного слоя и расширения его функций в новых областях приложений в будущем сделают эту зависимость еще сильнее.