Programování

Stručně řečeno, EJB 3.0

Přes několik pozitiv brání přijetí J2EE složitost architektury Enterprise JavaBeans. Architektura EJB je pravděpodobně jedinou komponentou J2EE, která tak nešťastně selhala při plnění příslibu J2EE o zvýšené produktivitě vývojářů a důkladném usnadnění vývoje. EJB 3.0 dělá další pokus o splnění tohoto slibu snížením složitosti EJB pro vývojáře. EJB 3.0 snižuje počet programovacích artefaktů, které mají vývojáři poskytovat, eliminuje nebo minimalizuje metody zpětného volání vyžadované pro implementaci a snižuje složitost programovacího modelu entity bean a modelu mapování O / R.

V tomto článku se nejprve věnuji nejvýznamnějším změnám v EJB 3.0. Před ponorem do fondu EJB 3.0 je důležité mít připravené základní informace. Dále poskytuji pohled na vysoké úrovni na koncept EJB 3.0 a poté se dostanu ke specifikům navrhované specifikace, přičemž věnuji pozornost všem změnám jeden po druhém: dopad na typy podnikových fazolí, model mapování O / R, entity- relační model, EJB QL (EJB Query Language) atd.

Pozadí

Dvě nejvýznamnější změny v navrhované specifikaci EJB 3.0 jsou použití anotačního zařízení programu zavedeného v Javě 5 a nový model mapování O / R založený na Hibernate.

Zařízení metadat v Javě 5

Java 5 (dříve J2SE 1.5 nebo Tiger) zavedla do jazyka nové zařízení pro anotaci programů. Pomocí této funkce můžete definovat vlastní anotace a poté pomocí těchto anotací anotovat pole, metody, třídy atd. Anotace přímo neovlivňují sémantiku programu, ale nástroje (čas kompilace nebo běhový modul) mohou tyto anotace zkontrolovat a vygenerovat další konstrukty (například deskriptor nasazení) nebo vynutit požadované chování běhového prostředí (jako stavová povaha komponenty EJB). Annotations can be inspected through source parsing (eg, compilers or IDE tools) or by using the additional reflection APIs added in Java 5. Annotations can be defined to be available only at the source code level, at the compiled class level, or at runtime . Všechny anotace navržené v počátečním návrhu EJB 3.0 mají a Retenční politika z RUNTIME. Tím se nepatrně zvyšuje paměťová stopa třídy, ale mnohem se usnadní život poskytovatele kontejnerů a poskytovatelů nástrojů.

Další informace o tomto tématu najdete v části Zdroje.

Přezimovat

Hibernate je populární open source rámec mapování O / R pro prostředí Java, který má chránit vývojáře před nejběžnějšími programovacími úlohami souvisejícími s trvalostí dat. Má také specifický Hibernate Query Language (HQL), jehož otisky lze vidět v novém EJB QL. Hibernate nabízí zařízení pro získávání a aktualizaci dat, sdružování připojení, správu transakcí, správu vztahů s deklarativními entitami a deklarativní a programové dotazy.

Pohled z ptačí perspektivy

Změny v navrhované specifikaci EJB 3.0 lze rozdělit do dvou kategorií:

  • Annotation-based EJB programming model, kromě modelu EJB 2.1 definujícího chování aplikace prostřednictvím deskriptorů nasazení a několika rozhraní.
  • Nový model perzistence pro fazole entit. EJB QL se také významně změnilo.

Existuje také několik vedlejších účinků těchto návrhů, jako je nový model programování klienta, použití obchodních rozhraní a životní cyklus entity bean. Vezměte prosím na vědomí, že programovací model EJB 2.1 (s deskriptory nasazení a domácími / vzdálenými rozhraními) je stále platný. Nový zjednodušený model nenahrazuje zcela model EJB 2.1.

Anotace EJB

Jedním z důležitých cílů skupiny odborníků je snížit počet artefaktů, které musí poskytovatel fazolí poskytnout, a skupina při plnění tohoto cíle odvedla pěknou práci. Ve světě EJB 3.0 jsou všechny druhy podnikových fazolí spravedlivé obyčejné staré objekty Java (POJO) s příslušnými anotacemi. Annotations can be used to define the bean's business interface, O / R mapping information, resource references, and just about anything else that was defined through deployment descriptors or interfaces in EJB 2.1. Deskriptory nasazení již nejsou vyžadovány; domovské rozhraní je pryč a nemusíte nutně implementovat obchodní rozhraní (kontejner jej může vygenerovat).

Například deklarujete fazole relace bez státní příslušnosti pomocí @ Bez státní příslušnosti anotace k třídě Java. U stavových fazolí je @Odstranit anotace je označena na konkrétní metodě, která označuje, že instance fazole by měla být odstraněna po dokončení volání označené metody.

