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

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

Дорога в рай открытых распределенных систем - доведенной до классически простого plug-and-play совместимости приложений, баз данных, операционных систем и методов соединения - все еще слишком трудна и не ясна. Промежуточное ПО (middleware), несколько помогая в этом, вносит в то же время и новый уровень сложности в управление предприятием. Это серьезное препятствие на пути к действительно открытым распределенным системам, использующим такие архитектуры, как Distributing Computing Environment (DCE) и Common Object Request Broker Architecture (CORBA).

Компании, пытающиеся создавать распределенные системы сегодня, не могут больше ждать распространения продуктов, поддерживающих DCE, или завершения доработок CORBA 2.0.

"Это не лучшая картина", - заметил Марк Ханнер, директор по стратегии разработки приложений в Meta Group. Его определение промежуточного ПО - "то, что находится между вами и вашими данными" - выглядит предельно конкретным, если принять во внимание весь спектр доступных программ.

По терминологии бостонской Patricia Seybold Group к промежуточному может быть отнесено любое ПО, которое управляет информационным потоком между клиентами и серверами. Сюда входят удаленные вызовы процедур (RPC), шлюзы баз данных, программы передачи файлов, обработчики объектных запросов (object request brokers) и мониторы обработки транзакций.

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

Как же определить, какое ПО необходимо для ваших задач? Лучше всего начать с конца. "Сформулируйте свою задачу или функцию, которую хотите реализовать, - советует Джим Хэнди, главный инженер компании SSDS, занимающейся системной интеграцией. - В большинстве случаев промежуточное ПО выполняет одну из двух функций: обслуживает доступ к базам данных или распределенные системы".

Данные, которые под рукой

Такие средства управления или доступа к данным, как EDA/SQL (Information Builder) или Connection (Open Horizon), обеспечивая общий интерфейс прикладного программирования API для различных баз данных и приложений, полагаются на Open Database Connectivity (ODBC).

ODBC API за счет хранимых процедур поддерживает полиморфизм, позволяющий программистам спрятать различные реализации за общим интерфейсом, упрощающим взаимодействие объектов, и разрешает менять параметры, задаваемые по умолчанию. Хранимые процедуры позволяют разработчикам разгрузить клиента за счет переноса SQL-кода на сервер, а также изолируют приложения от модели представления данных на нижнем уровне. Как хранимые процедуры, так и параметры по умолчанию делают приложение независимым от изменений в базе данных.

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

Как заявил Ханнер, "наше основное правило - по возможности придерживаться двухзвенного (two-tier) клиент-серверного промежуточного ПО на базе SQL".

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

Вычислительные системы этой производственно-конструкторской фирмы выполняют большие корпоративные приложения на мэйнфреймах IBM под MVS с мониторами транзакций CICS и IMS. Программы, управляющие производственными процессами, выполняются на VAX/VMS компании Digital. Инженеры пользуются Unix-станциями компаний Hewlett-Packard и Digital. Административный персонал работает на ПК под различными ОС, в том числе OS/2, DOS, Windows и Windows NT.

Изучая предложения рынка, Хослер и его команда пришли к выводу, что для прозрачной передачи транзакций в этой разнородной среде требуется промежуточное ПО мультиплатформенного доступа к данным. Выбор пал на EDA/SQL компании Information Builder, поскольку этот продукт выглядел наиболее законченным из всех предлагаемых на рынке. По мнению Хослера, главное достоинство этого продукта в том, что он не нарушит работу уже использующегося в Caterpillar мэйнфрейма.

Хотя компанию Home Depot не беспокоили вопросы совместимости с мэйнфреймами, здесь также решили осуществлять доступ к базам данных Informix и DB2 с помощью основанного на ODBC продукта SequeLink фирмы Intersolv, недавно приобретенного вместе с компанией TechGnosis.

"Мы уже выбрали техническое оборудование, и требовался только продукт, который заполнил бы нишу доступа к данным, - объяснил Бич Кларк, менеджер сетевой архитектуры Home Depot. - В качестве стандарта для баз данных мы приняли реляционную модель. ODBC вполне соответствует нашим требованиям". SequeLink занимается трансляцией SQL-запросов.

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

Кроме того, производители промежуточного ПО доступа к данным, заглядывая в будущее, добавляют в свою продукцию поддержку DCE и CORBA.

Системные службы

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

"Как только заходит разговор о переносе процедур на сервер и о взаимодействии с другими процедурами в других системах, все значительно усложняется", - считает Ханнер.

Как правило, эти методы работают на более низком уровне, чем ПО доступа к базам данных, а потому они в большей степени привязаны к структуре предприятия и средствам связи. В настоящее время используются два основных метода: удаленный вызов процедур (RPC, Remote Procedure Call) и ориентированное на сообщения промежуточное ПО (MOM, Message Oriented Middleware). RPC находят применение в Unix-подобных операционных системах и на таких платформах, как Sun Microsystems и IBM.

К MOM относятся системы разработки MQSeries Three-Tier компании IBM и Pipes компании PeerLogic. MQSeries предоставляют разработчикам в VisualAge доступ к инфраструктуре соединений мэйнфрейма, а Pipes позволяет создавать промежуточное ПО взаимодействия приложений в системе с разными сетевыми протоколами.

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

Home Depot, например, использует как RPC, так и MOM.

