Download Middleware Technology (Part VIII, Enterprise Java Beans)

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
Middleware Technology
(Part VIII, Enterprise Java
Beans)
Andrei Popovici
Information and Communication Systems
Research Group
Department of Computer Science
ETH Zürich
[email protected]
http://www.inf.ethz.ch/department/IS/iks/
Outline
ο
ο
ο
ο
ο
ο
EJB fundamentals: beans and containers
Containers
Beans
• session beans
• entity beans
Example
EJB Internals:
⇒ Persistence
⇒ Pooling
⇒ Transactions
Conclusions and Outlook
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
2
The EJB Component Model
Ahead towards the ideal middleware system:
ο
portability
⇒ Java
⇒ components: pure application logic
ο Interoperability
⇒ components have hooks to cooperate with the
environment (container)
• EJB API and coding conventions
ο Integration
⇒ Naming services
⇒ Data Persistence
⇒ Transactions
⇒ Authentication & Authorization
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
3
EJB: Beans and Containers
Two main concepts dominate the EJB paradigm:
ο Beans: fit together in a standard way
⇒ contain pure application logic and hooks
ο
clients
ο
ο
CONTAINER
CONTAINER
Java Virtual Machine
ο
ο
Containers = middleware
know how to communicate with the
beans and with the clients
know how to create and destroy
beans
implement services developers don’t
want to worry about
all messages go through the
container
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
4
Containers
ο
A bean container is the server
application on which the bean
code runs.
⇒ container vendors: IBM,
SUN, Oracle
ο The container interposes itself
between the client and the bean.
Server Host
ο
Before a bean is able to live in a container, it
has to be adapted to a specific container.
This process is called deployment.
ο Deployment is vendor specific...
The client triggers the creation of beans inside the container,
but does not directly access the methods of the beans it has
created. Instead, the container exports a remote interface to
the client.
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
5
EJB: The Big Picture
Step 1: install bean
JNDI: ejb/beans/myBeanH
= bean code (app.logic)
Deployment
descriptor
= bean home, generated by the deployer,
published as jndi:ejb/beans/myBeanH
deploy bean
= the XML-formatted file created by
the deployer in which the type of
the bean, its name, etc.. are
specified
Deployment
descriptor
Step 2:
use bean
ask home for
bean instance
client
(create Bean)
use bean
CONTAINER
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
6
Beans and Clients
ο
Beans are (independent) business objects. Some examples:
⇒ The small software piece behind a web site counter
⇒ A currency converter
⇒ A shopping cart in a web store may be implemented by a
bean. The items inside may be other beans.
ο Scenarios:
⇒ The bean is not influenced by what the client did before
(e.g., currency converter)
• Stateless session bean
⇒ The bean is influenced by what the client did (e.g.,
shopping cart)
• Stateful session bean
⇒ The bean has to survive a server crash (e.g., web site
counter)
• Stateful, entity bean. All entity beans are stateful.
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
7
Bean Types
ο
Session Beans
⇒ are used by one client at a time
⇒ are lost in a server crash
⇒ Stateless: look the same to the client before and after the
operation
⇒ Stateful: persistence
ο Entity Beans
⇒ are the core business objects
⇒ represent shared data in a database
⇒ allow shared access from multiple clients
⇒ survive a server crash
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
8
Example: Web Counter
Page
ο
request
Developer:
app. logic
utility
EJBObject
EJBHome
EntityBean
container
Web server = client role
ο
Deployer:
(1) Counter.xml:
Counter
CounterHome
CounterBean
int click()
create()
ejbCreate()
int click()
<name>ejb/beans/myBeanH</name>
<home>CounterHome</home>
...
(2) bash$ deployejb counter.xml container
ο
Java client (code running in the web server):
counterHome=ctx.lookup(“jndi:ejb/beans/myBeanH”);
Counter c = counterHome.create();
ctx: JNDI Context
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
9
EJB and Persistence (1)
ο
Session beans have to use JDBC. Fortunately, beans do not
have to bother with the JDBC driver setup, which is the main
portability problem in Java applications which access a
database. Instead, the database (data source) is published in
the JNDI naming service. The beans just specify the SQL
command for retrieving the data from a database:
⇒ Example stateless session bean:
ejbCreate()
{
/* ask container for data source*/}
ejbRemove() { /* tell container we’re finished */ }
⇒ Example
(code from CounterBean.java)
stateful session bean:
ejbCreate() {..}
ejbRemove() {..}
ejbActivate() { /* similar to
ejbPassivate() { /* similar to
ejbCreate */ }
(code from CounterBean.java)
ejbRemove */}
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
10
EJB and Persistence (2)
ο
Entity beans usually correspond to a record in a relational database.
Therefore, it has a unique identifier which survives over time and over
client accesses: the primary key (PK). The bean developer must create a
special PK Java class.
ο Clients get references to entity beans by specifying the PK
ο The persistence of an entity bean may be:
⇒ bean managed (like in session beans, using JDBC). In this case, the
bean developer has to provide the proper code for storing and
retrieving the state of the bean (ejbLoad, ejbStore)
⇒ container managed: the container automatically stores in the
database all attributes of an entity bean instance. Container managed
persistence makes life easier (no SQL statements) for the developer.
The developer still has to implement some special methods.
ο What kind of persistence mechanisms the bean uses is specified in the
deployment descriptor:
<persistence-type>container</persistence-type>
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
11
EJB and Pooling
ο
If a container has many clients, it cannot afford to keep all
beans associated to the clients in the main memory.
Therefore
⇒ it reuses the stateless session beans living in the
container
⇒ it temporarily stores the data of a stateful session bean in
persistent storage (activation and passivation)
ο As a consequence, the developer of a bean has to implement
methods like ejbActivate, ejbPassivate, ejbCreate,
ejbRemove to react to the container’s decision about a bean.
ο On the other hand, the container has to consistently call
these methods every time it creates, destroys, or stores a
bean.
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
12
EJB and Transactions
ο
A business method implemented by a bean (e.g.
‘doReservation(hotel,flight)’ has to be executed atomically,
like a transaction
ο The deployer can specify this in the deployment
descriptor,like this:
<container-transaction>
<method>doReservation</method>
<trans-attribute>required</trans-attribute>
</container-transaction>
ο
The transaction management in EJB is based the JTA
(Java Transaction API)
ο The transaction management (like persistence) may be
⇒ implicit - container uses JTA, developer writes pure
application logic
⇒ explicit - developer writes JTA and JDBC code
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
13
Practical Considerations
ο
ο
ο
ο
ο
Shall I choose Corba or EJB?
⇒ Corba provides at least the same services as EJB.
⇒ EJB application is easier to write and deploy.
⇒ The EJB framework is complex.
Which container vendor shall I choose?
⇒ Sun’s specifications are ahead of the vendor’s
implementation.
Current trend: everybody is reshaping their applications
towards EJB
World Wide Web: Java Server Pages (JSP) or Servlets work
well together with EJB
Performance: Java is still slower its counterparts for WWW
⇒ however, EJB provides good scalability.
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
14
Conclusions and Outlook
ο
ο
ο
ο
ο
Enterprise Java Beans are easy to write
But the EJB architecture is complex and is closely tied to
other Java packages and specifications, like JNDI, JDBC,
JTA or RMI. A bean developer will have to understand them
as well.
By separating deployment and development, reusing of
beans becomes a reality. Most of the services needed by
such components can be transparently managed by the
container. The almost complete separation between services
and business logic is one of the main advantages of EJB.
SUN’s specifications are ahead of the products supplied by
container vendors.
EJB can be used in conjunction with other server-side java
technologies like servlets or Java Server Pages (JSP). That’s
why many E-commerce companies are shifting their products
towards EJB and Java-based www technologies.
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
15
Appendix: ContainerBean.java
Class CounterBean implements EntityBean {
public String counterId;
public int counterValue;
public CoutnerPK ejbCreate(String id, int cval) {..}
public ejbPostCreate(String id,int cval) {..}
public setEntityContext(EntityContext ctx) {..}
public unsetEntityContext() {..}
This Java class is an example of
about half the methods which
have to be implemented in
a
Bean. Sometimes, the methods
may be left empty, e.g., if the
persistence is containermanaged.
public void ejbActivate() {..}
public void ejbPassivate() {..}
public void ejbLoad() {..}
public void ejbStore() {..}
public void click() { }
public int getValue();
}
A. Popovici. Information and Communication Systems Research Group. ETH Zürich.
Part VIII - EJB
16