EJB 3.0 накратко

Въпреки няколко положителни страни, сложността на архитектурата Enterprise JavaBeans възпрепятства приемането на J2EE. Архитектурата на EJB е може би единственият компонент на J2EE, който се провали толкова мизерно, като изпълни обещанието на J2EE за повишена производителност на разработчиците при пълна лекота на разработка. EJB 3.0 прави още един опит да изпълни това обещание, като намалява сложността на EJB за разработчиците. EJB 3.0 намалява броя на програмните артефакти, които разработчиците да предоставят, елиминира или свежда до минимум методите за обратно извикване, които се изискват да бъдат внедрени, и намалява сложността на модела за програмиране на обект и O / R картографиране.

В тази статия първо обхващам най-значимите промени в EJB 3.0. Важно е да имате основите на място, преди да се потопите в басейна EJB 3.0. След това давам изглед на високо ниво на проекта на EJB 3.0 и след това навлизам в спецификите на предложената спецификация, като обръщам внимание на всички промени едно по едно: въздействие върху видовете корпоративни зърна, модел на O / R картографиране, субект- модел на взаимоотношения, EJB QL (EJB Query Language) и др.

Заден план

Двете най-съществени промени в предложената спецификация EJB 3.0 са използването на съоръжението за анотиране на програмата, въведено в Java 5, и новия модел на O / R картографиране, базиран на Hibernate.

Съоръжение за метаданни в Java 5

Java 5 (по-рано наричана J2SE 1.5 или Tiger) въведе ново средство за анотиране на програмата в езика. С това съоръжение можете да дефинирате персонализирани анотации и след това да анотирате полета, методи, класове и т.н. с тези анотации. Анотациите не засягат пряко семантиката на програмата, но инструментите (време за компилиране или време на изпълнение) могат да инспектират тези анотации, за да генерират допълнителни конструкции (като дескриптор на разполагане) или да налагат желаното поведение по време на изпълнение (като състоянието на компонента на EJB). Анотациите могат да бъдат проверени чрез парсинг на източника (например компилатори или IDE инструменти) или чрез използване на допълнителните API за отражение, добавени в Java 5. Анотациите могат да бъдат дефинирани така, че да бъдат достъпни само на ниво изходен код, на ниво компилиран клас или по време на изпълнение . Всички предложени в EJB 3.0 ранен проект анотации имат RetentionPolicyнаRUNTIME. Това незначително увеличава отпечатъка на паметта на класа, но значително улеснява живота на доставчика на контейнери и доставчика на инструменти.

Обърнете се към ресурси за допълнително четене по тази тема.

Хибернация

Hibernate е популярна рамка за картографиране O / R с отворен код за Java среди, предназначена да предпази разработчиците от най-често срещаните програми, свързани с постоянството на данни. Той също така има специфичен Hibernate Query Language (HQL), отпечатъци от който могат да се видят в новия EJB QL. Hibernate предлага съоръжения за извличане и актуализиране на данни, обединяване на връзки, управление на транзакции, управление на декларативни обекти и декларативни и програмни заявки.

Птичи поглед

Промените в предложената спецификация EJB 3.0 могат да бъдат разделени на две категории:

  • Базиран на анотации модел за програмиране на EJB, в допълнение към модела EJB 2.1 за определяне на поведението на приложението чрез дескриптори на разполагане и няколко интерфейса.
  • Новият модел на устойчивост за обектни зърна. EJB QL също се е променил значително.

Има и няколко странични ефекти на тези предложения, като нов модел за програмиране на клиенти, използване на бизнес интерфейси и жизнен цикъл на обекта. Моля, обърнете внимание, че моделът за програмиране EJB 2.1 (с дескриптори за разполагане и интерфейси за дома / отдалечеността) все още е валиден. Новият опростен модел не замества изцяло модела EJB 2.1.

EJB анотации

Една от важните цели на експертната група е да се намали броят на артефактите, които доставчикът на зърна трябва да предостави, и групата е свършила доста добра работа при постигането на тази цел. В света на EJB 3.0, всички видове корпоративни зърна са просто стари Java обекти (POJO) с подходящи анотации. Анотациите могат да се използват за дефиниране на бизнес интерфейса на боб, информация за картографиране на O / R, референции за ресурси и почти всичко друго, което е дефинирано чрез дескриптори за разполагане или интерфейси в EJB 2.1. Дескриптори за внедряване вече не са необходими; домашният интерфейс е изчезнал и не е задължително да прилагате бизнес интерфейс (контейнерът може да го генерира за вас).

