Disseny de la persistència Enterprise Java Beans Toni Navarrete Enginyeria del Software II – UPF 2003

Tutorial de J2EE de Sun Aquesta presentació està basada en bona part en el tutorial de J2EE v. 1.3 de Sun, que podeu baixar de: http://java.sun.com/j2ee/tutorial/download.html

EJB EJB=Enterprise Java Bean Escrit en Java, un EJB és un component de servidor que encapsula lògica de negoci d’una aplicació La lògica de negoci és el codi que satisfà els propòsits d’una aplicació Per exemple, en una aplicació de gestió d’inventaris, un ejb pot implementar la lògica de negoci amb mètodes anomenats controlarNivellInventari i ferComandaProducte Un altre exemple: mantenir un “carretó de la compra” Un EJB corre a un EJB-container, que és una part d’un servidor d’aplicacions

No confondre EJB amb Java Bean. EJB versus Java Bean No confondre EJB amb Java Bean. Un EJB és un "deployable component". El terme indica que existeix un ambient de execució. Aquest ambien és el EJB-container Un Java Bean ha d’estar integrat amb altres components per ser funcional

Arquitectura d’un servidor d’aplicacions Exemples: J2ee server (RI, només per desenvolupament) Tomcat (servlet engine) + Jboss (EJB-container) “Fully-J2EE-compliant”: WebLogic, Websphere, Jrun, Oracle 9i Application Server, Sun ONE Application Server

Tres tipus d’EJB Session EJBs Messaging EJBs Un Session EJB permet implementar una lògica concreta, sol·lictiada per un client (que pot ser un JSP/Servlet, un applet o altre EJB) N’hi ha que no guarden el seu estat (stateless session ejb), per exemple, un ejb que implementa una operació que no requereix guardar dades del client, com una cerca, i n’hi ha que sí (statefull session ejb), per exemple, un “carretó de la compra” Messaging EJBs Ofereixen funcionalitats de sistemes de missatgeria asíncrona No els estudiarem

Tres tipus d’EJB Entity EJBs Un Entity ejb, al contrari que un session ejb, treballa conjuntament amb un repositori persistent de dades (típicament una BD) Així, un entity ejb pot llegir i escriure informació externa al ejb-container (a una BD) Exemples: clients, comandes, productes... Típicament un entity ejb està mapejat amb una taula d’una BDR, i cada instància del bean es correspondrà amb una fila El ejb container dóna suport de pooling sense haver de programar-ho

Dos tipus de Entity EJB Bean Managed Persistence El propi EJB s’encarrega de definir la lògica per accedir (manipular i consultar) a la BD. És a dir, s’ha de programar manualment, típicament utilitzant JDBC per sota Container Managed Persistence El propi ejb-container és qui s’encarrega de definir la lògica per accedir a la BD Molt transparent! Aparentement, un “bean managed ejb” sempla que no té massa sentit, però hi ha casos en què la lògica d’accés és molt complexa i el ejb-container no ho “sap” manegar

Estructura d’un EJB Un EJB està format per una classe, dues interfaces i un fitxer de “deployment”, agrupats en un un fitxer jar Remote interface (Converter) Home interface (ConverterHome) El propi ejb (ConverterEJB o ConverterBean)

Remote interface La interfície remota defineix els mètodes de negoci que un client pot cridar. Els mètodes de negoci s’implementarien a la classe del ejb Extèn EJBObject Un exemple (d’un session ejb): import javax.ejb.EJBObject; import java.rmi.RemoteException; import java.math.*; public interface Converter extends EJBObject { public BigDecimal dollarToYen(BigDecimal dollars) throws RemoteException; public BigDecimal yenToEuro(BigDecimal yen) }

Home interface La interfície home defineix els mètodes que permeten a un client crear, trobar i eliminar un ejb Extèn EJBHome En l’exemple, conté només un mètode de creació, que retorna un objecte que implementa la interfície remota import java.io.Serializable; import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; public interface ConverterHome extends EJBHome { Converter create() throws RemoteException, CreateException; }

La classe ejb La classe ejb ha d’implementar els mètodes de negoci definits a la interfície Remote i els mètodes relacionats amb el cicle de vida (ejbCreate, ejbActivate...) Constructor sense arguments obligatori Extèn SessionBean o EntityBean Exemple: import java.rmi.RemoteException; import javax.ejb.SessionBean; import javax.ejb.SessionContext; import java.math.*; public class ConverterBean implements SessionBean { BigDecimal yenRate = new BigDecimal("121.6000"); BigDecimal euroRate = new BigDecimal("0.0077"); public BigDecimal dollarToYen(BigDecimal dollars) { BigDecimal result = dollars.multiply(yenRate); return result.setScale(2,BigDecimal.ROUND_UP); } public BigDecimal yenToEuro(BigDecimal yen) { BigDecimal result = yen.multiply(euroRate); public ConverterBean() {} public void ejbCreate() {} public void ejbRemove() {} public void ejbActivate() {} public void ejbPassivate() {} public void setSessionContext(SessionContext sc) {}

Una aplicació client (ConverterClient.java) S’ha de crear el naming context inicial, part de JNDI Context initial = new InitialContext(); Un naming context és un conjunt de bindings de noms a objectes. El context inicial és el punt de començament per fer la resolució de noms. Totes les operacions de noms són relatives a un determinat context. Ara obtenim el naming context de l’aplicació client Context myEnv = (Context)initial.lookup("java:comp/env"); I recuperem l’objecte lligat al nom ejb/SimpleConverter Object objref = myEnv.lookup("ejb/SimpleConverter");

Una aplicació client (ConverterClient.java) ejb/SimpleConverter és el nom lògic que fa referència a la interfície home d’un ejb, en el nostre cas de ConverterHome object Els noms dels ejbs han d’estar sembre en el subcontext java:com/env/ejb A partir de la referència obtenim un objecte ConverterHome (narrow the reference) ConverterHome home = (ConverterHome) PortableRemoteObject.narrow(objref, ConverterHome.class);

Una aplicació client (ConverterClient.java) Ara es crea la instància del ejb, cridant el mètode create definit a ConverterHome. Aquest mètode retorna un objecte de tipus Converter (que implementa la interfície remota Converter) i que recordem que té els mètodes de negoci als quals pot cridar el client Converter currencyConverter = home.create(); Ara ja es poden cridar els mètodes de negoci: BigDecimal param = new BigDecimal ("100.00"); BigDecimal amount = currencyConverter.dollarToYen(param);

Codi del client import javax.naming.Context; import javax.naming.InitialContext; import javax.rmi.PortableRemoteObject; import java.math.BigDecimal; public class ConverterClient { public static void main(String[] args) { try { Context initial = new InitialContext(); Object objref = initial.lookup ("java:comp/env/ejb/SimpleConverter"); ConverterHome home = (ConverterHome)PortableRemoteObject.narrow(objref, ConverterHome.class); Converter currencyConverter = home.create(); BigDecimal param = new BigDecimal ("100.00"); BigDecimal amount = currencyConverter.dollarToYen(param); System.out.println(amount); amount = currencyConverter.yenToEuro(param); System.exit(0); } catch (Exception ex) { System.err.println("Caught an unexpected exception!"); ex.printStackTrace(); } Codi del client

Codi del client index.jsp (1/2) <%@ page import="Converter,ConverterHome,javax.ejb.*, javax.naming.*, javax.rmi.PortableRemoteObject, java.rmi.RemoteException" %> <%! private Converter converter = null; public void jspInit() { try { InitialContext ic = new InitialContext(); Object objRef = ic.lookup("java:comp/env/ejb/TheConverter"); ConverterHome home = (ConverterHome)PortableRemoteObject.narrow(objRef, ConverterHome.class); converter = home.create(); } catch (RemoteException ex) { ... } %> <html> <head> <title>Converter</title> </head>

Codi del client index.jsp (2/2) <body bgcolor="white"> <h1><center>Converter</center></h1> <hr> <p>Enter an amount to convert:</p> <form method="get"> <input type="text" name="amount" size="25"> <br> <p> <input type="submit" value="Submit"> <input type="reset" value="Reset"> </form> <% String amount = request.getParameter("amount"); if ( amount != null && amount.length() > 0 ) { BigDecimal d = new BigDecimal (amount); %> <p><%= amount %> dollars are <%= converter.dollarToYen(d) %> Yen. <p><%= amount %> Yen are <%= converter.yenToEuro(d) %> Euro. } </body> </html>

Eina deploytool del J2EE RI Cal definir els bindings de noms JDNI Deployment Eina deploytool del J2EE RI Cal definir els bindings de noms JDNI ejb/SimpleConverter en l’aplicació client ejb/TheConverter en l’aplicació web Web contest: converter

Execució Cal posar en marxa el j2ee container: Fem el deploy Executem j2ee -verbose Fem el deploy Executem Client web http://127.0.0.1:8000/converter Aplicació client Set APPCPATH = ConverterAppClient.jar ConverterAppClient.jar s’obté en fer el deploy runclient -client ConverterApp.ear -name ConverterClient -textauth

Interfícies locals i interfícies remotes El que hem vist és quan el client remot hi accedeix Una altra possibilitat és que hi accedeixin objectes locals (de la mateixa JVM), s’utilitzen altres interfícies, tot i que són equivalents: LocalHome (LocalConverterHome) Local Interface (LocalConverter) De nou, Local defineix els mètodes de negoci i LocalHome els del cicle de vida i “finders” En cas de dubte: remot (es poden declarar les dues però no és gens comú) Cas particular: els ejb d’entitat que són container-managed i tenen relacions amb altres ejb, han de tenir interfaces locals i no remotes

Arquitectura de les EJB: Interfaces Well designed interfaces simplify the development and maintenance of J2EE applications. Not only do clean interfaces shield the clients from any complexities in the EJB tier, but they allow the beans to change internally without affecting the clients. For example, even if you change your entity beans from bean-managed to container-managed persistence, you won't have to alter the client code. But if you were to change the method definitions in the interfaces, then you might have to modify the client code as well. Therefore, to isolate your clients from possible changes in the beans, it is important that you design the interfaces carefully.

Remote vs local interfaces The decision on whether to allow local or remote access depends on the following factors: Container-Managed Relationships If an entity bean is the target of a container-managed relationship, it must use local access. Tight or Loose Coupling of Related Beans Tightly coupled beans depend on one another. For example, a completed sales order must have one or more line items, which cannot exist without the order to which they belong. The OrderEJB and LineItemEJB beans that model this relationship are tightly coupled. Tightly coupled beans are good candidates for local access. Since they fit together as a logical unit, they probably call each other often and would benefit from the increased performance that is possible with local access. Type of Client If an enterprise bean is accessed by J2EE application clients, then it should allow remote access. In a production environment, these clients almost always run on different machines than the J2EE server. If an enterprise bean's clients are web components or other enterprise beans, then the type of access depends on how you want to distribute your components. Component Distribution J2EE applications are scalable because their server-side components can be distributed across multiple machines. In a distributed application, for example, the web components may run on a different server than the enterprise beans they access. In this distributed scenario, the enterprise beans should allow remote access.

EJBs d’entitat Quan el client invoca un mètode create, el EJB container invoca el corresponent mètode ejbCreate. Típicament un mètode ejbCreate en un bean d’entitat fa les següents tasques: Inserta l’estat de l’entitat a la BD Inicialitza les variables d’instància Retorna la primary key

Mètodes finder Els mètodes finder permeten els clients localitzar beans d’entitat La classe ha d’implementar tots els mètodes de finder que s’hagin especificat a la interfície home ejbFindByPrimaryKey és obligatori d’implementar (els altres depenen de la lògica de negoci) Els mètodes finder sempre han de començar amb el prefix ejbFind i han de ser públics (i no poden ser ni finals ni estàtics) Retornaran o bé una primary key o bé una col·lecció de primary keys Exemple: public SavingsAccount findByPrimaryKey(String id) throws FinderException, RemoteException; public Collection findByLastName(String lastName) public Collection findInRange(BigDecimal low, BigDecimal high)

Mètodes de Home Un mètode home conté la lògica de negoci que s’aplica a tots els beans d’entitat d’una classe. En canvi, els mètodes de negoci s’apliquen a instàncies individuals, que tenen un id únic Típicament, un mètode home localitza una col·lecció d’instàncies bean i invoca mètodes de negoci a mesura que va iterant la col·lecció Estan declarats a la interfície home Sempre comencen pel prefix ejbHome, i sempre han de ser públics (i no poden ser estàtics)

Classe EJB Resumint, la classe EJB haurà d’implementar: Interfície EntityBean Zero o més mètodes ejbCreate i ejbPostCreate Mètodes finder methods Mètodes de negoci Mètodes de Home L’EJB invoca ejbPostCreate immediatament després de cridar ejbCreate. Així, a diferència d’ejbCreate, pot invocar els mètodes getPrimaryKey i getEJBObject de la interfície EntityContext El mètode ejbRemove provoca que s’esborri una instància del bean, i que s’elimini el seu estat de la BD

Life-cycle of an entity bean

Dos tipus d’EJB d’entitat BMP (Bean-Managed Persistence) La persistència es pot manegar directament pel propi bean, incloent la connexió a la BD i el codi SQL necessari Exemple SavingAccounts CMP (Container-Managed Persistence) Serà el container qui s’encarregarà de la persistència

CMP La classe bean ha de ser pública i abstracta La classe haurà d’implementar: La interfície EntityBean Zero o més mètodes ejbCreate i ejbPostCreate Els mètodes d’accés get i set, definits abstractes, per a tots els camps persistents i per als camps de relació La declaració dels mètodes de select, definint-los com a abstractes Els mètodes home Els mètodes de negoci Per tant, NO ha d’implementar: Els mètodes finder El mètode finalize

Diferències entre persistència manegada pel bean i pel container Difference Container-Managed Bean-Managed Class definition Abstract Not abstract Database access calls Generated by tools Coded by developers Persistent state Represented by virtual persistent fields Coded as instance variables Access methods for persistent and relationship fields Required None findByPrimaryKey method Handled by container Customized finder methods Handled by container, but the developer must define the EJB QL) queries Select methods Return value of ejbCreate Should be null Must be the primary key

Finds i selects Diferències entre finds i selects Son semblans, ja que tots dos serveixen per fer seleccions: Un mètode select retorna una interfície local o remota (o una col·lecció d’interfícies) Consulta la BD El descriptor de deployment especifica una consulta en EJB QL para cada método select La classe bean no implementa els mètodes select Però es diferencien en: Un mètode select pot retornar un camp persistent (o una col·lecció d’ells) d’un ejb d’entitat relacionat. Un mètode de finder només pot retornar una interfície local o remota (o una col·lecció d’elles) Els mètodes de select no s’exposen en cap interfície, amb la qual cosa no es poden invocar des dels clients, només es poden cridar des de dins del propi ejb, típicament des d’un altre mètode de negoci El mètode de select es defineix a la classe ejb. Els finder si BMP a la ejb, si CMP no.

EJB QL The Enterprise JavaBeans Query Language ("EJB QL") defines the queries for the finder and select methods of an entity bean with container-managed persistence. A subset of SQL92, EJB QL has extensions that allow navigation over the relationships defined in an entity bean's abstract schema. The scope of an EJB QL query spans the abstract schemas of related entity beans that are packaged in the same EJB JAR file You define EJB QL queries in the deployment descriptor of the entity bean. Typically, a tool will translate these queries into the target language of the underlying data store. Because of this translation, entity beans with container-managed persistence are portable (their code is not tied to a specific type of data store)

Exemple aplicació CMP

Passes per crear un ejb d’entitat CMP Engegar el container j2ee –verbose En l’exemple també usen la BD Cloudscape de la RI, que s’engega amb cloudscape -start Engegar l’eina de deployment deploytool Crear i compilar totes les classes i interfícies Declarar-les en l’eina de deployment Declarar l’esquema abstracte Especificar els camps persistents i les relacions (i els seus tipus) Configurar les entrades JDNDI (EJB refs) Deploy

Resum dels diferents Java Archives JAR (Java ARchives) JAR ("Java Archives") és un format desenvolupat per Sun que permet agrupar les classes Java per a la seva distribució. S’utilitza sovint en qualsevol “ambient” de Java, ja que redueix la càrrega d’administració degut a que només cal distribuïr un únic fitxer. També comprimeix (redueix temps de baixada) WAR (Web ARchives) WARS o "Web Archive" és una especificació de Sun que permet agrupar un conjunt de classes, servlets, JSPs, documents HTML,... que formen una aplicación web en Java Permet interoperabilitat entre diferents Application servers EJB-JAR (EJB Java ARchives) Un EJB-JAR és la manera en què és distribuïts un ejb (amb les seves interfaces) EAR (Enterprise ARchives) Un EAR simplement és un WAR i diversos EJB-JAR agrupats Es genera amb el deploytool del J2EE SDK