Download Gen

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
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