Middleware: модель сервисов распределенной системы

Другой пример. Многие производители реализовали протокол IBM 3270 с тем, чтобы обеспечить взаимодействие с приложениями для мэйнфреймов IBM. Отметим, что вообще-то они (производители) предусмотрели в своих разработках иные программные интерфейсы. Однако поскольку они все-таки поддерживают протокол IBM 3270, их системы могут взаимодействовать с системами IBM.

Чтобы помочь потребителям решить проблемы неоднородности и распределенности и сделать возможной реализацию информационных служб, производители предлагают сервисы распределенной системы, которые обладают стандартными программными интерфейсами и протоколами. Такие сервисы называются сервисами промежуточного (среднего) слоя (middleware services), поскольку располагаются "в середине", занимая промежуточный уровень между операционными системами и сетевым программным обеспечением с одной стороны, и приложениями, ориентированными на конкретную прикладную область, с другой стороны.

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

Для многих вновь разрабатываемых приложений компоненты ПО промежуточного слоя становятся более важными, чем операционные системы и сетевые сервисы, от которых раньше зависело приложение. Так, вновь разрабатываемые приложения в большинстве случаев опираются на сервис реляционных СУБД (а не на файловый сервис ОС), на механизм RPC (а не на механизм передачи сообщений). В общем, ПО промежуточного слоя заменяет "нераспределенную" функциональность операционных систем на "распределенную" функциональность, которая строится на основе компьютерной сети (распределенные базы данных, удаленный доступ к файлам, удаленный вызов процедур).

Для многих приложений программный интерфейс, предоставляемый ПО промежуточного слоя, фактически определяет вычислительную среду. Например, многие приложения трактуют таким образом языки четвертого поколения (4GL), мониторы обработки транзакций (IBM CICS, DEC ACMSxp) и офисные интегрирующие системы ( Lotus Notes, DEC LinkWorks).

Унаследованные приложения (legacy applications), разработанные еще до того, как мобильное ПО промежуточного слоя стало фактическим стандартом, также могут воспользоваться его сервисами. Можно определить унаследованное приложение как набор функций и воспользоваться коммуникационными сервисами ПО промежуточного слоя для обеспечения удаленного доступа к этим функциям. Для этой цели можно, например, воспользоваться реализацией Common Object Request Broker Architecture (CORBA) консорциума Object Management Group (OMG). Это предполагает использование объектно-ориентированного интерфейса прикладного программирования (API) для связывания с удаленными приложениями (объектами) и их вызовом либо через статичный (как суррогаты удаленных процедур) интерфейс, либо через динамический интерфейс (в форме Call (имя приложения, параметр1, параметр2,...)). Можно также обеспечить расширенный интерфейс к унаследованному приложению посредством использования высокоуровневых сервисов ПО промежуточного слоя, например, перехватывая операции ввода-вывода алфавитно-цифрового терминала и транслируя их в операции графического интерфейса пользователя. Другой вариант заключается в том, что некоторые внутренние компоненты унаследованного приложения подменяются сервисами ПО промежуточного слоя. Например, можно заменить в приложении вызовы функций конкретной СУБД на вызовы сервисов ПО промежуточного слоя, отвечающих за работу с базами данных.

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

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

Сервисы ПО промежуточного слоя

Мы описываем свойства ПО промежуточного слоя, проблемы, которые оно может решить, и задачи, решение которых лежит вне спектра его возможностей (см. также [4]).

Сервис ПО промежуточного слоя (middleware service) — сервис общего назначения, который располагается между платформами и приложениями (см. Рис. 2). Под платформой мы подразумеваем набор низкоуровневых сервисов и функциональные особенности, определяемые парой: архитектура процессора и API операционной системы, например, Intel x86 и Win32, SunSPARC и Solaris, IBM RS/6000 и AIX, Alpha AXP и OpenVMS, или Alpha AXP и Windows NT.

Сервис ПО промежуточного слоя определяется интерфейсами прикладного программирования и протоколами, их поддерживающими. Сервис может иметь множество реализаций, соответствующих спецификациями его интерфейса и протокола, как, например, различные реализации DCE RPC и протокола IBM 3270, упомянутые выше.

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

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

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

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

Сервис ПО промежуточного слоя является распределенным. Это означает, что к нему возможен удаленный доступ (например, сервис СУБД), либо он обеспечивает удаленный доступ к другим сервисам и приложениям (например, коммуникационный сервис). Сервис ПО промежуточного слоя, к которому возможен удаленный доступ, обычно включает клиентскую часть (client part), которая содержит интерфейс прикладного программирования (API) сервиса, функционирующий в адресном пространстве приложения, и серверную часть (server part), которая содержит главные функции сервиса и может функционировать в другом адресном пространстве (например, в другой системе). Допускается множество реализаций каждой части.