Aby se snížilo množství informací, které musíte pro komponentu určit, přijala skupina odborníků a konfigurace podle výjimky přístup, což znamená, že poskytujete intuitivní výchozí hodnoty pro všechny anotace, takže lze odvodit většinu běžných informací.

Nový model vytrvalosti

Nové fazole entit jsou také jen POJO s několika anotacemi a nejsou to trvalé entity od narození. Instance entity se stává trvalou, jakmile je přidružena k EntityManager a stává se součástí a kontext vytrvalosti. Kontext vytrvalosti je volně synonymem kontextu transakce; přísně řečeno, implicitně koexistuje s rozsahem transakce.

Vztahy entit jsou také definovány prostřednictvím anotací. Kromě toho se mapování O / R provádí také prostřednictvím anotací a poskytuje se podpora několika operací specifických pro databázi. S EJB 2.1 používali vývojáři vlastní návrhové vzory nebo použili nepřenosné techniky (například strategie generování automatických klíčů).

Kopat hluboko

Nyní je čas zabývat se zvláštnostmi návrhů předložených v dřívějším návrhu EJB 3.0. Začněme se všemi čtyřmi typy podnikových fazolí a poté přejdeme k obecným návrhům k celému programovacímu modelu EJB.

Fazole bez státní příslušnosti:

Bezstavová relační fazole (SLSB), napsaná způsobem EJB 3.0, je jen obyčejný soubor Java s anotací na úrovni třídy @ Bez státní příslušnosti. Třída bean může implementovat javax.ejb.SessionBean rozhraní, ale není vyžadováno (a obvykle nebude).

SLSB již nemá domácí rozhraní - ve skutečnosti to žádný typ EJB nevyžaduje. Třída bean může nebo nemusí implementovat obchodní rozhraní. Pokud neimplementuje žádná obchodní rozhraní, vygeneruje se obchodní rozhraní pomocí všech veřejných metod. Pokud by v obchodním rozhraní měly být vystaveny pouze určité metody, lze všechny tyto metody označit @BusinessMethod anotace. Ve výchozím nastavení jsou všechna generovaná rozhraní lokální, ale @Dálkový anotaci lze použít k označení, že by se mělo vygenerovat vzdálené rozhraní.

K definování a stačí několik následujících řádků kódu Ahoj světe fazole. S EJB 2.1 by stejný fazole vyžadoval alespoň dvě rozhraní, jednu implementační třídu s několika prázdnými implementacemi metod a deskriptor implementace.

import javax.ejb. *; / ** * Bean relace bez státní příslušnosti vyžadující, aby pro něj bylo vygenerováno rozhraní vzdáleného podnikání *. * / @Stateless @Remote public class HelloWorldBean {public String sayHello () {return "Hello World !!!"; }} 

Úplný zdrojový kód, který je přiložen k tomuto článku, najdete v části Zdroje.

Stavové fazole relace

Příběh se stavovými fazolemi relace (SFSB) je pro SLSB téměř stejný, s výjimkou několika bodů specifických pro SFSB:

  • SFSB by měl mít způsob inicializace (poskytované prostřednictvím ejbCreate () metoda v EJB 2.1 a dřívějších). Specifikace EJB 3.0 navrhuje, aby tyto inicializační metody byly poskytovány jako vlastní metody a vystaveny prostřednictvím obchodního rozhraní fazole. Břemeno nyní leží na klientovi, aby před použitím fazole zavolal vhodné inicializační metody. Skupina odborníků stále diskutuje o potřebě poskytnout anotaci, která označuje konkrétní metodu pro inicializaci.
  • Poskytovatel fazolí může označit jakoukoli metodu SFSB pomocí @Odstranit anotation to indicate that the bean instance must be removed after an annotated method is called. Expertní skupina opět diskutuje o tom, zda je nutné zařízení indikující, že fazole nesmí být odstraněna, pokud se metoda nedokončí normálně.

Tady je můj názor na dvě otevřené otázky:

  • Měla by existovat anotace pro metodu inicializace? Můj hlas je ano - s předpokladem, že kontejner zajistí, že bude volána alespoň jedna z inicializačních metod před voláním jakékoli jiné obchodní metody. To nejen chrání před náhodnými programovacími chybami, ale také zvyšuje jistotu kontejneru při opakovaném použití instancí SFSB. Pro jasnost zde zmíním, že ne určená inicializace metody (jako ejbCreate) jsou v úvahu; skupina odborníků pouze zvažuje, že bude mít metodu anotace jako metodu inicializace.
  • Mělo by být konfigurovatelné, že abnormální ukončení @Odstranit metoda neodstraní instanci fazole? Můj hlas je opět ano. Poskytne to pouze lepší kontrolu poskytovatelům fazolí a klientským programátorům. Zůstává jen jedna otázka: co se stane s těmi fazolemi označenými jako ne odstraněno při neúspěšném volání metody remove a metoda odebrání konkrétní instance se nikdy nedokončí úspěšně? Neexistuje žádný způsob, jak tyto instance programově odebrat, ale budou odstraněny při vypršení časového limitu relace.

