Transcript Gen

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.
Other Java EE –
teknologies and EJB
• 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
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 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