Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:JAVA. Серверные приложения
.pdf
Часть 4. Распределенные компненты EJB 191
Поскольку EJB являются элементами, непосредственно работающими с данными, расположенными в базе данных и к тому же использующими транзакционные механизмы, важно знать основные свойства
транзакций. Все транзакции характеризуются следующими свойствами:
атомарность (Atomicity);
•
связность (Consistency);
•
изолированность (Isolation);
•
сохраняемость (Durability).
•
1. Атомарность подразумевает, что для завершения транзакции необходимо успешное выполнение всех ее операций. Если хотя бы одна из
операций не выполнена, не должны быть выполнены все остальные.
2. Под связностью понимается связность информации в базе данных.
Транзакции должны переводить базу данных из одного связного (устойчивого) состояния в другое. Транзакция должна обеспечивать семантическую и физическую связность данных в БД. Изолированность требует, чтобы каждая транзакция рассматривала себя как единственную
транзакцию, выполняемую в настоящий момент над базой данных. Параллельно с ней могут выполняться и другие транзакции, но текущая
транзакция не должна видеть промежуточные изменения, внесенные
другими транзакциями, до тех пор, пока они не подтвердили (commit)
свои действия. Вследствие независимости вносимых изменений, транзакции могли бы видеть некорректные результаты, являющиеся только
подмножеством изменений, вносимых другими транзакциями. Изолированность транзакции позволяет избежать такого рода проблем.
3. Понятие изолированности тесно связано с понятием совместного
доступа. Существует понятие уровня изоляции, и чем он выше, тем более ограничены возможности внесения параллельных изменений. Наиболее высокий уровень изоляции транзакций подразумевает выполнение всех транзакций в порядке очереди (сериализация). Другими словами, содержимое базы данных меняется так, как если бы новая
транзакция могла начаться только после завершения предыдущей. Тем
не менее многие приложения способны работать с более низким уровнем изоляции транзакций и соответственно с большими возможностями
параллельного доступа к данным. Как правило, такие приложения позволяют использовать большое количество одновременных транзакций,
даже если некоторые из них выполняют чтение данных, которые частично изменены другими транзакциями.
4. И наконец, сохраняемость означает, что изменения, внесенные
подтвержденными транзакциями, остаются в базе данных независимо
от последующих сбоев. Сохраняемость гарантирует, что подтвержденные изменения сохраняются в базе данных, даже если произошел сбой
после завершения транзакции и что база данных может быть восстановлена после такого сбоя.
Прикладные программисты пользуются многими преимуществами,
разрабатывая свои приложения на платформах, подобных Java 2 Enterprise Edition (J2EE), которые поддерживают транзакции. Ориентированные на использование транзакций, системы разработки существенно
упрощают процесс создания приложений, так как они освобождают
разработчика от необходимости заботиться об обеспечении устойчиво-
192 Часть 4. Распределенные компненты EJB
сти к сбоям и необходимости обслуживания многих клиентов одновременно. Для использования таких транзакций не обязательно работать с
одной базой данных или на одном компьютере. В распределенной транзакции могут одновременно участвовать несколько баз данных, работающих под управлением разных серверов.
Enterprise JavaBean (EJB) представляют собой многократно используемые Java EJB, подобные обычным Bean, которые могут совмещать в
себе другие enterprise beans или другие распределенные Java EJB трехуровневых приложений. Чаще всего EJB создаются и распространяются как jar-архивы. EJB достаточно просто разрабатывать, они просты в
управлении и выполняются в системе, поддерживающей Java. Рабочая
версия EJB, поставляемая фирмой SUN, имеет номер 1.1, и на настоящий момент именно эту версию поддерживают основные производители
программного обеспечения для создания e-commerсe приложений.
Основными EJB, описанными в EJB спецификации, являются Enterprise
Bean. Создавая распределенное приложение, бизнес-логика кодируется
в EJB. В отличие от стандартного решения размещения бизнес-логики в
базе данных, использование EJB имеет свои преимущества. Во-первых,
EJB работают в специальном окружении. Во-вторых, именно окружение
отвечает за все действия, производимые как клиентом, так и самими
EJB. В-третьих, доступ к базе данных осуществляется при помощи тех
же EJB вместо специальных объектов.
Enterprise beans содержат бизнес-логику предприятия. С помощью
специального интерфейса клиент получает доступ к методам, хранящимся в EJB. В-четвертых, различные системные сервисы доступны
через использование JTS. JTS является службой, которая входит в состав Контейнера и используется для управления транзакцией по умолчанию. JTS предоставляет большие возможности, но содержит и существенные ограничения — она не поддерживает тайм-ауты транзакции.
Транзакция может никогда не завершиться вследствие некоторых причин. В отсутствие тайм-аута некорректная транзакция может «зависнуть». Если с такой транзакцией сопоставлен EJB, то EJB Контейнер
никогда не сможет удалить его, так как Контейнер не может удалять
EJB, связанные с транзакцией. Очевидно, что это существенно ограничивает возможности Контейнера по эффективному управлению ресурсами.
Как сами EJB, так и Контейнеры способны управлять транзакциями.
Технология EJB позволяет изменять информацию в нескольких базах
данных в контексте одной транзакции. Данные могут находиться не
только в различных БД, но и на разных компьютерах в сети. Технология EJB использует стиль управления транзакциями, который отличается от традиционного стиля. EJB устанавливает свои атрибуты транзакции на стадии поставки. Эти атрибуты транзакции определяют, будет ли управление транзакцией осуществляться Контейнером, или это
возьмет на себя сам EJB. При использовании традиционного стиля за
все аспекты управления транзакциями отвечает само приложение. Это
подразумевает выполнение следующих операций:
1. Создание объекта «транзакция».
2. Явное начало транзакции.
Часть 4. Распределенные компненты EJB 193
3. Передача и отслеживание контекста транзакции.
4. Подтверждение транзакции после внесения всех изменений.
Это требует от разработчика приложения глубоких знаний о том, как
управлять транзакциями с начала и до конца.
При декларативном стиле управления транзакциями Контейнер берет на себя выполнение большинства, если не всех, необходимых операций. Контейнер начинает и завершает транзакцию, а также поддерживает контекст транзакции в течение ее существования. Это существенным образом упрощает задачу разработчика, особенно для транзакций
в распределенных средах. Итак ключевыми моментами использования
EJB в Web-приложениях можно назвать следующие свойства EJB-технологии:
Все EJB являются серверными приложениями, написанными иск-
•
лючительно на языке Java. Это значит, что EJB использует все достоинства, присущие данному языку программирования.
Все EJB описывают только бизнес-логику и бизнес-методы, сис-
•
темными функциями заведует EJB-сервер.
EJB-архитектура поддерживает критерии распределенных систем,
•
такие, как транзакционность, переносимость, масштабируемость и
безопасность.
Все EJB свободно переносимы с одного сервера на другой и с одной
операционной системы на другую.
• EJB-архитектура поддерживает большое количество различных
транспортных протоколов IIOP, JRMP, HTTP, DCOM.
Нельзя говорить о достоинствах, не упоминая о недостатках. Зная
недостатки, легче найти подход или по крайней мере общий язык.
А объективный взгляд еще больше привлекает внимание к изучаемому
объекту.
Итак, чего не могут делать EJB.
Ниже приведен список программных ограничений, определенных в
спецификации EJB 1.1:
1. Экземплярам EJB не разрешается управлять потоками (threads)
или группами потоков. EJB не следует создавать новые потоки или активизировать приостановленные, а также завершать или приостанавливать выполняемые. Кроме того, EJB не должны менять приоритеты потоков или их имена.
2. Экземплярам EJB не разрешено использовать static-поля, за исключением полей «только для чтения». Следовательно, все static-поля
должны быть объявлены как final.
3. Экземплярам EJB не разрешено использовать средства синхронизации потоков для синхронизации выполнения кода нескольких экземпляров EJB.
4. Экземпляры EJB не должны использовать средства Java AWT для
вывода информации на экран или воспринимать информацию, вводимую с клавиатуры.
5. Экземпляры EJB не могут использовать пакет java.io для работы с
файлами или каталогами файловой системы. Для работы с файловыми
объектами должен использоваться API JNDI.
194 Часть 4. Распределенные компненты EJB
6. Экземплярам EJB следует избегать использования сокетов: не следует получать информацию из сокетов и отслеживать соединения. Кроме того, им не следует взаимодействовать с создателями сокетов, т. е.
порожденных от классов ServerSocker и Socket, использующие URL.
Опять же в данном контексте предпочтительнее использование JNDI.
7. Экземпляры EJB не должны обращаться к классам или пакетам, а
также пытаться получить информацию о классах с использованием
способов, не поддерживаемых языком Java, а также пытаться получить
доступ к классам, недоступным для EJB.
8. Экземпляр EJB не должен обращаться к функциям и сервисам
среды исполнения, взаимодействием с которыми занимается Контейнер
EJB, — создавать загрузчики классов или получать доступ к их контексту, устанавливать или создавать менеджеров безопасности, останавливать JVM, изменять стандартные потоки ввода-вывода.
9. Экземпляры EJB не должны получать информацию о профилях
безопасности для конкретных источников кода.
10. Экземпляры EJB не должны загружать native-библиотеки, использующие другие языки программирования.
11. Экземпляры EJB не должны добавлять классы в пакеты, так как
это (в целях обеспечения безопасности) должны делать Контейнеры.
12. Экземпляры EJB не должны использовать subclass и возможности
object substitution Java Serialization Protocol.
13. Следует проявлять осторожность при передаче this в качестве
аргументов или при возврате результата. Безопаснее в этом случае использовать результаты вызовов методов SessionContext.getEJBObject()
или EntityContext.getEJBObject().
41. Экземплярам EJB не разрешается получать доступ или изменять объекты конфигурации безопасности. Например, им не разрешено
изменять свой java.security.Identity. Любые попытки такого рода должны приводить к возникновению исключения java.security. SecurityException.
Глава 29. Основной пакет компании SUN по работе с EJB
Основные интерфейсы и классы исключительных ситуаций, необходимые для создания EJB, поставляются в стандартном расширении javax.ejb набора пакетов Java 2 Enterprise Edition (J2EE). Данный набор
пакетов представляет комплект, состоящий из нескольких утилит, базы
данных, графического средства разработки и J2EE-сервера, исполняющего роль сервера приложений. Используя набор J2EE API, можно полностью отказаться от прикладных пакетов по созданию EJB-приложений. Ограничения при использовании J2EE-сервера и программ из
средств разработки с тем же названием связаны с использованием базы
данных CLOUDSCAPE, а также с тем, что весь инструмент написан на
100%-ной Java, что накладывает свой отпечаток на скорость разработки
приложений. Особенно это касается машин среднего уровня. Для нормальной работы с J2EE-сервером и API, поставляемым в данном пакете,
Часть 4. Распределенные компненты EJB 195
необходимо минимум 128 Мбайт оперативной памяти и достаточно быстрый процессор. Это связано в первую очередь с тем, что JVM достаточно ресурсоемкое приложение, а также с тем, что приложения, использующие JVM для своих нужд, также требуют много ресурсов, и нельзя забывать о том, что количество используемых сервисов или демонпотоков операционных систем, требующих внимания процессора и использующих оперативную память, также велико.
Так что если предполагается использовать другую базу или другой
сервер приложений, то лучше воспользоваться каким-нибудь другим
интегрированы средством разработки. Существует множество прикладных пакетов, более удобных для разработчика, например VisualAge for
Java представленный фирмой IBM, — прекрасный инструмент для создания и отладки не только EJB, но и других Java-компонентов.
Архив, содержащий необходимые классы, называется j2ee.jar и является общим для большинства пакетов приложений уровня предприятий. Обычно данный архив располагается в папке lib установленного
продукта J2EE. Некоторые среды разработки, такие, как VisualAge, не
требуют установки архивов в переменной CLASSPATH, для этого они
используют собственное системное окружение, Visual Age помещает архивы в рабочий репозитарий. В большинстве же других IDE при работе
с внешними архивами указываются пути к архивам либо в системном
окружении проекта, например в Jbuilder, либо в системной переменной
CLASSPATH, со значениями которой и работают средства разработки.
В любом случае установленный в системной переменной jar-архив не
вызовет никаких побочных эффектов, не считая укорачивания значения переменной CLASSPATH. Напомним, что в системах Windows длина значения системной переменной CLASSPATH составляет 512 символов. Поэтому не рекомендуется производить установки различных JDK
в директорию Program Files, предлагаемую по умолчанию операционной
системой Windows для всех устанавливаемых программ. Тем более, необходимо учесть, что и другие архивы используемых Java-классов тоже
помещаются в системной переменной, что значительно сокращает ее
длину. Одним из решений проблемы нехватки емкости CLASSPATH является загрузка необходимых архивов непосредственно перед стартом
программы, для чего используется командный файл с директивами SET.
В пакете javax.ejb описаны интерфейсы, содержащие методы, необходимые для создания и управления EJB. Часть интерфейсов, не имеющих непосредственного отношения к созданию и жизненному циклу
EJB, представляют методы системного окружение и получение информации об исполняемой среде.
Системную информацию о выполняемом EJB можно получить, используя методы интерфейса javax.ejb. EJBContext. Одним из полезных
методов является метод getEJBHome(), предоставляющий информацию
о home интерфейсе bean.
Интерфейс javax.ejb. EnterpriseBean является общим базовым интерфейсом для остальных интерфейсов и, в свою очередь, наследует интерфейс java.io.serializable. Этот интерфейс не содержит объявлений методов. Каждый создаваемый класс EJB должен наследовать данный ин-
196 Часть 4. Распределенные компненты EJB
терфейс, являющийся к тому же и родительским для SessionBean- и
EntityBean-интерфейсов.
Получить информацию о структуре EJB (его метаданные) можно, используя методы интерфейса javax.ejv.EJBMetaData. Информация о home- и remote-интерфейсах, а также классах primary key доступна с помощью методов данного интерфейса. Полезным методом для определения того, является ли EJB Session bean или Entity bean является
isSession(). Метод isStatelessSession() позволяет определить, имеет ли
Session bean состояние (т. е. является ли он stateless-session bean или
нет). И, наконец, метод getEJBMetaData() возвращает метаданные о
EJB.
Идентификатор (handle) представляет собой доступную для удаленных объектов логическую ссылку на экземпляр EJB или его home-интерфейс. Интерфейс javax.ejb.Handle, который должен быть реализован
для всех классов Идентификаторов EJB, предоставляет хранимую (persistence) ссылку на экземпляр EJB. Handle EJB представляет собой его
уникальный идентификатор; для него может быть выполнена операция
сериализации Java. Времена существования handle и сопоставленного с
ним объекта совпадают. При работе с Entity bean клиент может сохранять (с помощью Java-сериализации) значение этого идентификатора с
последующим восстановлением в нужный момент. Этот идентификатор
может корректно ссылаться даже на различные экземпляры EJB; он
остается корректным даже после сбоя на сервере с последующим перезапуском, а также в случае «перемещения» объектов на другие серверы
или компьютеры. Идентификатор может быть использован для долговременного хранения ссылки на экземпляр EJB путем Java-сериализации экземпляра класса, реализующего handle-интерфейс. Это очень похоже на преобразование к строковому виду объектной ссылки CORBA.
Существует также интерфейс javax.ejb. HomeHandle, который позволяет использовать хранимую ссылку на home-интерфейс EJB. Этот интерфейс должен быть реализован в классах, являющихся представлением такой ссылки. Обычно реализацию handle-интерфейсов обеспечивает Контейнер.
Для синхронизации данных, в пакете javax.ejb описан интерфейс javax.ejb.SessionSynchronization. Необязательный интерфейс SessionSynchronization обеспечивает объекту возможность получения уведомлений
о транзакционных действиях. Другими словами, экземпляр получает сообщение о том, что какие-либо действия, связанные с транзакциями,
либо только что произошли, либо сейчас будут выполнены. Экземпляры
EJB могут использовать эти уведомления для выполнения некоторых
действий с данными в СУБД. Например, реализация этого интерфейса
позволяет объектам выполнить синхронизацию кэшированных в памяти
данных с данными в БД в процессе выполнения транзакции. Только stateful session-EJB с сохранением, управляемым Контейнером (containermanaged persistence, CMP), могут реализовывать интерфейс SessionSynchronization. Ни session bean (stateless), ни Entity bean c сохранением (bean-managed persistence, BMP) не следует пытаться реализовать
этот интерфейс.
Часть 4. Распределенные компненты EJB 197
Любой EJB возбуждает исключительные ситуации java.ejb.EJBException (или java.rmi.RemoteException) для сигнализации о неожиданном сбое на системном уровне. Например, такое исключение возбуждается, если невозможно установить соединение с базой данных.
При создании EJB очень часто используются классы находящиеся в
других пакетах. Наиболее часто употребляемыми являются следующие
пакеты:
java.rmi — пакет содержит основные классы, используемые для вызова удаленных методов (RMI);
javax.rmi — в этом пакете содержится дополнительный класс PortableRemoteObject, необходимый для EJB-объектов;
java.util — пакет содержит различные классы Java утилит, таких,
как коллекции, классы по работе с датами и т. д.;
javax.naming — пакет содержит классы и интерфейсы, используемые в спецификации Java Naming and Directory Interface (JNDI), служит для получения клиентом необходимых объектов EJB.
Глава 30. Архитектура EJB и основные EJB
Архитектурные EJB-технологии представляют полный цикл от создания до управления EJB.
Спецификация Enterprise JavaBean (EJB) определяет несколько
основных компонентов (рис. 4.1).
Enterprise JavaBean (server) — сервер, хранящий и загружающий
один или более ejb, в которых реализована бизнес-логика и данные, используемые клиентами. Взаимодействие между обычным сервером и
ejb-сервером осуществляется с помощью низкоуровневых сервисов, таких, как потоки и механизмы транзакций.
Источник данных (Data Sourse) определяет два вида enterprise bean:
session bean, содержащий клиентские данные и задачи, и entity bean,
4.1. Компоненты Enterprise JavaBean
198 Часть 4. Распределенные компненты EJB
работающий с постоянным данными EJB-клиентов — их тоже два, один
из них — HTTP-клиент, взаимодействующий с EJB server посредством
servlet и JSP, использующий HTTP-протокол как способ взаимодействия, другой — стандартное Java-приложение, контактирующее с EJB
server, используя методы Remote Method Invocation (RMI) удаленного
вызова — улучшенного варианта, широко распространенного RPC.
И наконец, интерфейс управления (Administration Interface) — предназначен для управления окружением EJB server.
30.1. EJB сервер
Основой в EJB-композиции является особенный сервер. Именно в
EJB-сервере и благодаря его свойствам осуществляется весь цикл работ, используемых Web-приложением, основанным на решении EJB.
Как и другие серверы, EJB-сервер является носителем информации и
одновременно обработчиком запросов к доступным ресурсам. EJB-server представляет собой встроенную часть Application Server. EJB-сервер — это логическое понятие, представляющее собой набор сервисов,
таких, как служба имен, сервис транзакций и т. п., необходимых для
функционирования всех EJB. Эти сервисы могут быть запущены как в
одном адресном пространстве, так и в различных пространствах.
EJB сервер определяет взаимодействие отдельных частей приложений. Для лучшего понимания работы EJB server необходимо рассмотреть содержимое сервера. EJB server состоит из трех элементов:
1. контейнер EJB (containers);
2. среда выполнения EJB;
3. enterprise bean.
Enterprise bean располагаются на EJB-сервере, взаимодействие между ними и внешней средой осуществляется при помощи контейнера.
EJB-сервер управляет EJB-контейнером и выполняет функцию моста
между контейнером и основной платформой, сервером приложений.
Контейнер EJB организует доступ к системным ресурсам, таким, как
база данных, монитор транзакций и существующим приложениям.
Каждый EJB загружается в специальном системном окружении называемом «контейнер» (container). Контейнер EJB представляет собой
специализированный сервис, который непосредственно обслуживает
EJB. Передача созданного EJB под управление EJB-серверу называется
«установкой» (deploy) EJB. Этот сервис берет на себя управление циклом «жизни» установленных в нем EJB, транзакциями, безопасностью,
именами объектов, сохранением их состояний и др. в соответствии с
требованиями и ограничениями спецификации EJB. Для решения многих из этих задач EJB-контейнер обращается за помощью к серверу
EJB. Контейнер управляет Enterprise JavaBean так же, как Web Server
управляет servlets, или браузер управляет апплетами. Вне границ контейнера Enterprise JavaBean представляют обычные jar-архивы, которые не работают самостоятельно. Вернее сказать, они могут исполняться на установленной JVM, но правильных действий лучше не ждать.
Ejb-jar-архив может содержать один или несколько классов Enterprise
Часть 4. Распределенные компненты EJB 199
Bean. Для каждого объекта EJB в jar-архиве содержатся соответствующие классы, интерфейсы и дескрипторы. Контейнер управляет всеми
аспектами жизнедеятельности EJB во время выполнения, организуя доступ к bean, безопасность, транзакционность и доступ к ресурсам и т. д.
Он использует основные сервисы для обеспечения работы EJB:
1. Сервис безопасности — дескриптор, содержит описания доступа
методов клиента к различным бизнес-методам, содержащимся в EJB.
Контейнер позволяет получать доступ к EJB, находящимся в контейнере, только авторизованным клиентам. В дескрипторе описываются все
правила доступа к EJB, размещенным в контейнере.
2. Организация удаленного соединения — контейнер управляет низкоуровневыми взаимодействиями, обычно скрытыми от клиента и разработчика EJB точно так же, как если бы система работала в локальной
конфигурации, т. е. без использования удаленных вызовов вообще.
3. Управление жизненным циклом EJB — клиент только создает экземпляр EJB и удаляет его. Больше клиент не вправе производить никаких операций. Однако контейнер управляет всем жизненным циклом
EJB, отвечает за нормальное выполнение бизнес-методов и использование системных ресурсов. Контейнер может активировать или дезактивировать EJB, сохранить во временном пуле или организовать доступ к
данному EJB.
4. Управление транзакциями — дескриптор содержит описания требований, необходимых для осуществления транзакции EJB. Контейнер
хранит отдельно данные о транзакциях, периодически обновляя системную базу данных. Транзакцией в терминах СУДБ называется последовательный набор SQL-операторов, представляющих неделимую логическую единицу. Это значит, что либо выполняется единица целиком, т. е.
буквально все операторы, либо не выполняется ни один оператор вообще. Об успешном выполнении всех SQL-операторов данной единицы сообщает специальный оператор COMMIT, об отсутствии успешного результата СУБД информирует оператор ROLLBACK.
EJB-сервер и EJB-контейнер совместно организуют доступ к другим
низкоуровневым сервисам.
Совместный уровень безопасности гарантирует доступ к бизнес-методам только определенных клиентов. В распределенных системах, где
производится доступ к различным ресурсам, разбросанным как угодно
далеко друг от друга, обеспечению безопасности отводится одна из
основных ролей. EJB прекрасно подходит для решения этой задачи.
Контейнер и EJB-сервер используют различные методы обеспечения
секретности. Авторизация и аутентификация — два прекрасных способа определения клиента. Аутентификация указывает местоположение
пользователя или компьютера, инициировавшего доступ к ресурсу. Пользовательским идентификаторами обычно служат ID и пароль вводимый в момент посещения сайта. Авторизация определяет место, где
произошла аутентификация.
Кроме сервиса безопасности, EJB-контейнер и EJB-сервер отвечают
за синхронизацию данных, хранимых в системной базе данных. Используя сервис транзакции, синхронизация используется для обновления,
вставки и удаления данных. Доступ к объектам осуществляется при по-
200 Часть 4. Распределенные компненты EJB
мощи сервиса именований. Для этого используется стандартный API
JNDI. Данный набор API предназначен для организации доступа к Java-объектам. Используя JNDI, Java-объекты сохраняют имя любого
объекта. В JNDI описаны методы, предназначенные для любой стандартной операции работы с объектами, такими, как ассоциация атрибутов с
объектами и поиск объектов по атрибутам. В распределенном приложении, таком, каким является Web, клиент должен иметь доступ к различным системам и объектам. Но в различных средах объекты именуются по-разному. Для решения этой проблемы используется технология
JNDI, в основном с Java-объектами. Сервис именований, описанный в
спецификации EJB, основывается непосредственно на JNDI-технологию. Используя JNDI, любые java-объекты могут хранить и получать
имя необходимого ресурса или Java-объекта. Системное окружение
EJB-сервера описывается в специальном дескрипторе, в котором используется JNDI для всех enterprise bean. При старте EJB-сервер использует JNDI-имена EJB-объектов для инициализации.
Контейнер изолирует Enterprise JavaBean от прямого доступа клиента к методам EJB, обеспечивая повышенный уровень безопасности транзакций. После создания кода и размещения EJB в контейнере, инструмент разработки, используемый для создания EJB, должен автоматически сгенерировать дополнительные классы — это условие спецификации.
Эти классы описывают предварительную версию созданного EJB, также
генерируются специальные EJB, заглушки и классы скелетонов, предназначенные для выполнения методов удаленного вызова (RMI). Для Entity bean создаются классы обработчики взаимодействий между bean источником данных. Перед размещением EJB на сервере, необходимо создать оригинальный описатель (deployment descriptor), описывающий
свойства созданного EJB. Если для создания EJB применялась интегрированная среда разработки (IDE), например VisualAge, то дескриптор генерируется автоматически средой программирования. Либо для создания
дескриптора используются системные утилиты, чаще всего XML-редакторы с готовыми шаблонами дескриптора серверов приложений.
EJB-контейнер содержит Enterprise bean, к которым клиент обращается через стандартный набор API, описывающий взаимодействие bean
и системного окружения среды выполнения. И сам EJB server и EJBконтейнер определяют, как взаимодействуют все участники процесса,
клиентский запрос, системное окружение и bean между собой посредством различных сервисов, предоставляемых контейнером. Всякий раз,
когда какой-либо EJB создается, удаляется, запрашивается клиентом,
контейнер управляет всем механизмом взаимодействия. Когда клиент
вызывает удаленный метод EJB, контейнер проверяет несколько параметров, контролирует уровень доступа, размещает bean в памяти, вызывает методы жизненного цикла. Если bean не используется по какимлибо причинам, контейнер помещает EJB во временный пул до того момента, пока в данном EJB не возникнет потребность, или же просто
удаляет из памяти. Чтобы избежать конфликтов при использовании нескольких сервисов, EJB лишены возможности управлять системными
потоками. Доступ к файлам, описанный в EJB-спецификации, запрещает использование стандартных потоков ввода-вывода пакета java.io. EJB
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]