Příklad zdrojového kódu SFSB najdete ve zdrojovém kódu.

Fazole založené na zprávách

Fazole založené na zprávách (MDB) jsou jediný druh fazole, který musí implementovat obchodní rozhraní. Typ tohoto rozhraní označuje typ systému zasílání zpráv, který fazole podporuje. U MDB založených na JMS (Java Message Service) je toto rozhraní javax.jms.MessageListener. Všimněte si, že obchodní rozhraní MDB není skutečně podnikání rozhraní, je to jen rozhraní pro zasílání zpráv.

Entitní fazole

Fazole entity jsou označeny @Entity anotace a všechny vlastnosti / pole ve třídě fazole entity ne označeno @ Přechodné anotace jsou považovány za trvalé. Trvalá pole entity bean jsou vystavena prostřednictvím vlastností stylu JavaBean nebo jen jako veřejná / chráněná pole třídy Java.

Bity entit mohou používat pomocné třídy pro reprezentaci stavu objektu bean entity, ale instance těchto tříd nemají trvalou identitu. Místo toho je jejich existence silně svázána s instancí fazole vlastňující entity; také tyto objekty nelze sdílet mezi entitami.

Podívejte se na zdrojový kód pro některé příklady fazole entity.

Vztahy mezi entitami

EJB 3.0 podporuje jednosměrné i obousměrné vztahy mezi entitami fazole, které mohou být vztahy jeden na jednoho, jeden na mnoho, mnoho na jednoho nebo mnoho na mnoho. Obě strany obousměrného vztahu se však rozlišují jako strana vlastnící a strana obrácená. Vlastník je zodpovědný za šíření změn vztahů do databáze. U přidružení mnoho k mnoha musí být výslovně uvedena vlastnická strana. Ve skutečnosti je to zadní strana, kterou určuje isInverse = true anotační člen na zadní straně ManyToMany anotace; z toho se odvodí strana, která je vlastníkem. Neříkala nyní skupina odborníků, že usnadňuje EJB?

O / R mapování

Model mapování O / R se také významně změnil z přístupu založeného na schématu abstraktní perzistence na přístup inspirovaný režimem Hibernate. Ačkoli skupina expertů o modelu stále diskutuje a jasný obraz se objeví až v příštím návrhu, tento návrh obsahuje jasné náznaky celkového přístupu.

U jednoho bude mapování O / R specifikováno v samotné třídě objektu bean pomocí poznámek. Přístupem je také odkaz na konkrétní tabulky a sloupce namísto abstraktního schématu perzistence. Model mapování O / R má vnitřní podporu pro nativní SQL; tj. podpora na hlubší úrovni, nejen schopnost spouštět nativní dotazy SQL. Například anotace s definicemi sloupců (@Sloupec) má člena columnDefinition to může být něco jako columnDefinition = "BLOB NENÍ NULL".

Model programování klienta

Klient EJB může získat odkaz na obchodní rozhraní fazole pomocí injekčního mechanismu (@Inject anotace). Pomocí nově zavedené @ javax.ejb.EJBContext.lookup () metoda je další přístup. Specifikace však není jasná, jak samostatný klient Java získává odkaz na instanci fazole, protože samostatní klienti Java běží v kontejneru klienta J2EE a nemají přístup k @ javax.ejb.EJBContext objekt. Existuje ještě další mechanismus - nově zavedený univerzální kontextový objekt: @ javax.ejb.Context (). Specifikace ale opět neříká, jak lze tento objekt použít v klientském kontejneru.

EJB QL

Dotazy lze definovat pomocí @NamedQuery anotace. Dva členové této anotace jsou název a Řetězec dotazu. Jakmile je tento dotaz definován, lze k němu přistupovat pomocí EntityManager.createNamedQuery (název) metoda. Voláním můžete také vytvořit běžný dotaz ve stylu JDBC (Java Database Connectivity) EntityManager.createQuery (ejbqlString) nebo nativní dotaz pomocí EntityManager.createNativeQuery (nativeSqlString).

Dotazy EJB QL mohou mít jak poziční, tak pojmenované parametry. The javax.ejb. Dotaz rozhraní poskytuje metody pro nastavení těchto parametrů, provádění aktualizací, výpis výsledků atd.

Zde je jeden příklad toho, jak lze vytvořit a provést dotaz EJB QL:

.. .. @NamedQuery (name = "findAllCustomersWithName", queryString = "VYBRAT c OD ZÁKAZNÍKA c KDE c.name LIKE: custName") .. .. @Inject public EntityManager em; customers = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults (); 

V následujícím seznamu jsou uvedena některá z několika vylepšení provedených v samotné QL: