Вы можете не сознавать этого, но обойтись без промежуточного ПО сегодня весьма сложно. Любая среда клиент-сервер, от небольшой локальной сети до крупной распределенной системы, использует ту или иную его форму. Фактически всегда, когда клиент посылает запрос серверу или приложение извлекает данные из БД, посредником в звене клиент-сервер выступает промежуточное ПО, сглаживая возможную несовместимость между коммуникационными протоколами, языками запросов к базе данных, программами-приложениями и операционными системами.
Можно сказать, что промежуточное ПО - наиболее важная часть среды клиент-сервер, поскольку если оно не работает правильно, ничего не будет работать вообще. В то же время этот вид программного обеспечения представляется весьма “темным местом”. В связи с этим давайте рассмотрим вопросы, которые можно считать основными: как выбрать промежуточное ПО, в каких случаях его использовать и что с его помощью можно делать.
Ориентация в новом мире
Понять, что такое есть промежуточное ПО, может быть, весьма сложно, в частности потому, что оно имеет множество определений и технологических реализаций, не говоря уже о воплощении в виде конкретных продуктов. Для руководителя службы автоматизации или сетевого инженера освоение концепций и технологий прмежуточного ПО совершенно необходимо для ориентации в клиент-серверном мире.
Дать абстрактное определение промежуточному ПО несложно: обычно это программный слой, определенный с помощью интерфейса прикладного программирования (API), который играет роль посредника в коммуникациях высокого уровня между клиентом и сервером или между серверами. Обычно он работает поверх сетевого или транспортного уровня и не зависит от нижележащих коммуникационных служб.
Теоретически происходит следующее: приложение, находящееся в клиентской части, нуждается в данных или службе, которые находятся где-то в сети, чаще всего на сервере, использующем другую операционную систему и БД со специфичным языком запросов. Часть клиент-серверного приложения, занимающаяся поиском необходимых данных, посылает запрос к промежуточному ПО, с тем чтобы оно нашло поставщика данных или услуги безотносительно к его местоположению, передало ему запрос, отформатировало ответ и переслало его обратно приложению.
Обычно программисты пишут основной код приложения отдельно от той его части, которая взаимодействует с промежуточным ПО, а при написании этой части обычно используется API промежуточного ПО. Такое разбиение идеально подходит для распределенной среды клиент-сервер, где данные могут находиться на любой серверной платформе - от сервера Novell или Unix до мэйнфрейма IBM.
Реальность
Прежде чем внедрять у себя промежуточное ПО, компания должна принять ответственные стратегические решения. Первопроходцы, уже прошедшие внедрения промежуточного ПО, могут привести много примеров неудач и промахов и соглашаются, что виной тому были как неоправданные обещания поставщиков ПО, так и неосведомленность пользователей. Покупая промежуточное ПО, необходимо не только владеть фундаментальным знанием бизнес-задач и процессов, которые будет решать промежуточное ПО, но и понимать особенности различных предлагаемых продуктов, их положительные стороны и компромиссы.
Большинство специалистов рекомендуют начинать с анализа деловых аспектов, а затем переходить к вопросам технологии. Возможно, это звучит банально, но в жизни приходится только удивляться, как часто пользователи выбирают определенную технологию промежуточного ПО, не успев толком осознать, что она может и чего не может для них сделать.
В общих чертах процесс может выглядеть так:
- формулировка задачи (например, сокращение затрат и временных циклов в целях повышения конкурентоспособности);
- определение пути достижения цели (внедрение системы, более быстродействующей и гибкой по сравнению с существующей);
- поиск приложений, которые будут работать в новой среде;
- подбор соответствующего промежуточного программного обеспечения.
Выбор ПО промежуточного слоя
На рынке промежуточного ПО можно выделить шесть основных (очень разных) типов продуктов: промежуточное ПО баз данных, промежуточное ПО удаленных вызовов процедур, промежуточное ПО передачи сообщений, брокеры объектных запросов, мониторы обработки транзакций и специально разработанное ПО.
Промежуточное ПО баз данных, как и следует из его названия, имеет ограниченное применение. В клиентской части большинства систем клиент-сервер, как правило, есть приложение, которое обращается к данным в БД сервера. Если оно предназначено для использования только одного типа БД, например Oracle, то это наверняка останется неизменным, и тогда хорошим решением будет промежуточное ПО баз данных Oracle. Данный пример характерен для большинства реляционных БД и соответствующей технологии промежуточного ПО. Шлюзы БД обычно имеют системы промежуточного ПО БД, которые производят трансляцию между различными вариантами баз данных SQL или между SQL и не-SQL. Такие шлюзы воплощают скорее технологию трансляции, нежели технологию промежуточного ПО.
Промежуточное ПО удаленных вызовов процедур (RPC, Remote Procedure Calls) основано на более общем подходе к клиент-серверным вычислениям.
Разработчики приложений применяют RPC для доступа к данным на удаленном сервере аналогично вызову функции доступа к локальной БД.
Эта базовая концепция RPC используется в большинстве других технологий промежуточного ПО. С помощью RPC также можно передавать программное управление на удаленный сервер. Промежуточное ПО удаленных вызовов процедур, такое, как DCE (Distributed Computing Environment), предложенное OSF (Open Software Foundation), по существу производит поиск сервера базы данных в сети.
Удаленный вызов процедур применяется для доступа к большому числу источников разнообразных данных из одного приложения, в некоторых случаях это может быть комбинация реляционных и нереляционных данных. Такая гибкость позволяет строить гораздо более сложные среды клиент-сервер, нежели системы, основанные только на технологии промежуточного ПО баз данных.
Вместе с тем подход, основанный на RPC, имеет одну особенность: после осуществления удаленного вызова клиентская система обычно ждет ответа сервера на запрос. Любой сбой на пути запроса блокирует клиентское приложение.
Системы передачи сообщений развивают идеологию RPC, решая проблему сбоев в системе клиент-сервер. В системах передачи сообщений главное - обеспечить более надежное соединение, благодаря которому сообщение передается по назначению, несмотря на сбои в сети и отказы сервера. Связь клиента и сервера может быть синхронной и асинхронной, соответственно сообщения передаются незамедлительно или с промежуточным хранением.
В отличие от технологии RPC, когда приложения обычно жестко привязаны к определенной БД или серверу, в данном случае сообщение может иметь множество пунктов назначения в зависимости от того, каким образом администратор системы хочет учитывать отказы. Сообщение может доставляться по различным сценариям: немедленно (синхронно) или с задержкой (асинхронно). Промежуточное ПО передачи сообщений может быть наилучшим решением в том смысле, что оно обеспечивает более надежную доставку широкого спектра данных и процессов в распределенной среде.
Объектное промежуточное ПО представлено брокерами объектных запросов (ORB, Object Request Brokers). Эта технология пропагандировалась как единственный путь, позволяющий привнести преимущества объектной технологии в распределенные вычисления. Брокеры объектных запросов управляют объектами, которые ведут себя практически так же, как RPC.Однако распределенные объекты могут содержать гораздо более сложную информацию о распределенном запросе или службе, чем RPC или большинство сообщений, они могут работать и с неструктурированными или нереляционными данными. Брокеры объектных запросов, соответствующие стандарту общей архитектуры брокера объектных запросов CORBA (Common Object Request Broker Architecture) поддерживают язык описания интерфейса IDL (Interface Definition Language), который в процессе пересылки объектов по сети работает как API промежуточного ПО.
Мониторы обработки транзакций прошли значительный путь эволюции и сейчас отвечают более широким задачам, представляя сложившуюся технологию промежуточного ПО. Первоначально они разрабатывались для управления сложными распределенными системами, требовавшими очень быстрого гарантированного отклика для большого количества пользователей. Мониторы обработки транзакций не превзойдены в транзакционной семантике, что позволяет программно управлять скоростью и надежностью обработки.
Как промежуточное ПО мониторы обработки транзакций обеспечивают единый API для написания распределенных приложений. Обладая полным набором инструментов управления, эти системы управляют распределенной средой подобно системам, основанным на мэйнфреймах.
Специально разработанное ПО. Многие инструменты разработки систем клиент-сервер и широкомасштабные приложения клиент-сервер имеют свою технологию промежуточного ПО. Такие специальные системы, как, например, промежуточное ПО R/3 BASIS компании SAP, оптимизированы для конкретного инструмента разработки или приложения. Они обычно работают хорошо, но адаптировать их к существующей клиент-серверной среде, средствам разработки и другим приложениям довольно сложно.
Итак, мы рассмотрели основные категории промежуточного ПО. Но как сделать правильный выбор? Не забывая о первом шаге - изучении требований бизнеса - необходимо учесть следующие моменты.
- Возможно, в сложной среде клиент-сервер придется применить не один подход к организации промежуточного слоя: даже отдельное приложение в принципе может использовать RPC для доступа к реляционной БД, систему сообщений для управления транзакциями на мэйнфрейме и ORB - для управления объектами. Многие системы промежуточного слоя могут взаимодействовать друг с другом. Однако надо иметь в виду, что при совместном использовании нескольких продуктов промежуточного ПО возникает проблема дополнительного администрирования, совместимости различных API и взаимодействия служб.
- Разные продукты промежуточного слоя используют собственные API, которые далеко не всегда совместимы. Эта проблема существует внутри классов промежуточного ПО. Например, языки описания интерфейса IDL неидентичны для различных брокеров объектных запросов, и сообщения различных систем передачи сообщений не могут смешиваться. Такая же ситуация наблюдается и в случае разных классов промежуточного ПО. Приложение, основанное на RPC, невозможно просто перенести в среду, построенную на основе ORB. В результате, выбрав конкретное промежуточное ПО, вы жестко зависите от него. Если в программе заложено использование конкретного класса промежуточного ПО, то работать с данным приложением будет только оно. Для замены промежуточного ПО надо переписать приложение или его часть. 4
Владимиру Бржезинскому, сотруднику фирмы US-Lab, можно позвонить
по телефону: (095) 485-2473.
Владимир Бржезинский
