Александр Цимбал

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

Введение

Интерес к программным средствам такого рода высок еще и потому, что прикладным разработчикам, в общем, не приходилось близко сталкиваться с этой проблемой. Господствующей архитектурой клиент-серверных приложений была (и остается) 2-хзвенная схема - сервер базы данных (или аналогичное ему стандартное программное обеспечение) и клиентские приложения. «Широкими массами» разработчиков накоплен богатый опыт работы «на стороне клиента», но проблемы обеспечения функционирования серверов касались, главным образом, системных администраторов. Прикладных программистов интересовал API клиента серверов СУБД, но не технологические подходы, обеспечивающие их эффективную работу.

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

Как всегда, наличие реальной проблемы стимулировала работы по ее решению. В настоящий момент дальше всего в этом направлении продвинулись две технологии - Enterprise JavaBeans и COM+ (особенно после появления Windows 2000). В самое ближайшее время - ориентировочно, в конце 2000 года - ожидается «выход на ринг» еще одного очень сильного участника - Компонентной модели CORBA.

Заметим, что основные соперники EJB либо находятся в стадии окончательной доводки и создания реализации (компонентная модель CORBA), либо имеют ограниченную область применения из-за привязки к одной операционной системе и разработанным именно для нее другим программным средствам (COM+).

Назначение и концепция

Самый элементарный анализ того, что такое «создание масштабируемых и эффективных серверов приложений с использованием Java», приводит к необходимости рассмотрения следующих проблем:

• организация удаленных вызовов между объектами, работающими под управлением различных виртуальных машин Java;
  
• управление потоками на стороне сервера;
  
• управление циклом жизни серверных объектов (создание, взаимодействие с пользователем, уничтожение). Оптимизация использования ресурсов (время процессора, память, сетевые ресурсы). Такая задача требует создания некоторых сред по управлению объектами - «контейнеров».
  
• создание схемы взаимодействия контейнеров и операционных сред;
  
• создание схемы взаимодействия контейнеров и клиентов, включая универсальные средства создания разработки компонентов и включения их в состав контейнеров;
  
• создание средств администрирования и обеспечение их взаимодействия с существующими системами;
  
• создание универсальной системы поиска клиентом необходимых серверных компонентов;
  
• обеспечение универсальной схемы управления транзакциями;
  
• обеспечение требуемых прав доступа к серверным компонентам;
  
• обеспечение универсального взаимодействия с СУБД.
  

Использование Java решает еще одну очень важную и непростую проблему - обеспечение всех вышеперечисленных требований на различных платформах и для различных операционных систем. Правда, возникает вопрос о производительности создаваемых программных комплексов (в настоящее время Java-программы в общем случае уступают в этом смысле своим C++-аналогам).

Спецификация EJB дает ответы на все вышеперечисленные вопросы. Как и всякая серьезная и универсальная технология, EJB имеет свою «философию». Вот ее основные положения:

• необходима формализация процесса разработки распределенной системы с использованием EJB и взаимодействия различных его этапов между собой;
  
• необходима формализация схемы взаимодействия клиентов и серверов;
  
• необходима формализация взаимодействия серверов и операционной среды.
  

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

Этапы создания EJB-проектов

Процесс разработки подразделяется на 5 этапов (6-ой этап, предусмотренный спецификацией EJB - этап администрирования). С каждым этапом сопоставлены вполне конкретные обязанности (роли):

• Поставщик Сервера (Server Vendor))
  
• Поставщик Контейнера (Container Vendor)
  
• Разработчик Компонента (Bean Provider)
  
• Сборщик Приложения (Application Assembler)
  
• Установщик EJB (EJB Deployer)
  

Создание Серверов EJB и Контейнеров EJB (первые две роли) - проблема поставщиков инструментальных средств (BEA, INPRISE, Oracle, Sun и др.) При создании проектов прикладных разработчиков касаются вопросы, относящиеся к оставшимся трем ролям.

