Container Managed Persistent in EJB 2.0

Transcription

1 Container Managed Persistent in EJB 2.0 A comprehensive explanation of the new CMP in EJB 2.0 (PFD 2) using the RI of SUN By Raphael Parree 2001 IT-DreamTeam

2 Table of Contents INTRODUCTION 3 CMP IMPLEMENTATION BASICS 3 The provider 3 Writing the Bean class 4 The Interfaces 5 The Deployment Descriptor 6 The Deployer 9 Using the Deploytool 10 The XML file 12 Deployment 12 CONTAINER MANAGED RELATIONSHIPS 13 One to One and One-to-Many 14 Providing 14 Deploying 22 SELECT METHODS 23 HOME METHODS 26 CONCLUSION 27 2

3 Container managed persistence in EJB 2.0 Introduction This document describes how CMP Entity Beans are defined (provider s, assembler s and deployer s viewpoint, as well as tool support). CMP in EJB 2.0 has changed drastically as this document will show you. This document is intended for those who are familiar with the EJB 1.1 specification. CMP implementation basics The provider In the EJB 2.0 (pfd 1) spec, a new framework element was added. In previous EJB specs, the container was responsible for all the system level services (security, persistence, resources, etc.). According to the EJB 2.0 PFD 1 the container moved the responsibility of persistence to the Persistent Manager. The Persistent Manager was intended to be a separate component in the EJB framework. However in the EJB 2.0 pfd 2 the persistent manager has been removed and the persistence remains the responsibility of the Container. The persistent implementation of the container doesn t work in mysterious ways; it simply extends your entity beans. The EJBObject and HomeObject (or container) act as wrapper/factory to the bean instances. This way they intercept all calls and can perform system level services. These wrapper classes remain the same in the EJB 2.0 specification, keeping security, life cycle, and transactions part of the Container. The functionality for persistency is handled by the subclasses of your bean. In order to enable the above pattern to the framework, the bean implementation class must conform to new rules. To further enable the PM part of the Container to do its work, changes have also been made to the Deployment Descriptors (DD). In this section changes for writing a minimal CMP entity bean is explained. Changes are separated for the provider and the deployer. The Bean provider is responsible for providing the classes that make up the Component and create the initial DD. When using the EJB2.0 spec, this will mean a little more work, which is explained in the sections to come. 3

