EJB 3.0 ukratko

Unatoč nekoliko pozitivnih rezultata, složenost Enterprise JavaBeans arhitekture koči usvajanje J2EE. Arhitektura EJB je vjerojatno jedina komponenta J2EE koja je tako jadno zakazala u ispunjavanju obećanja J2EE-a o povećanoj produktivnosti programera uz jednostavnost razvoja. EJB 3.0 čini još jedan pokušaj da ispuni to obećanje smanjenjem složenosti EJB-a za programere. EJB 3.0 smanjuje broj programskih artefakata koje programeri mogu pružiti, eliminira ili minimizira metode povratnog poziva potrebne za primjenu i smanjuje složenost entitetskog modela graha i O / R modela mapiranja.

U ovom članku prvo pokrivam najznačajnije promjene u EJB 3.0. Važno je imati osnove na mjestu prije zaranjanja u bazen EJB 3.0. Dalje, dajem pogled na visokoj razini nacrta EJB 3.0, a zatim ulazim u specifičnosti predložene specifikacije, obraćajući pažnju na sve pojedinačne promjene: utjecaj na vrste graha u poduzeću, O / R model mapiranja, entitet- model odnosa, EJB QL (EJB Query Language) itd.

Pozadina

Dvije najznačajnije promjene u predloženoj specifikaciji EJB 3.0 su uporaba programskog obilježavanja uvedenog u Javi 5 i novi model mapiranja O / R zasnovan na hibernaciji.

Objekt metapodataka u Javi 5

Java 5 (prethodno nazvana J2SE 1.5 ili Tiger) uvela je novu mogućnost označavanja programa u jezik. Pomoću ove mogućnosti možete definirati prilagođene bilješke, a zatim bilježiti polja, metode, klase itd. S tim bilješkama. Bilješke ne utječu izravno na semantiku programa, ali alati (vrijeme kompajliranja ili vrijeme izvođenja) mogu pregledati te bilješke kako bi generirali dodatne konstrukcije (poput deskriptora implementacije) ili nametnuli željeno ponašanje u vrijeme izvođenja (poput prirode stanja EJB komponente). Bilješke se mogu pregledati raščlanjivanjem izvora (npr. Kompajleri ili IDE alati) ili upotrebom dodatnih API-ja za odražavanje dodanih u Javi 5. Bilješke se mogu definirati tako da budu dostupne samo na razini izvornog koda, na razini prevedene klase ili u vrijeme izvođenja . Sve primjedbe predložene u EJB 3.0 ranog nacrta imaju RetentionPolicyodRUNTIME. To neznatno povećava memorijski otisak klase, ali znatno olakšava život dobavljača spremnika i davatelja alata.

Za daljnje čitanje ove teme pogledajte Resurse.

Hibernate

Hibernate je popularan, O / R okvir za mapiranje otvorenog koda za Java okruženja, namijenjen zaštiti programera od najčešćih programskih zadataka povezanih s upornošću podataka. Također ima specifični Hibernate Query Language (HQL), čiji se otisci mogu vidjeti u novom EJB QL. Hibernate nudi mogućnosti za pronalaženje i ažuriranje podataka, spremanje veza, upravljanje transakcijama, upravljanje odnosima deklarativnog entiteta i deklarativne i programske upite.

Ptičja perspektiva

Promjene u predloženoj specifikaciji EJB 3.0 mogu se podijeliti u dvije kategorije:

  • Model programiranja EJB zasnovan na napomenama, uz model EJB 2.1 definiranja ponašanja aplikacije putem deskriptora implementacije i nekoliko sučelja.
  • Novi model postojanosti za grah entiteta. EJB QL također se značajno promijenio.

Postoji i nekoliko nuspojava ovih prijedloga, poput novog modela programiranja klijenta, upotrebe poslovnih sučelja i životnog ciklusa graha entiteta. Napominjemo da je model programiranja EJB 2.1 (s deskriptorima implementacije i matičnim / udaljenim sučeljima) još uvijek važeći. Novi pojednostavljeni model ne zamjenjuje u potpunosti model EJB 2.1.

EJB bilješke

Jedan od važnih ciljeva stručne skupine je smanjiti broj artefakata koje dobavljač graha mora pružiti, a grupa je prilično uredno obavila svoj posao u postizanju tog cilja. U svijetu EJB 3.0, sve vrste poslovnog graha samo su obični stari Java objekti (POJO) s odgovarajućim bilješkama. Bilješke se mogu koristiti za definiranje poslovnog sučelja graha, informacije o mapiranju O / R-a, reference resursa i gotovo sve ostalo što je definirano pomoću deskriptora implementacije ili sučelja u EJB 2.1. Deskriptori implementacije više nisu potrebni; kućno sučelje je nestalo i ne morate nužno implementirati poslovno sučelje (spremnik ga može generirati umjesto vas).

Na primjer, deklarirate grah sesije bez stanja pomoću @Statelessbilješke na Java klasi. Za grah sa statusom, @Removebilješka je označena na određenoj metodi kako bi naznačila da instancu graha treba ukloniti nakon dovršetka poziva označene metode.

Da bi se smanjila količina podataka koju morate navesti za komponentu, stručna skupina usvojila je pristup konfiguracije po iznimci , što znači da pružate intuitivne zadane vrijednosti za sve bilješke kako bi se mogla zaključiti o većini uobičajenih informacija.

Novi model ustrajnosti

Novi grah entiteta također su samo POJO-ovi s nekoliko bilješki i nisu postojani entiteti po rođenju. Instanca entiteta postaje trajna kada se poveže s EntityManageri postane dijelom konteksta trajnosti . Kontekst postojanosti labavo je sinonim za kontekst transakcije; strogim riječima, implicitno koegzistira s opsegom transakcije.