Bean Provider - это специалист в той прикладной области, в которой создается данный проект. Его задача - реализация необходимой заказчику функциональности системы. Такой разработчик, в общем, не должен быть специалистом ни в области сетевых технологий, ни в области управления транзакциями, ни в области взаимодействия с конкретными СУБД. Технология EJB и рассчитанные на взаимодействие с ней инструментальные средства (например, Borland JBuilder) позволяют автоматически генерировать «скелет» создаваемого компонента. Разработчику остается только дописать код необходимых методов.

Кроме этого, Разработчик Компонента может потребовать выполнения определенных условий на последующих этапах разработки. Например, он может обращаться к методам стандартного Java-интерфейса доступа к СУБД (JDBC), но при этом не указывать URL конкретного драйвера - на этом этапе создания компонента этот URL либо может быть еще просто неизвестен, либо компонент должен уметь работать с любым драйвером. В этом случае Разработчик резервирует место под URL конкретного драйвера в специальной структуре описания создаваемого компонента - так называемом Дескрипторе Развертывания (Deployment Descriptor), а в код компонента помещает команды извлечения конкретного URL из Дескриптора, которые выполняются в процессе работы программы. Указание реально используемого URL должно быть выполнено (без этого Компонент нельзя будет поместить в Контейнер) на любой из последующих стадий разработки - обычно на стадии Развертывания (Deployment).

Application Assembler, как и Bean Provider, является специалистом в прикладной области, и его задача - использовать готовые Компоненты либо для создания готового приложения, либо для создания новых, «укрупненных» Компонентов. На этой стадии обычно создается код для взаимодействия компонентов, например, с сервлетами, JSP или друг с другом. Любая информация, помещенная в Дескриптор Развертывания Разработчиком Компонентов, может быть дополнена или переопределена.

Delpoyer отвечает за присутствие всей необходимой информации в Дескрипторе Поставки и за ее корректность. Его не интересует код компонентов - его задача обеспечить их функционирование в данной операционной среде, определить права доступа к Компонентам и правила выполнения транзакций (кроме случая, когда компоненты сами управляют транзакциями), обеспечить взаимодействие с конкретными СУБД, разместить компоненты в нужные Контейнера. Вообще, под процессом развертывания приложения понимается совокупность всех действий по настройке системы в конкретной операционной среде, после которых клиент может приступить к работе с ней.

Подробнее о том, что собой представляют Сервера, Контейнеры и Компоненты EJB, будет рассказано несколько позже.

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

Концепция EJB-компонентов

EJB пошла по пути создания ограниченной, но в то же время достаточно гибкой компонентной модели. Ее достоинством является простота автоматизации создания компонентов и управления ими. Концептуально можно выделить два вида компонентов EJB:

• компоненты, ориентированные на взаимодействие сервера и конкретного пользователя. Такая ориентированность означает, что компонент создается клиентом в начале сеанса работы с сервером и прекращает свое существование при завершении этого сеанса - отсюда и их название - session-компоненты. Поскольку session-компонент обслуживает только конкретного клиента, технология не предусматривает для него команды «поиска» - вполне достаточно команды «создания». Эти компоненты, в свою очередь, также можно разделить на две группы - компоненты с состоянием, которые отслеживают историю своих вызовов клиентом, и компоненты без состояния. Такие два подвида введены для оптимизации управления их циклом жизни, и их отличия не так уж важны для прикладного программиста. Заметим, что session-компоненты без состояния являются основой для создания COM+ -приложений.
  
• компоненты, являющиеся объектным представлением данных в БД - реляционных или объектных. Они называются Entity-компонентами. Создание entity-компонента связано с добавлением данных в базу данных, его уничтожение - с удалением, например, записи их таблицы реляционной базы данных. В принципе, интерфейс пользователя entity-компонентов может даже не содержать команды «создать» - компоненты создаются автоматически, например, в результате выполнения SQL-команды INSERT, зато обязательно должна присутствовать команда (или команды) «найти». Поскольку entity-компонент предназначен для доступа к информации, доступной многим клиентам, он не может содержать информацию, специфическую для одного клиента. Его состояние - просто кешированная копия информации из (записи) базы данных.
  

Обычно в EJB-приложении клиент «общается» с информацией в базе данных по цепочке «клиент - session-компонент - entity-компонент(ы)».

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

Какие проблемы решаются с помощью EJB

