Спецификация EJB версии 2.0
Серверы Enterprise JavaBeans упрощают разработку промежуточного программного обеспечения путем предоставления автоматической поддержки таких сервисов, как транзакции, безопасность, связность баз данных и т.д. Спецификация EJB 2.0 представляет собой существенно новую версию, предлагающую множество значительных преимуществ. Данная статья описывает изменения в EJB 2.0 и то, как новые особенности могут упростить и ускорить разработку приложений.
Новое в спецификации Enterprise JavaBeans 2.0
После своего внедрения более двух лет назад, спецификация Enterprise JavaBeans (EJB) сохраняла свое беспрецедентно устойчивое продвижение на фоне похожих продуктов от поставщиков платформ для разработки и корпоративных систем. Это является следствием того, что серверная часть EJB упрощает разработку компонент промежуточного программного обеспечения, которые поддерживают транзакции, масштабируемы и переносимы.
Серверы Enterprise JavaBeans упрощают разработку промежуточного ПО путем предоставления автоматической поддержки таких сервисов, как транзакции (transactions), безопасность (security), связность баз данных (database connectivity) и проч.
Спецификация EJB 2.0 представляет собой существенно новую версию, предлагающую множество значительных преимуществ, упрощая и ускоряя разработку и размещение более опционально насыщенных корпоративных приложений.
26 апреля 2001 года компания Sun представила общественности спецификацию EJB 2.0 "Final Purpose Draft" №2 через Java Community Process (JCP 2.0).
Данная статья описывает изменения в EJB 2.0 и то, как новые особенности могут упростить и ускорить разработку приложений.
Так как спецификация EJB была основной технологией в реализации задач электронной коммерции, в качестве примера для описания ключевых возможностей спецификации EJB 2.0 будем рассматривать web-сайт, занимающийся розничной продажей.
Интеграция с JAVA MESSAGE SERVICE (JMS) – Asynchronous Capabilities Streamline Systems (системы ускорения асинхронных сервисов)
Использование асинхронных сообщений делает возможным разработку слабо связанных систем (или приложений). Эти системы более эластичны в случае сбоев и легко расширяемы по мере появления новых приложений. В добавок к этому, сервис сообщений является эффективным средством обмена запросами между приложениями.
Java Message Service (JMS) предоставляет службы асинхронных сообщений для разработчиков приложений на Java.
Интеграция JMS и EJB позволяет корпоративным компонентам (enterprise beans) эффективно участвовать в работе слабо связанных систем. Посредством такой интеграции корпоративные компоненты, управляемые сообщениями, могут получать JMS-инструкции и действовать согласно им, без привлечения (или даже существования) клиента пользовательского интерфейса. Эта новая возможность делает EJB превосходным средством для разработки распределенных бизнес-служб. Кроме того, любой из EJB-компонентов может отправлять асинхронные сообщения через JMS API (прикладной программный интерфейс JMS).
На примере торгового web-портала, когда покупатель делает заказ, компонент-"кладовщик" (inventory bean) может уведомить управляющий компонент (ordering bean) или внешнюю систему координации поставок о снижении запасов. Так как это сообщение асинхронно, покупатель не должен ждать завершения сложного процесса перенаправления заказов. Более того, off-line клиенты, такие, как пользователи мобильных телефонов, могут запросить сделку (например, покупку/продажу акций) и сразу же отсоединиться. Соответсвующее асинхронное сообщение будет отправлено компоненту-торговцу (trading enterprise bean), который может совершить сделку и по исполнении послать уведомление на телефон клиента.
Как показывает этот простой пример, интеграция с JMS ускоряет работу приложений, устраняет узкие места ("bottlenecks") и уменьшает время ожидания для пользователя, что в итоге приводит к повышению продаж и удержанию заказчиков.
Персистентность, управляемая контейнером (Container-Managed Persistence (CMP)) – упрощение и ускорение разработки приложений
Архитектура EJB существенно упрощает связь между уровнями приложений и баз данных (БД). Спецификация EJB 2.0 продвигает это преимущество на следующую ступень, позволяя разработчикам создавать портативные приложения, не зависящие от БД и не содержащие кода доступа к БД.
Как это часто бывает, разработчики не имеют доступа к физической схеме БД во время создания приложений. Иногда это делается из соображений безопасности, иногда- из-за того, что схема БД не была разработана или закончена. В других случаях сами разработчики не хотят знать всей схемы БД, особенно когда большая и сложная БД разделена между многими менее сложными приложениями.
CMP может быть использована, дабы изолировать разработчика от физической схемы БД. Это достигается путем создания абстрактной схемы, которая отвечает нуждам данного приложения, и использования CMP, чтобы поставить в соответствие абстрактную и физическую схемы. Этот метод позволяет лучше распределить усилия между разработчиками, требует написания и поддержки меньшего объема машинного кода и ускоряет продвижение продукта. В добавок ко всему, использование CMP гарантирует мобильность приложений в случае смены схемы БД или поставщика.
Спецификация EJB 1.1 предоставляла простые возможности CMP, которые содержали некоторые из этих преимуществ. Тем не менее, информация от разработчиков свидетельствовала о том, что эти средства были слишком ограничены, как в способах организации данных, так и в используемом механизме установления соответсвия между CMP-компонентом и схемой БД.
EJB 2.0 расширяет CMP для реализации этих возможностей. Добавлена гораздо более устойчивая служба моделирования, с поддержкой декларативного управления взаимосвязями между entity-компонентами (entity beans). Разработчикам больше не требуется переустанавливать взаимосвязи между отдельными бизнес-компонентами, входящими в их приложение- контейнер, контейнер автоматически восстанавливает взаимосвязи между компонентами по мере их загрузки, позволяя переходить от одного компонента к другому, как если бы они были стандартными Java-объектами.
Спецификация EJB 2.0 также впервые предоставляет портативный язык запросов, основанный на абстрактной схеме, а не на более сложной схеме БД. Это предоставляет независимый от поставщика и структуры БД способ поиска сущностей (entity beans) в процессе работы системы, основанный на разнообразных критериях поиска.
Что это означает? Разработчики могут сосредоточиться на создании бизнес-логики, в то время как оболочка EJB автоматически управляет доступом их приложений к БД.
Для нашего web-продавца преимущество CMP проявит себя во многом. Например, многочисленные обновления БД должны происходить после покупки – в складской БД, в БД заказов, БД покупателей и так далее. Чтобы усложнить ситуацию, будем считать, что некоторые БД связанные, в то время как остальные могут быть, например, системой управления взаимоотношений с клиентами или другими корпоративными приложениями.
Декларативные взаимосвязи между корпоративными компонентами (enterprise beans) позволяют разработчику определить соотношения между покупателями и заказами. Нет надобности знать складские технологии, или связи с внешним ключом, или даже вручную прописывать код доступа к БД, чтобы облегчить все обновления БД. Это повышает конкурентоспособность web-продавца за счет ускорения внедрения своих продуктов, причем не только для отдельно взятых приложений, но и для их обновлений, что необходимо при часто меняющихся потребностях рынка. В итоге приложение будет более компактным (а соответственно, его легче поддерживать) и переносимым на базы данных и серверы приложений других поставщиков, позволяя таким образом выбирать различных поставщиков по мере изменения политики бизнеса.
Локальные интерфейсы (Local Interfaces) – ускорение запросов между локальными бизнес-компонентами
Спецификация EJB изначально разрабатывалась под удаленные вызовы с использованием механизма Java Remote Method Invocation (RMI), и позже расширилась для поддержки стандартного механизма передачи COBRA через RMI/IIOP (Internet Inter-ORB Protocol). Эта структура предусматривала максимальную гибкость в процессе разработки приложений, не учитывая общего сценария создания системы, и была сильной стороной в поддержке повторного использования компонент J2EE.
Было получено множество отзывов, касающихся использования EJB-элементов на местах. Многие проектировщики используют EJB локально, то есть некоторые или даже все EJB-запросы посылаются компонентами внутри одного контейнера.
Помня об этой обратной связи, экспертная группа EJB 2.0 создала механизм локального интерфейса. Для компонента локальный интерфейс может быть задан во время разработки, чтобы разрешить получение ускоренных запросов, при условии, что отправитель запроса находится в том же контейнере. Эта опция улучшит работу приложений, для которых учтено близкое расположение.
Интерфейсы спецификации EJB 2.0 могут оказаться весьма полезными в ситуациях, для которых они были разработаны.
Однако, важно понимать, что семантика запросов локальных интерфейсов отличается от семантики для удаленных интерфейсов. Например, удаленные интерфейсы передают пераметры, используя схему "вызов по значению" (call-by-value), в то время как локальные интерфейсы используют "вызов по ссылке" ("call by reference").
Это значит, что для безопасного использования локальных интерфейсов разработчики должны заранее внимательно рассмотреть потенциально возможные сценарии размещения, затем определить, какие интерфейсы будут локальными, а какие – удаленными, и только потом писать приложение с учетом указанных факторов.
Локальные интерфейсы EJB 2.0 чрезвычайно полезны в некоторых ситуациях. Однако долгосрочная стоимость этих элементов (особенно в случае возможных изменений требований и повторных использований компонентов) должна быть учтена в проектном решении.
Межсерверное взаимодействие – задействование неоднородных сред (homogenous environments)
Межсерверная мобильность всегда являлась центральной предпосылкой для технологии EJB. Спецификация EJB 2.0 продвигает это преимущество на следующую ступень, предлагая возможность для межсерверного взаимодействия приложений. Это позволит приложениям, сонованным на технологии EJB и работающим на EJB-серверах различных поставщиков, свободно взаимодействовать, используя протокол RMI-IIOP.
В примере с web-продавцом , компонент-"тележка" ("cart bean") на сервере одного торгового агента сможет получать складскую информацию, связываясь с компонентом-"кладовщиком" (inventory bean), существующим на сервере другого агента. Таким образом торговые агенты смогут размещать свои EJB-приложения в неоднородных окружениях, совмещая работу на серверах различных агентов.
При этом компоненты способны эффективно связываться между собой через эти серверы.
Заключение
Спецификация EJB 2.0, созданная Java Community под спецификацией Java Community Process 2, является важным шагом в ускорении разработки и размешения J2EE-приложений. Когда эта спецификация будет применяться под J2EE 1.3, разработчики смогут создавать приложения, отвечающие ключевым характеристикам J2EE:
J2EE ускоряет продвижение программных решений на рынок;
J2EE предотвращает блокировку поставщика;
J2EE упрощает интеграцию.