Стандарты

OSF/DCE

Что предлагал в первую очередь стандарт Distributed Computing Environment организации Open Software Foundation, так это удалённый вызов (remote procedure call, RPC) и возможность распараллеливания процесса, нити (threads).

Вместо ручного программирования, на уровне таком же как, например socket, NetBIOS или LU 6.2, стандарт предлагает описывать группы функций (интерфейсы) на специальном языке IDL (Interface Definition Language), на основе которого препроцессор должен генерировать функции-заглушки и сразу два исходных текста - для стороны клиента и для стороны сервера. Это сочетается с набором специализированных библиотек, используемых при построении задачи. Цель - максимально упростить создание распределённых систем, сокрыть все детали, хотя и давать к ним доступ, если в том возникнет необходимость. Нити нужны для того, чтобы процесс мог одновременно отвечать на множество приходящих по сети вызовов и в свою очередь обращаться к другим серверам сети.

При построении распределённой системы, включающей множество серверов и предоставляемых ими сервисов (доступных по RPC), служба имён становится остро необходимой. В DCE предлагаются две - это Cell Directory Service и Global Directory Service. Первая, CDS, объединяет серверы и сервисы, но не даёт возможности выхода за границы ячейки. Вторая организует глобальный каталог X.400. Другими определяемыми в OSF/DCE сервисами являются служба секретности и распределённая файловая система DFS. Необходимость в реализации DFS здесь, а не на более высоком, прикладном, уровне обусловлена тем, что и службе секретности, и службе имён необходимо вести и синхронизировать в распределённой среде собственные файлы, хранящие конфигурацию и т.п. Ещё один сервис - служба времени. Синхронизация часов в сети необходима, иначе мы теряем возможность определить очерёдность событий, расчёта временных интервалов и т.п.

Целью DCE было стандартизовать распределённые "системы вообще". Принцип, сформулированный Джеромом - взять не то, что может пригодиться, а то, без чего нельзя обойтись. Об этом надо помнить, читая аналитические опусы о закате DCE. "Закат" этот ознаменован тем, что OSF/DCE реализована для всех основных платформ. Она включена в базовый набор Digital Unix, HP-UX и AIX. Она доступна в качестве опции для Solaris, NT и даже OS/400 и S/390. Другое дело - DCE не стала широко распространённой средой для прикладного программирования. Но далее мы вспомним о ней ещё не раз.

COM/DCOM

Данная технология восходит к OLE 1 и расширениям VBX. О COM мы услышали после выходя стандарта OLE 2 и OCX. Стандарт Component Object Model - общий фундамент для разработки и использования программных компонент. Поскольку COM изначально предусматривал в том числе и вызов функций, находящихся за границами процесса, переход к Distributed COM, был делом техники. DCOM сочетает в себе COM и удаленный вызов в стандарте Microsoft. В порядке отступления: Microsoft оказалась первой фирмой, реализовавшей RPC в стандарте DCE - ещё в Windows NT 3.1. И так как интегрироваться было особо не с кем, компания решила позволить себе некоторые вольности в реализации, направленные на повышение производительности. Однако до сих пор MS Platform SDK поддерживает как собственный MS RPC, так и стандартный, OSF/DCE RPC.

С появлением DCOM модификации подвергся и язык описания интерфейсов DCE IDL. Он стал называться ODL. Справедливости ради, надо заметить, что сам стандарт OSF/DCE подразумевает возможность внесения подобных изменений, и Microsoft всё делала в соответствии со стандартом. Как и в DCE, компиляция текста ODL даёт на выходе "скелет" кода на том языке программирования, для которого предназначен компилятор. В интегрированных средах типа Visual Basic или PowerBuilder программисту не приходится работать с ODL при создании COM объектов, все детали скрыты.

Перенос DCOM на Solaris был осуществлён самой Microsoft. Порты DCOM на S/390 и ряд клонов UNIX, включая Linux, был осуществлён компанией Software AG в рамках создания ею новой версии своего связующего ПО Entire - EntireX.