Если сформулировать в самой краткой форме преимущества, которые получает компания, использующая EJB для создания корпоративных систем, то, наверное, получилось бы следующее: отпадает необходимость иметь в штате (или привлекать к работам в рамках проекта) квалифицированных специалистов в системных областях. Вместо этого фирма платит деньги и получает готовые решения по обеспечению взаимодействия EJB-компонентов, реализующих необходимую функциональность, и операционной среды. Разработчик проекта может не беспокоиться о возможных проблемах с точки зрения функционирования системы на разных платформах, в разных операционных системах и при взаимодействии с различными СУБД, поддерживающими технологию JDBC. EJB демонстрирует высокую эффективность и уровень масштабируемости создаваемых приложений. Кроме того, системы получаются открытыми в том смысле, что с ними могут взаимодействовать CORBA-клиенты, написанные на любом из языков, поддерживающих CORBA.

При использовании EJB cнижаются (по сравнению с традиционными подходами) требования к квалификации основной массы программистов, зато очень важно иметь грамотных менеджеров проекта.

Следует иметь в виду, что требуется предварительный анализ, насколько технология EJB оптимальна для решения именно вашей задачи.

EJB, RMI и CORBA

Ранее говорилось о конкуренции нескольких технологий в рамках создания серверных приложений, и при этом упоминалась технология CORBA. На самом деле говорить о CORBA исключительно как о сопернике технологии EJB, конечно, не приходится. Многие CORBA-средства сознательно положены разработчиками EJB в фундамент этой технологии. В первую очередь, это протокол обмена IIOP и Служба Управления Транзакциями (в EJB используется отображение на Java Объектного Сервиса Транзакций, OTS, CORBA). Кроме того, на использовании инфраструктуры и возможностей CORBA часто основаны многие сервисы EJB - например, служба имен JNDI, которая в реализации технологии EJB фирмой Inprise (Inprise Application server 4.0) работает «поверх» Службы Именования (Naming Service) CORBA.

Существует стандарт отображения EJB на CORBA, касающийся управления транзакциями, безопасностью и службы имен. В этом стандарте указано, что спецификация EJB 1.1 не требует (хотя и считает желательной) полную координацию между EJB и CORBA; жесткое требование в этом плане содержится в спецификации Java 2 Enterprise Edition (J2EE).

Итак, составной частью EJB может быть только то, что соответствует стандартам как RMI, так и CORBA. Такое подмножество обычно называют RMI/IDL.

Такое взаимодействие не означает, что EJB и CORBA постепенно мигрируют в сторону создания некой единой технологии. Между ними остаются фундаментальные различия. EJB является сравнительно небольшой моделью, оптимизированной для решения вполне конкретных классов задач с использованием небольшого количества стандартных подходов, к тому же базирующейся исключительно на языке Java. CORBA возлагает на свою объектную модель надежды, связанные с созданием универсального подхода к решению всех проблем, связанных с взаимодействием удаленных объектов, и с этой точки зрения EJB может рассматриваться как некий частный случай - например, как результат отображения некоторого подмножества универсальной CORBA-модели на язык Java. Планы OMG, как видите, не страдают отсутствием амбиций, но даже если эти планы и будут полностью реализованы, то это произойдет не завтра. Программисты же, которые нуждаются в средствах создания качественных корпоративных приложений, хотят иметь их уже сейчас.

Несколько слов о названии - Enterprise JavaBeans. Его похожесть на название другой Java-технологии - JavaBeans - может создать впечатление, что одно является развитием другого.

Конечно, некий элемент преемственности присутствует; в конце концов, и та, и другая технологии предлагают компонентную модель и основаны на использовании Java. На самом же деле правильнее будет считать JB и EJB различными технологиями.

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

Естественно, что технология создания серверных объектов, базирующаяся на Java, использует технологию RMI для организации удаленных вызовов между виртуальными машинами Java. Правда, собственно RMI не предоставляет никаких универсальных путей управления транзакциями, да и служба имен RMI недостаточно развита по сравнению, например, со своим CORBA-аналогом. Поэтому разработчики EJB приняли решение использовать сильные стороны как одной, так и другой технологии - и RMI, и CORBA.

