June 1999 EJB1 EJB and CHAIMS Dorothea Beringer Enterprise Java Beans and how to build a CHAIMS infrastructure using the EJB paradigm

June 1999 EJB2 EJBs versus Java Beans

June 1999 EJB3 EJB framework EJB server and container Bean B (EJB Instance) A: home interface A: remote interface B: home interface B: remote interface A:Home Object A: EJB Object B: Home Object B: EJB Object Bean A (EJB Instance) creates calls creates Transaction Naming Persistence Deployment Descriptor ClientProgramClientProgram RMI or CORBA or IIOP or HTTP or … other beans or (other) databases or remote services or … coded (extending EJB interfaces and classes) generated at deployment time

June 1999 EJB4 Session Beans: Interfaces and Instance ChaimsMegamodule extends EJBHome {interface} EJBMetaData getEJBMetaData() void remove (Handle h) void remove (Object key) ChaimsConnection create (String megamodulename) is home interface, is home to all connections to all megamodules residing in this EJB server, better name is ChaimsConnectionHome Wrapper implements SessionBean {class} void ejbcreate (String mmname) void ejbActivate() void ejbPassivate() void ejbRemove() void setSessionContext (…) … GETPARAM (…) … SETPARAM (…) … ESTIMATE (…) … INVOKE (…) … EXAMINE(…) … EXTRACT (…) … TERMINATE (…) … TERMINATEALL () is bean instance, one instance per connection, implement all important methods SETUP is replaced by create()

June 1999 EJB5 Session Beans: Interfaces and Instance Wrapper implements SessionBean {class} void ejbcreate (String mmname) void ejbActivate() void ejbPassivate() void ejbRemove() void setSessionContext (…) … GETPARAM (…) … SETPARAM (…) … ESTIMATE (…) … INVOKE (…) … EXAMINE(…) … EXTRACT (…) … TERMINATE (…) … TERMINATEALL () is bean instance, one instance per connection, implement all important methods ChaimsConnection extends EJBObject {interface} EJBHome getEJBHome() Object getPrimaryKey() Handle getHandle() void remove() boolean isIdentical(EJBObject o) … GETPARAM (…) … SETPARAM (…) … ESTIMATE (…) … INVOKE (…) … EXAMINE(…) … EXTRACT (…) … TERMINATE (…) … TERMINATEALL () is remote interface, handles all connections to all megamodules

June 1999 EJB6 Deployment Descriptor (1) Describes for each bean: »names of all classes and interfaces involved, name for JNDI »ACL »environment properties »stateless / stateful (only session beans) »session timeout (only session beans) »list of container managed fields (only entity beans) »primary key class names for finder methods (only entity beans) Describes for each method: »transaction attributes: - TX_NOT_SUPPORTED (existing transactions are suspended) - TX_SUPPORTS, TX_REQUIRES_NEW, TX_MANDATORY - TX_REQUIRED (transaction context needed, either new or existing one) - TX_BEAN_MANAGED (bean demarks its own transaction boundaries) »transaction isolation level

June 1999 EJB7 Deployment Descriptor (2) ==> describing instead of programming (similarities to aspect-oriented programming?) ==> framework has control, bean provider and deployer just provide plug-ins Packaging of beans: All files inclusive deployment descriptor are put in a jar file by bean provider with a manifest just containing the name of the deployment descriptor. Deployment descriptor provides the full description of all the files in the jar that together define the enterprise bean. This jar file is acquired by deployer and read by server.

June 1999 EJB8 Session Beans Entity Beans

June 1999 EJB9 Entity Bean Order order 4 Entity Bean Order order 5 Entity Bean Order order 6 Session Beans Entity Beans Session Bean A instance 1 client 1 Session Bean A instance 2 client 2 Entity Bean Order order 1 Entity Bean Order order 2 Entity Bean Order order 3 Database

June 1999 EJB10 Tasks of the EJB Framework (1) The server/container are responsible for: Managing beans »creation, initialization, removal of beans »offering JNDI naming service Resource management: »e.g. swapping stateful session beans and entity beans: uses ejbPassivate() and ejbActivate() to inform bean before and after it is swapped out of memory and written to disk Persistence management: »defined in deployment descriptor »using ejbLoad() and ejbStroe() to inform entity bean about start of transaction or commit »1) server loads and stores (container managed persistence), entity beans created by mapping defined in deployment descriptor (fields to columns) or automatically generated by special tool for object-relational mapping ==> no programming of load and store »2) bean loads and stores data itself (bean managed persistence) and server only handles locks on underlying database

June 1999 EJB11 Tasks of the EJB Framework (2) Transaction Management »1) automatic transaction management: the EJB server/container maintains the transactions on behalf of the beans, beans just describe how they participate in transactions in deployment descriptor ==> no programming of transactions »for entity beans and stateless session beans: participation in transaction is all implicit »for stateful session beans: can implement SessionSynchronization interface in order to be informed about transaction begin and commit (methods afterBegin(), beforeCompletion(), afterCompletion(boolean rollback_or_commit) »all beans get setRollBackOnly() method through their EJBcontext for requesting rollback of the transaction they participate in »2) bean and client managed transactions: the bean or the client calls methods of JTS (interface UserTransaction contains methods for begin(), rollback(), commit(); transaction attribute set to TX_BEAN_MANAGED for all methods, this makes sure bean gets reference of JTS in its EJBContext) Distributed Transaction Support

June 1999 EJB12 Tasks of the EJB Framework (3) Integration with databases »beans not allowed to communicate directly with database concerning transactions, this has to be done by server Interfaces to CORBA, http, and other access protocols »generation of all necessary stubs and skeletons Security services Scalability ==> services are transparent to beans provider as well as client program writers (higher level as in CORBA yet OTS compliant)

June 1999 EJB13 Portability A note about portability: »enterprise beans are portable across servers from different vendors »legacy code has to be changed in order to be used in beans (e.g. changing all transaction related things, no autocommit, no commit or rollback by the bean on the connection to the database) »EJB-server requires special JDBC drivers for databases (for transaction management) »how portable is client code? slight differences in how to get home object over JNDI? differences in access over http or CORBA?

June 1999 EJB14 Roles in EJB Development EJB Developer »writes business objects as enterprise beans for specific problem domain, sells these business objects »defines certain deployment requirements (e.g. concerning transaction control, security, environment properties) and makes first version of deployment descriptor EJB Server vendor »develops and sells an EJB server (e.g. WebLogic, Oracle) EJB Deployer »enhances and fills out deployment descriptor (e.g. ACLs, databases used, access protocols, external names of bean) »takes enterprise beans and installs them into a specific EJB server installation which reads deployment descriptor and installs bean in name space Application developer »writes business application using services of business objects

June 1999 EJB15 EJB’s and CHAIMS (1) Difference in access: »client has remote reference of both, home-object and bean, SETUP replaced by create(mmname) »client sends messages directly to an object that represents one connection, instead of to a megamodule object that dispatches it to a connection object Advantages of EJB’s: »automatic transaction control within one connection, simpler / alternative implementation for megamodules, connection level based transaction control has not to be coded by megamodule provider Session Bean Connection for Megamodule BookHotel client 1 INVOKE(findHotel) INVOKE(getPrices) INVOKE(book) database access for findHotel database access for getPrices database access for book Entity Beans create(megamdodulenam)

June 1999 EJB16 EJB’s and CHAIMS (2) Automatic transaction control across several connections?: »split up setup into contacting EJB server (create on a session bean that encompasses all connections from same client to all megamodules of that server, only once per megaprogram) and setting up connection to megamodule (create on a connection session bean) »allows having different parameter sets for different megamodules (instead of merging all megamodules of same server in one) while still having transaction control across these megamodules client 1 findHotel getPrices book Entity Beans INVOKE(findFlight, …) getPrices book Session Bean Connection for Megamodule BookHotel Session Bean Megaprogram- session create() Session Bean Connection for Megamodule BookFlight create() SETUP(BookFlight) SETUP(BookHotel)

June 1999 EJB17 EJB’s and CHAIMS (3) Transaction control across whole megaprogram?: »use JTS in client program (client demarcated transactions), let the rest of the transaction management be done by the EJB servers »requires that EJB server supports client demarcated transactions all megamodules are implemented in such EJB servers

June 1999 EJB18 Components versus Frameworks If applications are hard to design, and toolkits are harder, then frameworks are hardest of all!

June 1999 EJB19 Customization of Frameworks Special methods (presetting of properties) additional parameters in methods external description in text files as in deployment descriptor setting of properties in other kind of tools at development/composition time at using/execution time

June 1999 EJB20 Challenges in Developing Frameworks (and Components) Architecture / design of framework »three application rule »second design rule »consistency in environment and basic requirements »ROI Complexity ease of use and maintenance »framework designer: cover all cases »application developer: ease of use »how much customizability? »guessing future requirements and isolating necessary changes