CORBA

Цели введения стандарта Common Object Request Broker Architecture примерно те же, что и у DCE. Однако для CORBA изначально была объявлена ориентация на объектную модель и язык описания интерфейсов. CORBA IDL в отличие от DCE IDL базировался на подмножестве C++. Существенно для CORBA IDL, что он поддерживает наследование, в то время как DCE IDL и MS ODL - нет. Это нередко служит источником для различных спекуляций. Запись на CORBA IDL действительно выглядит компактнее, она вызывает меньше вопросов у тех, кто знаком с C++, однако надо помнить, что COM/DCOM объект может реализовывать более одного интерфейса (CORBA класс, как и в C++ - только один), а описание COM интерфейса призвано быть независимым от языка реализации.

Основополагающими документами для CORBA являются два - "The Common Object Request Broker: Architecture and Specification" и "CORBAservices: Common Object Services Specification".

Первый описывает все основы CORBA, а также многие вполне конкретные вещи, составляющие фундамент CORBA, в том числе:

IDL, о котором было сказано выше.
Dynamic Invocation Interface (DII) позволяет клиенту обращаться к объектам, которые были неизвестны или недоступны ему на стадии компиляции.
Dynamic Skeleton Interface (DSI), позволяющий динамически перенаправлять приходящие от клиентов запросы уже на стороне сервера - от ORB-а конкретному объекту. Надо заметить, что динамические DII и DSI не рекомендуется применять без особой надобности, так как они заметно медленнее статических.
Portable Object Adaptor (POA). Данная спецификация преследует своей целью создавать приложения, которые могут легко переноситься между ORB-ами разных производителей.
Interface Repository - хранилище спецификаций объектов, заданных IDL текстами.
В CORBA 2.0 и выше много внимания уделено вопросам интеграции. Спецификация General Inter-ORB Protocol (GIOP) задаёт общие принципы удалённого вызова в CORBA, описывает формат представления данных (CDR) и служебных сообщений. Часто упоминаемый Internet Inter-ORB Protocol (IIOP) является специализацией GIOP для сетей TCP/IP. Другим частным случаем GIOP и заодно Environment Specific Inter-ORB Protocol является DCE CIOP, "укутывающий" DCE/RPC.
Документ описывает также, как генерировать из IDL исходные тексты для языков программирования C, C++, Smalltalk, Cobol и Java,
и как интегрировать CORBA с COM и OLE Automation
Interceptors описывают стандарт внедрения между вызывающим и вызываемым дополнительных агентов.

Документ "CORBAservices" перечисляет базовый набор сервисов (интерфейсов), которые неплохо было бы иметь для того, чтобы можно было надстраивать над ними прикладные сервисы. Знать 15 сервисов, описанных в данном документе очень полезно, так как за абстрактной "поддержкой CORBA" тем или иным производителем могут скрываться совершенно различные вещи. Сервисы эти разной степени важности, но, так или иначе, вот они:

