streamalism.org

1. Áttekintés

Az Enterprise Java Beans (EJB) a Java EE specifikáció központi része, amelynek célja az elosztott vállalati szintű alkalmazások fejlesztésének egyszerűsítése. Az EJB-k életciklusát egy alkalmazásszerver kezeli, például a JBoss WildFly vagy az Oracle GlassFish.

Az EJB-k robusztus programozási modellt nyújtanak, amely megkönnyíti a vállalati szintű szoftver modulok bevezetését, mivel az üzleti szerveren kívüli kérdések kezelése, mint például a tranzakciók kezelése, az alkatrészek életciklus-kezelése vagy a függőség-injektálás, az alkalmazásszerver feladata.

Ezenkívül már két cikket tettünk közzé, amelyek az EJB alapfogalmaival foglalkoznak, ezért nyugodtan nézze meg itt és itt.

Ebben az oktatóanyagban bemutatjuk, hogyan lehet egy alapvető EJB modult megvalósítani a WildFly-n, és hívni kell egy EJB-t egy távoli kliensről egy JNDI-n keresztül.

2. Az EJB modul megvalósítása

Az üzleti logikát egy vagy több helyi / távoli üzleti interfész (más néven helyi / távoli nézet) valósítja meg, vagy közvetlenül olyan osztályokon keresztül, amelyek nem valósítanak meg semmilyen felületet (nem nézeti interfészek).

Érdemes megjegyezni, hogy a helyi üzleti interfészeket akkor használják, amikor a babot ugyanazon környezetben, azaz ugyanazon EAR vagy WAR fájlban élő ügyfelektől fogják elérni, míg távoli üzleti interfészekre akkor van szükség, amikor a babot más környezetből fogják elérni , azaz egy másik JVM vagy alkalmazásszerver.

Hozzunk létre egy alapvető EJB modult, amely csak egy babból fog állni. A bab üzleti logikája egyértelmű lesz, csak egy adott konvertálására korlátozódik Húr nagybetűs változatához.

2.1. Távoli üzleti felület meghatározása

Először határozzunk meg egyetlen távoli üzleti felületet, amelyet a @Távoli annotáció. Ez az EJB 3.x specifikáció szerint kötelező, mivel a babot távoli kliensről fogják elérni:

@Remote public interface TextProcessorRemote {String processText (String text); }

2.2. Hontalan bab meghatározása

Ezután valósítsuk meg az üzleti logikát a fent említett távoli interfész megvalósításával:

@Stateless public class TextProcessorBean implementálja a TextProcessorRemote {public String processText (String text) {return text.toUpperCase (); }}

A TextProcessorBean osztály egy egyszerű Java osztály, amelyet a @ Állam nélküli annotáció.

A hontalan babok definíció szerint nem tartanak fenn semmiféle beszélgetési állapotot az ügyfelekkel, még akkor sem, ha képesek fenntartani a példányállapotot különböző kérések során. Párjuk, az állapottartalmú bab megőrzi társalgási állapotukat, és például drágább létrehozni az alkalmazáskiszolgáló számára.

Mivel ebben az esetben a fenti osztálynak nincs példányállapota, hontalanná tehető. Abban az esetben, ha van állapota, egyáltalán nem lenne értelme használni a különböző ügyfélkérelmekben.

A bab viselkedése determinisztikus, vagyis nincs mellékhatása, ahogy egy jól megtervezett babnak lennie kell: csak egy bemenetre van szükség Húr és visszaadja annak nagybetűs változatát.

2.3. Maven-függőségek

Ezután hozzá kell adnunk a javaee-api Maven-artefaktum a modulhoz, amely az összes Java EE 7 specifikációs API-t biztosítja, beleértve az EJB-khez szükségeseket is:

 javax javaee-api 7.0 biztosított 

Ezen a ponton sikerült létrehoznunk egy alapvető, mégis funkcionális EJB modult. Ahhoz, hogy elérhetővé váljon az összes potenciális ügyfél számára, JAR fájlként hozzá kell adnunk a tárgyat a helyi Maven-tárunkhoz.

2.4. Az EJB modul telepítése a helyi adattárba

Ennek elérésére több módszer létezik. A legegyszerűbb a Maven életciklusának végrehajtása tiszta - telepíteni építési fázisok:

mvn tiszta telepítés

Ez a parancs az EJB modult aszerint telepíti ejbmodule-1.0.jar (vagy bármely tetszőleges tárgyi azonosító, amelyet a pom.xml fájl) a helyi adattárunkba. A helyi JAR telepítésével kapcsolatos további információkért tekintse meg ezt a cikket.

Feltéve, hogy az EJB modult helyesen telepítették a helyi adattárunkba, a következő lépés egy távoli kliens alkalmazás kifejlesztése, amely kihasználja a TextProcessorBean API.

3. Távoli EJB kliens

Rendkívül egyszerűvé tesszük a távoli EJB kliens üzleti logikáját: először JNDI keresést hajt végre, hogy TextProcessorBean meghatalmazott. Ezt követően meghívja a meghatalmazottakat processText () módszer.

