Enterprise Java Beans 3 0 What is EJB

Enterprise Java. Beans 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.

Other Java EE –teknologies and EJB • Sun renamed J 2 EE to Java EE from version 5. 0 (also J 2 SE -> 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

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

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 Entity. Beans in 3. 0 –standard • Other beans can use entities freely to get persistence services

Relation. Ship of App. Server, Services and Beans

Persistence • EJB 3. 0 uses new persistence concept : entities • 3. 0 also supports Entity. Beans defined in previous EJB -standard version • Main motivation for new concept was performance issues with Entity. Beans • 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