Web Applications through Components

Alessio Bechini June 2002

The Evolution of Frameworks

The evolution of web servers, application servers and frameworks as seen in 1999:

Products Sold by Publicly Trade Companies

• • • • • • • • • • • • • •

WebSphere and Domino Application Servers (IBM Corporation) iPlanet/Netscape Application Server (AOL/Netscape/Sun) NetDynamics 5.0 (Sun MicroSystems) Oracle Application Server (Oracle Corporation) BEA WebLogic Server 5.1 (BEA Systems) WebObjects (Apple Computer, Inc.) Inprise Application Server (Inprise Corporation) Sybase Enterprise Application Server 3.0 (Sybase Corporation) Persistence PowerTier for EJB (Persistence Software) Progress Apptivity 3.0 (Progress Software) Dynamo Application Server (Art Technology Group) SilverStream (SilverStream Software) Iona IPortal (Iona Technologies) Unify eWave Engine (Unify Corporation)

Products Sold by Other Companies

• • • • • • • • • • • •

Sapphire/Web (Bluestone Software) Versata Logic Server (Versata, Inc.) HahtSite (Haht Corporation) Novera jBusiness (Novera Software) Gemstone/J 3.0 (Gemstone Systems) Parlay Application Integration Server (Information Builders) Secant Extreme Enterprise EJB Server (Secant Technologies) Proton EJB Server (Pramati Technologies) Ejipt EJB Application Server (Valto Systems) Prosyst Enterprise Beans Server (Prosyst Software GmBH) Orion Application Server (Orion) Voyager Application Server (ObjectSpace)

Open Source Products

• • • • • • •

Enhydra Java Application Server- (Lutris Technologies) Locomotive Application Server- (Leverage Information Systems) Voyager Application Server (ObjectSpace) JOnAS: JavaTM Open Application Server- (BullSoft) The EJBoss server- (EJBoss) Apache JServ Servlet engine Jakarta Tomcat - a reference implementation for servlets and JSP

EJB Goals (I)

The

EJB Spec

tries to meet several goals at once: • EJB is designed to help developers to create applications, freeing them from low-level system details of managing transactions, threads, load balancing, and so on.

Developers can concentrate on business logic and leave

the details of managing the data processing to

the framework. For specialized applications, though, it's always possible to customize these lower-level services.

• The

EJB Spec

defines the major structures of the EJB framework, and then specifically

defines the contracts between them.

The responsibilities of the client, the server, and the individual components are all clearly spelled out. A developer creating an EJB component has

a very different role

from someone creating an EJB-compliant server, and the spec describes the responsibilities of each.

EJB Goals (II)

• EJB aims to be the standard way for client/server applications to be built in the Java language. Just as JavaBeans (or whatever components) from different vendors can be combined to produce a custom client, EJB server components from different vendors can be combined to produce a custom server. EJB components will of course run in any EJB-compliant server without recompilation. • Finally, the EJB is compatible with and uses other Java APIs, can interoperate with non-Java applications, and is compatible with CORBA.

How an EJB System Works

To understand how an EJB client/server system operates, we need to understand the basic parts of an EJB system: • the EJB component • the EJB container • the EJB object.

The EJB Component

An Enterprise JavaBean is a component.

EJBs execute within an

EJB container,

which in turn executes within an server.

EJB server.

Any server that can host an EJB container and provide it with the necessary services can be an EJB An EJB component is a Java class, written by an EJB developer, that implements business logic. All the other classes in the EJB system either support client access to or provide services (like persistence, etc.) to EJB component classes.

The EJB Container

The EJB container is where the EJB component "lives." The EJB container provides services such as

transaction and resource management, versioning, scalability, mobility,

persistence,

and security

to the EJB components it contains. Since the EJB container handles all of these functions, the EJB component developer can concentrate on business rules, and leave database manipulation and other such fine details to the container. Multiple EJB component instances typically exist inside a single EJB container.

The EJB Object and the Component Interface

Client programs execute methods on remote EJBs by way of an

EJB object.

The EJB object implements the component interface" of the EJB component on the server. The C.I. represents the "business" methods of the EJB component. An

EJB component

and implements the business logic. The

EJB object

runs on the server in an EJB container runs on the client and remotely executes the EJB component's methods.

EJB Clients

An EJB client is an object that interacts with an enterprise bean; in other words, a bean must undertake a given activity upon a request from a client.

Such an interaction does not involve any instance of the EJB class, but it takes place by means of the

component interface

of the EJB.

In EJB 2.0 there are two types of component interfaces: • Remote • Local (introduced in EJB 2.0)

Local vs. Remote Clients

• Local clients are always placed on the same Java Virtual Machine that handles the enterprise bean.

• The direct coupling of an enterprise bean with a local client yields a number of disadvantages, because of the lack of location transparency.

• The usage of local clients is mainly motivated by performance issues • Remote clients are placed on a different Java Virtual Machine, respect to the enterprise bean.

• There is no direct coupling of an enterprise bean with a remote client: the location transparency is achieved.

• The remote client does not know, and does not care about the actual physical position of the enterprise bean.

Accessing EJBs by Component Interfaces

If the EJB is accessed by local clients, its component interface must extend javax.ejb.EJBLoc alObject If the EJB is accessed by remote clients, its component interface must extend javax.ejb.EJBObject

The bean class doesn’t actually implement its own component interface, but it must contain the same operating methods defined in the component interface.

To get the object that implements the C.I., we can use either javax.ejb.SessionContext

or javax.ejb.EntityConext

, depending on the bean type.

Use of the Home Interface

A client can invoke a method of the C.I. once it has obtained a reference to an object that implements such an interface.

The component in charge of creating C.I. instances is the bean

Home Interface

.

An Home Interface must be provided for each enterprise bean in the application.

The home interface defines methods to allow clients to create, find, and remove EJB objects.

The H.I. must extend either javax.ejb.EJBLocalHome

javax.ejb.EJBHome

, depending on the bean type or

The Container & the Home Interface

As for the C.I, the container creates an object that implements the bean home interface.

The home object is aimed at behaving like a factory for creating objects that implements the component interface.

An home interface manages the lifecycle of all the instances (it has created) of a certain EJB.

For local and remote clients two different “home factories” are used.

Types of Enterprise JavaBeans

There are three different types of beans: • Session beans – Stateful session beans – Stateless session beans • Entity beans • Message-driven beans

Goals for a Server Component Technology

The fundamental goal of a server component technology is this: How do you go about creating a server whose methods are extensible at runtime?

How can someone, for example, buy an accounting package, drop it into a running server, and use the client software that came with the package to access the server functionality, all

without even shutting the server down ,

much less recompiling it?

Conclusion: Extensible application servers realized

The answer that Enterprise JavaBeans provides is to create the client in terms of component interfaces. These component interfaces are implemented on the client as remote method invocations, and the very same interface is implemented on the server side as domain functionality. The EJB server uses JNDI to publish the availability of these services. The client uses JNDI to locate a new class's home interface by name, and then uses the home interface to create objects with the remote interface that provides the service.

This late-binding between available interfaces on a server and the interface names is what makes an EJB server runtime-extensible.