Например декларирате боб на сесия без състояние, като използвате @Statelessанотацията в класа Java. За боб със статут, @Removeанотацията е маркирана на определен метод, за да покаже, че екземплярът на боб трябва да бъде премахнат след завършване на извикване на маркирания метод.

За да намалите количеството информация, което трябва да посочите за даден компонент, експертната група е приела подход за конфигуриране по изключение , което означава, че предоставяте интуитивни настройки по подразбиране за всички анотации, така че да може да се изведе повечето от общата информация.

Новият модел на постоянство

Новите обекти на обекти също са само POJO с няколко анотации и не са постоянни обекти по рождение. Екземпляр на обект става постоянен, след като е свързан с EntityManagerи става част от контекста на постоянство . Контекстът на постоянство е слабо синоним на контекст на транзакция; с строги думи, тя имплицитно съжителства с обхвата на транзакцията.

Взаимоотношенията на обектите също се дефинират чрез анотации. В допълнение, O / R картографирането също се извършва чрез анотации и се осигурява поддръжка за няколко операции, специфични за база данни. С EJB 2.1 разработчиците използваха свои собствени дизайнерски модели или използваха непоносими техники (например стратегии за автоматично генериране на ключове).

Копае дълбоко

Сега е време да се запознаем със спецификата на предложенията, направени в ранния проект на EJB 3.0. Нека започнем с всичките четири вида корпоративни зърна и след това да преминем към предложенията, общи за целия програмен модел на EJB.

Сесионни зърна без гражданство:

Сесионният бин без състояние (SLSB), написан по начина EJB 3.0, е просто обикновен Java файл с анотация на ниво клас @Stateless. Класът bean може да реализира javax.ejb.SessionBeanинтерфейса, но не се изисква (и обикновено няма).

SLSB вече няма домашен интерфейс - всъщност нито един тип EJB не го изисква. Класът bean може или не може да внедри бизнес интерфейс. Ако не реализира никакви бизнес интерфейси, бизнес интерфейс ще бъде генериран, използвайки всички публични методи. Ако в бизнес интерфейса трябва да бъдат изложени само определени методи, всички тези методи могат да бъдат маркирани с @BusinessMethodанотацията. По подразбиране всички генерирани интерфейси са локални, но @Remoteанотацията може да се използва, за да покаже, че трябва да се генерира отдалечен интерфейс.

Следващите няколко реда код са достатъчни за дефиниране на HelloWorldбоб. С EJB 2.1, един и същ бин щеше да изисква поне два интерфейса, един клас на изпълнение с няколко реализации на празен метод и дескриптор за разполагане.

импортиране на javax.ejb. *; / ** * Сеанс без гражданство, изискващ генериране на отдалечен бизнес * интерфейс за него. * / @Stateless @Remote публичен клас HelloWorldBean {публичен низ sayHello () {return "Hello World !!!"; }}

Вижте Ресурси за пълния изходен код, придружаващ тази статия.

Покупка на сесия

Историята със състоящи сесионни компоненти (SFSB) е почти същата за SLSB, с изключение на няколко специфични за SFSB точки:

  • SFSB трябва да има начин да се инициализира (предоставен чрез ejbCreate()метода в EJB 2.1 и по-стари версии ). Спецификацията EJB 3.0 предлага такива методи за инициализация да бъдат предоставени като персонализирани методи и изложени чрез бизнес интерфейса на боб. Сега клиентът носи тежестта да извика подходящи методи за инициализация, преди да използва компонента. Експертната група все още обсъжда необходимостта от предоставяне на анотация, която маркира определен метод за инициализация.
  • Доставчикът на боб може да маркира всеки SFSB метод с @Removeанотацията, за да посочи, че екземплярът на боб трябва да бъде премахнат след извикването на анотирания метод. Отново експертната група все още обсъжда дали е необходимо съоръжение, за да се посочи, че бобът не трябва да се отстранява, ако методът не завърши нормално.