4 Writing the Bean class As depicted above, the container will extend parts of our bean; these parts are defined as abstract in our bean implementation classes. The parts that need to be abstract are all methods that access the persistent state of our bean. For now that means all the CMP fields (later CMR is discussed). The CMP fields are not defined in the Bean (as they where defined as public field variables in the previous spec). Instead the bean provided must declare abstract get and set methods for the persistent state of the bean: minimal.employeebean.java public abstract class EmployeeBean implements javax.ejb.entitybean { // EntityBean interface implementation public void ejbremove(){ public void ejbactivate() { public void ejbpassivate() { public void ejbload() { public void ejbstore() { public void unsetentitycontext() { public void setentitycontext(entitycontext ctx) { // CMP fields public abstract String getfullname(); public abstract void setfullname(string newfullname); public abstract void set (string new ) ; public abstract String get (); public abstract String getid(); public abstract void setid(string id); The abstract class EmployeeBean will be extended at deployment time by the container (resulting with Sun s RI in a EmployeeBean_PM class). Affecting the persistent state of the bean is done via the abstract accessor methods. For example, when setting the primary key values in the ejbcreate() method: 4

5 minimal.employeebean.java public abstract class EmployeeBean implements javax.ejb.entitybean { // EntityBean interface implementation // CMP fields // Methods resulting from the Home interface public String ejbcreate(string id) throws CreateException{ setid(id); return null; public void ejbpostcreate(string id){ The ejbcreate method has the same semantics as in the EJB1.x specification, with the following implementation differences: 1) The ejbcreate method must indicate to throw the javax.ejb.createexception. 2) The ejbcreate method changes the persistent state through the CMP accessor method The Interfaces In general the interfaces are defined before the bean class, but within this I would like to illustrate the difference in the provider s view and the client s view of the bean. In the previous section the bean implementation was shown, with the abstract CMP implementations. Many EJB developers used to expose the get and set methods of an Entity Bean in the remote interface. This makes a bean very fine grained and in many cases more an Object than a Component. The EJB2.0 spec still allows you to expose the get and set methods in the remote interface. The new spec, however, promotes providers to expose Business Services instead of data access methods. It was (or is) a common practice to place certain business rules (mainly validation) in the set methods of beans. However the set (and get) methods are now defined as abstract, and can hold no code to validate values specified by the caller. For now we will expose the get and set methods defined in the bean (except for setid, which is the primary key): 5

6 minimal.employee.java public interface Employee extends javax.ejb.ejbobject { // Get and set methods public String getfullname() throws RemoteException; public void setfullname(string newfullname) throws RemoteException; public void set (string new ) throws RemoteException; public String get () throws RemoteException; public String getid() throws RemoteException; // Business services added later The Home interface still has the role of factory, with one additional function. The Home interface can now also define home methods, which are explained later. The create methods in the Home interface can have different names, as long as they start with create (createsalesemployee, createhourlyemployee, createwithname, etc). minimal.employeehome.java public interface EmployeeHome extends javax.ejb.ejbhome { // Factory methods public Employee create(string id) throws CreateException, RemoteException; public Employee findbyprimarykey(string id) throws FinderException, RemoteException; public Collection findbyname(string fullname) throws FinderException, RemoteException; // Home methods will be added later The Deployment Descriptor The DD shown in the example below is the same as in the EJB1.1 spec (with the exception of the DTD reference). 6

7 ejb-jar.xml <?xml version="1.0" encoding="cp1252"?> <!DOCTYPE ejb-jar ' <ejb-jar> <description> EJB JAR for CMP 2.0 </description> <display-name> MinimalEmpBeans </display-name> <enterprise-beans> <entity> <description>employeebean with minimal CMP functionality</description> <display-name>minimalemployeebean</display-name> <ejb-name>minimalemployeebean</ejb-name> <home>com.itdt.paper.cmpejb20.employee.minimal.employeehome</home> <remote>com.itdt.paper.cmpejb20.employee.minimal.employee</remote> <ejb-class>com.itdt.paper.cmpejb20.employee.minimal.employeebean</ejb-class> </entity> <enterprise-beans> <assembly-descriptor> <container-transaction> <method> <ejb-name>minimalemployeebean</ejb-name> <method-name>*</method-name> </method> <trans-attribute>required</trans-attribute> </container-transaction> </assembly-descriptor> <ejb-jar> Within the EJB2.0 spec the EJB1.1 persistence management must be still supported. This means that your existing ejb-jar files can still be used in the new version of your vendor s Application Server (or container). DD elements have been defined to indicate the use CMP 2.0 style (so the default is the EJB1.1 version). 7

8 ejb-jar.xml <?xml version="1.0" encoding="cp1252"?> <!DOCTYPE ejb-jar ' <ejb-jar> <enterprise-beans> <entity> <cmp-version>2.x</cmp-version> <abstract-schema-name>employeeschema</abstract-schema-name> <cmp-field> <description>company of the employee</description> <field-name> </field-name> </cmp-field> <cmp-field> <description>full name of the employee (first last)</description> <field-name>fullname</field-name> </cmp-field> <cmp-field> <description>company Employee ID</description> <field-name>id</field-name> </cmp-field> <primkey-field>id</primkey-field> </entity> <enterprise-beans> <ejb-jar> The cmp-version indicates which version is used for the persistent management of the Bean. The abstract-schema will be used later, when defining the query language for the finder and select methods. The query language is one of the remarkable enhancements since the EJB1.1 spec. An EJB QL (Enterprise Java Beans Query Language) has been defined to define the query for finders (and later select methods). This makes your ejb-jar files more portable. 8

9 ejb-jar.xml <?xml version="1.0" encoding="cp1252"?> <!DOCTYPE ejb-jar ' <ejb-jar> <description>no description</description> <display-name>empbeansapril</display-name> <enterprise-beans> <entity> <query> <description> Finder to retrieve employees by there exact fullname </description> <query-method> <method-name>findbyname</method-name> <method-params> <method-param>java.lang.string</method-param> </method-params> </query-method> <ejb-ql>from EmployeeSchema as e where e.fullname=?1</ejb-ql> </query> <query> <description>standard PK finder method</description> <query-method> <method-name>findbyprimarykey</method-name> <method-params> <method-param>java.lang.string</method-param> </method-params> </query-method> <ejb-ql/> </query> </entity> <enterprise-beans> <ejb-jar> The Deployer Only finder methods other than findbyprimarykey need a EJBQL specified in the DD. In the example above the EJBQL for findbyname is specified as: from EmployeeSchema as e where e.fullname=?1 EmployeeSchema is the abstract-schema-name specified for the EmployeeBean.fullName is one of the CMP fields specified. Arguments of the finder methods are specified by?n, where n is the argument number (from left to right, and specified in the methods-params element). More on EJBQL later. The deployer will need to use the tools of the vendor to generate the wrapper classes and PM implementation classes of the Bean. The persistence storage of the CMP bean can be a database, ERP systems or others. In this document we will explore the persistent mapping of the 9

10 Reference Implementation (J2EE1.3 beta). This PM can synchronize the transactional state of the bean with an RDBMS, in a similar way as in the previous version. Mapping the CMP fields to persistent storage columns is still vendor specific. (The Persistent managers as an additional EJB component was removed from the PFD 2 for the EJB 2.0 spec). The PM capabilities of the container in the RI, needs a sun-j2ee-xml file with the SQL statements for all the methods (store, load, create, remove, finders and select methods). The easiest way create the initial DDs is to use the deploytool (generate SQL). Using the Deploytool Within the RI of SUN, a Datasource needs to be configured on the server. In the previous version, you had to change one of the configuration files. With the new release the Deploytool has an option to configure the server (Tools Server Configuration) Datasources (and other resources) can also be configured using the command line tool j2eeadmin: c:\>j2eeadmin -addjdbcdatasource jdbc/emp jdbc:cloudscape:rmi:emp;create=true Specifying the CMP version and CMP fields has been done by the provider and results in: 10

11 The deployer can then specify the finder/select methods: To indicate the datasource and generate the SQL, deployment settings must be used: 11

12 The XML file Below the RI specific XML file is displayed, which was generated with the deployment tool. Only the important information is shown below. ejb-jar.xml <j2ee-ri-specific-information> <server-name></server-name> <rolemapping /> <enterprise-beans> <module-name>minimalemp.jar</module-name> <unique-id>0</unique-id> <ejb> <ejb-name>minimalemployeebean</ejb-name> <jndi-name>cmp20/emp/minimal</jndi-name> <ior-security-config> </ior-security-config> </ejb20-cmp></ejb20-cmp> </ejb> <cmpresource> <ds-jndi-name>jdbc/emp</ds-jndi-name> <default-resource-principal> <name>none</name> <password>none</password> </default-resource-principal> </cmpresource> <finder-table-base-name> _1</finder-table-base-name> </enterprise-beans> </j2ee-ri-specific-information> The enterprise-beans element holds the different ejb s from a specific module. As shown, the MinimalEmployeeBean has an external JNDI name of cmp/emp/minimal, which is used by the client(s) to retrieve the HomeObject of this bean. Within the <ejb20-cmp> all the generated SQL statements are specified (not shown for size reasons). The mapping to the actual datasource is done in the <cmp-resource> element. The jdbc/emp is a registered datasource within the J2EE server. Deployment When deploying, the server will generate the necessary classes. In the drawing below the architectural role each plays in the framework is illustrated. 12

13 Figure 1 The Relationship between different classes Stub EmployeeHome_Stub Employee Home EmployeeHomeImpl_Tie HomeObject EmployeeHomeImpl Bean Abstract implementation Employee Stub Employee_Stub Employee EmployeeBean_PM_EJBObjectImpl_Tie EJBObject EmployeeBean_PM_EJBObjectImpl PM EmployeeBean_PM State EmployeeBean_PMState The two IIOP-Stubs are enabling the IIOP-communication from the client. The Servants (the two tie implementations) have as targets the HomeObject implementation and the EJBObject implementation respectively. The EJBObject acts as a wrapper to the bean. So far not much has changed since the previous release of EJB (on CORBA enabled servers). The largest difference lies in the bean. In the EJB1.1 spec, the bean is an instance of your class. As we have seen during the providing phase, the EmployeeBean is abstract. The implementation is handled by the container (class EmployeeBean_PM) which is wrapped by the EJBObject. The EmployeeBean_PMState holds the actual values of the Employee ( , fullname, etc) with a status flag of the current condition of this state. When a client invokes a business method on the stub (getfullname), a marshaled remote call to the tie is eventually handled by the EJBObject. The EJBObject can do the system level services needed (get out of the pool, check security, start a transaction, ). The EJBObject will hand over the invocation to the PM implementation. Container Managed Relationships Entity Beans are related to each other, Examples are: Order to OrderItems (one-to-many) Employee in role of manager to Department manages (one-to-one) Employee in role of works on to project staffed by (many to many) 13

14 These relationships can be unidirectional or bi-directional. When programming these relationships in EJB1.1 you needed to do all the work yourself. You might have used master-finders (findbyorderid on OrderItems), or detailgetters (getallorderlines on Order), or you might have used a Session Bean to do the work for you. In the EJB2.0 spec, these relationships can be declared and managed by the vendor. Within this section CMR between beans is explained, in a later section we will notice that these relationships can also exist between beans, using a finer grained approach (local interfaces). The relationships are defined in the Deployment Descriptor as one-to-one, one-to-many and many-to-many. The provider will also specify the direction of the relationship: unidirectional of bi-directional. A bi-directional relationship can be navigated both ways, whereas a uni-directional relationship can be navigated from one way. The container s implementation will handle these relationships, respecting the cardinality. The following scenario will illustrate this. When a one-to-many relationship has been defined between an employee (in role of manager) and projects, and employee John is manager on project ACME. Setting Jennifer as manager to the project ACME will take John of the manager position of the project (keep in mind that eventually database row(s) are created, in this case the record(s) that makes the relationship between John and ACME is deleted). The container considers the fact that the employee side of the relationships has a cardinality of one. The fact that Jennifer was already managing project X is of no importance for the project side of the relationship is many. The definition of Relationships can also include the lifecycle of the to-role in terms of cascaded deletes. When the relationship between an Order and Orderline has cascaded deletes enabled, the OrderLines will be deleted when the Order is deleted. (When the relationship is bi-directional and the relationship between the OrderLine and Order also has cascaded delete enabled, deleting the OrderLine will result in deleting the Order). One to One and One-to-Many Providing Two relationship are illustrated. One bi-directional relation between employees and department (many employees work at one department) and one unidirectional relation between an employee and one department (one employee is manager of one department). 14

15 Figure 2 UML Diagram for relationships between Employee and Department The UML diagram shows the associations between the Beans. The works at relationship (between one department and many employees) is bi-directional. Employee has department get and set methods, the department has getstaff, addemployee and removeemployee. The managed by relationship is unidirectional (unidirectional for illustration purposes, in a real system you probably want to be able to navigate both ways) and has get- and setmanager on the department bean. To use the code from the previous example (EmployeeBean) inheritance is used (as shown in the diagram). These relationships can be completely handled by the container by using Container Managed Relationships (CMR). The provider only has to program abstract methods, which will be implemented by the container, and define the relationship in the Deployment descriptor. The Employee The UML diagram (Figure 2) only shows the remote interfaces, the code is shown below: 15

16 cmr.one.employee.java public interface Employee extends com.itdt.paper.cmpejb20.employee.minimal.employee{ public Department getdepartment() throws RemoteException; public void setdepartment(department dep) throws RemoteException; The Employee remote interface extends the Employee remote interface from the example shown on page 6. The CMR version only extends the remote interface with a get and set method for the Department. The Home interface didn t change, so the EmployeeHome from page 6 isused. The bean class extends the EmployeeBean from page 6. cmr.one.employeebean.java public abstract class EmployeeBean extends com.itdt.paper.cmpejb20.employee.minimal.employeebean implements javax.ejb.entitybean { public abstract Department getdepartment(); public abstract void setdepartment(department dep); The specialization is limited to the CMR-fields. CMR fields must be declared as abstract (the same as with CMP fields). Because the relationship managed by is unidirectional, we don t define a CMR fields on Employee for this relationship but only for Works at. CMR Fields must conform to the following: They must be declared as get and set methods They must be declared as public abstract The return type is either the Remote interface of the associated bean or one of the collection interfaces (java.util.collection or java.util.set) In this case the relationship methods return the Remote reference of Department (It is one Department). This is also why we are able to expose these methods in the remote interface. Keep in mind that exposing these CMR fields is a coincidence. The published interface of a component (in this case home and remote interfaces) is defined before the internal structure will be designed. There is a clear separation between the client view and the persistent view. The Department The code for remote interface of the Department bean as illustrated in Figure 2, is listed below: 16

17 cmr.one.department.java public interface Department extends EJBObject{ public String getdeptno() throws RemoteException; public String getname() throws RemoteException; public void setname(string name) throws RemoteException; public Employee getmanager() throws RemoteException; public void setmanager(employee manager) throws RemoteException; public Set getstaff() throws RemoteException; public void addemployee(employee emp) throws RemoteException; public void removeemployee(employee emp) throws RemoteException; The first three methods (getdeptno, getname and setname) are regular methods; exposed CMP fields. The getmanager and setmanager are exposed CMR fields (keep in mind the coincidence note made earlier. The CMP and CMR names of the methods within the bean could or should be different, in order to separate client view from persistent view.) Because the employees (the staff) are many, we are unable to expose the persistent view of the bean. The home interface is familiar; nothing is different from the previous EJB spec apart from home-methods, which are not used in this example. cmr.one.department.java public interface DepartmentHome extends EJBHome{ public Department create(string deptno) throws RemoteException, CreateException; public Department findbyprimarykey(string deptno) throws RemoteException, FinderException; The first listing of the DepartmentBean shows the create-related methods and the CMP fields: 17

18 cmr.one.departmentbean.java (1) public abstract class DepartmentBean implements EntityBean{ //Home interface implementation public String ejbcreate(string deptno) throws CreateException{ setdeptno(deptno); return null; public void ejbpostcreate(string deptno) { //CMP declaration public abstract String getdeptno(); public abstract void setdeptno(string deptno); public abstract String getname(); public abstract void setname(string name); So far nothing new under the Sun. The CMP fields are declared as abstract (the same as illustrated with the EmployeeBean in the first chapter). The CMR methods for the manager resemble the CMR of the EmployeeBean: cmr.one.departmentbean.java (2) public abstract class DepartmentBean implements EntityBean{ //CMR declaration for the Employee in role of Manager public abstract Employee getmanager(); public abstract void setmanager(employee manager); The employees working at this department are many, meaning that the CMR fields must be of a Collection type. cmr.one.departmentbean.java (3) public abstract class DepartmentBean implements EntityBean{ //CMR declaration for the Employees at this department public abstract Set getemployees(); public abstract void setemployees(set employees); In this example the java.util.set is used (an Employee will never work twice at the same department). These CMR methods are not exposed in the remote interface of the bean. The first reason is (and actual reason) is to keep the client s view separated from the internal persistent view of the bean. The second reason (and more technician) has to do with the distributed behavior of beans. If the bean would expose these CMR methods in the remote interface, the client would be able to use the collection methods (add, remove etc). Adding an employee in the returned collection within the client would either mean that the client works on a copy or by reference. By reference is not an option, because the Collection has no distributed behavior. Working on a copy wouldn t change the underlying persistent state of the Department 18

19 (and related Employee). The implementation of the collection interfaces in the Reference Implementation do not implement Serializable, so trying to expose CMR fields would result in a invalid RMI-IIOP argument type. As we saw in the UML diagram (Figure 2), the employee related methods are addemployee, removeemployee and getstaff. The implementation of these methods use the methods of the collection interface: cmr.one.departmentbean.java (4) public abstract class DepartmentBean implements EntityBean{ public void addemployee(employee emp){ Set col = getemployees(); Iterator i = col.iterator(); col.add(emp); public void removeemployee(employee emp){ Set col = getemployees(); col.remove(emp); public Set getstaff() { Set emps = getemployees(); HashSet staff=new HashSet(); staff.addall(emps); return staff; The addemployee and removeemployee methods, use the add and remove methods of the java.util.set interface. These methods first retrieve the persistent state of the employee relationship, after which the java.util.set methods can be used. The cardinality of the relationship is maintained by the operation of the collection interfaces (as explainer earlier). The getstaff methods returns a serialized copy of the persistent view (HashSet implements the java.io.serializable interface) The Deployment Descriptor The skeleton of the ejb-jar file is shown in the first lising of the Deployment Descriptor: 19

20 ejb-jar.xml (1) <ejb-jar> <description>ejb JAR for CMP 2.0 </description> <display-name>employeedepartment</display-name> <enterprise-beans> <entity> <ejb-name>cmremployeebean</ejb-name> </entity> <entity> <ejb-name>cmrdepartmentbean</ejb-name> </entity> </enterprise-beans> <relationships> </relationships> <assembly-descriptor> </assembly-descriptor> </ejb-jar> We will focus on the <relationships> element. Within this element two <ejbrelation> elements will be defined, one for the employees and a department and one for the manager of a department. Each <ejb-relation> will have two roles defined in a <ejb-relationship-role> element, one for the start and one for the end part of the relation. The relationship for all the employees of a department is made up of the two roles CMREmployee and CMRDepartment: 20

21 ejb-jar.xml (2) <ejb-relation> <description>employees at Department</description> <ejb-relation-name/> <ejb-relationship-role> <description>employee works at Department </description> <ejb-relationship-role-name>cmremployeebean</ejb-relationship-role-name> <multiplicity>many</multiplicity> <role-source> <ejb-name>cmremployeebean</ejb-name> </role-source> <cmr-field> <cmr-field-name>department</cmr-field-name> </cmr-field> </ejb-relationship-role> <ejb-relationship-role> <description> Department has many Employees </description> <ejb-relationship-role-name>no Name</ejb-relationship-role-name> <multiplicity>one</multiplicity> <role-source> <ejb-name>cmrdepartmentbean</ejb-name> </role-source> <cmr-field> <cmr-field-name>employees</cmr-field-name> <cmr-field-type>java.util.set</cmr-field-type> </cmr-field> </ejb-relationship-role> </ejb-relation> The first role Employee works at Department operates on the CMREmployeeBean and has CMR-field department to enable the relationship. The multiplicity is declared as many, because this role is the many part of the relationship. The second role in the relation is CMRDepartment, which is on the one side of the relationship. The CMR field is employees. Because this field referrers to many employees we need to specify which collection interface is used in the code (java.util.set). The relationship Manager of a Department is a unidirectional one-to-one relationship between a Department and an Employee. 21

22 ejb-jar.xml (3) <ejb-relation> <description>manager of a department</description> <ejb-relation-name/> <ejb-relationship-role> <description> Department is managed by employee</description> <ejb-relationship-role-name>cmrdepartmentbean</ejb-relationship-role-name> <multiplicity>one</multiplicity> <role-source> <ejb-name>cmrdepartmentbean</ejb-name> </role-source> <cmr-field> <cmr-field-name>manager</cmr-field-name> </cmr-field> </ejb-relationship-role> <ejb-relationship-role> <description>employee is manager of department </description> <ejb-relationship-role-name>no Name</ejb-relationship-role-name> <multiplicity>one</multiplicity> <role-source> <ejb-name>cmremployeebean</ejb-name> </role-source> </ejb-relationship-role> </ejb-relation> The first role in this relationship is Department is managed by employee operates on the CMRDepartmentBean which has a CMR field manager. The second role is the the CMREmployeeBean, which has a multiplicity of one. Because this is a unidirectional relationship, no CMR field in specified on the CMREmployeeBean. Deploying When the deployer picks up the ear file created by the provider, he or she needs to map the beans and the relationships to the actual database. Besides the mapping of the bean to a storage layer, the RI generated a Dependent Object for the one-to-many relation Employee works at Department. Dependent objects are removed from the PFD 2 spec, so in the new version this will be handled different. The j2sdkee is made conforming the PFD 1 spec of EJB 2.0, so how this is done in the new version is unknown to me at this time. Most likely they will use local home interfaces and as a component interface a local as well. 22

23 Figure 3 Table Digram EmployeeBeanTable id fullname _reverse_manager_deptno CMRE mployeebean_depart ment_cmrdepart ment Bean CMRE mployeebean_id CMRDepart mentbean_deptno De part me ntbeantable deptno name _manager_id Figure 3 shows the tables generated by the RI tool. The table CMREmployeeBean_department_CMRDepartmentBean (which could be abbreviated by the tool) belongs to a Dependent Object that joins the Department with Employee. Remember that Dependent objects are remove and my comment earlier on the implementation strategy applies here as well. If you are working with existing tables, a mapping needs to be made in the sun-j2ee-ri.xml file (or use the deploytool). Select methods Select methods are another new feature that made its introduction in the EJB 2.0 specification. In previous versions of EJB, the home interface has finder method(s). These methods run when the bean is pooled and return remote references to EJBObjects. The finder methods reside in the client s view of the bean. Select methods are similar to finder methods, with the largest exception that the select methods are only used from within the bean itself and are never exposed in the component interfaces. Select methods can return references to anything that is in the abstract schema of the bean (CMP and CMR). A select method can be invoked when a bean is in the ready state or when the bean is pooled. It depends from where the select method is invoked. If the select method is invoked from within a home method, the select method runs in the pooled state, when the select method is invoked from a business method it is called with the ready state. A bean declares a select method following the rules below: it must prefix ejbselect It must be declared as public abstract it must indicate to throw FinderException 23

24 The return type is any valid CMP-field or EJBObject(s)/EJBLocalObject(s) or one of the collection interfaces when more than one is object is returned The ejbselect method has an associated EJBQL in order for the container to generate the implementation. In the following example a business method is added to the Department bean. The remote interface and the bean will have an additional method: sendnewsline: cmr.one.department.java public interface Department implements EJBObject{ public void sendnewsline(string newsline) throws RemoteException; The implementation of the sendnewline, will send an to all the employees of the department it is invoked on. For this an ejbselect method will be added to the bean: cmr.one.departmentbean.java(1) public abstract class DepartmentBean implements EntityBean{ public abstract Set ejbselectall s(string deptno) throws FinderException; One of the parameters of the ejbselect method is the deptno, this is because select methods do not operate on the identity of the bean it is invoked from. This way we could also send an to all employees that are not part of the department. The select method returns a Set, this also means that the keyword DISTINCT will be used when making the query. The returned set will contain addresses of the employees. The implementation of the business method is listed below: 24

25 cmr.one.departmentbean.java(2) public abstract class DepartmentBean implements EntityBean{ public void sendnewsline(string newsline) { try{ Set s = ejbselectall s(getdeptno()); Iterator i = s.iterator(); System.out.println("Sending to"); while (i.hasnext()){ String address = (String)i.next(); System.out.println("CC " + address); System.out.println("Content " + newsline); catch(finderexception fe){ System.out.println("Unable to send s: " + fe.getmessage); The code just prints to the System.out that an will be send, This is done for illustration purposes. (note: This would be a good point to use a MessageDrivenBean to send out a message to start sending s, this way the system doesn t have to wait for the routine to be ready.) The Deployment Descriptor must include an EJBQL for the select method: ejb-jar.xml <entity> <ejb-name>cmrdepartmentbean</ejb-name> <query> <description>no description</description> <query-method> <method-name>ejbselectall s</method-name> <method-params> <method-param>java.lang.string</method-param> </method-params> </query-method> <ejb-ql>select e. FROM DepartmentSchema AS d, e IN d.employees where d.deptno=?1</ejb-ql> </query> </entity> The EJBQL for the select method, selects the from employees that are in the CMR employees of department. Notice also that the where clause, where we filter on deptno (because a select method doesn t use the identity of the bean by default). 25

26 Home methods The last new feature in the EJB 2.0 spec that is covered in this article are Home methods. Home interfaces, so far, have factory methods. Client s can use the home interface to create and find beans. The HomeObject has no identity, and is a singleton within a container (sometimes it is the container). The Home interface could than also provide business methods that are not restricted to a single bean. The EJB 2.0 spec added this functionality to the Home Interface. Business methods can be added, that work on the type for which this type is a factory. It is like a static in Java and C++, these methods work on the class (=type) and through that works on all the instances of a certain class. A home method, just like the finder method, is execute in the pooled state: Figure 4 Home method invocation Free pool Client 1. foo(i) Home Object 2. ejbhomefoo(i) Bean Bean The client invokes the home method on the HomeObject, which will invoke an ejbhomexxx method on a bean in the pool. Because the home method is invoked in the pooled state, the implementation must not access the CMP or CMR fields, it is however possible to talk to the Database. In case of a CMP bean, only select methods can be used to communicate with the persistent layer. To illustrate home methods, an example will be show with a method getdepartmentnames in the home interface: 26

27 cmr.one.departmenthome.java public interface DepartmentHome extends EJBHome{ public Set getdepartmentnames() throws RemoteException; The provider must implement the home methods. The method must be declared as ejbhomexxx (public and not static). cmr.one.departmentbean.java public abstract class DepartmentBean implements EntityBean{ public abstract Set ejbselectallnames() throws FinderException; public Set ejbhomegetdepartmentnames() { try{ Set depnames = ejbselectallnames(); HashSet s = new HashSet(); s.addall(depnames); return s; catch(finderexception fe){ System.out.println("Cannot retrieve department names " + fe.getmessage()); return null; The home method is declared as ejbhomegetdepartmentnames and uses a new select method ejbselectallnames. The EJBQL for this select method is declared in the ejb-jar.xml as: SELECT d.name FROM DepartmentSchema AS d The client can now get all the department names without using the overhead of the non-read-only behavior of EntityBeans. Before you had to use a findall method and, on the returned EJBObject, invoke getname. This would result in 1+n select statements to the database where n=the number of beans found, plus n update statements before n transactions are committed (from a nontransactional client). Conclusion During the development of this document the PFD 2 was released. Initially this document used the PFD 1 of the EJB 2.0 spec. The Persistent Managers, which was mentioned in the PFD 1, didn t make it to the PFD 2. Also Dependent Objects where eliminated from the new release of the spec. Dependent objects where a means to further design the internals of the bean (see the PFD 1 release of EJB 2.0). I saw many problems with this approach, and am pleased that Dependent Objects have been removed. Similar functionality can be obtained by using the new Local interfaces. This enables beans to communicate in a much finer grained way, eliminating the overhead of distribution. 27

28 The fact that the Persistent Managers have been removed makes me less cheerful. The PM would make CMP Entity beans much more portable. A PM would have been a separate product that hooks into the EJB container. It is my belief that a future release of EJB will have this architecture. A lot has been done to achieve more portability and interoperability. Very important is the RMI/IIOP standard and the EJB QL. CMR makes using CMP Entity beans a lot easier. This has a good side and a bad side. I have always been reluctant to use Entity Beans for performance reasons. With the introduction of CMR more people will hesitate to start using Entity beans. The major reason (in my opinion) for using Entity Beans lies in faster development. Using CMR will expand this reason, resulting in even faster development time. It will also expand the configurability of the system, which is another important reason to use Entity Beans. For me, the home methods can greatly increase the performance for systems that used this functionality with EntityBeans. So for those people that where already using Entity Beans: life has become better. For those that where not using it: stick to the reasons you had for not choosing Entity Beans. 28