В идеале, сервис ПО промежуточного слоя поддерживает стандартный протокол (например, TCP/IP или стек протоколов ISO OSI), или, по крайней мере, опубликованный протокол (например, IBM SNA LU6.2). Таким образом можно разработать множество реализаций сервиса, и все они будут взаимодействовать между собой. Однако, если сервис ПО промежуточного слоя действительно работает на всех популярных платформах, его можно рассматривать как стандартный, даже если его протоколы не опубликованы. Таким свойством обладает, например, большинство СУБД. Если охват платформ достаточно широк, потребители, как правило, не требуют от производителей соответствия стандарту протокола. Например, протокол "клиент/сервер" SQL Access Group не снискал широкого признания, хотя принятый этим консорциумом интерфейс прикладного программирования ODBC имеет большой успех, поскольку Microsoft обеспечила его поддержку в своем семействе операционных систем Windows.

Сервис ПО промежуточного слоя должен поддерживать стандартный API. Он (сервис) является прозрачным (transparent) по отношению к API, если к нему обеспечен доступ посредством API, но при этом не требуется модификация последнего. Непрозрачное (nontransparent) ПО промежуточного слоя требует нового интерфейса. ПО промежуточного слоя, прозрачное по отношению к стандартному API, быстро получает признание на рынке, поскольку приложения, которые используют существующий API, могут обращаться к новому сервису без модификации. Например, в рамках интерфейса прикладного программирования, обеспечивающего доступ к разделяемым файлам (такого, как DEC PATHWORKS), было реализовано несколько различных протоколов доступа к распределенным разделяемым файлам. Продукт PATHWORKS включает файловый сервис для персональных компьютеров.

Если производитель ПО обеспечивает широкий охват платформ и обладает значительной долей рынка, то поддерживаемый им интерфейс прикладного программирования и протокол можно рассматривать как фактический стандарт, даже если ни интерфейс, ни протокол не имеют в виду другие производители. Например, в реляционных СУБД ORACLE и SYBASE поддерживаются собственные диалекты языка SQL, и при этом они рассматриваются большинством потребителей как фактический стандарт. Аналогично монитор обработки транзакций CICS корпорации IBM использует собственные интерфейс прикладного программирования и протокол (LU6.2), и, тем не менее, является фактическим стандартом.

