SYSTEM AND METHOD FOR ENTERPRISE JAVABEANS CONTAINER

Description

This application claims the priority of U.S. Provisional Patent Application No. 60/926,989, filed Apr. 30, 2007.

BACKGROUND

1. Field of Invention

The invention relates generally to enterprise application servers, and, more specifically, to implementing an Enterprise JavaBeans container within an enterprise application server.

2. Background

Application servers are platforms that host and provide services to applications. Application servers manage the life cycles of applications and ensure that the logic implemented in applications is accessible to clients in a centralized fashion. Application servers based on the Java™ Platform, Enterprise Edition 5 (hereinafter “Java EE”) host and provide services to Java enterprise applications (also referred to as “Java EE applications”) and are referred to as Java™ application servers. Java EE applications are written in the Java™ language and conform to a set of specifications so that they can run on a Java™ application server. Application server vendors develop application servers in accordance with the rules and requirements set forth in the Java™ EE 5 specification. A Java™ EE application has application code and configuration information packed into an Enterprise Application Archive (hereinafter “EAR”). The EAR contains one or more modules of a specific type, for example, web modules, web services modules, Enterprise JavaBeans™ (hereinafter “EJB”) modules, and deployment descriptors. Each module is hosted and serviced by a dedicated container on the server. For example, web modules are serviced by a web container, EJB modules are serviced by an EJB container, web services modules are serviced by a web services container, and so on. Each container is implemented according to a dedicated specification part of the Java™ family of enterprise technologies.

Java™ EE 5 provides a number of new features as compared to previous versions of the platform. For example, Java™ EE 5 includes a new version of the EJB specification, that is, EJB 3.0. The EJB 3.0 specification provides new features and sets forth new requirements for EJB containers. However, the specification does not prescribe how such requirements should be implemented by application server vendors. It is up to the application server vendor to decide how to implement all the requirements set forth in the specification so that the application server complies with the specification.

SUMMARY OF THE INVENTION

A system to run Enterprise JavaBeans is described. The system is implemented as a set of components. Each component provides certain functionality to run Enterprise JavaBeans. The components include a life cycle manager, a client views manager, a proxy invocation handler, an invocation chain manager, and an invocation context.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.

FIG. 1 is a block diagram of an Enterprise JavaBeans™ container implemented according to an embodiment of the invention;

FIG. 2 is a block diagram of an Enterprise JavaBeans™ runtime environment implemented according to an embodiment of the invention;

FIG. 3 is a flowchart of a process performed by an embodiment of the invention.

DETAILED DESCRIPTION

A system and method to implement an Enterprise JavaBeans™ container and runtime environment is described.

FIG. 1 is a block diagram of a system of an embodiment of the invention for implementing an Enterprise JavaBeans™ (EJB) container. The EJB Container 1000 is implemented as a set of components. Each component defines a set of interfaces to communicate with the other components. As used herein component generically refers to managers, applications, services, and Application Programming Interfaces (“APIs”). Referring to FIG. 1, the EJB container 1000 includes a client views manager 1100, a proxy invocation handler 1200, an invocation chains manager 1300, a lifecycle manager 1400, and a timeout manager 1500. The client views manager 1100 uses client view factory instances 1−n to create and destroy client view instances. Each client view factory instance is connected to the proxy invocation handler 1200. The proxy invocation handler 1200 passes client requests from clients such as the client 1050 to bean instances. For example, the client 1050 sends a request for a particular bean instance. The request is received at client view factory instance 1 and sent to the proxy invocation handler 1200. The proxy invocation handler 1200 sends the request to the invocation chains manager 1300. The invocation chains manager 1300 identifies an interceptor chain to service the request and associates it with an invocation context. The invocation context manages the lifecycle of the interceptor chain. An interceptor chain is a set of interceptors. Each interceptor is a class that implements specific functionality. In each chain, interceptors are grouped in a specific order and executed in that order so that the request is processed. The lifecycle manager 1400 is responsible for managing the lifecycle of bean instances. The timeout manager 1500 is responsible for managing timeout invocations.

Implementing the EJB container 1000 as a set of independent components has a number of benefits. First, having each component as an independent unit reduces maintenance time and effort. Each component is maintained separately and the maintenance of a single component does not affect the performance of the EJB container 1000. Second, the architecture of the EJB container 1000 facilitates extensibility because new implementations of components can be provided on top of existing ones. Also, new implementations can be switched on transparently, that is, without affecting the work of other components. Third, because components are independent and communicate only through interfaces, it is possible to provide several different implementations of a concrete component. These implementations can co-exist and service requests thus enabling the EJB container 1000 to handle any number of use cases required by clients. For example, the EJB container 1000 can have a number of client view implementations and each client view can serve a distinct task, such as aggregation, caching, performance optimizations, interoperability, isolation, and so on.