Разработчику компонентов нет необходимости использовать язык OMG IDL для определения удаленных интерфейсов – можно использовать стандартную семантику Java RMI. Если необходимо, на базе этих Java-объявлений с помощью стандартного компилятора, разработанного OMG (rmi2idl), можно сгенерировать IDL-файл, который может быть использован CORBA-программистами для создания на любом поддерживающем CORBA языке клиентских приложений, взаимодействующих с EJB как серверными объектами CORBA. Подчеркнем это еще раз: любой компонент EJB является одновременно полноценным CORBA-объектом.

Интерфейс Java, соответствующий спецификации RMI/IDL, должен соответствовать следующим требованиям:

• этот интерфейс явно или неявно должен наследовать интерфейс java.rmi.Remote;
  
• все его базовые интерфейсы соответствуют требованиям RMI/IDL;
  
• все методы интерфейса должны возбуждать исключение java.rmi.RemoteException;
  
• все аргументы методов и возвращаемые типы должны соответствовать требованиям RMI/IDL, предъявляемым к типам. Тип считается соответствующим требованиям RMI/IDL, если он либо один из базовых типов языка Java, либо это ссылка на удаленный объект, либо это любой класс Java, реализующий (явно или неявно) интерфейс java.io.Serializable, либо это массив всех ранее перечисленных типов, либо это исключение, либо это тип java.lang.Object.
  

Такие требования не накладывают почти никаких ограничений по сравнению с обычными правилами RMI. Обратите внимание, что в связи с особенностями IDL нельзя использовать в одном удаленном интерфейсе одно и то же имя для нескольких методов. При генерации IDL-деклараций на базе RMI-интерфейсов, содержащих несколько методов с одинаковыми именами (ejbCreate, например), принимаются специальные меры, позволяющие обойти это ограничение.

Терминология

Спецификация EJB (версия 1.1 на момент написания обзора) определяет несколько понятий, относящихся к ключевым аспектам технологии EJB.

EJB Server

Сервер EJB – это среда времени выполнения, в которой могут функционировать компоненты. Его задача – обеспечить доступ к системным сервисам, необходимым для работы компонентов. Важнейшим из этих сервисов является сервис распределенных транзакций (JTS). Сервер EJB не взаимодействует непосредственно с компонентами – это задача так называемого Контейнера (Container) EJB.

EJB Container

Контейнер EJB лучше всего рассматривать как некий логический уровень управления компонентами. Контейнер взаимодействует с сервером, когда одному или нескольким компонентам, находящимся под управлением Контейнера, необходим доступ к системным ресурсам. Контейнер представляет собой совокупность классов и программных средств, работающих в контексте Сервера EJB. Контейнер, в частности, обеспечивает:

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

Разработчик приложений, использующих EJB, обычно получает Сервер и Контейнер в готовом виде от фирм-производителей программного обеспечения. Примером может служить INPRISE Application Server.

Компонент EJB

Компонент EJB – это класс Java, который, собственно, и реализует всю необходимую функциональность. Необходимо четко понимать, что сам компонент в принципе недоступен для клиента. Клиент обращается к нему косвенно, через специальный интерфейсный объект-посредник (proxy). В литературе по EJB он обычно называется EJBObject. Время существования компонента и его proxy-объекта в общем случае различно. Сам компонент находится под управлением Контейнера, и пользователь в общем случае не может быть уверен, что два последовательных вызова клиента будут обслужены одним и тем же компонентом.

Компонентная модель накладывает определенные ограничения на структуру proxy-объекта; например, существуют жесткие правила соответствия имен компонента и его proxy-объекта. Как и в других технологиях создания распределенных систем, нет необходимости создавать класс (или классы) proxy-объекта «вручную» - они генерируются автоматически с помощью средств, предоставляемых поставщиком программного обеспечения.

Помимо EJBObject, модель EJB требует наличия другого вспомогательного объекта – так называемого HomeObject. Если EJBObject реализует так называемый Remote интерфейс, обеспечивающий доступ к бизнес-методам компонента после его создания, то HomeObject реализует Home интерфейс, который используется для создания компонентов. По сути, HomeObject является фабрикой компонентов. Поскольку EJB компонент – это еще и CORBA-объект, разумно использовать стиль CORBA для создания компонентов. Спецификация CORBA POA предоставляет все необходимые возможности.

