Сервер приложений - дверь в новый мир

Технология CORBA 2.3 стандартизировала чаяния и стремления производителей ПО, а спецификация Java 2 Platform Enterprise Edition (J2EE) стала отправной точкой при строительстве поистине уникальных программных решений для самых разных аппаратных и программных платформ. Заметим, что объектная технология COM+ корпорации Microsoft, всегда считавшаяся альтернативной, проповедует во многом схожие идеи.

Некоторые солидные фирмы, например Inprise/ Borland и IONA Technologies, используют стандарт J2EE в качестве открытого интерфейса для программистов, «подложив» под него средства CORBA. К сожалению, «сердце» технологии J2EE — Enterprise JavaBeans (EJB) — в качестве основы использует метод удаленного вызова RMI. Поэтому в сервере приложений IONA iPortal Inprise Application Server, равно как и в конкурирующем продукте Inprise Application Server, большая часть средств J2EE выполнена с использованием сервисов и составляющих CORBA. К примеру, JNDI использует сервис именования (Naming Service) CORBA.

Как устроен IONA iPortal

Сервер приложений iPortlal Application Server ирландской компании IONA поддерживает требования технологии J2ЕЕ и может выполнять сеансовые (session) и сущностные (entity) компоненты EJB, организовывать их взаимодействие с контейнерами и между собой с помощью RMI/IIOP и следить за транзакциями приложения. Сервер iPortal содержит драйверы JDBC 2.0 для доступа к базам данных, подсистемы для выполнения сервлетов версии 2.2, серверных страниц Java версии 1.1 и прочие обязательные атрибуты полноценного сервера приложений.

Любопытно, что сервер компонентов EJB в этом продукте строится на основе переносимых объектных адаптеров (POA) спецификации CORBA 2.3 с применением автоматического поиска объектов и их активизации (подробнее об этих средствах см. «Мир ПК», № 3/2000, с. 156). POA в iPortal (равно как и в Inprise Application Server) служит для организации всех контейнеров. Именно внедрение этого типа объектных адаптеров сделало серверы приложений быстрыми и мощными. И хотя компания IONA ставит это себе в заслугу, думается, что большинство схожих продуктов работают одинаково, ибо описанная архитектура действительно наилучшим образом подходит для их реализации.

Еще одной особенностью iPortal является активное использование менеджеров сервантов CORBA, а конкретнее — объекта ServantLocator. Этот класс служит для поиска ссылок на серванты по запросу клиента, когда они не обнаруживаются в таблице активных объектов. ServantLocator находит подобную ссылку или же создает экземпляр серванта и возвращает ссылку на него — прямой пример запуска объекта в нужное время. Этот механизм прекрасно работает и с пулом уже запущенных объектов: получив запрос, ServantLocator обращается к менеджеру пула объектов и просит его найти не занятый работой сервант объекта. В приложении к компонентам EJB получается следующая картина. Как известно, ведущая свою родословную от RMI, технология компонентов EJB разбивает компонент на три части: собственно код компонента, Home-интерфейс, выполняющий поиск и активацию объекта, и Remote-интерфейс, служащий удаленным представителем кода компонента. Из этого следует, что при поиске компонента программы обращаются сначала к его Home-интерфейсу. Последний с помощью ServantLocator находит в пуле ссылку на свободный объект либо дает команду создать новый экземпляр объекта. Возвращаемая ссылка указывает на Remote-интерфейс и может использоваться в качестве точки обращения к компоненту EJB. Как видите, в iPortal две технологии — J2EE и CORBA — так тесно переплетаются, что трудно понять, что есть что. Даже Java-классы Home- и Remote-интерфейсов реализованы в виде заглушек (stubs) CORBA. Это RMI-IIOP в действии. И между прочим, все указывает на то, что в сервере приложений компании Inprise используется похожая архитектура. Разница лишь в том, что в качестве менеджера сервантов применяется не ServantLocator, а другой объект — ServantActivator.

Orbix 2000 — важнейшая часть iPortal

Другой важнейшей частью iPortal является брокер объектных запросов Orbix 2000, выполненный по архитектуре ART (Adaptive Runtime Technology). Это ORB, соответствующий спецификации CORBA и служащий транспортной шиной для всех запросов и данных. Адаптивность Orbix 2000, подчеркнутая названием, состоит в активном применении концепции заменяемых модулей.

Поэтому внутри каталога orbix_art1.0idl пользователь найдет все необходимые файлы с IDL-описаниями объектов Orbix. Указать же новые модули можно в конфигурационных файлах доменов.

Приложения из компонентов EJB

IONA iPortal Application Server содержит различные средства создания приложений, соответствующих требованиям технологии J2EE. Однако своего компилятора Java в этом продукте нет, поэтому все конфигурационные файлы для сборки примеров настроены на использование стандартного компилятора javac из набора JDK. Если учесть, что большая часть работы по созданию J2EE-ориентированных приложений заключается в архивации готовых классов Java и модификации дескриптора развертывания (deployment descriptor), становится понятно, почему все внимание IONA было сфокусировано на единственном графическом инструменте — Graphical Application Builder, написанном целиком на Java. Применяется он на всех основных этапах жизненного цикла EJB-приложений:

• сборка компонентов и приложений;
• развертывание компонентов и приложений;
• управление готовыми приложениями.

Эти три задачи распадаются на множество подзадач. Скажем, сборка компонентов и приложений требует частого обновления архивных файлов, модификации внутренней информации. Со всем этим утилита Graphical Application Builder справляется прекрасно. Правда, ее интерфейс многим программистам покажется донельзя путаным, что связано с отходом от традиционной практики создания приложений.