Вопрос о том, относится ли данный сервис к ПО промежуточного слоя, со временем решается по-разному. Компонент, который в данный момент рассматривается как часть платформы, может в будущем стать ПО промежуточного слоя. В результате реализация ОС упростится, а сервисы, предоставляемые данным компонентом, станут общедоступными для всех платформ. Например, мы рассматривали традиционную файловую систему как стандартный компонент операционных систем, каковой она несомненно была во всех коммерческих ОС, разработанных до 1980 года. Однако сегодня мы часто рассматриваем файловую систему как ПО промежуточного слоя — имея в виду, например, реализации, соответствующие стандарту API X/Open C-ISAM. Напротив, ПО промежуточного слоя может быть встроено в платформу, чтобы улучшить ее производительность и повысить коммерческую ценность платформы. Например, стек протокола транспортного уровня раньше часто рассматривался как продукт, обеспечивавший доступ к коммуникационным сервисам, как продукт, независимый от ОС. Теперь он обычно включаются в ОС (наглядный пример — поддержка TCP/IP в Windows'95).

Ввиду того значения, которое имеют стандартные интерфейсы для переносимости приложений, а стандартные протоколы — для их взаимодействия, ПО промежуточного слоя стало объектом усилий по стандартизации. Некоторые из них были предприняты организациями, вырабатывающими стандарты, например, ISO и ANSI, некоторые — консорциумами производителей, такими как X/Open, OSF и OMG, а некоторые получили поддержку компаний, занимающих значительную долю рынка ПО. Например, архитектура Windows Open Services Architecture (WOSA) стала результатом усилий компании Microsoft. Кстати, существование консорциумов производителей и их растущее влияние на продукты само по себе является свидетельством значимости ПО промежуточного слоя. Иногда отдельный сервис получает наибольшее распространение и поэтому становится фактическим стандартом, как, например, Adobe PostScript, монитор транзакций IBM CICS и Network File Service (NFS) компании Sun Microsystems.

Усилия по стандартизации приводят к появлению корпоративных стандартов. То есть, правительства и компании выбирают какие-либо стандарты и выдвигают их в качестве требований к производителям, чтобы гарантировать, что сходные продукты, полученные от разных производителей, будут поддерживать одни и те же приложения и взаимодействовать между собой. Некоторые примеры стандартов, ориентированных на потребителя, — Government Open System Interconnect Profile (GOSIP) правительства США и Multivendor Integration Architecture (MIA) компании Nippon Telegraph and Telephone. Отметим, что работа над стандартом MIA привела к появлению консорциума SPIRIT, охватывающего, помимо телекоммуникаций, и другие отрасли.

Производители ПО часто реагируют на появление стандартов, включая в свои продукты полезную функциональность, не соответствующую, однако, стандарту. Тем самым они пытаются вызвать ажиотажный спрос на свои продукты и "привязать" своих клиентов к функциям, которых нет в конкурирующих продуктах, соответствующих стандарту. Например, именно таким образом производители реляционных СУБД в течение многих лет расширяли и продолжают расширять функциональность языка SQL. В то же время комитеты и консорциумы по стандартизации стараются не отставать от них, обобщая функциональность, реализованную производителями в своих продуктах и формируя на ее основе новые стандарты языка SQL.

Следующие компоненты являются или могли бы быть сервисами ПО промежуточного слоя:

• Управление представлением (presentation management): менеджер форм, менеджер графики, компоновщик гиперсреды (hypermedia linker) и менеджер печати.
• Вычисление (computation): сортировка, математические расчеты, сервисы интернационализации (для манипуляции с символами и строками), конверторы данных и служба времени.
• Управление информацией (information management): сервер каталогов, менеджер регистрации, менеджер файлов, менеджер записей, реляционные СУБД, объектно-ориентированные СУБД, менеджер репозитория.
• Коммуникации (communication): передача сообщений по схеме "равный-с-равным", удаленный вызов процедур, управление очередями сообщений, электронная почта, электронный обмен данными.
• Средства управления (control): менеджер потоков (thread), менеджер транзакций, диспетчер ресурсов, планировщик запросов, планировщик заданий.
• Средства администрирования (system management): служба уведомления о событиях, служба учета (accounting service), менеджер конфигурации, менеджер установки ПО, детектор сбоев, координатор восстановления, сервис аутентификации, сервис аудита, сервис криптозащиты, контроллер доступа.

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

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

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

Но сервисы ПО промежуточного слоя нельзя рассматривать как панацею. Во-первых, существует определенное расхождение между принципами и практикой. Многие популярные сервисы ПО промежуточного слоя используют собственные интерфейсы прикладного программирования. Из-за этого приложения обычно оказываются зависимы от программного продукта одного производителя. Кроме того, сервисы в ряде случаев опираются на закрытые, неопубликованные протоколы. Из-за этого производителям платформ сложно перенести сервис на собственную платформу так, чтобы он взаимодействовал с реализациями того же сервиса, но на других платформах. Например, как указывалось выше, во многих реляционных СУБД поддерживаются собственные диалекты SQL и собственные протоколы. Некоторые из них недоступны на многих популярных платформах, что ограничивает потребителя в выборе платформ и сужает его возможности при работе в неоднородных системах. Это замечание относится, например, к реляционным СУБД Rdb корпорации Oracle (ранее система принадлежала DEC) и DB2 корпорации IBM. Даже если сервис ПО промежуточного слоя является высокотехнологичным программным продуктом, разработчик приложения, которое опирается на данный сервис, принимает на себя новую форму риска — риск, что этот сервис не сможет идти в ногу с технологией. Например, многие приложения, использовавшие сетевые СУБД (стандарт CODASYL) пришлось переписывать, чтобы воспользоваться преимуществами реляционных СУБД, которые пришли на смену сетевым в качестве фактического стандарта.

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

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

Интегрирующая среда

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

Приведем примеры ИС. Это — так называемые офисные системы (Lotus Notes, Microsoft Office, DEC LinkWorks), мониторы транзакций (IBM CICS, DEC ACMSxp, BEA Systems Tuxedo, Transarc Encina), языки четвертого поколения (Uniface, Cognos, Focus), системы автоматизированного проектирования (Mentor Graphics Falcon, DEC Powerframe), CASE-системы (HP SoftBench, Texas Instruments Composer by IEF, Andersen Consulting Foundation, DEC COHESIONworX), и системы управления распределенными ресурсами (HP OpenView, Tivoli Management Environment, IBM NetView).

Интегрирующая среда — это один из видов ПО промежуточного слоя.

Для ясности мы далее используем термин "сервис ПО промежуточного слоя" (middleware services) применительно к базисным сервисам распределенных систем, а "ПО промежуточного слоя" (middleware) — применительно к сервисам ПО промежуточного слоя и/или интегрирующей среде.

Интерфейс прикладного программирования интегрирующей среды обычно представляет собой профиль (profile) интерфейсов прикладного программирования к сервисам ПО промежуточного слоя. В ряде случаев он может быть новым API, который упрощает интерфейсы базисных сервисов ПО промежуточного слоя. Например, интерфейс прикладного программирования интегрирующей среды системы автоматизированного проектирования (САПР) или CASE-системы может включать интерфейсы сервиса представления, сервиса, обеспечивающего вызов компонентов инструментария, и сервиса репозитория (для хранения разделяемых этими компонентами данных). Интерфейс прикладного программирования интегрирующей среды может быть также просто объединением интерфейсов этих сервисов. Если интерфейс интегрирующей среды отличается от интерфейсов базисных сервисов, он представляет собой своего рода "оболочку", покрывающую базисные сервисы с общим синтаксисом. Однако в большинстве случаев интерфейс интегрирующей среды все-таки обладает расширенными возможностями по сравнению с интерфейсами базисных сервисов. Такими возможностями могут быть, например, специализированный интерфейс с пользователем, упрощение интерфейса прикладного программирования за счет поддержки разделяемого контекста, возможность вызова собственных (частных) сервисов конкретной интегрирующей среды. Например, во всех известных нам мониторах обработки транзакций возможности интерфейса прикладного программирования расширены именно таким образом.

Иногда сервисы ПО промежуточного слоя вырастают до масштабов ИС. Так произошло с инструментарием для работы с реляционными СУБД. Из элементарных интерактивных средств формирования и выполнения SQL-запросов они превратились в сложные системы с комплексным набором инструментов. Иногда набор сервисов интегрирован в такой степени, что фактически превращается в ИС. Например, в OSF DCE интегрированы сервис удаленного вызова процедур, сервис имен, сервис аутентификации, служба времени, сервис идентификации и файловый сервис. Отметим, что в DCE нет как такового обобщенного интерфейса пользователя, и весь интерфейс прикладного программирования DCE — это, собственно, API упомянутых выше сервисов. Тем не менее, DCE поддерживает контекст вызовов (по идентификатору пользователя), и обеспечивает прозрачный вызов сервисов для упрощения некоторых операций, например, прозрачного вызова сервиса имен с целью поиска сервера, который может обработать вызов RPC.

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

ИС может включать собственный интерфейс пользователя, который является специализацией графического интерфейса пользователя (GUI), предоставляемого базисной платформой. Например, GUI интегрирующей среды — офисной системы должен обеспечивать адекватный внешний вид рабочей области и поддерживать работу с пиктограммами и форматами, понятными пользователю офисных приложений. Если ИС поддерживает работу с несколькими оконными системами (скажем, Motif, Microsoft Windows и Macintosh), специализация собственного GUI интегрирующей среды должна быть выполнена так, чтобы облегчить пользователям перемещение между различными системами (например, между мобильным персональным компьютером под управлением Windows и рабочей станцией под управлением Unix).

Один из методов, при помощи которого упрощается интерфейс прикладного программирования интегрирующей среды — сохранение контекста вызова различных сервисов. Например, в большинстве ИС вызовы сервисов требуют в качестве параметров идентификатор пользователя (для контроля доступа) и идентификатор устройства (для установления связи). ИС трактует эти идентификаторы как контекст приложения, но не как параметры, упрощая таким образом API. Например, CASE-система COHESIONworX поддерживает контекст, включающий имя пользователя, имя дисплея и рабочую область, содержащую каталоги файлов и указатели на объекты. Поддержка контекста не является уникальным свойством ИС. Сервис тоже может поддерживать контекст, хотя этот контекст обычно бывает локальным по отношению к данному сервису. Например, DCE RPC сохраняет идентификатор пользователя между вызовами удаленных процедур.

ИС может предоставлять упрощенный API, имея в своей основе модель, которая не требует вызова всех функций сервисов ПО промежуточного слоя. Например, CASE-система может предложить упрощенный интерфейс для управления конфигурацией разрабатываемого программного обеспечения, который затрагивает далеко не все функции менеджера репозитория.

ИС иногда может включать частные сервисы ПО промежуточного слоя. Обычно это происходит потому, что интегрирующей среде необходим сервис, а такого стандартного сервиса ПО промежуточного слоя не предоставляет. Например, многие мониторы обработки транзакций используют частную реализацию удаленного вызова процедур, однако при наличии DCE на базисной платформе, некоторые из них заменяют свои собственные реализации RPC стандартной реализацией. Другой пример. CASE-системы и системы автоматизированного проектирования часто предлагают специфичные для интегрирующей среды сервисы управления конфигураций и управления версиями. В будущем эти частные сервисы могут быть заменены на стандартные сервисы ПО промежуточного слоя. Это произойдет, если в качестве фактического стандарта будет принята одна из технологий репозитория.

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

Компонент инструментария — инструмент (tool) — является частью интегрирующей среды, если он интегрирован с другими ее элементами по данным, по управлению или по представлению. Интеграция по данным предполагает, что инструмент использует данные (обычно постоянные) совместно с другими инструментами, которые являются частью ИС. При этом требуется, чтобы инструменты использовали одну и ту же модель объектов (абстрактную модель, определяющую форматы данных) и, собственно, сами форматы разделяемых данных. Иногда формат задается одним инструментом, который владеет данными и экспортирует их. В этом случае другие инструменты могут ссылаться на эти данные при условии, что они "понимают" их формат (примером может служить словарь данных в реляционной СУБД). В других случаях данные в равной степени используются двумя или более инструментами, что легче организовать, если все эти инструменты выпускает один производитель. Например, CASE-системы включают репозиторий, который совместно используют инструменты анализа, проектирования и генерации кода программ. В качестве примера можно привести CASE-системы Andersen Consulting Foundation или Texas Instruments Composer by IEF. Точно так же среда программирования 4GL обычно включает словарь данных, который совместно используют менеджер форм, программы на языке запросов и языке прикладного программирования.

Инструментарий может распределять оперативный доступ к хорошо детализированным данным (как в приведенных выше примерах с каталогом базы данных, репозиторием CASE-системы и словарем среды программирования на 4GL), или обеспечивать передачу данных между инструментами (например, используя формат CASE Data Interchange Format для обмена между CASE-инструментами или формат Express для обмена между инструментами системы автоматизированного проектирования). Все это он делает вне зависимости от того, находятся ли данные во владении одного инструмента или в равной степени совместно используются многими. Если доступ к данным происходит в оперативном режиме, возможно, что от инструмента потребуется совместимость по протоколу, то есть по набору допустимых операций над данными и последовательностей таких операций.

При интеграции по управлению инструменты ИС могут вызывать друг друга и обмениваться данными и управляющими директивами. Это предполагает, что интерфейс инструмента должен быть стандартизован хотя бы в рамках ИС. Должен быть также определен формат вызова инструмента (или создания его экземпляра в случае необходимости), и формат обмена сообщениями между инструментами. Например, в продуктах DEC COHESIONworX, HP SoftBench, Sun SPARCWorks каждый инструмент ИС может отправить сообщение, которое направляется всем инструментам, ранее "подписавшимся" на получение сообщений данного типа. Иногда бывает полезным, чтобы инструмент работал в системе, отличной от той, в которой функционирует ИС.

В этом случае интеграция по управлению требует вызова удаленного сервиса. Например, DEC COHESIONworX использует для вызова удаленных инструментов реализацию CORBA (DEC Object Broker).

При интеграции по представлению инструмент использует дисплей совместно с другими инструментами, функционирующими в рамках ИС. Как правило, стиль пользовательского интерфейса конкретного инструмента соответствует стилю, принятому для инструментария ИС. Обычно это достигается за счет использования одного и того же GUI и принятия стандартных соглашений об использовании элементов интерфейса — скажем, предложения семантики, сходной с семантикой абстрактных операций (например, "вырезать" (cut), "вставить" (paste)). Стиль интерфейса может определяться некоторой метафорой, например, метафорой рабочего стола. Это приводит, в свою очередь, к принятию соглашений об использовании пространства экрана, форматов элементов интерфейса (например, панели управления) и т.д. Иногда интеграция по представлению выдвигает требования к интеграции по данным и по управлению. Например, если из редактора составных документов вызывается электронная таблица, необходима как интеграция по данным (содержание электронной таблицы должно быть включено в документ), так и интеграция по управлению (из редактора необходим запуск приложения, обрабатывающего электронные таблицы).

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

Интеграцию по представлению и по управлению часто бывает легче реализовать, чем интеграцию по данным. При интеграции по управлению каждый инструмент может быть интегрирован независимо, путем определения его интерфейсов и обеспечения доступа к ним посредством коммуникационного сервиса. Эта работа локализуется в интерфейсе инструмента и не требует модификаций в теле инструмента. То же самое верно и для интеграции по представлению. Интеграция инструмента сводится к переопределению его интерфейса путем перехвата операций терминального ввода-вывода и их трансляции в операции GUI. Напротив, интеграция по данным требует, чтобы все разработчики инструментов договорились об общем формате данных, которые они (инструменты) будут совместно использовать. Поскольку операции доступа к данным не локализованы и заданы в нескольких фрагментах реализации инструмента, изменение форматов данных часто бывает утомительным и дорогостоящим делом. Изменения в инструменте можно локализовать, создав представления (view) разделяемых данных, что обеспечивает инструменту доступ к разделяемым данным в их исходном формате. Однако менеджеры разделяемых данных часто не поддерживают представлений вообще или поддерживает необновляемые представления, что делает такой подход несостоятельным.

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

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

Для иллюстрации концепции ПО промежуточного слоя рассмотрим один из видов ИС — мониторы обработки транзакций (Transaction Processing Monitor — TPM) [1]. Основная функция TPM — управление потоком запросов между терминалами или другими устройствами и прикладными программами, которые могут обрабатывать эти запросы. Запрос (request) — это специфическое сообщение, инициирующее выполнение транзакции. Приложение, которое выполняет транзакцию, обычно имеет доступ к менеджерам ресурсов, например, к СУБД. Типичный TPM включает функции управления транзакциями, средства для организации межпроцессного взаимодействия, средства управления очередями запросов и средства управления формами и меню (см. Рис. 4).

Управление транзакциями предполагает наличие операций начала, фиксации и отката (прерывания) транзакции, а также интерфейсов к менеджерам ресурсов. Интерфейс к менеджеру ресурсов обеспечивает, помимо других, следующие возможности. Менеджер ресурсов оповещает менеджер транзакций, что текущая транзакция получила к нему доступ, а менеджер транзакций сообщает менеджеру ресурсов об успешном завершении или прервании транзакции. В TPM реализован двухфазный протокол фиксации транзакций, гарантирующий одновременное успешное завершение или откат транзакции несколькими вовлеченными в нее менеджерами ресурсов (см. [2]).

TPM поддерживают традиционные возможности межпроцессного взаимодействия, когда один процесс передает некоторый фрагмент своего контекста другому процессу — и все это в рамках одной транзакции. Это, как правило, либо взаимодействие по схеме "равный-с-равным" ("отправить сообщение", "получить сообщение"), или стандартный либо несколько модифицированный механизм RPC ("отправить запрос", "получить ответ").

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

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

Традиционно в TPM эти функции были реализованы как специальные сервисы интегрирующей среды, которые, в свою очередь, опирались только на сервисы платформы. Сегодня многие из этих сервисов ИС определены как сервисы ПО промежуточного слоя. Разрабатываемые сегодня мониторы обработки транзакций обращаются к таким стандартным сервисам, как менеджеры записей, менеджеры транзакций и менеджеры очередей. Доступ к ним возможен непосредственно из приложений или через другие сервисы ПО промежуточного слоя (например, СУБД) или через интегрирующую среду (например, офисную систему).

Делаются попытки стандартизации API и протоколов всех описанных выше сервисов. Так, например, консорциум X/Open работает над стандартами API для управления транзакциями и коммуникациями (стандарт X/Open ATMI — Application — Transaction Management Interface), а ISO — над стандартным протоколом для управления очередями.

Традиционно большинство TPM зависели от платформы, для которой и были созданы. Современные мониторы обработки транзакций опираются на сервисы ПО промежуточного слоя и обладают большей переносимостью, так как в их основу положены сервисы ПО промежуточного слоя, которые переносимы сами по себе — например, OSF DCE. Поэтому такие TPM можно переносить на самые разные платформы. Так, в IBM создана новая реализация монитора обработки транзакций CICS, которая построена на сервисах ПО промежуточного слоя, предоставляемых компанией Transarc. Было объявлено, что эта реализация, помимо IBM RS/6000 AIX, будет работать и на других Unix-платформах.

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

Например, приложение может потребовать поместить сообщение в очередь; в этом случае TPM добавит в качестве параметров идентификатор текущей транзакции (чтобы менеджер очереди мог сообщить менеджеру транзакции, что транзакция получила к нему доступ) и идентификатор пользователя (чтобы менеджер очереди мог проверить авторизацию пользователя).

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

TPM обычно включает инструментарий прикладного программирования. Например, в него может входить словарь данных, используемый менеджером форм, приложениями и СУБД. DEC использует для этой цели собственный словарь данных Common Data Dictionary/Repository (для интеграции TPM ACMS, реляционной СУБД Rdb, менеджера форм DECforms). Это — пример интеграции по данным. TPM также может включать CASE-средства для разработки приложений, которые существенно упрощают использование инструментов для компиляции кода, управления конфигурацией приложений и их тестирования, как, например, DECadmire и TP Workcenter. Это — пример интеграции по управлению и по представлению.

TP-монитор также включает средства системного управления и мониторинга. Они позволяют отображать состояние транзакции или запросов, следить за показателями производительности системы и настраивать ее параметры. Функции управления и мониторинга могут быть реализованы в обособленной ИС. Она объединяет средства управления и мониторинга TPM и средства управления платформой и СУБД. Тогда мы имеем единообразный способ мониторинга и контроля всех доступных ресурсов.

Большинство потребителей приобретают полную TPM-систему у одного производителя; в нее входят монитор обработки транзакций, СУБД и платформа. Он (производитель) может быть, а может и не быть одновременно владельцем TP-монитора. В любом случае производитель отвечает за работоспособность TPM-системы в целом, гарантируя, что она обеспечивает адекватную производительность, надежность, удобство использования и т.д.

Lotus Notes

Рассмотрим систему Lotus Notes как еще один пример интегрирующей среды, удачно иллюстрирующий приведенные выше тезисы. Lotus Notes обеспечивает разработку и выполнение приложений, которые создают, организуют и совместно используют информацию, представленную в виде документов. Ниже мы опишем некоторые ключевые возможности Lotus Notes в терминах изложенной выше модели сервисов распределенной системы.

Приложения Lotus Notes хранятся в базах данных на серверах локальных компьютерных сетей. Каждая база данных содержит документы, формы (которые определяют внешний вид документов, включающих разнородную информацию: текст, видео-, аудио-информацию) и виды (которые отражают различные подмножества множества всех документов и упорядочивают документы по категориям, а также определяют, какая информация будет отображаться по каждому документу). Наличие средств работы с формами, видами и специального языка описания формул, сходного с языком электронных таблиц, позволяет переложить большую часть работы по созданию приложений на специалистов, которые не обладают квалификацией 3GL- или 4GL-программистов. Управление базами данных централизовано незначительно. На каждом сервере Lotus Notes (т.е. для каждой инсталляции Lotus Notes) базы данных определены и поддерживаются независимо друг от друга. Тем не менее, такие базы данных связаны между собой. Для отслеживания связей и управления базами данных используются сервисы ПО промежуточного слоя.

Lotus Notes R3.0 имеет трехуровневую структуру: уровень сервисов платформы, уровень сервисов ПО промежуточного слоя, доступ к которым осуществляется через интегрированный API, уровень инструментария (см. Рис. 5). Уровень сервисов платформы представлен набором сервисов для управления памятью, файлами, процессами и окружением (environment). Данные сервисы имеют одинаковую семантику в разных версиях для многих платформ, таких как Microsoft Windows, Apple Macintosh, IBM OS/2, Novell NetWare и нескольких реализаций Unix. Цель этого — обеспечить переносимость сервисов следующего уровня. Уровень платформы включает также функции для работы с элементарными типами данных.

На этом уровне также определены и используются функции для управления представлением для различных платформ и функции, обеспечивающие двоичную совместимости приложений, баз данных и сетевых сообщений. Строго говоря, эти функции не являются функциями платформы. Дело в том, в архитектуре Lotus Notes имеет место сетевой компонент, который изолирует более высокие уровни от сетевых архитектур. Кроме того, он скрывает детали транспортного уровня передачи сообщений. В архитектуре Lotus Notes также имеет место не зависящий от платформы интерфейс с пользователем, который скрывает от более высоких уровней детали и различия в оконных системах. Изоляция ИС или сервисов ПО промежуточного слоя от платформы при помощи сервисов, описанных выше, является общепринятой практикой. Например, таким образом построено большинство переносимых СУБД и TP-мониторов.

Многие специфичные для ИС независимые от платформы сервисы ПО промежуточного слоя расположены выше уровня сервисов платформы. Доступ к ним осуществляется через С-функции, которые определяют Lotus Notes API. Определены следующие сервисы:

• сервис управления объектами — обеспечивает обработку элементарных типов данных и хранение недетализированной информации;
• сервис управления документами — использует сервис управления объектами, именует документы, организует их и поддерживает язык формул (язык сценариев для создания приложений);
• сервис защиты — поддерживает шифрование, цифровые подписи, произвольное управление доступом; использует сервис RSA Data Security;
• сервис индексации — обеспечивает индексированный доступ к содержанию документов (за счет использования средств контекстного поиска компании Verity Corp.) и к дескрипторам документов;
• сервис сообщений — поддерживает адресацию (в том числе адресацию к группам имен и иерархически организованным именам) и передачу почтовых сообщений;
• сервис событий — осуществляет оповещение посредством почтовых сообщений или за счет использования механизма регистрации;
• сервис регистрации — выполняет функции аудита событий, происходящих в базах данных;
• сервис именования — поддерживает взаимодействие клиента и сервера; интегрирован с транспортным сервисом и сервисом защиты, что очень напоминает архитектуру DCE (система Lotus Notes — предшественница DCE);
• функции управления системой, в том числе функции управления конфигурацией приложений, установки сервера Lotus Notes и администрирования (обеспечивает управление системой с удаленной консоли).

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

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

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

Router — данный компонент передает почтовые сообщения между серверами.

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

Chronos — это фоновый процесс, который выполняет формулы (на языке формул).

Event, Report — представляют собой процессы (программы) администрирования.

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

В Lotus Notes поддерживается множество других инструментов, в том числе инструмент для редактирования форм (Editor), средство создания видов и навигации по видам (View), инструмент для организации доступа к приложениям (Desk). Каждый инструмент также включает частный сервис для конкретных функций, например, проверки орфографии, отправки сообщений и преобразования форматов документов. Lotus Notes — типичная интегрирующая среда нового типа, в том смысле, что использует специфичные для ИС сервисы ПО промежуточного слоя и уникальный API интегрирующей среды. Если и другие ИС подобного типа завоюют популярность, то можно ожидать появления общих для них сервисов ПО промежуточного слоя и стандартного API.

Интеграция сервисов ПО промежуточного слоя

Важнейший способ придания дополнительных потребительских качеств сервисам ПО промежуточного слоя заключается в их интеграции. Можно, например, предусмотреть, чтобы сервисы использовали общие соглашения именования, обладали сбалансированными характеристиками производительности, поддерживали одни и те же наборы международных символов и выполнялись на одних и тех же платформах. Такого рода интегрированные сервисы выступают в качестве компонентов ИС. Однако это не является обязательным. Например, OSF DCE представляет собой интегрированный набор сервисов, которые, тем не менее, в совокупности не являются ИС. Интегрированную систему от простой коллекции общесистемных сервисов отличает то, что в ИС они хорошо работают вместе. Деятельность по созданию такой интегрированной системы из независимо разрабатываемых элементов-частей называется системным конструированием (system engineering).

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

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

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

Кроме собственно принципов и методов интеграции сервисов ПО, важно также иметь адекватные способы оценки ее результатов. Что касается оценки свойств производительности, то принято характеризовать систему по ее поведению в эталонных тестах. Для некоторых свойств можно оценивать систему, исходя из ее функциональных возможностей (например, критерии безопасности согласно "Оранжевой Книге" Министерства обороны США). Другие свойства оценить много труднее, поскольку не существует общепринятых методов измерения (например, свойства расширяемости или удобства в использовании). Разработка методов измерения ряда диффузионных свойств также открывает большие возможности для исследований.

Тенденции

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

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

Сегодня ПО промежуточного слоя слишком неоднородно, с чем приходится мириться как потребителям, так и разработчикам. Потребители и организации, разрабатывающие стандарты, решают эту проблему, предлагая профили, в которые входит некоторое подмножество множества сервисов ПО промежуточного слоя, покрывающее ограниченный набор принципиально важных функций (без дублирования, т.е. по одному сервису на каждую функцию). Один из наиболее известных профилей — X/Open Portability Guide [7]. К сожалению, для разных профилей выбираются различные сервисы, что тяжким грузом ложится на производителей ПО, которые стремятся продавать свои продукты клиентам, требующим разных профилей. В конечном счете это наносит вред пользователям, поскольку производители ПО вынуждены вкладывать свои усилия в разработку различных профилей. Группы по разработке стандартов начинают относиться к этой проблеме внимательнее, и более серьезно работают над тем, чтобы скоординировать свои усилия во избежание распространения конкурирующих стандартов. В конце концов рынок все расставит по своим местам, когда определенные компоненты и профили превратятся в недорогие потребительские товары. Появление на рынке нестандартных компонентов и их конкуренция с общепринятыми решениями станут невозможными.

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

Производители ПО тоже реагируют на неоднородность ПО промежуточного слоя. Они сформировали консорциумы — часто совместно с большими компаниями-потребителями ПО — для создания профилей, нужных и производителям, и пользователям. В качестве примера можно упомянуть X/Open и Object Management Group. Консорциумы также работают над интеграцией наборов сервисов ПО промежуточного слоя, с тем чтобы результат такой интеграции можно было использовать в качестве готового решения. Например, OSF DCE интегрирует RPC со службой каталогов, службой времени, службой безопасности и файловым сервисом [6]. OSF пытается работать в том же стиле над средой распределенного управления (Distributed Management Environment — DME) [3]. Отдельные производители ПО публикуют те интерфейсы ПО промежуточного слоя, которым они отдают предпочтение. Цель — сообщить разработчикам приложений, на что те могут рассчитывать. Например, DEC делает ставку на Network Application Support (NAS) [5], а Microsoft — на Windows Open Services Architecture (WOSA).

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

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

Литература

1. P.A Bernstein -- Transaction Processing Monitors -- Commun. ACM 33, 11, 75-88, Nov. 1990
2. P Bernstein , N. Goodman , N Goodman -- Concurrency Control and Recovery in Database Systems -- Addison-Wesley, Reading, Mass., 1987
3. D Chappell -- The OSF disrtibuted management envirnment -- ConneXions 6, 10, 10-15, Oct. 1992
4. S.S King -- The OSF distributed management environment -- Data Communications, 58-67, Mar. 1992
5. L Laverdure , J. Collonna-Romano , P Srite -- Network Application Support Architecture Reference Manual -- Digital Press, 1993
6. W. Rosenberry , D. Kenney , G. Fisher -- Understanding DCE -- O'Reily, Sebastopol, Calif., 1992
7. X/Open Portability Guide -- The X/Open Company, Reading, England