Модель EJB предусматривает наличие двух видов компонентов – Session Bean и Entity Bean. При создании нового компонента его разработчик явно указывает тип:

public class MyBean implements javax.ejb.SessionBean { …

или

public class MyBean implements javax.ejb.EntityBean { …

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

Session Bean

Каждый экземпляр такого компонента создается для обслуживания только создавшего его клиента. Если Session Bean имеет состояние (stateful Bean), то клиент может быть уверен, что при последующем вызове компонент будет находиться в состоянии, оставшемся от вызова предыдущего. Session Bean может и не иметь состояния (stateless Bean). При работе с компонентами c состоянием и без него Контейнер может вести себя по-разному.

Дело в том, что серверные объекты создаются по запросу клиентов, а ресурсы любого сервера (например, размер памяти) ограничены. В связи с этим контейнер может (руководствуясь теми или иными соображениями) временно удалять компонент из памяти, помещая его состояние, например, в объектную или реляционную базу данных. Этот процесс называется Деактивизацией (Passivation). Обратный процесс – размещение объекта в памяти с восстановлением его предыдущего состояния – называется Активизацией (Activation). Естественно, Session Bean, не имеющий состояния, может быть просто уничтожен Контейнером, а затем в нужный момент создан заново – совершенно прозрачным для клиента образом.

Entity Bean

Такие компоненты ориентированы на то, чтобы являться объектным представлением записи в реляционной базе данных. Здесь «ориентированы» не значит, что они не годятся ни для чего другого – просто удобнее всего в настоящее время их использовать именно таким образом. Обычно один такой компонент сопоставлен с одной записью в базе данных (разумеется, он может быть сопоставлен с одной записью не в таблице, а в представлении (view), которое содержит данные из нескольких таблиц). Поскольку данные одной записи должны быть доступны для нескольких клиентов сразу, Entity Bean должен быть доступен для нескольких клиентов и, следовательно, не может иметь состояния, относящегося к конкретному клиенту.

Транзакция

Как уже говорилось, в EJB используется спецификация управления транзакциями CORBA, реализованная на языке Java (JTS). Обычно разработчик не обращается к методам интерфейсов JTS, поскольку компонентная модель обеспечивает вспомогательный программный слой - Java Transaction API (JTA). Это и есть рабочий инструмент программиста при управлении транзакциями.

Поскольку спецификация CORBA OTS четко определяет участников распределенной транзакции и их роли, JTA также поступает подобным образом. Участниками транзакции с точки зрения JTA являются:

• ресурс, под которым понимается соединение с базой данных;
  
• менеджер ресурсов – драйвер JDBC;
  
• сервер приложений – Сервер EJB;
  
• менеджер транзакций и
  
• транзакционное приложение, т.е. компонент или клиент.
  

Для каждой из этих ролей в JTA определены соответствующие интерфейсы.

В общем случае, управлять транзакциями (начинать транзакцию, завершать ее или откатывать) может как компонент, так и контейнер. Соответственно, в спецификации определены эти два вида транзакций.

Транзакция, управляемая компонетом (Bean Managed Transaction, BMT)

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

Транзакция, управляемая Контейнером (Container Managed Transaction, CMT)

Режим разрешен как для Session-, так и для Entity-компонентов. Компонент не имеет возможности ни начать, ни завершить транзакцию (хотя любой из участников транзакции может потребовать ее отката (rollback) при завершении) – управление транзакцией полностью берет на себя Контейнер. Транзакция начинается при вызове каждого удаленного метода и завершается при возврате из него. Программист может установить один из нескольких разрешенных режимов, определяющих поведение транзакции.

Дескриптор развертывания (Deployment descriptor)

Дескриптор развертывания (иногда используются термины «установки» или «поставки» - в настоящий момент еще нет устоявшегося термина на русском языке)- необходим для настройки созданного компонента на работу в конкретной операционной среде. Необходимость в нем возникает из-за того, что спецификация EJB четко определяет несколько этапов, который проходит компонент от своего создания до доставки конечному пользователю с окончательной настройкой. Об этих этапах уже говорилось ранее. Наличие подобного «конвейера» требует передачи информации от одного этапа к другому. С каждым компонентом сопоставлен свой дескриптор.

Спецификация EJB 1.1 требует, чтобы Дескриптор Развертывания имел XML-формат. Поскольку XML является метаязыком, то для описания каждого конкретного класса документов нужно создать свой язык - в частности, определить набор используемых тегов и правила взаимоотношений между ними. Такой язык называется Document Type Definition (DTD).

Дескриптор Развертывания соответствует DTD, разработанному фирмой Sun Microsystems. Он содержит набор свойств, который описывает, как Контейнер будет выполнять процесс развертывания Компонента или приложения, и включает набор тегов и атрибутов, чьи значения определяют состояние свойств Компонента. В качестве примера приведем несколько тегов:

<session> - говорит о том, что Компонент является session-Компонентом (тег <entity> используется для обозначения Entity-Компонентов).
Внутри области тега <session> могут использоваться другие теги:
<ejb-class> - имя класса реализации.
<home> - имя home-интерфейса.
<remote> - имя remote-интерфейса.
<session-type> - показывает, является ли session-Компонент stateful- или stateless-Компонентом.
<transaction-type> - показывает, используется ли для Компонента CMT или BMT.
<trans-attribute> - задает значение атрибутов транзакции для каждого метода.
<timeout> - значение тайм-аута для session-Компонента.

В качестве примера приведем фрагмент Дескриптора Развертывания для компонента Cart, поставляемого в качестве примера с Inprise Application Server 4.0:

<ejb jar>
<enterprise beans>
<session>
<description>
XML deployment descriptor created from file:
D:\Kodiak\kodiak04\ejb_ea_0_4\examples\cart\cart.ser
</description>
<ejb-name>cart</ejb-name>
<home>CartHome</home>
<remote>Cart</remote>
<ejb-class>CartBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>cart</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>cart</ejb-name>
<method-name>purchase</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>

Inprise Application Server

Inprise Application Server представляет собой набор сервисов и программных средств, которые позволяют вам разрабатывать и поставлять web-ориентрованные и другие многозвенные приложения, а также управлять их поведением. Общей характеристикой таких приложений является динамическая генерация документов с использованием Java, сервлетов, JavaServer Pages и компонентной модели Enterprise JavaBeans, т.е. технологий, объединенных общим названием Java 2 Enterprise Edition (J2EE).

Основой Inprise Application Server является ORB VisiBroker для Java. Он обеспечивает:

• Механизм взаимодействия удаленных объектов;
  
• Очень эффективное управления потоками и соединениями TCP/IP;
  
• Поддержку RMI поверх IIOP;
  
• Передачу объектов "по значению" (Object-By-Value, OBV) для передачи сложных структур данных;
  
• Масштабируемость создаваемых систем путем использования Portable Object Adaptor (POA).
  

В состав Application Server входят следующие сервисы:

• Контейнер EJB;
  
• Служба Web (сервлеты, JSP, файлы HTML и т.д.);
  
• Naming Service;
  
• JDataStore;
  
• Служба транзакций (Transaction Engine).
  

Конфигурация Inprise Application Server по умолчанию предусматривает запуск всех основных сервисов, так что вы сразу можете создавать и запускать сервлеты, страницы JSP и компоненты EJB. Он также представляет из себя прекрасную среду разработки.

Inprise Application Server также включает в себя графическую консоль, которая исполняет роль главного центра управления. Консоль позволяет управлять серверами, останавливать и запускать те или иные сервисы и т.д. Кроме этого, Консоль позволяет управлять EJB JAR-файлами и контейнерами, устанавливать свойствами развертывания и оценивать производительность системы.

Как правило, Application Server запускается на мощных UNIX- или Windows NT-серверах, в то время как консоль может быть размещена на любом компьютере, с которого вам удобно управлять распределенной системой. Имея один экземпляр Консоли, вы имеете доступ к любому серверу в сети.

Заключение

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