Переходя к тому, что предлагают производители программного обеспечения, я хотел бы заметить, что то, следуя стандартам, надо соблюдать чувство меры. Не ради оригинальничанья, а потому что стандарт лишь задаёт направление, упрощает общение, но не обязательно отвечает всем имеющимся требованиям.
BEA Systems
К настоящему моменту BEA System стала обладателем разношёрстной компании продуктов. Это Tuxedo, о котором нам пришлось много услышать, когда его владельцем ненадолго стала известная и уважаемая в СССР и России компания Novell. Это разработанный NCR монитор TopEnd, по некоторым параметрам технически более совершенный, чем Tuxedo (не использовавшая нити, требовавшая выделенного процесса для организации сессионного взаимодействия с клиентом, имевшая неудачную с точки зрения распределённых приложений систему общих досок объявлений и только к версии 6.4 разрешившая проблемы производительности междоменного взаимодействия). Это TQM система MessageQ, разработанная DEC. И, конечно, ответы на изменившиеся реалии.
BEA M3 - CORBA совместимый сервер. Превратить Tuxedo или TopEnd в CORBA достаточно тяжело, слишком велики архитектурные различия. Поэтому M3 - дополнительный продукт, а не новая версия старых. Сильным моментом M3 надо признать наличие концентратора соединений (Connection Concentrator). При этом, правда, не стоит принимать близко к сердцу утверждения BEA об уникальности этого подхода - в "концентраторе" легко угадываются черты CORBA Trading Service. Состояние объекта хранится вне объекта и считывается/записывается из/в внешнего хранилища на время жизни объекта. Время жизни определяется, в зависимости от выбранной стратегии, временем исполнения метода, продолжительностью всей транзакции или процесса в целом. Клиентом M3 может быть программа, созданная на Java, C++ или ActiveX. На май 1998 года сервер мог разрабатываться только на C++, планировалась поддержка Java и EJB.
Из средств разработки - ObjectBroker Builder, TUXEDO Builder и MessageQ Builder. Входящий в TUXEDO Builder Active Expert облегчает создание ActiveX компонент для Tuxedo и подключается к VB, VC++ и PowerBuilder. Другой важный компонент TUXEDO Builder, Contract Repository, является хранилищем всех имеющихся интерфейсов.
Jolt является Java переходником, дающим доступ Java клиентов непосредственно к приложениям Tuxedo. И наконец, WebLogic - интернет-сервер с богатыми возможностями расширения. Он поддерживает 10 из Enterprise Java API (это почти всё), а также ASP и COM и разработку на Java, VB и VC++.
IBM
Как уже было сказано выше, IBM является одним из творцов подхода как такового. Это не пустые слова. Мониторы IMS и CICS являются живыми памятниками самим себе. На 70 тысячах хостов работает CICS. А за 31 год существования IMS было продано более 15 миллионов клиентских лицензий к нему. В то же время это не какие-нибудь окаменелости - последняя, шестая, версия IMS датируется прошлым годом, а CICS, продолжая существовать на S390, OS/400 и OS/2 в своём привычном виде, на UNIX и NT входит в новейший продукт TXseries. Достаточно новым является и TPF, предназначенный для S-390. В отличие от иерархической IMS DB, TPFDF - хранилище "плоских" файлов записей. Это упрощает интеграцию данных с реляционной DB2.
Монитор Encina - пожалуй, самый интересный из мониторов транзакций "последней волны" (тройка Encina-TopEnd-Tuxedo). Он создавался Transarc (теперь подразделение IBM), как дополнение OSF/DCE до полного сервера приложений. Encina Toolkit возлежит непосредственно на OSF/DCE и привносит следующую функциональность:
И уже выше лежат Encina Monotor, Recoverable Queuing Service, Structured File Server, PPC. Модуль SFS - хранилище файлов записей. Радикальным отличием Encina является его максимальная открытость и расширяемость. Все перечисленные блоки являются не только "прямоугольниками на диаграмме", но и доступны разработчику. Используя, например, LOG & REC, можно организовать собственный журнал транзакций и хранить в нём историю операций, так как это делают СУБД. При восстановлении после сбоя этот журнал может дать возможность начать прерванные транзакции с точки сбоя, что сильно отличается от обычной практики рестартовать транзакцию с самого начала. Именно эта гибкость позволила IBM объединить CICS и Encina в TXSeries. TXSeries, это, фактически, добавление блока совместимости CICS в Encina - TXSeries использует ядро только Encina.
Разработка серверной части для Encina может вестись на C++ и Transactional-C. Клиентом могут использовать дополнительно Java или ActiveX. В Encina была включена и интеграция с CORBA. Входящий в Encina++/CORBA компилятор IDL от IONA генерирует всё необходимое для того, чтобы превратить Encina в CORBA OTS. Encina реализована для основных версий UNIX и NT, а Encina Toolkit - и для S/390.
С IMS и "чистым" CICS проблема сложнее. Хотя к ним и можно подключить Java-клиента, в остальном ситуация та же, что и для Tuxedo и TopEnd. Поэтому не в последнюю очередь и для них создан Component Broker Connector. Однако не следует считать CBConnector простым переходником. В нём реализован OTS, поэтому он сам по себе уже монитор. Особо отметим реализацию в CBConnector сервиса CORBA Query Service. Поддерживается слегка отличающийся от SQL3 собственный синтаксис IBM OO-SQL.
Инструментарий для CBConnector это CBToolkit. Здесь содержатся средства конструирования (Object Builder и CICS/IMS Connection Tool) и отладки объектов, расширяющие возможности VisualAge for Java & C++. Помимо этого поддерживаются и инструментарий третьих фирм - Microsoft VB & VC++ (для последнего реализуется и удалённая отладка), а также ERWin.
Существующие Application Adaptors позволяют разрабатывать объекты стороны сервера на C++ и Java, а для клиента возможно и создание ActiveX заглушек.
Сообщалось о включении CBConnector и TXSeries в Enterprise редакцию интернет сервера IBM WebSphere. До сих пор WebSpere был сервером приложений только в той степени, какую может обеспечить поддержка JavaScript и Java Servlets (разработка - на WebSpere Studio и лицензированном инструментарии NetObjects).
Inprise
Образованная слиянием компаний Borland и Visigenic, Inprise в настоящий момент владеет продуктами по всем трём направлениям - стандартам распределённых вычислений: OSF/DCE (Entera), CORBA (Visibroker), DCOM.
Я не стану дублировать доклад компании Inprise, идущий в этой же секции, однако не могу не отметить три благоприятных для Inprise момента. Во-первых, это мировая известность Visibroker. Фактически, это одна из двух наиболее часто упоминаемых реализаций CORBA, лицензированная многими крупными компаниями, в частности Oracle и Netscape. Компоненты для разработки CORBA от Visigenic включались многими поставщиками средств разработки в свои продукты. Во-вторых, средства разработки Borland пользуются большой популярностью. В третьих, развитие Delphi, C++ Builder & JBuilder пошло правильным путём - Inprise предоставляет разработчику два уровня сложности - один максимально приближенный к стандарту, а второй - скрывающий все ненужные поначалу детали.
IONA Technologies
Является вторым из упомянутых ранее самых известных поставщиков CORBA. IONA Orbix - пожалуй, наиболее широко, полно и близко к стандарту поддерживает CORBA. Здесь и редко реализуемый Trading (OrbixTrader), и ещё реже реализуемый шлюз CORBA/COM (OrbixCOMet), и совсем редкий и ещё не принятый TQM - CORBA Messaging (OrbixTalk). Представлены, конечно, и самые базовые сервисы (OrbixNames, OrbixSSL), и OTS (OrbixOTS), а также дополнительные средства защиты (Wonderwall). Помимо UNIX и NT, Orbix работает и на S/390.
Согласно французской пословице, "каждый порок есть чуточку продлённая добродетель". Точно так же и слабость Orbix кроется там же, где и его сила - в следовании стандарту. Большое количество API в CORBA делает разработку сложной, а отсутствие у IONA собственного инструментария ослабляет её позиции. Orbix Code Generation Toolkit не в состоянии конкурировать с более развитыми и популярными пакетами.
Microsoft
Инфраструктура, которая реализует промежуточный уровень, в случае Microsoft включает web сервер Internet Information Server, Microsoft Transaction Server и TQM систему MS Message Queuing Service. Всё это базируется на COM и DCOM, а также использует возможности операционной системы Windows NT.
Что делает MTS сильным сервером приложений? Во-первых, компонентность. Известно, что методы In-Process COM сервера вызываются с той же скоростью, что и методы C++ объекта. Отсюда мы имеем ту же скорость вызова, что и в статически слинкованном CORBA сервера. В то же время это компоненты - для их подключения или замены не требуется остановки старого/запуска нового приложения. Использование Java серверах направлено на достижение именно этого удобства - но, увы, ценой снижения скорости. COM предлагает самую гибкую схему распараллеливания выполнения методов объекта - апартаменты (apartment). Single-thread apartment (STA) подразумевает последовательное выполнение методов в единственной нити. Частный случай STA, когда в апартаментах оказывается единственный объект, приводит нас к соглашениям EJB (методы объекта не могут выполняться параллельно). Модель STA предельно проста и безопасна, она не привносит заботит о синхронизации, так как с одной стороны апартаменты (и нити) изолированы друг от друга, с другой - в одной нити всё выполняется последовательно. В CORBA обычно реализуется одна или несколько из перечисленных стратегий: thread-per-connection(session, client, …), thread-per-object, thread-pool (хотя бывают и другие). Если с первыми двумя всё ясно, то к последней надо относиться очень внимательно, так как смысл только в том, что нить выделяется только на время выполнения метода, а затем возвращается в общий пул. Но могут ли выполняться параллельно в двух разных нитях методы одного и того же объекта? Не обязательно, и надо очень внимательно читать документацию конкретного производителя. Вернёмся к COM. Наиболее гибкая модель - multi-threaded apartment (MTA), когда методы объекта могут выполняться параллельно. Здесь уже приходится прибегать к штатным механизмам синхронизации. MTS предотвращает возможное возникновение взаимоблокировок при использовании самого быстрого из способов синхронизации в NT - критических секций. Дело в том, что эта часть Win32 API разрабатывалась до появления COM, поэтому и не учитывает особенности, привнесённые компонентным подходом. Блокировка в MTS производится с учётом activity ID, чем и предотвращает описанный выше неприятный эффект.
Для организации распределённых транзакций MTS использует Distributed Transaction Coordinator, он взаимодействует с менеджером ресурсов по XA или собственному протоколу Microsoft - OLE Transactions. DTC теперь входит в комплект MTS, что снимает прошлые проблемы (ранее он поставлялся только с SQL Server). Для сохранения состояния объекта может использоваться Shared Property Manager, хотя это и не единственный способ. Помимо XA, MTS поддерживает протокол LU 6.2 и может соединяться с CICS и IMS.
В качестве средств разработки для MTS и MSMQ могут использоваться любые, поддерживающие COM средства. Из того, что включает в себя MS Visual Studio, это, как минимум, Visual Basic, C++ & J++. Эти же инструменты могут быть использованы и при создании интернет-приложений для IIS и IE, хотя более приспособлены для этого J++ и InterDev.
Важным моментом является то, что MTS, как и весь MS Option Pack (IIS, MSQS, и т.д.) не требует лицензирования. А Windows 2000 будет включать их в состав дистрибутива. Узким местом MTS является служба имён Windows NT. И решение этой проблемы напрямую связано со сроками выхода Windows 2000 с его службой ActiveDirectory. Имеются в виду, конечно, ограничения для интранет, так как в интернет-приложениях спасает IIS.
Netscape Application Server
По иронии судьбы, Netscape Application Server использует в качестве ядра IONA Orbix. Ирония в том, что до того, как купить KIVA Applocation Server, Netscape активно сотрудничала с Visigenic.
Теоретически на KIVA можно строить любые приложения. Практически же среда разработки расставляет акценты и выдаёт интересы владельца продукта - это интернет. KIVA Developer Studio состоит из следующих компонент: Project Manager, Query Designer, HTML Designer, AppLogic Designer. Поддерживаются два языка программирования, C++ и Java, однако никаких следов CORBA или EJB вы не найдёте. Всё упрятано очень хорошо. Кроме, разве что, упоминания о том, что интерфейс Open Client Library базируется на IIOP (планируется добавить и DCOM). Программные интерфейсы KIVA описывают построение клиента, использующего HTTP или напрямую OCL, а также создание динамически изменяющихся шаблонов web страниц. Ещё один аспект - работа с СУБД. Предусмотрено управление транзакциями, выполнение простых, иерархических и асинхронных запросов. Интересной особенностью является возможность работы со схемой базы (создание и удаление триггеров и хранимых процедур) непосредственно из API KIVA. Обычно, когда речь идёт о "чужой" СУБД, да ещё и разных СУБД (поддерживаются Oracle, Informix, DB2, SYBASE & MS SQL Server) такого рода средства если и доступны, то только на фазе разработки. Здесь же и генерация отчётов - для клиент-сервер архитектуры это довольно странно, но на самом деле в этом и заключается ориентация на очень тонкого клиента.
Особое внимание уделено организации сессий, т.е. управлению контекстом. Примечательно, что в KIVA можно сессии и состояние делать устойчивыми к сбоям. На практике это означает, что если клиент успел заполнить экранных форм, то при сбое KIVA сервера, ему не придётся набивать всё по новой.
Мы не рассматриваем здесь другие продукты Netscape, такие, как web серверы или LDAP сервис. KIVA - среда, подчинённая решению конкретных задач, она достаточно проста в использовании. В целом среда очень цельная, хотя и нельзя не отметить "спартанские" возможности средств разработки в версии 2.1.
Oracle Application Server
Версия 4 построена на базе лицензированного Visibroker, в то же время присутствуют оригинальные возможности, доступные с предыдущих версий.
Динамическая генерация web страниц доступна посредством целого семейства типов картриджей - LiveHTML, PL/SQL, C, Perl, JWeb и ODBC. Последний позволяет отображать в HTML-таблицах данные, доступные из ODBC источников. Остальные - посылать web клиенту создаваемые "на лету" при помощи разных языков HTML страницы. Приложение может состоять из группы картриджей, каждый из которых реализует отдельную функцию или экранную форму. Неудобством для больших проектов может явиться то, что в рамках одного приложения не допускается смешения типов картриджей, т.е. оно может быть написано только на PL/SQL, только на Java (JWeb) и т.п.
Вторую группу возможностей предоставляют JCORBA и, с некоторыми ограничениями, EJB, предлагающие независимый от HTML (HTTP может использоваться только для перекачки апплета, далее взаимодействие происходит по IIOP) стиль разработки, годный и для интернет, и для интранет приложений.
Oracle отклоняется от стандарта CORBA, заменяя ряд объектов стандарта собственными, и при переносе Java кодов с других CORBA серверов нужно было бы удалить все "extends", так как JCORBA классы не наследуют от "скелета". Впрочем, это не страшно. Остальные ограничения больше обусловлены особенностями Java как языка. Объект может сохранять состояние, только если его методы объявлены как synchronized. Одна транзакция не может выполняться в разных нитях. И т.п. Тем не менее использование JCORBA или EJB предоставляет больше возможностей, чем другие способы разработки в OAS.
Однако это ещё не все ограничения. OTS реализован только в Enterprise версии OAS, но и он не может сам координировать распределённые транзакции, этим занимается сервер баз данных Oracle, но только версии 8. Использование 7 версии допускается, при этом активизируются HO (Heterogeneous OTS) Agents. Об этом не говорится напрямую, но OAS не позволяет работать ни с какими другими СУБД. Несмотря на присутствие функций с префиксом "tx_" в названии, это лишь имитация X/Open DTP - отсутствует сама возможность задать профиль (DAD - database access descriptor) для отличных от Oracle СУБД, а поле "тип СУБД" на деле оказывается версией Oracle. Можно ли это считать недостатком - сложный вопрос. Вполне вероятно, что Oracle и не ставит перед собой задачи создания интегрирующего ПО, и в добавок явно заинтересован в том, чтобы клиенты быстрей переходили на новую версию сервера данных.
В ближайшее время возможности OAS должны расшириться за счёт добавления Oracle Developer и Developer Server. Oracle Developer Server - очень своеобразный и интересный подход к "интернетизации" имеющихся наработок. Сервер обеспечивает перехват всего экранного вывода обычного двухуровневого приложения и перенаправляет его удалённому клиенту на специальный Java апплет. Этот подход применён также и IBM на AS/400, но только для Java. Там стандартный AWT заменён на Remote AWT. Ясно, что объёмные приложения, разработанные на Developer, будут отнимать много ресурсов на сервере, но и выигрыш очевиден - имеющиеся приложения не надо переделывать вообще!
Из наиболее современных средств разработки Oracle предлагает JDeveloper - лицензированный у Borland и дополненный собственными wizard-ами и JSQL прекомпилятором JBuilder. Не заполнен пока пробел в средствах создания HTML страниц.
Sun NetDynamics
По идеологии NetDynamics очень близок KIVA. Точно так же он базируется на ядре CORBA (но собственном). Процесс разработки ориентирован на HTML и Java, всё выглядит так, как при создании двухуровневых приложений. Возможности богатые, множество wizard-ов для создания HTML страниц, объектов для работы с данными и иных, компонент, встроенный редактор JavaBeans. Работа с сессиями, СУБД, возможность сохранения состояния сессии тоже позволяют проводить определенные параллели с KIVA.
Дополнительные типы серверных компонент NetDynamics могут быть подключены через PAC - Platform Adapter Components. Готовых PAC поставляется для NetDynamics изрядно, это стыки с мониторами транзакций, R3, для подключения COM/DCOM компонент и т.д., однако доступен и SDK для создания новых.
С NetDynamics поставляется Inprise Gatekeeper для обеспечения взаимодействия Java апплетов с сервером "сквозь" брандмауэры. В дополнение к этому указывается, что NetDynamics совместим с Visibroker-ом - не в смысле взаимодействия по IIOP, а более тесном. Дело в том, что run-time библиотеки NetDynamics не конфликтуют с библиотеками Visibroker. Это позволяет использовать более полно CORBA сервисы, реализованные в Visibroker, например, такой небесполезный, как OTS.
SYBASE Enterprise Application Server
Данный продукт объединил под общим названием среду динамической генерации web страниц PowerDynamo и Jaguar Component Transaction Server.
Сервер Jaguar CTS поддерживает разработку непосредственно на языках C, C++, Java. При этом поддерживаются разнообразные технологии. Клиентом может быть кто угодно, совместимый с IIOP. Помимо этого могут генерироваться ActiveX/COM заглушки на стороне клиента (при этом по-прежнему используется IIOP). Серверная часть может базироваться на ActiveX/COM, Enterprise и просто JavaBeans, а также создаваться на C, C++ и Java в соответствии со стандартом CORBA. Новые версии продуктов Sybase должны выйти в апреле, и появляется новая возможность - создания как клиента, так и непосредственно исполнения на сервере модулей PowerBuilder. Появились, наконец, и балансировка нагрузки в кластере и восстановление после сбоев.
Административная консоль Jaguar позволяет генерировать IDL для уже существующих объектов, возможно не CORBA-объектов. Имеются и средства генерации переходников к CICS и хранимым процедурам СУБД. Примечательно и другое. Наряду с IIOP Jaguar продолжает поддерживать удалённый вызов в стандарте SYBASE Open Client/Open Server и передавать данные в формате Tabular Data Stream, используемый в том числе и SYBASE SQL Server. TDS уступает IIOP на коротких передачах данных (например, вызове методов объектов), однако эффективен при передаче больших объёмов табличных данных. Но главное даже не это. Поддержка TDS даёт возможность обращаться к методам объектов так, как если бы это были хранимые процедуры SQL Server. Это означает, что безо всякой переделки с Jaguar могут общаться любые приложения, написанные для SQL Server и не понимающие IIOP. Данная особенность называется Methods As Stored Procedures (MASP).
Интересно то, что и в Jaguar не требуется наследовать от "скелета", сформированного IDL компилятором. Вместо этого вызов делегируется. Сделано это для того, чтобы избавиться от привязки к конкретным компиляторам C++ и дать возможность работать с любым. Вместо линковки со статическими библиотеками используются заголовочные файлы, содержащие всё необходимое в форме inline методов.
Однако сохраняется и существенное ограничение - Jaguar лишён средств управления распределёнными транзакциями. Он либо использует псевдокоординатор Shared Connection, либо Microsoft DTC.
Спектр средств разработки Sybase широк. Это PowerBuilder, PowerJ & Power++. Это CASE PowerDesigner и это развитой пакет для создания HTML страниц PowerSite. Sybase предлагает также и PowerBuilder Web Deployment - аналог вышеописанного Oracle Developer Server, но для PowerBuilder приложений.
Назад | Содержание | Вперед