"Мы считаем, что применение найдется для обоих", - заявил Кларк. Из его объяснения следует, что с точки зрения ODBC и RPC в конце конвейера должен находиться пользователь, а для метода MOM, действующего как способ передачи от машины к машине, пользователь не нужен.

"RPC характеризуется высокоскоростной обработкой почти в реальном времени, - пояснил Митч Крамер, консультант Patricia Seybold Group. - Но если приложение охватывает большие организации, например связывает между собой различные компании, то может оказаться удобным использование MOM, поскольку одна компания не будет загружать ресурсы другой".

И RPC, и MOM призваны скрыть от пользователя сложные системно-зависимые интерфейсы, а от клиента - местонахождение распределенных сервисов в сети.

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

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

По мнению аналитиков, как RPC, так и MOM фактически переносят всю сложность соединения с баз данных и приложений на интерфейсы связи.

"Вы просто перекладываете всю нагрузку на другой узел - на службы управления инфраструктурой промежуточного ПО", - объясняет Грег Пэйвони, системный разработчик компании Technology Investment.

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

Принимая во внимание сложность подходов MOM и RPC, Ханнер из Meta Group даже рекомендует подождать с применением этих продуктов, пока они не будут окончательно отработаны.

Стандартные архитектуры

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

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

В число производителей промежуточного ПО, придерживающихся DCE, входят Transarc, Open Horizon и Gradient Technologies. PC-DCE и PC-DCE/32 фирмы Gradient переносят сервисы DCE на ПК под Windows.

Одно из главных преимуществ DCE - способность скрыть от пользователя различные операционные системы и протоколы и упростить управление сетью.

Как рассказал Джон Детлофф, разработчик из Аризонского университета в Таксоне, у них DCE стала стандартом де-факто для службы защиты распределенных данных, названной Kerberos, а также для процедуры входа в систему. Детлофф, как и другие члены группы Student Information Systems 2000, занимается разработкой технологической инфраструктуры для университета.

Для реализации ODBC в соответствии со спецификацией DCE здесь используется Connection фирмы Open Horizon.

"DCE у нас является стандартом. Мы пользуемся им, поскольку он обеспечивает защищенный, единый для всей сети идентификатор и позволяет шифровать данные, передаваемые по сети", - объяснил Детлофф.

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

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

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

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

Дейв Рафельдт, технический директор фирмы Strategic Systems Europe, которая помогает корпорациям в стратегическом планировании технологии, считает, что "DCE - концептуально неплохая идея, но для ее действительно успешного применения требуется хорошее знание Unix".

Хотя спецификация CORBA 2.0 и не относится к архитектуре распределенных систем, ее технология обработки объектных запросов дает разработчикам возможность связать между собой различные языки и операционные системы.

Главный аргумент против принятия CORBA 2.0 - тот факт, что Version 2.0 будет дорабатываться еще полтора-два года, пока спецификация не примет законченную форму. Тем не менее, многие разработчики и аналитики рассматривают ее как Holy Grail распределенных вычислений.

Во всяком случае, Рафельдт считает, что CORBA - "шаг в правильном направлении".

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

"Для многих промежуточное ПО - это панацея от различных изъянов, передающихся от версии к версии в долгосрочных разработках, а также в архитектуре и планировании, - считает Рафельдт. - Хотя она и продлит жизнь существующих программных продуктов, похоже, что с его помощью и без того достаточно глубокая технологическая яма станет еще глубже.

Довольно сложно оценить, во что обойдется использование промежуточного ПО, особенно если у компании нет конкретного стратегического плана, а у большинства компаний его нет".

Кратковременный выигрыш

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

"Промежуточному ПО требуется согласованная работа многих элементов, - объяснил Хослер. - Изменение любого из них может привести к тому, что работа конечных пользователей остановится".

В компании Caterpillar к этим многочисленным элементам относятся приложения, написанные на С++, EDA/SQL для ПК, программы управления телекоммуникациями, маршрутизаторы, мосты и мэйнфрейм, выполняющий функции сервера.

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

Управление еще более осложняется тем, что группа Хослера пересекает административные границы.

"Нам приходится работать со всеми подразделениями - специалистами по ПК, локальным сетям, мэйнфреймам и т.д. Все это разные люди", - объяснил он.

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

DCE и CORBA - это основа, на которой будут строиться приложения, не зависящие от сложности оборудования на нижнем уровне. Для DCE это относится в основном к сложности вычислительных сетей, а что касается CORBA, то эксперты прогнозируют ее распространение в мире распределенных динамически объединяемых систем.


Эмили Лейнфас - независимый автор (Сарасота, шт. Флорида).

ИНСТРУМЕНТАРИЙ КЛАССА MIDDLEWARE

Connection

Open Horizon Corp.

http://www.openhorizon.com

DCE

Transarc Corp.

http://www.transarc.com

EDA/SQL

Information Builders Inc.

http://www.ibi.com

MQSeries Three-Tier

IBM

http://www.hursley.ibm.com

PC-DCE, PC-DCE/32

Gradient Technologies Inc.

http://www.gradient.com

Pipes for Visual Basic

PeerLogic Inc.

http://www.peerlogic.com

SequeLink

Intersolv Inc.

http://www.intersolv.com

Поделитесь материалом с коллегами и друзьями