Odnosi entiteta također su definirani putem bilješki. Uz to, O / R mapiranje se također vrši putem bilješki, a pruža se podrška za nekoliko operacija specifičnih za bazu podataka. S EJB 2.1, programeri su koristili vlastite obrasce dizajna ili su koristili prenosive tehnike (na primjer, strategije automatskog generiranja ključeva).

Kopati duboko

Sada je vrijeme da se upoznamo sa specifičnostima prijedloga danih u ranom nacrtu EJB 3.0. Počnimo sa sve četiri vrste graha za poduzeća, a zatim prijeđimo na prijedloge koji su generički za cijeli programski model EJB.

Grah sesije bez državljanstva:

Grah sesije bez državljanstva (SLSB), napisan na način EJB 3.0, samo je obična Java datoteka s oznakom na razini klase @Stateless. Klasa bean može implementirati javax.ejb.SessionBeansučelje, ali nije potrebna (i obično neće).

SLSB više nema kućno sučelje - zapravo, to ne zahtijeva nijedan tip EJB. Klasa graha može ili ne mora implementirati poslovno sučelje. Ako ne implementira nijedno poslovno sučelje, poslovno sučelje će se generirati korištenjem svih javnih metoda. Ako u poslovnom sučelju trebaju biti izložene samo određene metode, sve te metode mogu se označiti @BusinessMethodbilješkom. Prema zadanim postavkama, sva generirana sučelja su lokalna, ali @Remotenapomena se može koristiti da naznači da treba generirati udaljeno sučelje.

Sljedećih nekoliko redaka koda dovoljno je za definiranje HelloWorldgraha. S EJB 2.1, isti bi grah trebao najmanje dva sučelja, jednu klasu implementacije s nekoliko praznih implementacija metode i deskriptor implementacije.

uvoz javax.ejb. *; / ** * Građa sesije bez državljanstva koja traži da se za njega generira udaljeno poslovno * sučelje. * / @Stateless @Remote javna klasa HelloWorldBean {javni niz sayHello () {return "Hello World !!!"; }}

Potpuni izvorni kod koji prati ovaj članak potražite u Resursima.

Stabilni grah za sjednice

Priča sa grahom sesije sa statusom (SFSB) prilično je ista za SLSB, osim nekoliko točaka specifičnih za SFSB:

  • SFSB bi trebao imati način da se inicijalizira (pruža se ejbCreate()metodom u EJB 2.1 i starijim). Specifikacija EJB 3.0 sugerira da se takve metode inicijalizacije daju kao prilagođene metode i izlažu kroz poslovno sučelje graha. Klijent je sada dužan pozvati odgovarajuće metode inicijalizacije prije upotrebe graha. Stručna skupina još uvijek raspravlja o potrebi davanja napomene koja označava određenu metodu inicijalizacije.
  • Dobavljač graha može označiti bilo koju SFSB metodu oznakom @Removekako bi naznačio da se instanca graha mora ukloniti nakon što se pozove anotirana metoda. Ponovno, stručna skupina još uvijek raspravlja je li objekt potreban kako bi se naznačilo da se grah ne smije ukloniti ako metoda ne završi normalno.

Evo mog mišljenja o dva otvorena pitanja:

  • Treba li postojati napomena za metodu inicijalizacije? Moj je glas da - uz pretpostavku da će spremnik osigurati da se barem jedna od metoda inicijalizacije pozove prije nego što se pozove bilo koja druga poslovna metoda. To ne samo da štiti od slučajnih pogrešaka u programiranju, već i čini spremnik sigurnijim u ponovnoj upotrebi SFSB instanci. Radi jasnoće, ovdje da napomenem da se ne razmatraju nikakve određene metode inicijalizacije (poput ejbCreate); stručna skupina razmatra samo postavljanje oznake bilješke kao metodu inicijalizacije.
  • Treba li se konfigurirati da abnormalni završetak @Removemetode ne ukloni instancu graha? Opet, moj glas je potvrdan. Pružit će bolju kontrolu samo dobavljaču graha i programerima klijenata. Ostaje samo jedno pitanje: što se događa s onim grahom koji je označen da se neće ukloniti neuspješnim pozivom metode uklanjanja i metoda uklanjanja određene instance nikada se ne dovrši uspješno? Te slučajeve ne možete programski ukloniti, ali uklonit će se nakon isteka sesije.

Pogledajte izvorni kod za primjer SFSB-a.

Grah vođen porukom

Grahovi vođeni porukama (MDB) jedina su vrsta graha koja mora implementirati poslovno sučelje. Vrsta ovog sučelja označava vrstu sustava za slanje poruka koji grah podržava. Za MDB-ove temeljene na JMS-u (Java Message Service), ovo sučelje je javax.jms.MessageListener. Imajte na umu da poslovno sučelje MDB zapravo nije poslovno sučelje, već je samo sučelje za razmjenu poruka.

Entitetski grah

Grahovi entiteta označeni su @Entitybilješkom, a sva svojstva / polja u klasi graha entiteta koja nisu označena @Transientbilješkom smatraju se trajnim. Postojana polja zrna entiteta izložena su kroz svojstva u stilu JavaBean ili samo kao javna / zaštićena polja Java klase.

Entity beans can use helper classes for representing entity bean state, but instances of these classes don't have a persistent identity. Instead, their existence is tied strongly to the owning entity bean instance; also these objects are not shareable across entities.

Refer to the source code for some example entity beans.

Entity relationships

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; kupci = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults ();

Slijedi popis nekih od nekoliko poboljšanja na samom QL-u: