В статье классифицируется программное обеспечение промежуточного слоя (middleware), описываются его свойства, рассказывается о его эволюции. Предложена концептуальная модель для понимания программного обеспечения распределенных систем сегодняшнего и завтрашнего дня.
Вычислительные средства больших компаний превращаются в обычные службы, аналогичные энергетическим и телекоммуникационным (например, телефонным) службам. С точки зрения информационной службы, любой сотрудник организации, работающий с информацией, располагает устройством, с помощью которого можно воспользоваться этой службой. Под устройством подразумевается терминал, персональный компьютер, рабочая станция и т.д. Сама по себе служба - это сеть информационных сервисов масштаба организации, объединяющая приложения и базы данных в локальных и глобальных сетях.
Серверы в локальных вычислительных сетях (ЛВС) обычно обеспечивают обработку файлов и запуск приложений, опирающихся на модель файлового сервера - например, электронную почту, доски объявлений, подготовку документов и сетевую печать. Локальные серверы поддерживают службу каталогов и предоставляют пользователям возможность поиска интересующих их сервисов и подключения к ним.
Серверы в глобальной сети отвечают за доступ к базам данных, корпоративным каталогам, электронным библиотекам. На них также могут выполняться приложения оперативной обработки транзакций (OLTP), например, программы финансовых расчетов или программы для управления движением материальных ресурсов. Некоторые серверы обеспечивают шлюзы к сервисам, существующим вне рамок организации - например, к услугам туристических фирм, информационно-поисковым службам, службам новостей (погода, котировки ценных бумаг) или службам, поддерживающим электронный обмен документами с деловыми партнерами. Ряд компаний перестраивают свои бизнес-процессы таким образом, чтобы максимально эффективно использовать указанные возможности и с этой целью создают службы, призванные обеспечить унифицированный доступ к различным источникам информации. Эти службы будут поставлять необходимую людям актуальную и значимую информацию именно в тот момент, когда она потребуется.
Информационно-вычислительные средства современных организаций - пока только некоторое приближение к модели информационных служб. Одна из причин - неоднородное аппаратное и программное обеспечение. Во многих организациях существует множество неоднородных компьютерных платформ, включая персональные компьютеры, рабочие станции, мини-компьютеры и мэйнфреймы. Эти компьютеры работают под управлением различных операционных систем (ОС) и опираются на различные сетевые архитектуры. Как следствие - интеграция сложна и ее результаты часто оказываются неполными.
Например, локальные серверы часто бывают изолированы от глобальной сети; с персонального компьютера возможен доступ к файлам и принтерам на локальном сервере рабочей группы, однако с него нельзя получить доступ к информации, расположенной на серверах других рабочих групп или в других ЛВС. Иногда приложение можно запустить только на одном локальном сервере и нельзя на других, поскольку другие отделы или рабочие группы используют серверы, на которых это конкретное приложение работать не может в принципе. Серверы в глобальных сетях также обладают рядом ограничений. Часто, например, они представляют собой серверы приложений с символьным пользовательским интерфейсом и могут поддерживать работу только с простыми алфавитно-цифровыми терминалами. В результате на персональном компьютере необходимо эмулировать терминал, чтобы получить доступ к серверу. Иногда с рабочего места можно получить доступ к серверу глобальной сети только в том случае, если соответствующими средствами доступа снабжен локальный сервер. Пользователю, возможно, придется входить в систему каждого сервера отдельно, вводя независимые пароли и имея дело с разными интерфейсами. Даже если с персонального компьютера можно получить доступ к удаленному приложению, его компоненты - электронная таблица или текстовый процессор - часто не имеют доступа к актуальным данным; чтобы обеспечить такой доступ, необходимо разработать дополнительные программы. И это только некоторые из ограничений неоднородных систем.
Многочисленные проблемы, возникающие при построении корпоративных информационных систем, заставляют компании усиливать прессинг на производителей компьютерных платформ и программного обеспечения, с тем чтобы последние оказали им помощь в интеграции распределенных систем на основе неоднородных платформ. Один из способов решения проблемы неоднородности - это поддержка стандартных программных интерфейсов. Стандартные программные интерфейсы облегчают задачу переноса приложений на серверы различных моделей и производителей, обеспечивая потребителю определенную независимость от последних. В прошлом было достаточно поддержки стандартного языка программирования, такого, как COBOL или С. Сегодня же типичное приложение может использовать базы данных, коммуникации и другие сервисы, интерфейсы к которым не являются компонентами языка или среды программирования. Условием успешного переноса приложения на другую платформу является поддержка соответствующих интерфейсов на этой другой (целевой) платформе. Поэтому пользователям необходимы интерфейсы, существующие на большинстве платформ, то есть стандартные.
Стандартные интерфейсы важны и для самих производителей серверов. Потребители покупают приложения, а не серверы. Они выберут любой сервер, на котором можно запускать необходимые им приложения. Поддерживая множество стандартных интерфейсов, производитель увеличивает число приложений, которые работают на его серверах. И это привлекает потребителей.
Другой способ, применяемый производителями для разрешения проблемы неоднородности - поддержка стандартных протоколов. Стандартные протоколы делают возможным взаимодействие программ. Говоря о взаимодействии (interoperate), мы имеем в виду, что программа в составе одной системы имеет доступ к программам и данным в составе другой системы. Взаимодействие возможно только тогда, когда две системы используют один и тот же протокол, то есть одинаковые форматы и последовательности сообщений. Кроме того, приложения, функционирующие в рамках этих систем, должны иметь сходные семантики, чтобы оба приложения правильно воспринимали контекст сообщений, которыми они обмениваются. Системы, поддерживающие один и тот же протокол, часто опираются на различные машинные архитектуры и операционные системы, и, несмотря на это, взаимодействуют друг с другом.
Например, спецификация Distributed Computing Environment консорциума Open Software Foundation (OSF DCE) включает протокол удаленного вызова процедур (Remote Procedure Call - RPC). В любую реализацию DCE RPC включен компилятор. Он транслирует описание интерфейса (на IDL - Interface Definition Language) в клиентский суррогат (client stub). Последний оформляет вызов процедуры, формируя из параметров вызова пакет (package), который доставляется серверному суррогату (server stub). Серверный суррогат раскрывает пакет и формирует локальный вызов сервера (см. рис. 1). Клиентский суррогат может паковать параметры, определенные в иной, чем у сервера, языковой среде и машинной архитектуре. Таким способом достигается взаимодействие клиента и сервера на различных платформах. Реализация RPC также включает библиотеку времени выполнения, поддерживающую обмен сообщениями на базе различных транспортных протоколов. Компания Microsoft реализовала RPC независимо, однако, взаимодействие обеспечено и с этой реализацией.
Рисунок 1.
Архитектура удаленного вызова процедур.
Другой пример. Многие производители реализовали протокол 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 и Solaris1), IBM RS/6000 и AIX, Alpha AXP и OpenVMS, или Alpha AXP и Windows NT.
Рисунок 2.
Программное обеспечение промежуточного слоя.
Сервис ПО промежуточного слоя определяется интерфейсами прикладного программирования и протоколами, их поддерживающими. Сервис может иметь множество реализаций, соответствующих спецификациями его интерфейса и протокола, как, например, различные реализации 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, быстро получает признание на рынке, поскольку приложения, которые используют существующий 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.
Следующие компоненты являются или могли бы быть сервисами ПО промежуточного слоя.
В настоящее время не все эти сервисы являются распределенными, переносимыми и стандартными. Однако значительное число из перечисленных выше сервисов может и должно быть отнесено к ПО промежуточного слоя.
Предложенные категории нетрудно оспорить. Мы просто предложили удобный способ группировки сервисов, чтобы их было легче запомнить и обсуждать.
Основное назначение сервисов ПО промежуточного слоя - помочь решению многих проблем, обсуждавшихся выше. Они (сервисы) обеспечивают интерфейс прикладного программирования, не зависящий от платформы, так что приложения будут работать на многих платформах. Они скрывают детали сетевых протоколов и распределенных систем. Сервисы ПО промежуточного слоя разрабатываются таким образом, чтобы встроить общеупотребительные функции в независимые компоненты, которые затем можно распределить по различным платформам и программным средам.
Но сервисы ПО промежуточного слоя нельзя рассматривать как панацею. Во-первых, существует определенное расхождение между принципами и практикой. Многие популярные сервисы ПО промежуточного слоя используют собственные интерфейсы прикладного программирования. Из-за этого приложения обычно оказываются зависимы от программного продукта одного производителя. Кроме того, сервисы в ряде случаев опираются на закрытые, неопубликованные протоколы. Из-за этого производителям платформ сложно перенести сервис на собственную платформу так, чтобы он взаимодействовал с реализациями того же сервиса, но на других платформах. Например, как указывалось выше, во многих реляционных СУБД поддерживаются собственные диалекты SQL и собственные протоколы. Некоторые из них недоступны на многих популярных платформах, что ограничивает потребителя в выборе платформ и сужает его возможности при работе в неоднородных системах. Это замечание относится, например, к реляционным СУБД Rdb корпорации Oracle (ранее система принадлежала DEC) и DB2 корпорации IBM. Даже если сервис ПО промежуточного слоя является высокотехнологичным программным продуктом, разработчик приложения, которое опирается на данный сервис, принимает на себя новую форму риска - риск, что этот сервис не сможет идти в ногу с технологией. Например, многие приложения, использовавшие сетевые СУБД (стандарт CODASYL) пришлось переписывать, чтобы воспользоваться преимуществами реляционных СУБД, которые пришли на смену сетевым в качестве фактического стандарта.
Во-вторых, препятствием к использованию сервисов ПО промежуточного слоя является их огромное количество. Использование даже небольшого числа сервисов ПО промежуточного слоя может привести к существенному усложнению разработки - если рассматривать полный API каждого сервиса, имея в виду не только вызовы сервиса, но и особенности использования сервиса в различных языках программирования, системные интерфейсы и средства определения данных. Чтобы сохранить среду программирования простой, управляемой и обозримой, разработчики выбирают небольшое число сервисов, которые отвечают их требованиям к функциональности и спектру платформ.
В-третьих, хотя сервисы ПО промежуточного слоя повышают уровень абстракции при программировании распределенных приложений, они по-прежнему оставляют разработчика приложения перед лицом серьезных проблем проектирования. Например, разработчик по-прежнему должен решать, какие функции включить в клиентскую, а какие - в серверную часть распределенного приложения. Обычно сервис представления располагают в клиентской части приложения ("ближе к экрану"), а сервисы, ответственные за обработку данных, - в серверной части ("ближе к базе данных"). Однако такое решение далеко не всегда будет идеальным, и в любом случае остается открытым вопрос о том, где расположить другие функции приложения.
Интегрирующая cреда
Интегрирующая среда (framework) - это среда программирования, которая спроектирована с целью упрощения разработки и администрирования домена2) специализированных приложений (см. рис. 3). Интегрирующая среда (ИС) определяется интерфейсом прикладного программирования, интерфейсом с пользователем, а также инструментарием. В дополнение к сервисам ПО промежуточного слоя, которые ИС импортирует из других продуктов, она может также включать собственные, частные сервисы (private services).
Рисунок 3.
Архитектура интегрирующей среды.
Приведем примеры ИС. Это - так называемые офисные системы (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) применительно к базисным3) сервисам распределенных систем, а "ПО промежуточного слоя" (middleware) - применительно к сервисам ПО промежуточного слоя и/или интегрирующей среде4).
Интерфейс прикладного программирования интегрирующей среды обычно представляет собой профиль (profile) интерфейсов прикладного программирования к сервисам ПО промежуточного слоя. В ряде случаев он может быть новым API, который упрощает интерфейсы базисных сервисов ПО промежуточного слоя. Например, интерфейс прикладного программирования интегрирующей среды системы автоматизированного проектирования (САПР) или CASE-системы может включать интерфейсы сервиса представления, сервиса, обеспечивающего вызов компонентов инструментария, и сервиса репозитория (для хранения разделяемых этими компонентами данных). Интерфейс прикладного программирования интегрирующей среды может быть также просто объединением интерфейсов этих сервисов. Если интерфейс интегрирующей среды отличается от интерфейсов базисных сервисов, он представляет собой своего рода "оболочку"5), покрывающую базисные сервисы с общим синтаксисом. Однако в большинстве случаев интерфейс интегрирующей среды все-таки обладает расширенными возможностями по сравнению с интерфейсами базисных сервисов. Такими возможностями могут быть, например, специализированный интерфейс с пользователем, упрощение интерфейса прикладного программирования за счет поддержки разделяемого контекста, возможность вызова собственных (частных) сервисов конкретной интегрирующей среды. Например, во всех известных нам мониторах обработки транзакций возможности интерфейса прикладного программирования расширены именно таким образом.
Иногда сервисы ПО промежуточного слоя вырастают до масштабов ИС. Так произошло с инструментарием для работы с реляционными СУБД. Из элементарных интерактивных средств формирования и выполнения SQL-запросов они превратились в сложные системы с комплексным набором инструментов. Иногда набор сервисов интегрирован в такой степени, что фактически превращается в ИС. Например, в OSF DCE интегрованы сервис удаленного вызова процедур, сервис имен, сервис аутентификации, служба времени, сервис идентификации и файловый сервис. Отметим, что в DCE нет как такового обобщенного интерфейса пользователя, и весь интерфейс прикладного программирования DCE - это, собственно, API упомянутых выше сервисов. Тем не менее, DCE поддерживает контекст вызовов (по идентификатору пользователя), и обеспечивает прозрачный вызов сервисов для упрощения некоторых операций, например, прозрачного вызова сервиса имен с целью поиска сервера, который может обработать вызов RPC.
Интегрирующая среда опирается на сервисы ПО промежуточного слоя. Провайдер6) ИС является потребителем ПО промежуточного слоя. Точно также приложение, которое опирается на ИС, является ее клиентом, и, опосредованно, - потребителем сервисов ПО промежуточного слоя. Все больше и больше вновь разрабатываемых приложений уходят от непосредственного вызова сервисов ПО промежуточного слоя и опираются в основном на сервисы интегрирующей среды. Причина состоит в слишком большом разнообразии и разнородности сервисов ПО промежуточного слоя. Эта тенденция аналогична другой, имевшей место в прошлом, тенденции, когда приложения уходили от непосредственного использования сервисов, предоставляемых платформой, и опирались на не зависящие от платформы сервисы ПО промежуточного слоя.
ИС может включать собственный интерфейс пользователя, который является специализацией графического интерфейса пользователя (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-системы и словарем cреды программирования на 4GL), или обеспечивать передачу данных между инструментами (например, используя формат CASE Data Interchange Format для обмена между CASE-инструментами или формат Express для обмена между инструментами системы автоматизированного проектирования). Все это он делает вне зависимости от того, находятся ли данные во владении одного инструмента или в равной степени совместно используются многими. Если доступ к данным происходит в оперативном режиме, возможно, что от инструмента потребуется совместимость по протоколу, то есть по набору допустимых операций над данными и последовательностей таких операций.
При интеграции по управлению инструменты ИС могут вызывать друг друга и обмениваться данными и управляющими директивами. Это предполагает, что интерфейс инструмента должен быть стандартизован хотя бы в рамках ИС. Должен быть также определен формат вызова инструмента (или создания его экземпляра в случае необходимости), и формат обмена сообщениями между инструментами. Например, в продуктах DEC COHESIONworX, HP SoftBench, Sun SPARCWorks каждый инструмент ИС может отправить сообщение, которое направляется всем инструментам, ранее "подписавшимся" на получение сообщений данного типа7). Иногда бывает полезным, чтобы инструмент работал в системе, отличной от той, в которой функционирует ИС. В этом случае интеграция по управлению требует вызова удаленного сервиса. Например, DEC COHESIONworX использует для вызова удаленных инструментов реализацию CORBA (DEC Object Broker).
При интеграции по представлению инструмент использует дисплей совместно с другими инструментами, функционирующими в рамках ИС. Как правило, стиль пользовательского интерфейса конкретного инструмента соответствует стилю, принятому для инструментария ИС. Обычно это достигается за счет использования одного и того же GUI и принятия стандартных соглашений об использовании элементов интерфейса - скажем, предложения семантики, сходной с семантикой абстрактных операций (например, "вырезать" (cut), "вставить" (paste)). Стиль интерфейса может определяться некоторой метафорой, например, метафорой рабочего стола. Это приводит, в свою очередь, к принятию соглашений об использовании пространства экрана, форматов элементов интерфейса (например, панели управления) и т.д. Иногда интеграция по представлению выдвигает требования к интеграции по данным и по управлению. Например, если из редактора составных документов вызывается электронная таблица, необходима как интеграция по данным (содержание электронной таблицы должно быть включено в документ), так и интеграция по управлению (из редактора необходим запуск приложения, обрабатывающего электронные таблицы).
С практической точки зрения интеграция по представению и по управлению обычно бывает более необходима, чем интеграция по данным, поскольку большинству пользователей требуется множество инструментов, и они не хотят иметь дела с инструментом со специфическими интерфейсами и методами вызова других инструментов. Несмотря на то, что интеграция по данным часто является исключительно важной и полезной, инструменты остаются необходимыми и удобными в работе и без интеграции по данным.
Интеграцию по представлению и по управлению часто бывает легче реализовать, чем интеграцию по данным. При интеграции по управлению каждый инструмент может быть интегрирован независимо, путем определения его интерфейсов и обеспечения доступа к ним посредством коммуникационного сервиса. Эта работа локализуется в интерфейсе инструмента и не требует модификаций в теле инструмента. То же самое верно и для интеграции по представлению. Интеграция инструмента сводится к переопределению его интерфейса путем перехвата операций терминального ввода-вывода и их трансляции в операции GUI. Напротив, интеграция по данным требует, чтобы все разработчики инструментов договорились об общем формате данных, которые они (инструменты) будут совместно использовать. Поскольку операции доступа к данным не локализованы и заданы в нескольких фрагментах реализации инструмента, изменение форматов данных часто бывает утомительным и дорогостоящим делом. Изменения в инструменте можно локализовать, создав представления (view)8) разделяемых данных, что обеспечивает инструменту доступ к разделяемым данным в их исходном формате. Однако менеджеры разделяемых данных часто не поддерживают представлений вообще или поддерживает необновляемые представления, что делает такой подход несостоятельным9).
Различия между интеграцией по данным, по представлению и по управлению несколько размыты из-за объектного характера интерфейсов инструментов. Во всех трех случаях обращение к инструменту заключается в вызове метода объекта. Несмотря на это, спектр возможностей, которые предоставляет ИС пользователю, все-таки очень сильно зависит от соотношения между этими тремя типами интеграции. Приходится учитывать также серьезную техническую проблему интеграции по данным, описанную выше. Таким образом, инструменты, которые совместно используют данные, должны быть совместимы по форматам каждого типа данных, что в равной степени сложно - вне зависимости от того, выражается это в имени метода или в его параметрах.
Мониторы обработки транзакций
Для иллюстрации концепции ПО промежуточного слоя рассмотрим один из видов ИС - мониторы обработки транзакций (Transaction Processing Monitor - TPM) [1]. Основная функция TPM - управление потоком запросов между терминалами или другими устройствами и прикладными программами, которые могут обрабатывать эти запросы. Запрос (request) - это специфическое сообщение, инициирующее выполнение транзакции. Приложение, которое выполняет транзакцию, обычно имеет доступ к менеджерам ресурсов, например, к СУБД. Типичный TPM включает функции управления транзакциями, средства для организации межпроцессного взаимодействия, средства управления очередями запросов и средства управления формами и меню (см. рис. 4).
Рисунок 4.
Архитектура монитора обработки транзакций.
Управление транзакциями предполагает наличие операций начала, фиксации и отката (прерывания) транзакции, а также интерфейсов к менеджерам ресурсов. Интерфейс к менеджеру ресурсов обеспечивает, помимо других, следующие возможности. Менеджер ресурсов оповещает менеджер транзакций, что текущая транзакция получила к нему доступ, а менеджер транзакций сообщает менеджеру ресурсов об успешном завершении или прервании транзакции. В TPM реализован двухфазный протокол фиксации транзакций, гарантирующий одновременное успешное завершение или откат транзакции несколькими вовлеченными в нее менеджерами ресурсов (см. [2], глава 7).
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 хранятся в базах данных на серверах локальных компьютерных сетей. Каждая база данных содержит документы, формы (которые определяют внешний вид документов, включающих разнородную информацию: текст, видео-, аудио-информацию) и виды10) (которые отражают различные подмножества множества всех документов и упорядочивают документы по категориям, а также определяют, какая информация будет отображаться по каждому документу). Наличие средств работы с формами, видами и специального языка описания формул, сходного с языком электронных таблиц, позволяет переложить большую часть работы по созданию приложений на специалистов, которые не обладают квалификацией 3GL- или 4GL-программистов. Управление базами данных централизовано незначительно. На каждом сервере Lotus Notes (т.е. для каждой инсталляции Lotus Notes) базы данных определены и поддерживаются независимо друг от друга. Тем не менее, такие базы данных связаны между собой. Для отслеживания связей и управления базами данных используются сервисы ПО промежуточного слоя.
Lotus Notes R3.0 имеет трехуровневую структуру: уровень сервисов платформы, уровень сервисов ПО промежуточного слоя, доступ к которым осуществляется через интегрированный API, уровень инструментария (см. рис. 5). Уровень сервисов платформы представлен набором сервисов для управления памятью, файлами, процессами и окружением (environment). Данные сервисы имеют одинаковую семантику в разных версиях для многих платформ, таких как Microsoft Windows, Apple Macintosh, IBM OS/2, Novell NetWare и нескольких реализаций Unix. Цель этого - обеспечить переносимость сервисов следующего уровня. Уровень платформы включает также функции для работы с элементарными типами данных.
Рисунок 5.
Архитектура Lotus Notes R3.0.
На этом уровне также определены и используются функции для управления представлением для различных платформ и функции, обеспечивающие двоичную совместимости приложений, баз данных и сетевых сообщений. Строго говоря, эти функции не являются функциями платформы. Дело в том, в архитектуре Lotus Notes имеет место сетевой компонент, который изолирует более высокие уровни от сетевых архитектур. Кроме того, он скрывает детали транспортного уровня передачи сообщений. В архитектуре Lotus Notes также имеет место не зависящий от платформы интерфейс с пользователем, который скрывает от более высоких уровней детали и различия в оконных системах. Изоляция ИС или сервисов ПО промежуточного слоя от платформы при помощи сервисов, описанных выше, является общепринятой практикой. Например, таким образом построено большинство переносимых СУБД и TP-мониторов.
Многие специфичные для ИС независимые от платформы сервисы ПО промежуточного слоя расположены выше уровня сервисов платформы. Доступ к ним осуществляется через С-функции, которые определяют Lotus Notes API. Определены следующие сервисы:
В 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 представляет собой интегрированный набор сервисов, которые, тем не менее, в совокупности не являются ИС. Интегрированную систему от простой коллекции общесистемных сервисов отличает то, что в ИС они хорошо работают вместе. Деятельность по созданию такой интегрированной системы из независимо разрабатываемых элементов-частей называется cистемным конструированием (system engineering)11).
Допустимы самые разные критерии оценки приложений и ПО промежуточного слоя и вообще программных систем. Среди них - удобство в использовании, степень распределенности и интегрируемости, соответствие стандартам, расширяемость, возможности интернационализации, управляемость, производительность, переностимость, надежность, масштабируемость и безопасность. Мы называем их диффузионными свойствами (pervasive attributes)12).
Разумеется, пользователи хотели бы иметь информационные системы с высокими показателями по каждому из указанных выше свойств. Этой цели можно достичь, разрабатывая системы на основе сервисов ПО промежуточного слоя, которые априори обладают диффузионными свойствами. Согласно определению, указанные выше свойства, присущие сервисам ПО промежуточного слоя, распространяются и на приложения, которые разрабатываются на основе данных сервисов, что и является гарантией надежности и высокой производительности всей системы в целом. Системные инженеры могут усилить диффузионные свойства ПО промежуточного слоя за счет специальных решений. Например, сервисы можно интегрировать таким образом, что полученный в результате набор сервисов будет обладать заранее заданными качествами. Этого можно достичь, вводя общие для сервисов соглашения об именах, совместимые характеристики производительности, проектируя и разрабатывая приложения так, чтобы они единообразно использовали сервисы ПО промежуточного слоя (например, имели общие соглашения об именовании или использовали определенный сервис аутентификации).
Сегодня системное проектирование - это по преимуществу деятельность, определяемая конкретной ситуацией. Для некоторых диффузионных свойств, например, производительности и надежности, существуют методы измерения и анализа. Известны также и технологии разработки и реализации, имеющие целью получение систем с заранее заданными свойствами. К большинству же диффузионных свойств теоретические или технические методы плохо применимы, здесь более уместны здравый смысл и рациональные методы системного конструирования. Важность последних обусловлена очевидными тенденциями к использованию при создании программных систем новейших программных разработок. Высокий спрос на разработки в этой области сулит специалистам в информатике блестящие перспективы и неограниченные возможности.
Кроме собственно принципов и методов интеграции сервисов ПО, важно также иметь адекватные способы оценки ее результатов. Что касается оценки свойств производительности, то принято характеризовать систему по ее поведению в эталонных тестах13). Для некоторых свойств можно оценивать систему, исходя из ее функциональных возможностей (например, критерии безопасности согласно "Оранжевой Книге" Министерства обороны США). Другие свойства оценить много труднее, поскольку не существует общепринятых методов измерения (например, свойства расширяемости или удобства в использовании). Разработка методов измерения ряда диффузионных свойств также открывает большие возможности для исследований.
Тенденции
Программное обеспечение промежуточного слоя завоевало место под солнцем и стало реальным фактором информационных технологий. Его компоненты со временем будут изменяться. Выше мы говорили о том, что некоторые сервисы ОС будут развиваться, превращаясь в ПО промежуточного слоя, а некоторые сервисы 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, а также расширения его функциональности в новых областях приложений в будущем сделают эту зависимость еще сильнее.
Благодарности
Эта статья появилась в результате нескольких лет работы над архитектурой ПО промежуточного слоя NAS корпорации DEC, в которой также участвовали десятки инженеров. Я очень обязан Дэвиду Стоуну (David Stone), который сумел сконцентрировать внимание на упомянутых здесь проблемах с позиции управления и вдохновил меня на их решение. Я благодарю Вэнди Кэсвел (Wendy Caswell), Скотта Дэвиса (Scott Davis), Ханса Джиллстрома (Hans Gyllstorm), Чипа Найлэндера (Chip Nylander), Барри Робинсона (Barry Robinson), Джона Майлса Смита (John Miles Smith), Марка Сторма (Mark Storm) и особенно Лео Лэйвердьюра (Leo Laverdure) за многие помогавшие в работе дискуссии о проблемах ПО промежуточного слоя и за помощь в разработке некоторых ключевых тезисов этой статьи. Я благодарен Кену Муру (Ken Moor) из фирмы Iris Associates, который сотрудничал со мной при описании среды Lotus Notes, и следующим людям, которые во многом помогли мне улучшить эту статью: Эду Балковичу (Ed Balkovich), Марку Брэмхоллу (Mark Bramhall), Майклу Броуди (Michael Brodie), Джону Колонна-Романо (John Colonna-Romano), Джуди Холл (Judy Hall), Мейкуну Хсу (Meichun Hsu), Хансу де Йонгу (Hans de Jong), Мюррею Мэйзеру (Murray Mazer) и Кэлтону Пу (Kalton Pu).
Литература
1. Bernstein, P.A. Transaction Processing Monitors. Commun. ACM 33, 11 (Nov. 1990), 75-86.
2. Bernstein, P., Hadzilacos, V., and Goodman, N. Concurrency Control and Recovery in Database Systems. Addison-Wesley, Reading, Mass., 1987.
3. Chappell, D. The OSF distributed management environment. ConneXions 6, 10 (Oct. 1992), 10-15.
4. King, S.S. Middleware. Data Communications (Mar. 1992), 58-67.
5. Laverdure, L., Collonna-Romano, J., Srite, P. Network Application Support Architecture Reference Manual. Digital Press, 1993.
6. Rosenberry, W., Kenney, D., and Fisher, G. Understanding DCE. O'Reily, Sebastopol, Calif., 1992.
7. X/Open Portability Guide. The X/Open Company, Reading, England.
Philip A. Bernstein, Microsoft Corporation
*) Переведено
и опубликовано с разрешения АСМ.
(c) COMMUNICATIONS OF THE ACM. February ../1996/Vol.39, # 2
(c) Авторизованный перевод Г.М. Ладыженского
1) В тексте было "SunSPARCstation and SunOS", но переводчик счел уместным определить пару "SunSPARC и Solaris" как более соответствующую современным реалиям и смыслу сказанного. (Прим. переводчика.)
2) Здесь, очевидно, автор имеет в виду набор взаимосвязанных и взаимодействующих приложений, что очень близко к определению домена в мониторах транзакций (например, в BEA Tuxedo). (Прим. переводчика.)
3) В оригинале было "underlying". Далее под базисными сервисами мы будет подразумевать низкоуровневые сервисы, на которые опирается интегрирующая среда. (Прим. переводчика.)
4) Здесь автор, видимо, имеет в виду, что middleware - это более общее понятие, нежели middleware services. То есть, в категорию middleware попадают как сервисы распределенной системы (distributed system services) - на рис.3 они выделены серым цветом, так и программное обеспечение более высокого уровня - интегрирующая среда (framework) (Прим.переводчика).
5) В оригинале было "veneer". Не удалось подобрать в русском языке точного эквивалента этого термина. В слэнге это звучит как "обвязка".(Прим.переводчика).
6) В оригинале так и было - "framework provider". Автор, видимо, имеет в виду того, кто разрабатывает и поддерживает ИС, будь то группа программистов или целая фирма (Прим.переводчика).
7) Такой способ взаимодействия носит название "публикация/подписка" (pudlish/subscribe). (Прим. переводчика.)
8) Термин view относится к понятиям баз данных, а его перевод как "представление" общеупотребителен. (Прим. переводчика.)
9) В качестве примера менеджера разделяемых данных, который поддерживает представления, в том числе обновляемые, можно привести реляционные СУБД (правда, не все). (Прим. переводчика.)
10) Перевод терминов, встречающихся в данном разделе, позаимствован из перевода книги Марка Шульмана (Mark Schulman) - "Using Lotus Notes" ("Работа в Lotus Notes", под общей редакцией С. Каратыгина, Бином, Москва, 1995). (Прим. перводчика.)
11) Здесь приходится вводить новый термин. Дело в том, что наиболее очевидный перевод - "системное проектирование" - уже используется достаточно широко как перевод термина "system design". Автор имеет в виду именно конструирование - инженерную деятельность по созданию единого целого из отдельных компонентов. (Прим. переводчика.)
12) Pervasive - отглагольное прилагательное, образованное от pervade (переводится как "проникать", "распространяться", "диффундировать"). Автор, очевидно, имеет в виду, что указанные имманентные свойства некоторых компонентов системы диффундируют во все другие ее компоненты, распространяются по всем ее уровням. (Прим. переводчика.)
13) Наиболее удачным примером оценки производительности тандема "СУБД+платформа" являются широко известные TPC-тесты. (Прим. переводчика.)