The functionality provided by the EJB container 1000 is implemented using interceptors. An interceptor is a class which implements specific functionality and contains source code corresponding to concrete EJB specification requirements. A sequence of concrete instances of interceptors is called an interceptor chain. The invocation chains manager 1300 monitors constructed chains. After an EJB application is initialized, each event that is received at the EJB container 1000 is assigned a chain of interceptors. The invocation chains manager 1300 assigns the chain of interceptors to perform the necessary task and associates the chain with an invocation context, as mentioned above. The invocation context controls the behavior of the interceptor chain. Each interceptor has the knowledge that it participates in a concrete chain and has access to its invocation context. At the time when the chain is executed to service a request or event, an interceptor associated with an invocation context can stop the execution, raise an error, or change the execution arguments. Also, an interceptor can introduce custom values to the invocation context and propagate them to application code or other interceptors. Using interceptors to provide the required functionality for the EJB container 1000 follows good development practices in terms of separating functionality into functional blocks (i.e. interceptors). Consequently, interceptors can be developed independently and the development and maintenance of an interceptor does not influence the work and performance of the EJB container 1000. Also, interceptor chains are not hard coded. This means that interceptor chains can be constructed dynamically to serve a specific scenario. Finally, to add or remove functionality to the EJB container 1000 the container provider simply implements a new interceptor or removes an existing interceptor, thus saving time and effort.

In some embodiments, to implement the required functionality, the EJB container 1000 provides some or all of the following interceptors outlined in the table below:

FIG. 2 is a block diagram of an EJB runtime environment provided by an embodiment of the invention. Referring to FIG. 2, the enterprise bean context 210 manages a bean instance 200 and all resources associated with the bean instance. As used herein, resources are understood to mean any number of system resources needed to service client requests, such as memory space, database connections, transactions, threads, and so on. The instance lifecycle manager 250 manages all lifecycle events associated with the bean instance 200 and its enterprise bean context 210. Depending on the request that has to be served in each case, the invocation chains manager 220 invokes an invocation chain 230 to serve business requests from clients or a callback invocation chain 240 to serve a lifecycle event for the bean instance 200. The invocation chain 230 invokes interceptor chains to service business requests and the callback invocation chain invokes interceptor chains to service lifecycle events, respectively. The component interface manager 260 manages factory objects associated with the enterprise bean context 210. The factory objects are local factory objects and remote factory objects. Local factory objects create instances of local interfaces and remote factory objects create instances of remote interfaces. The access type of the factory defines how the instance implementing the interface is accessed. Local access represents accessing components on the same Java Virtual Machine (“JVM”). Local access results in a direct Java invocation. Remote access represents accessing components on a different JVM. Remote access between two JVMs requires an underlying transport protocol to transport the requests and responses between the two JVMs.

In an embodiment of the invention, the runtime environment described in FIG. 2 is created and managed by a container as described in FIG. 1. Referring to FIGS. 1 and 2, the EJB container 1000 receives a request form the client 1050 or detects that a bean lifecycle event for the bean instance 200 should be processed. The EJB container 1000 requests the concrete invocation chains manager 220 associated with the enterprise bean context 210 to provide the corresponding chain of interceptors, either 230 or 240. For example, if the invocation chains manager 220 has to execute a business method from the client 1050 on client view instance 1, the client view instance 1 passes the call to the proxy invocation handler 1200. The proxy invocation handler 1200 passes the client request to the invocation chains manager 220. The invocation chains manager 220 identifies a chain to process the request from the invocation chains 230 and executes the chain to process the request.

FIG. 3 is a flowchart of a process performed by an embodiment of the invention. Referring to FIG. 3, at process block 300 a set of interceptors is created. Each interceptor in the set encapsulates logic to provide certain functionality. At process block 310, the interceptors are grouped in chains. In each chain, interceptors are grouped in a specific order and executed in that order so that a request can be processed. At process block 320 a request is received. At process block 330 a proxy invocation handler is invoked to receive the request. At process block 340 the proxy invocation handler passes the request to an invocation chains manager. At process block 350 the invocation chains manager identifies the correct chain to service the request. To identify an invocation chain to service the request, the invocation chains manager estimates if the request is for a bean life cycle event or a business request. At process block 360 the chain is associated with an invocation context. As the request involves performing an operation on a bean, such as business functionality or bean lifecycle event, at process block 370, a reference to the client view of the bean is obtained. Using this reference, at process block 380 the client request is processed via the execution of the identified interceptor chain.

In an embodiment of the invention, the process described in FIG. 3 is performed by a container as described in FIG. 1. Referring to FIGS. 1 and 3, the container 1000 creates interceptors at process block 300 to expose its functionality. At process block 310 the container 1000 groups interceptors in chains. At process block 320 the client 1050 sends a request to the container 1000. The request is received at a client view instance and passed to the proxy invocation handler 1200. The proxy invocation handler 1200 passes the request to the invocation chains manager 1300 at process block 340. The invocation chains manager 1300 analyzes the request to estimate if the request is for a bean life cycle event or a business request. Based on the estimation, at process block 350 the invocation chains manager 1300 identifies the correct chain to service the request. The invocation chains manager 1300 associates the request with an invocation context at process block 360. At process block 370 the client views manager 1100 creates a client view factory instance to obtain a reference to the client view of the bean. The invocation chains manager 1300 executes the identified chain to process the request using the reference to the client view of the bean.

Elements of embodiments may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cares, or other type of machine-readable media suitable for storing electronic instructions. Some embodiments of the invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).

It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.

In the foregoing specification, the invention has been described with reference to the specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.