Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:JAVA. Серверные приложения
.pdf
Часть 4. Распределенные компненты EJB 221
интерфейс имеет родителем javax.ejb.EJBObject интерфейс. Каждый
метод, объявленный в интерфейсе, должен иметь соответствующий метод в основном классе Enterprise bean; методы должны иметь одинаковые имя и сигнатуры. Кроме того, методы remote-интерфейса должны
возбуждать исключение java.rmi.RemoteException и возвращать корректные типы RMI. Все методы remote-интерфейса должны быть объявлены как public и возбуждать исключение java.rmi.RemoteException.
Кроме того, аргументы этих методов и возвращаемые ими результаты
должны иметь типы, соответствующие требованиям RMI. Должно быть
обеспечено соответствие между методами основного класса EJB и методами его remote-интерфейса. Каждая пара методов должна иметь одно
и то же имя, число и тип аргументов, тип результата и список возможных исключений.
1. import java.rmi.RemoteExcepton;
2. import javax.ejb.*;
3. public class SortBean implements javax.ejb. SessionBean {
4. public void setSessionContext(javax.ejb.SessionContext sessionContext) {}
5. public void ejbCreate() throws java.rmi.RemoteException {}
6. public void ejbRemove() throws java.rmi.RemoteException {}
7. public void ejbActivate() throws java.rmi.RemoteException {}
8. public void ejbPassivate() throws java.rmi.RemoteException {}
Для того чтобы клиент мог взаимодействовать с экземпляром session
bean, программист должен написать все три составные части EJB, описанные выше. Клиентское приложение использует home-интерфейс session bean для поиска и получения ссылки на его remote-интерфейс. После получения такой ссылки клиент может обращаться к любому методу remote-интерфейса. Клиент íå знает, является ýòîò метод
локальным или удаленным. С точки зрения клиента, вызов удаленного
метода выглядит так же просто, как вызов любого локального метода.
Контейнер EJB передает вызов клиента настоящему (и невидимому для
клиента) экземпляру session bean, используя необходимый коммуникационный протокол, а затем возвращает результат вызова клиенту через
remote-интерфейс.
В отличие от Entity bean, в Session bean отсутствует Primary key
класс, поскольку session bean не обращается к базе данных.
Согласно спецификации EJB, по соглашению, предлагаемому компа-
нией SUN, имя remote-интерфейса состоит из двух частей. Первая эквивалентна имени bean, для которого создан интерфейс, другая содержит постфикс Home.
Интерфейс Remote используется EJB-клиентом для организации до-
ступа к бизнес-методам Enterprise bean. В нем также содержатся методы по созданию и удалению экземпляров Enterprise bean.
Remote interface должен отвечать следующим требованиям:
•
расширяться от java.ejb.EJBObject интерфейса;
•
включает все бизнес-методы, описанные в enterprise bean;
•
параметры, возвращаемые в каждом методе, должны быть валид-
ными при использовании RMI;
222 Часть 4. Распределенные компненты EJB
обрабатывать исключения java.rmi.RemoteException.
•
setSesionContext () метод должен обеспечивать установку контек-
•
ста выполнения Enterprise bean;
должны использоваться: методы, наследуемые remoteInterface от
•
javax.ejb.EJBObject;
метод getEJBHome() должен возвращать home объект;
•
метод getHandle() — указывать обработчик EJBObjects;
•
метод getPrimaryKey() — возвращать значение первичного ключа,
•
объект Primary key;
метод isIdentical() — сравнивает два EJBObjects на эквивалент-
•
ность;
метод Remove() — удаляет Enterprise bean из контейнера и сведе-
•
ния о Enterprise bean в основной базе данных.
31.9. Жизненный цикл Session bean
Клиент это два разных типа приложений. Web-клиент не может не-
посредственно обратиться к session bean, для этого Web-клиент должен
использовать промежуточный элемент в виде servlet или JSP-страницы.
Для других Java-приложений используется RMI, поэтому запрос поступает сразу в EJB-контейнер.
В общем случае жизненный путь session bean делится на несколько
этапов (рис. 4.5):
1. В ответ на запрос клиента контейнер создает новый объект.
2. Экземпляр EJB готов к выполнению запросов клиента. Такое его
состояние называется «method ready state».
3. Бизнес-методы EJB могут выполняться как в контексте транзак-
ции, так и вне любой транзакции — в зависимости от значения атрибутов в Дескрипторе Поставки и контекста транзакции клиента.
Рис. 4.5. Жизненный цикл Session bean
Часть 4. Распределенные компненты EJB 223
4. Нетранзакционные методы session bean выполняются экземпляром
в состоянии method ready.
5. Экземпляр EJB становится участником транзакции, когда клиент
вызывает его транзакционный метод. Правильную работу с контекстом
транзакции обеспечивает контейнер. Завершение транзакции (подтверждение или откат) выполняется сервисом транзакций.
6. В определенный момент контейнер может выгрузить экземпляр
EJB из памяти. В этом случае выполняется деактивизация (passivation)
EJB с записью его состояния в хранилище. Session-Компонент не может
быть выгружен, если он участвует в транзакции.
7. Если клиент вызывает другой метод выгруженного EJB, контейнер
снова загружает его в память. При этом происходит восстановление его
состояния из хранилища, и EJB готов выполнить запрос клиента. В ответ на вызов клиентом метода remove() контейнер уничтожает экземплярEJB. Он может сделать это и о истечении определенного интервала
времени (по тайм-ауту).
С точки зрения используемых методов свой жизненный цикл Session
bean начинает с момента создания экземпляра session bean, используя
метод create(), описанный в интерфейсе Home. Разница в жизненном
цикле различных session bean, будет указана для каждого такого случая. В ответ на вызов метода create() контейнер производит следующие
действия: создает и размещает в памяти экземпляр session bean.
Затем контейнер вызывает метод setSessionContext (). Этот метод ис-
пользуется для организации доступа вновь созданного экземпляра к системным сервисам. Наконец контейнером вызывается метод ejbCreate().
Именно на данном этапе контейнер определяет, как вызываются методы — транзакционно или нетранзакционно. Если бизнес-методы вызываются транзакционно, то после этого Session bean делает свою работу,
пока транзакции не закончатся. Перед началом транзакции вызывается
метод afterBegin(), если такой метод реализован в данном классе, клиентские бизнес-методы взаимодействуют с бизнес-методами, определенными в remote interface вызываемого EJB. Метод вызывается beforeComplete() перед завершением транзакции, при условии, что данный
метод существует. Транзакции может или осуществиться, или быть
прерванной. Когда транзакция полностью прошла, контейнер может вызвать метод afterCompletion() при условии существовании оного. При
прерывании ( rollback) транзакции, значение данных в контейнере остается таким же, как до начала транзакции. При нетранзакционном вызове контейнер просто вызывает бизнес-методы.
После первого этапа session bean переходит в состояние готовности.
В этом состоянии клиент вызывает бизнес-методы, описанные в интерфейсе remote. Действия контейнера в этом состоянии определяются
тем, какие методы вызывались, транзакционые или нетранзакционные.
Контейнер управляет EJB по своему собственному алгоритму. Когда
контейнер определяет, что session bean находится в состоянии «долгоиграющего», контейнер перемещает session bean в резервный пул методом ejbPassivate(), куда он не может быть помещен, если имеет связанную с session bean транзакцию. Eсли клиент вызывает методы session
224 Часть 4. Распределенные компненты EJB
bean, находящегося в резервном пуле, то контейнер активизирует EJB,
вытаскивая его из пула методом ejbActivate().
Вызов транзакционных методов основан на ассоциации бизнес-мето-
дов с транзакциями. То есть действие метода продолжается до тех пор,
пока транзакция не совершится полностью. В этом случае контейнер
вызывает соответствующие методы.
Первым вызывается метод afterBegin(), описанный в bean классе.
Затем вызываются бизнес-методы remote интерфейса, необходимые
клиенту.
Экземпляр bean использует beforeCompletion(), описанный в основ-
ном bean классе, выполняемый до полного завершения транзакции. После завершения транзакции контейнер вызывает метод afterCompletion(), проверяющий ее результат. Если произошел откат, т. е. транзакция не завершилась, stateful session bean переходит в состояние до
выполнения транзакции, а bean Stateless session beans не работает с
транзакционными методами.
При вызове нетранзакционных методов контейнер просто вызывает
бизнес-методы.
Контейнер использует собственный алгоритм по размещению в па-
ìÿòè EJB.
Еще один вид состояния, в котором может находиться session bean —
активное или не активное. Контейнер сам определяет, как долго stateful
session bean пребывает в памяти и, вызывая метод ejbPassivate(), помещает по необходимости session bean в резервный пул памяти. Stateful
session bean не может быть деактивирован вышеуказанным методом в
момент прохождения транзакции. Если клиент вызывает деактивированный EJB, контейнер активизирует состояние stateful session bean,
вызывая метод ejbActivate() method. С stateless bean все и так понятно,
он не является активным, а значит, на него не распространяются вышеизложенные методы.
Последнее состояние session bean — состояние удаления.
Жизнь session bean заканчивается при вызове контейнером метода
ejbRemove(). Если по каким-либо причинам контейнер вызывает метод
ejbRemove(), при выполнении транзакции, то будет сгенерирована исключительная ситуация javax.ejb.RemoveException. После чего bean будет удален, а вызываемый метод сгенерирует исключительную ситуацию java.rmi.NoSuchObjectException. Контейнер содержит специальный
метод удаления через определенный промежуток времени. Параметр timeout, указанный в дескрипторе, передает указанное значение в метод
timeout(), вызываемый контейнером.
В отличие от session bean (stateful), описанного выше, всеми вопроса-
ми цикла жизни stateless session bean ведает EJB-контейнер. Цикл жизни такого session bean очень прост: когда контейнер создает новый экземпляр такого bean, контейнер вызывает методы setSessionContext() и
ejbCreate() основного класса EJB. Новый экземпляр помещается в пул
таких объектов, и любой из них готов обслуживать запросы клиентов.
Поскольку stateless-объекты не отслеживают своего состояния, контейнер для выполнения запроса клиента адресует этот запрос любому объекту из пула. При удалении контейнером объекта из пула он вызывает
Часть 4. Распределенные компненты EJB 225
метод session-объекта. Действия по созданию и удалению экземпляров
stateless session-bean из пула не связаны с вызовом методов create() или
remove() home-/remote-интерфейсов. Цикл жизни таких объектов определяется профилями контейнера (container policies).
Основные методы Session bean:
1) setSessionContext() — метод, описывающий системное окружение
и свойства контейнера, в котором выполняется session bean. EJB-контейнер вызывает этот метод, чтобы ассоциировать экземпляр EJB с
контекстом сессии. Интерфейс SessionContext объявляет методы для
доступа к свойствам времени выполнения контекста, в котором выполняется сессия. Как правило, объект сохраняет этот контекст как часть
своего состояния;
2) ejbRemove() — вызывается контейнером прежде, чем session bean
прекратит свое существование, обычно через определеное количество
времени;
3) ejbActivate() — предназначен для придания session bean статуса
активированного session bean;
4) ejbPassivate() — деактивирует session bean.
Уведомления о выполнении активизации и деактивизации позволяют
реализовывать эффективные схемы управления ресурсами.
Глава 32. Последние штрихи
Последним шагом при создании EJB является написание описателя
(deployment descriptor) и помещение его в jar-архив созданных классов.
И уже после создания jar-архива EJB можно помещать в контейнер
любого EJB-сервера, при этом обязательно следует учитывать специфику каждого EJB-сервера.
32.1. Дескриптор EJB (deployment descriptor)
Создание EJB — полдела. Далее необходимо описать, что будет де-
лать созданный EJB и как с ним должен работать EJB-контейнер. После того как написаны соответствующие классы и интерфейсы, EJB
подготовлен для поставки. Оттранслированный код помещается в стандартный архивный файл Java-файл ejb-jar. Этот файл может содержать один или несколько байт-кодов классов EJB. Данный jar-архив содержит интерфейсы, классы и дескриптор для каждого размещенного в
архиве EJB.
Под процессом «поставки» EJB понимается установка его ejb-jar-
файла в контейнер EJB. Процесс поставки включает в себя:
1) проверку, что все составные части EJB соответствуют друг другу;
2) регистрацию EJB в Naming Service;
3) обеспечение доступа к экземпляру через коммуникационную сис-
тему сервера EJB;
4) реализацию управления транзакциями и отслеживание профилей
безопасности.
226 Часть 4. Распределенные компненты EJB
В контейнере может быть установлено любое число EJB. Контейнер
EJB предоставляет как среду выполнения для своих EJB, так и инструменты для выполнения процесса поставки.
Информация, находящаяся в Дескрипторе Поставки, используется
для задания значений атрибутов EJB. Эти атрибуты определяют поведение EJB при его взаимодействии с конкретной средой исполнения.
В дескрипторе описывается следующая информация:
1. Имена классов, содержащие описание home- и remote-интерфей-
ñîâ.
2. JNDI-имя home-интерфейса для Enterprise bean.
3. Переменные для использования в CMP Enterprise bean.
4. Описание транзакционных механизмов.
5. Атрибуты обеспечения безопасности.
6. Специальные атрибуты поставщиков EJB-контейнера.
Дескриптор содержит атрибуты и системные переменные, необходи-
мые для вызова EJB. Чаще всего в роли дескриптора выступает обычный текстовый файл, но в последнее время все большую популярность
для описания дескрипторов приобретают XML-документы. Структура
дескриптора содержит несколько основных элементов и дополнительные EJB. Обращение к дескриптору очень похоже на процесс инициализации servlet. Для создания XML-документа, который впоследствии послужит дескриптором EJB, можно использовать любой XML-редактор
или в крайнем случае текстовой редактор. В большинстве современных
средств разработки EJB для создания дескриптора используются
встроенные утилиты. У каждого Application Server свой собственный
EJB-контейнер и свой собственный EJB-дескриптор. Но большая часть
параметров дескриптора стандартизирована и используется во всех
контейнерах, поддерживающих спецификацию 1.1. EJB. Типы дескриптора описываются при помощи атрибутов. Название атрибута и его значение позволяют управлять бизнес-логикой Enterprise bean без изменения кода, разработчик может в любой момент изменить параметры дескриптора.
Кроме самого Enterprise bean, в дескрипторе может содержаться ин-
формация о приложении, работающем с EJB.
Подводя итог, можно описать приблизительную структуру дескрип-
òîðà.
Для всех Enterprise bean указываются:
Имя Enterprise bean.
Класс Enterprise bean.
Home интерфейс Enterprise bean.
Remote интерфейс Enterprise bean.
Type Enterprise bean.
Переменные системного окружения:
1. Описание переменных хранящихся в базе данных.
2. Описание самих EJB.
3. Уровень секретности.
Конкретно для session bean:
Тип Session EJB.
Тип транзакции используемой в Session EJB.
Часть 4. Распределенные компненты EJB 227
Для Enterprise entity beans используются:
Persistence managed type Entity bean.
Primary key class Entity bean.
И специально для CMP Enterprise bean:
Переменные, используемые в CMP.
1. <?xml version=’1.0’ standalone=’yes’ ?>
2. <ejb-JAR>
3. <input-file>SampleIn.jar</input-file>
4. <output-file>Sample.jar</output-file>
5. <entity-bean dname="com/rrlabs/ejb/sample/Sample .ser">
6. <primary-key>com. rrlabs.ejb.sample.SamplePrimaryKey</primary-key>
7. <re-entrant value=false/>
8. <container-managed>accountId</container-managed>
9. <container-managed>type</container-managed>
10. <container-managed>balance</container-managed>
11. </entity-bean>
12. <!—Îïècàíèå session bean —!>
13. <input-file>SissionSampleIn.jar</input-file>
14. <output-file>SessionSample.jar</output-file>
15. <session-bean dname="com/rrlabs/ejb/sample/bank/Transaction.ser">
16. <session-timeout>0<\session-timeout>
17. <state-management>STATELESS_SESSION<\state-management>
18. <remote-interface> com/rrlabs/ejb/sample/bank/Transaction </remoteinterface>
19. <enterprise-bean> com/rrlabs/ejb/sample/bank/Transaction.TransferBean</enterprise-bean>
20. <JNDI-name>Transfer </JNDI-name>
21. <transaction-attr value="TX_REQUIRED"/>
22. <isolation-level value="SERIALIZABLE"/>
23. <run-as-mode value="CLIENT_IDENTITY"/>
24. <dependency> com/rrlabs/ejb/sample/bank /InsufficientFundsException.class</dependency>
25. <env-setting name="ACCOUNT_NAME">Account<env-setting>
26. <transaction-attr value="TX_REQUIRED"/>
27. <method-control>
28. <method-name>getBalance</method-name>
29. <parameter>long</parameter>
30. <transaction-attr value="TX_SUPPORTED"/>
31. </method-control>
32. </session-bean>
33. <datasource>
34. <res-ref-name>jdbc/SavingsDataSource</res-ref-name>
35. <url>jdbc:db2:sample</url>
36. <driver-class-name>com.ibm.jdbc.db2.app.DB2driver</driver-class-name>
37. </datasource>
38. </ejb-JAR>
228 Часть 4. Распределенные компненты EJB
Каждый дескриптор, основанный на XML-документе, имеет ряд
основных конструкций. Поскольку дескриптор описан с помощью XML,
то обязательным является пролог. Далее содержится основной тег, открывающий и закрывающий описание Enterprise bean. Это так называемый заголовочный тег. Данный тег <ejb-JAR> имеет тело и конечный
элемент </ejb-JAR>. Именно в теле этого тега указываются все остальные теги. Все Enterprise bean содержатся в архивах. По усмотрению
разработчика это могут быть как стандартные zip-архивы или же архивы нового типа jar-архивы.
Тег <input file > описывает архивы, содержащие один или несколько
Enterprise bean и EJB. Другой подобный тег <output file> содержит имя
архива, в который будут помещены создаваемые EJB.
Для созданного Entity bean используются специальные теги в деск-
рипторе. Открывающийся <entity-bean тег содержит атрибут dname,
значением которого является полное имя дескриптора, предназначенного для данного Entity bean. Между открывающимся и закрывающимся
тегом </Entity bean> содержатся специальные атрибуты для каждого
Entity bean:
<primary-key> — полное имя для primary key class;
<re-entrant> — указанный тег может принимать два логических
значения true или false. Значение true — указывает, что данный Entity
bean является участником процесса, указывает, какие методы EJB может вызывать внутри себя или у других EJB;
<container-managed> — тег описывает постоянные поля, используе-
мые в CMP entity bean. Каждая постоянная, хранимая в базе данных
«поле» (переменная) описывается в собственном теге <container-managed>.
Для каждого session bean используются свои теги:
<session bean> содержит атрибут dname. Значение атрибута содер-
жит полное имя созданного дескриптора, ассоциированного с session bean. Между открывающими и закрывающими тегами содержатся специальные теги, предназначенные только для session bean;
<session-timeout> — тег определяет количество времени в секундах,
прежде чем контейнер удалит session bean. Значение ноль указывает,
что session bean будет удален через максимальное время ожидания. По
умолчанию максимальное время ожидания соответствует 600 секундам;
<state-management> — â теге указывается òèï session bean:
STATELESS_SESSION èëè STATEFUL_SESSION.
Помимо этого, разработчик вправе добавить собственные теги по ра-
боте с Enterprise bean. Следующие теги предназначены для всех типов
Enterprise beans:
<remote-interface> — указывает полное имя remote-интерфейса. Ес-
ли тег указан в теле Entity bean, то соответственно имя интерфейса для
этого bean.
<enterprise-bean> — полное имя основного класса, то же самое, что
и для remote-интерфейса.
<JNDI-name> — указывается имя home интерфейса с использова-
íèåì JNDI.
Отдельное место занимают атрибуты контроля транзакций.
Часть 4. Распределенные компненты EJB 229
Транзакционные атрибуты определяет манеру вызова контейнером
различных методов EJB. Два основных атрибута содержит дескриптор.
Атрибуты устанавливаются отдельно для каждого метода или для всех
методов единолично. В EJB-сервере системное окружение описывает
взаимодействие каждого Entity bean с определенной транзакцией. Каждый EJB-клиент должен инициализировать транзакцию, прежде чем
вызывать метод bean. Транзакционные методы могут использоваться
как для каждого конкретного метода, так и для всего bean в целом.
Уровни изоляции транзакций определяются в терминах решения стандартных проблем, возникающих при параллельном доступе к данным.
Кроме того, уровни изоляций транзакций зависят от того, какой тип
JDBC драйвера используется в EJB.
<transaction-attr value> — параметр value может принимать одно из
нескольких значений TX_MANDATORY. Значение атрибута
TX_MANDATORY указывает контейнеру, как вызывается метод bean.
Если клиент вызывает метод без указания контекста транзакции, контейнер генерирует исключительную ситуацию javax.jts.TransactionRequiredException. Контекст транзакции описывается в любом EJB-объекте. Этот параметр используется, если метод bean должен вызываться
текущей транзакцией.
TX_NOT_SUPPORTED — данное значение определяет, что вызыва-
емый метод не использует содержимое транзакции, контейнер создает
новый поток для создания транзакции.
TX_SUPPORTS — значение атрибута, указывает контейнеру, как
вызывается конкретный метод в пределах транзакции.
TX_REQUIRES_NEW — значение указывает контейнеру на необхо-
димость обязательного создания нового контекста окружения.
TX_REQUIRED — данное значение атрибута определяет окружение
транзакции. Для каждого вызова клиентом метода определяется контекст транзакции. Если используется контекст транзакции клиента, то
контейнер использует значения этого контекста. Если клиент вызывает
метод, не описанный в контексте транзакции, то контейнер создает новое окружение.
TX_BEAN_MANAGED. Значение атрибута TX_BEAN_MANAGED
указывается индивидуально для session bean и не используется для методов session bean. Указанное значение для stateful session bean устанавливается EJB-сервером. Метод, начавший транзакцию, должен полностью завершить транзакцию, вернуть значение commit или rollback.
<isolation-level value> — атрибут, указывающий уровень, использу-
емый в каждом контейнере для изоляции одной транзакции от другой.
Атрибут устанавливается для Enterprise bean или для каждого метода
в отдельности. Если метод описан с различными уровнями изоляции,
контейнер вызывает исключительную ситуацию java.rmi.RemoteException.
Параметр value может принимать ряд значений.
SERIALIZABLE. Значение SERIALIZABLE для указанного атрибута
запрещает чтение данных их строки основной базы данных, пока первая из обратившихся транзакций не пройдет полностью или не откатится. Это необходимо при нескольких различных вариантах работы с дан-
230 Часть 4. Распределенные компненты EJB
ными. Во-первых, может возникнуть ситуация, когда одна транзакция
читает строку, вторая может изменить ту же самую строку. Тогда первая транзакция получает различные значения. Способ называется «не
повторяемое чтение» (Nonrepeatable reads). Во-вторых, использование
SQL-оператора SELECT с параметром WHERE в момент считывания
данных одной транзакцией может привести к неправильным результатам, поскольку вторая транзакция обновила данные в считанных строках (Phantom reads). И наконец, иногда первая транзакция читает данные не полностью прошедшей второй транзакции (Dirty reads). Для
предотвращения совместного доступа к ресурсам, хранящимся в базе
данных, устанавливаются соответствующие значения атрибута.
REPEATABLE_READ — представляет более гибкую возможность
работы с транзакциями, чем SERIALIZABLE. Указанный атрибут позволяет транзакциям использовать dirty reads nonrepeatable reads, но
запрещает использование phantom reads.
READ_COMMITTED — на этом уровне транзакции запрещено dirty
reads, но можно использовать nonrepeatable reads и phantom reads.
READ_UNCOMMITTED — предназначен для транзакций, деятель-
ность которых не повлияет на данные, хранящиеся в базе данных. То
есть можно использовать все три уровня доступа: dirty reads, nonrepeatable reads и phantom reads.
Следует заметить, что, чем выше уровень блокировки, тем медлен-
нее выполняется запрос. Это обстоятельство необходимо учитывать для
приложений, критичных ко времени исполнения.
Обеспечение безопасности выполнения описывается в теге <run-as-
mode value>. Значение value может принимать несколько различных
переменных, каждая из которых обеспечивает собственный уровень
безопасности.
CLIENT_IDENTITY — сервис безопасности EJB-сервера не получа-
ет дополнительных указаний относительно исполняемого bean.
SYSTEM_IDENTITY — используются специальные распоряжения
EJB-серверу об обеспечении дополнительных способов защиты.
SPECIFIED_IDENTITY — самый высокий уровень безопасности.
Специальные свойства EJB-контейнером определяются для исполняемого Enterprise bean.
<run-as-id> — с помощью тега определяются идентификаторы вы-
зовов методов и Enterprise bean.
<method-control> — тег, указывающий атрибуты безопасности вы-
полнения для каждого метода.
<dependency> — описывает полные имена классов, от которых зави-
ñèò Enterprise bean.
<env-setting> — в теге описываются системные переменные и их
значения. Имя системной переменной указывается с именем атрибута.
Ну и конечно же надо описать источник базы данных. Необходимо
указать три обязательных элемента:
•
URL источника данных. jdbc:DB2:sample;
•
Jndi-имя источника данных. sample;
•
Имя класса jdbc-драйвера. COM.ibm.db2.jdbc.app.DB2Driver.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]