Интерфейс Graphical Application Builder

При внимательном чтении документов Sun, посвященных идеологии J2EE, многое в интерфейсе Graphical Application Builder станет понятно.

Верхняя левая панель Explorer предлагает два вида ресурсов: ресурсы проекта и ресурсы Internet. Последние представляют собой встроенную систему доступа к страницам фирм-партнеров IONA Technologies, поставляющих компоненты EJB. Эта же система позволяет связаться с Web-узлом IONA, чтобы посмотреть документацию, заглянуть в базу данных технической поддержки и т. д.

Ресурсы проекта — это то, с чем работают специалисты, создающие и развертывающие приложения. Они размещены в трех секциях: Provision, Assembly и Deployment. Секция Provision предназначена разработчикам, самостоятельно создающим компоненты EJB и собирающим их в JAR-архивы. Объявив, какие компоненты должны войти в поставку, программист декларирует их Home- и Remote-интерфейсы, равно как и код бизнес-логики, вместе со ссылками на другие сущности. В общем, создает склад готовых к употреблению бизнес-компонентов, после чего они становятся доступны сборщикам приложений.

В задачу сборщика приложений, который работает с секцией Assembly, входит увязка компонентов между собой и создание дескриптора развертывания, по которому готовая система будет настраиваться. Здесь, пожалуй, стоит отметить самую интересную возможность среды Graphical Application Builder — связывание с помощью перетаскивания (drag-and-drop): сборщик «набрасывает» компоненты на рабочую поверхность и начинает соединять их, пододвигая друг к другу. При этом для компонента, обрамленного красным, соединение не предусмотрено. Если же рамка синяя, то между компонентами возникает связь, которая маркируется синей стрелкой (подобный способ знаком пользователям продуктов VisualAge корпорации IBM). Сборщик также создает роли для обеспечения безопасности.

* * *

IONA iPortal Application Server — это очень мощный продукт и, на мой взгляд, единственный достойный конкурент Inprise Application Server. Несмотря на свою склонность заставлять пользователей поработать руками, опора на идеи технологии J2EE позволяет при умелом применении в несколько раз сократить срок создания и развертывания большой информационной системы. Сочетание с некоторыми другими продуктами IONA обеспечивает потребителю еще и доступ к ресурсам старых мэйнфреймов и COM-объектов. Правда, если начальник предприятия предпочтет купить описанные программные средства, а не новый джип.

Дмитрий Рамодин

iPortal Application Server 1.1 Standard Edition

Требования к ОС: Windows NT 4.0 SP6a / Windows 2000/ SunOS 5.7 (Solaris 7) с установленным JDK 1.2.2.
Достоинства: модульность; гибкая конфигурация для самых разных задач; следование современным открытым стандартам; хорошая поддержка производителем; занимает относительно малое место (70—100 Мбайт) на жестком диске; хорошая документация в формате Adobe Acrobat; возможность разработки своих встраиваемых в архитектуру продукта модулей.
Недостатки: отсутствие представительства в России; очень скромный графический интерфейс пользователя; необходимость прописывать часть параметров вручную; расшифровка многих ошибок не отображается, а записывается в файлы протокола.
Разработчик: IONA Technologies PLC

Коротко о J2EE

До появления J2EE (версия 1.2) многие очень перспективные технологии были как бы бесхозными, «болтались» сами по себе и связи между ними были расплывчатыми и неконкретными. Спецификация J2EE все поставила на свои места. Интерфейс имен и каталогов, протокол удаленных вызовов, программные требования к Web-серверным расширениям-сервлетам и т. п. — все было увязано с сервисами CORBA, создан специальный транслирующий слой RMI-IIOP (также средствами CORBA) для поддержки начинающей устаревать RMI.

Если посмотреть на технологию J2EE с маркетинговой точки зрения, то основными представляются четыре позиции:

• спецификация платформы — документация, определяющая требования J2EE;
• reference implementation — набор инструментов, документации и библиотек, созданных компанией Sun в качестве эталона для других фирм-разработчиков;
• compatibility test suite — набор тестовых программ для проверки ПО на совместимость с платформой J2EE (доступны лишь для тех, кто лицензирует Java)
• Sun BluePrints Design Guidelines — документация, показывающая, как строить приложения в соответствии с требованиями J2EE.

Рис. 1

В основу J2EE легла стандартная редакция Java Development Kit (JDK) со всеми ее составляющими: компонентами JavaBeans, аплетами, CORBA, RMI, JDBC и др. (рис. 1). Базовым элементом программных технологий масштаба предприятия является контейнер — специальный код, внутри которого запускается другой код: сервлеты, компоненты Enterprise JavaBeans (EJB), Java Server Pages (JSP). Рука об руку с контейнерами трудятся службы транзакций (transactions), сообщений (messaging) и почты (mail).

Разработчикам прежде всего надо знать, как реализовать собственные компоненты EJB, поскольку в них «упаковывается» бизнес-логика промежуточного уровня. Почти все остальные составляющие работают, что называется, «на подхвате», т. е. обеспечивают правильное и полноценное функционирование компонентов EJB. Архитектура для решений на базе современных серверов приложений показана на рис. 2.

Рис. 2

Собственно, к серверу приложений относятся Web-контейнер и EJB-контейнер. Первый служит местом, куда устанавливаются сервлеты и страницы JSP. Второй предоставляет компонентам EJB среду исполнения и следит за транзакциями, обменом сообщениями, данными и т. д. Это означает, что львиную долю работы в создаваемых приложениях будет выполнять именно сервер приложений.