EJB and CHAIMS Dorothea Beringer Enterprise Java Beans

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

EJBs versus Java Beans June 1999 EJB 2

EJB framework coded (extending EJB interfaces and classes) generated at deployment time C l i e n t P r o g r a m A: home interface A: Home Object A: remote interface A: EJB Object B: home interface B: Home Object B: remote interface B: EJB Object RMI or CORBA or IIOP or HTTP or … June 1999 EJB server and container creates calls Deployment Descriptor Transaction Naming Persistence creates Bean A (EJB Instance) Bean B (EJB Instance) other beans or (other) databases or remote services or … EJB 3

Session Beans: Interfaces and Instance Chaims. Megamodule extends EJBHome {interface} Wrapper implements Session. Bean {class} • EJBMeta. Data get. EJBMeta. Data() • void remove (Handle h) • void remove (Object key) • void ejbcreate (String mmname) • void ejb. Activate() • void ejb. Passivate() • void ejb. Remove() • void set. Session. Context (…) • Chaims. Connection create (String megamodulename) • … GETPARAM (…) • … SETPARAM (…) • … ESTIMATE (…) • … INVOKE (…) • … EXAMINE(…) • … EXTRACT (…) • … TERMINATEALL () is home interface, is home to all connections to all megamodules residing in this EJB server, better name is Chaims. Connection. Home is bean instance, one instance per connection, implement all important methods SETUP is replaced by create() June 1999 EJB 4

Session Beans: Interfaces and Instance Chaims. Connection extends EJBObject {interface} Wrapper implements Session. Bean {class} • EJBHome get. EJBHome() • Object get. Primary. Key() • Handle get. Handle() • void remove() • boolean is. Identical(EJBObject o) • void ejbcreate (String mmname) • void ejb. Activate() • void ejb. Passivate() • void ejb. Remove() • void set. Session. Context (…) • … GETPARAM (…) • … SETPARAM (…) • … ESTIMATE (…) • … INVOKE (…) • … EXAMINE(…) • … EXTRACT (…) • … TERMINATEALL () is remote interface, handles all connections to all megamodules June 1999 is bean instance, one instance per connection, implement all important methods EJB 5

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 EJB 6

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 EJB 7

Session Beans <==> Entity Beans June 1999 EJB 8

Session Beans <==> Entity Beans client 1 client 2 June 1999 Session Bean A instance 1 Session Bean A instance 2 Entity Bean Order order 1 order 4 Database Entity Bean Order order 2 order 5 Entity Bean Order order 3 order 6 EJB 9

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 ejb. Passivate() and ejb. Activate() to inform bean before and after it is swapped out of memory and written to disk • Persistence management: » defined in deployment descriptor » using ejb. Load() and ejb. Stroe() 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 objectrelational 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 EJB 10

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 Session. Synchronization interface in order to be informed about transaction begin and commit (methods after. Begin(), before. Completion(), after. Completion(boolean rollback_or_commit) » all beans get set. Roll. Back. Only() 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 User. Transaction 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 EJB 11

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 EJB 12

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 EJB 13

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. Web. Logic, 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 EJB 14

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 create(megamdodulenam) client 1 INVOKE(find. Hotel) database access for find. Hotel INVOKE(get. Prices) Session Bean database access for get. Prices INVOKE(book) June 1999 Connection for Megamodule database access for book Book. Hotel EJB Entity Beans 15

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 create() Session Bean SETUP(Book. Flight) Megaprogram. SETUP(Book. Hotel) session client 1 June 1999 INVOKE(find. Flight, …) get. Prices book find. Hotel get. Prices book create() Session Bean Connection for Megamodule Book. Flight Entity Beans Session Bean Connection for Megamodule Book. Hotel EJB 16

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 EJB 17

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

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 EJB 19

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 June 1999 EJB 20