Middleware Technology (Part VIII, Enterprise Java Beans)

Middleware Technology (Part VIII, Enterprise Java Beans) Andrei Popovici Information and Communication Systems Research Group Department of Computer S...
0 downloads 4 Views 369KB Size
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()

ejb/beans/myBeanH CounterHome ...

(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: container

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:

doReservation required

ο

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