Naming - базовая служба имён. Иерархического вида каталог доступных в сети сервисов. Здесь надо быть внимательным - некоторые поставщики CORBA используют для реализации данной службы каталог DCE/CDS, что не возбраняется, однако требует, как минимум, его наличия. Вообще стандарт не запрещает использовать для реализации Naming Service любую существующую службу каталогов.
Event Service описывает возможности асинхронного взаимодействия, в том числе "активного сервера"
Persistent Object Service - описывает то, каким образом состояние объекта может быть сохранено, а затем восстановлено.
Life Cycle Service. Учитывает моменты, порождённые тем, что объект в течение своего жизненного цикла может перемещаться между компьютерами.
Concurrency Control Service. Специфицирует регулировку доступа к объекту в конкурентном режиме. Механизм - разные типы блокировок.
Externalization Service описывает способ представления состояния объекта в виде потока данных. Это используется при сохранении в файл или перемещениях между областями памяти.
Relationship Service. Возможность непосредственного представления отношений между объектами по образу и подобию классической ER модели Чена.
Transaction Service. Очень важный сервис. Его наличие и отсутствие в реализации CORBA и есть грань между объектно-ориентированным монитором транзакций и просто объектным брокером запросов. Object Transaction Service отвечает за демаркацию транзакций, координацию множества объектов, которые могут быть вовлечены в транзакцию, в том числе и объектов, распределённых по узлам сети.
Query Service. Даже работа с коллекциями объектов предусмотрена стандартом! Какой язык запросов должен использоваться, явно не указано, хотя говорится об объектных расширениях SQL.
Licensing Service - управление лицензированием
Property Service - возможность ассоциирования с объектами свойств, не являющихся атрибутами объекта.
Time Service - служба времени
Security Service - важный вид сервиса, суть которого, я надеюсь, понятна
Trading Object Service - очень интересное расширение службы имён. Вместо того, чтобы использовать точное имя сервиса по Naming Service, клиент указывает необходимый ему тип объекта, а trader сам находит подходящий.
Object Collection. Регламентирует базовые операции над коллекциями объектов.

Помимо вышеупомянутых документов существует ещё "Common Facilities", а также огромное количество разной степени важности бумаг. Достаточно уже и того, что далеко не всё из описанного в двух самых важных реализуется производителями CORBA или CORBA-совместимых серверов приложений.

Java

Несмотря на то, что Java и CORBA нередко оказываются рядом, надо помнить, что это не одно и то же. Совместное использование этих технологий в серверах приложений объясняется желанием совместить "лучшее двух миров". Традиционно при создании приложения CORBA используется линковка. В результате скорость исполнения высока, однако сопровождать такое приложение тяжело. И многие пытаются бороться с этим. В то же самое время Java предлагает единообразное решение - динамическое связывание, Java компоненты (beans) стороны сервера в сочетании с остальными API, объединённые общим названием Java Enterprise.

Enterprise Java Beans 1.0 - разновидность Java компонент, предназначенных для выполнения на сервере. Здесь описывается обязанности контейнера для EJB, обязательные для реализации классы Session и Entity (вообще говоря, в стандарте 1.0 второй необязателен, однако может стать таковым в 2.0), оговорены моменты, связанные с состоянием объекта, секретностью и обработкой ошибок. Описаны также аспекты взаимодействия с JTS, а также отображение в CORBA. Существенным для EJB является соотношение 1 экземпляр - 1 нить, т.е. методы объекта не могут выполняться в разных нитях, поэтому объект в целом - нереентерабелен.

Java Transaction API 1.0 - аналог X/Open DTP в Java варианте. Описывает, как менеджер транзакций (Java Transaction Manager, JTM) должен взаимодействовать с приложением (EJB) - за это отвечает интерфейс UserTransaction, сервером приложений - интерфейс TransactionManager, и менеджером ресурса - интерфейс XAResource. Использование XA закономерно - как я уже говорил ранее, этот интерфейс поддерживается всеми "большими" СУБД. Чтобы было понятно место других известных API из группы Java Enterprise: EJB описывает взаимодействие прикладного компонента (bean) с сервером приложений, а JDBC - взаимодействие сервера приложений с менеджером ресурсов. Там же, где и JDBC, находится Java Message Service - интерфейс к TQM. Несмотря на то, что в 9 случаях из 10 абстрактная TQM система на проверку оказывается IBM MQSeries (пожалуй, только она, да RTQ в TopEnd поддерживали XA), интерес к подобным системам возрастает, появляются новые, а вместе с ними и идут попытки их привести к общему знаменателю (CORBA messaging - один из примеров).

Совсем небольшой документ Java Transaction Service 0.95 описывает тот транзакционный сервис, на который должен опираться JTM. Вообще говоря, речь об CORBA OTS. И общая картина такова - JTM фактически является переходником, закрывающим OTS от остальных составляющих компонент сервера приложений Java.

Назад | Содержание | Вперед