Ето моето мнение по двата отворени въпроса:

  • Трябва ли да съществува анотация за метода на инициализация? Моят глас е „да“ - с предположението, че контейнерът ще гарантира, че поне един от методите за инициализация е извикан преди да бъде извикан друг бизнес метод. Това не само предпазва от случайни програмни грешки, но също така прави контейнера по-уверен при повторното използване на екземпляри на SFSB. За по-голяма яснота, нека спомена тук, че не се разглеждат определени методи за инициализация (като ejbCreate); експертната група обмисля само да има метод за отбелязване като метод за инициализация.
  • Трябва ли да се конфигурира, че необичайното прекратяване на @Removeметода не премахва екземпляра на боб? Отново гласът ми е „да“. Това ще даде само по-добър контрол на доставчика на зърна и клиентските програмисти. Само един въпрос остава: какво се случва с тези зърна, избрани за да не се отстранява от неуспешен метод за премахване и начин премахнете конкретен случай никога не завършва успешно? Няма начин да премахнете тези екземпляри програмно, но те ще бъдат премахнати при изчакване на сесията.

Обърнете се към изходния код за пример SFSB.

Управляван от съобщения фасул

Управляваните от съобщения зърна (MDB) са единственият вид боб, който трябва да внедри бизнес интерфейс. Типът на този интерфейс указва типа система за съобщения, която бобът поддържа. За MDS, базирани на JMS (Java Message Service), този интерфейс е javax.jms.MessageListener. Имайте предвид, че бизнес интерфейсът MDB не е наистина бизнес интерфейс, той е просто интерфейс за съобщения.

Етикет боб

Обектите @Entityна обекта са маркирани с анотацията и всички свойства / полета в класа на обекта на обекти, които не са маркирани с @Transientанотацията, се считат за постоянни. Постоянните полета на обект на обект се излагат чрез свойства в стил JavaBean или просто като публични / защитени полета на Java клас.

Обектните компоненти могат да използват помощни класове за представяне на състояние на обект на обект, но екземплярите на тези класове нямат постоянна идентичност. Вместо това тяхното съществуване е силно обвързано с екземпляра на притежаващия обект; също така тези обекти не могат да се споделят между обекти.

Обърнете се към изходния код за някои примерни обекти на обекти.

Взаимоотношения между субектите

EJB 3.0 supports both unidirectional and bidirectional relationships between entity beans, which can be one-to-one, one-to-many, many-to-one, or many-to-many relationships. However, the two sides of a bidirectional relationship are distinguished as the owning side and the inverse side. The owning side is responsible for propagating relationship changes to the database. For many-to-many associations, the owning side must be explicitly specified. Actually it's the reverse side that is specified by the isInverse=true annotation member on the reverse side's ManyToMany annotation; from that, the owning side is deduced. Now, didn't the expert group say it was making EJB easier?

O/R mapping

The O/R mapping model has also significantly changed from the abstract-persistence-schema-based approach to a Hibernate-inspired one. Though the expert group is still discussing the model, and a clear picture will emerge only with the next draft, this draft features clear indications of the overall approach.

For one, the O/R mapping will be specified in the entity bean class itself by annotations. Also, the approach is to refer to concrete tables and columns instead of the abstract persistence schema. The O/R mapping model has intrinsic support for native SQL; that is, support at a deeper level, not just the ability to run native SQL queries. For example, the column definitions annotation (@Column) has a member columnDefinition that can be something like columnDefinition="BLOB NOT NULL".

Client programming model

An EJB client can acquire a reference to the bean's business interface using the injection mechanism (@Inject annotation). Using the newly introduced @javax.ejb.EJBContext.lookup() method is another approach. But the specification is not clear as to how a standalone Java client acquires reference to a bean instance since the standalone Java clients run in a J2EE client container and lack access to the @javax.ejb.EJBContext object. There is yet another mechanism—a newly introduced universal context object: @javax.ejb.Context(). But, again, the spec does not say how this object can be used in a client container.

EJB QL

Queries can be defined through the @NamedQuery annotation. Two members of this annotation are name and queryString. Once defined, this query can be accessed using the EntityManager.createNamedQuery(name) method. You can also create a regular JDBC-style (Java Database Connectivity) query by calling EntityManager.createQuery(ejbqlString) or a native query using EntityManager.createNativeQuery(nativeSqlString).

EJB QL queries can have both positional as well as named parameters. The javax.ejb.Query interface provides methods for setting these parameters, executing updates, listing results, etc.

Here is one example of how an EJB QL query can be created and executed:

.. .. @NamedQuery (name = "findAllCustomersWithName", queryString = "SELECT c FROM Customer c WHERE c.name LIKE: custName") .. .. @Inject public EntityManager em; клиенти = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults ();

По-долу са изброени някои от няколкото подобрения, направени в самия QL: