Enterprise JavaBeans 3.0

What is EJB 3.0 -Reusable server-side component framework-technology -Designed to support building demanding enterprise – level solutions -EJB –standard defines many commonplace infrastructure services (a.k.a. Quality of Services, QOS ) -QOS’s are rendered to components hosted by Application Server (AS) -AS also provides running environment for EJB’s (along with QOS’s) -Frees application developers from re-inventing the wheel (in buggy way) and from many system level programming challenges, eg. Threading.

Sun renamed J2EE to Java EE from version 5.0 (also J2SE -> Java SE from version 6.0) EJB uses a lot of other existing Java - teknologies Most importants: JNDI, RMI, JMS, JTA, JDBC, Java persistence, JAAS Other Java EE – teknologies and EJB

How EJB works Copyright Sriganesh, Brose, Silverman in Mastering EJB 3.0 Picture 1 : Calling EJB Picture 2 : Various beans and clients

Different EJB 3.0 bean types Stateless bean is default choice always when program does not need to remember the state of the client conversation. All info into stateless bean via parameters (or bean retrieves info eg. from DB) Stateless bean example : Credit card verification component or video stream compressor engine Statefull when program needs to remember the state of client conversation. Eg. Web-bank or web-shop

Different types of EJB 3.0 Message-Driven Bean supports MOM –concept by taking advantage of JMS -standard Entities are not Beans, but are replacing the former EntityBeans in 3.0 –standard Other beans can use entities freely to get persistence services

RelationShip of AppServer, Services and Beans

Persistence EJB 3.0 uses new persistence concept : entities 3.0 also supports EntityBeans defined in previous EJB -standard version Main motivation for new concept was performance issues with EntityBeans Entities are defined in Java SE unifying persistence interfaces and programming Java Persistence is based on Plain Old Java Objects (POJO)

Transactions Transaction support is key part of EJB Programmer may choose (as with many services) explicit or implicit (declarative) transactions EJB’s can also be part of client-controlled transaction Support is based on Java Transaction Api (JTA)

Security Security support is another key part of EJB Programmer may choose (as with many services) explicit or implicit (declarative) security Support is based on Java Authentication and Authorization Service (JAAS) Place for security–info may vary, eg. DB, files, specific third-party software To protect data during transfer uses other standards, eg. SSL/TSL

Timer service Timer service may be used to automate clean up tasks Bean may run any kind of code when called back by timer service Not applicable for real-time operations Statefull beans and entities cannot register into service

Messaging service Message-Driven Beans uses JMS –standard to support MOM –concept JMS defines two interfaces : message-interface and messaging provider -interface Bean Container will call MDB when message arrives Supports both messaging –styles : point-to-point and puslish/subscribe

Java EE Connector Architecture Service to connect into legacy systems in a standard way Defines many interfaces that programmer may / may not implement Requires a specific resource –adapter for legacy system that implements the interfaces Supports eg, incoming/outgoing transactions, security, threading,…

Clustering EJB –standard does not define clustering -service but every major Application Server implements it some way Lack of standard leads into vendor-specific solutions Typical solution is to use ”smart stubs” which requires vendor specific compiling tools and couples the code into vendor Clustering is a common solution to get better performing and more robust service

Conclusion EJB is a good choice when Remoting is required Distributed transactions are required Security is required Persistence is required Integration with legacy apps is required Scalability is required Otherwise EJB may be overkill