3.1. Maven-függőségek

Az EJB kliensnek a várakozásoknak megfelelően működnie kell a következő Maven-tárgyakat:

 javax javaee-api 7.0 biztosított org.wildfly wildfly-ejb-client-bom 10.1.0.Final com.beldung.ejbmodule ejbmodule 1.0 

Bár elég nyilvánvaló, miért vesszük bele a javaee-api műtárgy, felvétele wildfly-ejb-client-bom nem. A műtárgy szükséges a távoli EJB invokációk végrehajtásához a WildFly-n.

Végül, de nem utolsósorban az előző EJB modult elérhetővé kell tennünk az ügyfél számára, ezért adtuk hozzá a ejbmodul függőség is.

3.2. EJB kliensosztály

Figyelembe véve, hogy az EJB kliens meghívja a TextProcessorBean, nagyon pragmatikusak leszünk, és megnevezzük az ügyfélosztályt TextApplication:

public class TextApplication {public static void main (String [] args) dobja a NamingException {TextProcessorRemote textProcessor = EJBFactory .createTextProcessorBeanFromJNDI ("ejb:"); System.out.print (textProcessor.processText ("minta szöveg")); } private static class EJBFactory {private static TextProcessorRemote createTextProcessorBeanFromJNDI (String namespace) dobja a NamingException {return lookupTextProcessorBean (névtér); } private static TextProcessorRemote lookupTextProcessorBean (String névtér) dobja a NamingException {Context ctx = createInitialContext (); Karakterlánc appName = ""; String moduleName = "EJBModule"; Karakterlánc különNév = ""; String beanName = TextProcessorBean.class.getSimpleName (); String viewClassName = TextProcessorRemote.class.getName (); return (TextProcessorRemote) ctx.lookup (névtér + alkalmazásnév + "/" + modulnév + "/" + különállóNév + "/" + babnév + "!" + viewClassName); } private static Context createInitialContext () dobja a NamingException {Properties jndiProperties = new Properties (); jndiProperties.put (Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); jndiProperties.put (Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); jndiProperties.put (Context.PROVIDER_URL, "http-távoli: // localhost: 8080"); jndiProperties.put ("jboss.naming.client.ejb.context", igaz); return new InitialContext (jndiProperties); }}}

Egyszerűen fogalmazva, mindaz TextApplicationAz osztály megcsinálja a bab proxyt és meghívja processText () módszer mintasztringgel.

A tényleges keresést a beágyazott osztály végzi EJBFactory, amely először létrehoz egy JNDI-t InitialContext példányt, majd továbbítja a szükséges JNDI paramétereket a konstruktornak, és végül felhasználja a babproxy megkeresésére.

Figyelje meg, hogy a keresést a WildFly saját „ejb:” névterének használatával hajtják végre. Ez optimalizálja a keresési folyamatot, mivel az ügyfél mindaddig elhalasztja a kapcsolatot a kiszolgálóval, amíg a proxyt kifejezetten meg nem hívják.

Érdemes megjegyezni azt is, hogy a babproxy keresése anélkül lehetséges, hogy egyáltalán igénybe vennénk az „ejb” névteret. Azonban, hiányozna a lusta hálózati kapcsolatok minden további előnye, így az ügyfél sokkal kevésbé lesz teljesítő.

3.3. Az EJB kontextus beállítása

Az ügyfélnek tudnia kell, hogy melyik gazdagéppel és porttal létesítsen kapcsolatot a babkeresés végrehajtásához. Ilyen mértékben az ügyfélnek meg kell szabnia a WildFly EJB saját környezetét, amelyet a jboss-ejb-kliens.tulajdonságok fájl osztályútjába helyezik, általában a src / main / resources mappa:

endpoint.name = kliens-végpont remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED = hamis remote.connections = alapértelmezett remote.connection.default.host = 127.0.0.1 remote.connection.default.port = 8080 remote .connection.default.connect.options.org.xnio.Options .SASL_POLICY_NOANONYMOUS = hamis remote.connection.default.username = felhasználónevem remote.connection.default.password = saját jelszó

A fájl meglehetősen magától értetődő, mivel megadja az összes paramétert, amely a WildFly-hez való kapcsolódáshoz szükséges, beleértve a távoli kapcsolatok alapértelmezett számát, az alapértelmezett gazdagépet és portot, valamint a felhasználói hitelesítő adatokat. Ebben az esetben a kapcsolat nincs titkosítva, de akkor lehet, ha az SSL engedélyezve van.

Az utolsó, amit figyelembe kell venni, az az ha a kapcsolat hitelesítést igényel, hozzá kell adni egy felhasználót a WildFly-hez a add-user.sh/add-user.bat hasznosság.

4. Következtetés

Az EJB-keresések végrehajtása a WildFly-n egyszerű, mindaddig, amíg szigorúan betartjuk a vázolt folyamatot.

Szokás szerint a cikkben szereplő összes példa elérhető a GitHubon itt és itt.