SYSTEM AND METHOD FOR ENTERPRISE JAVABEANS CONTAINER

Abstract

A system to implement functionality for running Enterprise JavaBeans. The functionality is provided by a set of components. The components include a life cycle manager, a client views manager, a proxy invocation handler, an invocation chain manager, and an invocation context.

Description

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:

Interceptor                      Functionality Provided by Interceptor
ExceptionTracerInterceptor       Traces an exception raised during the
                                 invocation of an interceptor chain.
RemoteExceptionConverterInterceptor Converts exceptions with local type to
                                 their remote equivalent.
SecurityCheckInterceptor         Performs security access checks.
RunAsInterceptor                 Switches a current principal to a
                                 principal supplied in metadata. A
                                 principal is an entity with certain
                                 security permissions.
ResourceInterceptor, CallbackResourceInterceptor and Apply the resource context to the
RestrictedResourceInterceptor    current context.
TransactionInterceptor, TimeoutTransactionInterceptor Associates the transaction context the
and UnspecifiedTransactionAttribute current thread.
StatefulSessionInstanceCreatorInterceptor Requests the Lifecycle Manager 1400 to
                                 create a new session bean and
                                 associate it with the current execution.
StatefulSessionInstanceGetterInterceptor Requests the Lifecycle Manager 1400 to
                                 locate a requested session bean either
                                 in the current transaction context or in
                                 the session management.
StatefulSessionInstanceDestroyerInterceptor Requests the Lifecycle Manager 1400 to
                                 locate a requested session bean either
                                 in the current transaction context or in
                                 the session management. The session
                                 instance is removed or passivated,
                                 depending or the status of the
                                 execution, either at commit time of the
                                 associated transaction, or after the
                                 interceptor chain continues execution.
StatefulSessionInstanceOldStyleDestroyerInterceptor Requests the Lifecycle Manager 1400 to
                                 locate a requested session bean only in
                                 the session management. The session
                                 instance is removed after the
                                 interceptor chain continues execution.
                                 This interceptor is used for backward
                                 compatibility purposes.
StatelessInstanceGetterInterceptor Requests lifecycle manager for a bean
                                 instance. If a bean instance does not
                                 exist the lifecycle manager is
                                 responsible for its creation.
StatelessProxyInstanceCreationInterceptor Creates a client view for a stateless
                                 bean using the client view factories of
                                 the bean. The interceptor is initialized
                                 with the name of the client view
                                 interface and the access type of the
                                 factory.
StatefulProxyInstanceCreationInterceptor Creates a client view for a stateful bean
                                 using the client view factories of the
                                 bean. The interceptor is initialized with
                                 the name of the client view interface
                                 and the access type of the factory.
StatefulTransactionAssociationInterceptor Associates the bean instance with the
                                 transaction context.
AfterBeginInterceptor            Invokes a
                                 SessionSynchronizartion.afterBegin( )
                                 method on the bean instance if the
                                 thread has transaction context and the
                                 bean is not associated with it, that is, it
                                 is the first time the bean is requested in
                                 the current transaction.
StatesTransitionInterseptor      Assigns a state to a bean instance
                                 currently associated with the execution
                                 to represent the collection of
                                 operations allowed to be performed in
                                 the subsequent bean method
                                 invocations.
ApplicationInterceptor,          These interceptors perform application
BeanClassApplicationInterceptor, interceptor method invocations.
CallbackApplicationInterceptor,
BeanClassCallbackApplicationInterceptor and
Callback2xStyleInvocationInterceptor
WSInterceptor                    Performs web services handlers
                                 preInvoke and posInvoke operations.
MessageEndpointLockInterceptor   Locks a client view to serialize method
                                 calls.
MessageListenerTypeInterceptor   Initializes a transaction context if the
                                 invocation requires a transaction
                                 context and the transaction context is
                                 not already initialized.
MessageEndpointReleaseInterceptor Handles the
                                 MessageEndpoint.release( ) method by
                                 denoting an instance as released.
BeforeDeliveryInterceptor        Handles the
                                 MessageEndpoint.beforeDelivery( )
                                 method in the same way as the
                                 MessageListenerTypeInterceptor
                                 without restoring the transaction
                                 context after completing execution.
AfterDeliveryInterceptor         Handles the
                                 MessageEndpoint.afterDelivery( )
                                 method in the same way as the
                                 MessageListenerTypeInterceptor
                                 without assigning the transaction
                                 context before proceeding with
                                 execution.
SessionEJBHomeInterceptor,       Handle methods implementing
SessionEJBLocalHomeInterceptor,  functionality from previous
SessionEJBObjectInterceptor and  specification versions for backward
SessionEJBLocalObjectInterceptor compatibility purposes.
ActivateStatefulContextInterceptor Locates a session bean instance within
                                 the session management and assigns it
                                 to the current invocation context.
PassivateStatefulContextInterceptor Stores a session bean instance,
                                 currently located in the invocation
                                 context, in the session management.
NewStatefulContextInterceptor,   Create an instance of the
NewStatelessContextInterceptor and corresponding bean context successor
NewMessageDrivenBeanContextInterceptor for the corresponding bean type and
                                 assigns the instance to the current
                                 invocation context
ApplicationInstancesCreatorInterceptor Creates new instances of the bean class
                                 and all concrete application interceptor
                                 classes and assigns them to the bean
                                 context instance in the current
                                 invocation context.
Session2xDependencyInjectionInterceptor, Perform injection on all injection
MessageDriven2xDependencyInjectionInterceptor and targets in the application classes.
EJBContext30DependencyInjectionInterceptor
DestroyStatefulContextInterceptor and Destroy the corresponding concrete
DestroyStatelessContextInterceptor bean context instance by destroying all
                                 resources associated to it.

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.

Claims

1. A system to run Enterprise JavaBeans (“EJB”), comprising: a life cycle manager to manage the lifecycle of bean instances;a client views manager to manage the life cycle of client views provided to bean clients;a proxy invocation handler coupled to a client view factory to propagate a client request from a client view to a bean instance;an invocation chains manager to execute the client request responsive to receiving the client request from the proxy invocation handler; andan invocation context to manage the lifecycle of an interceptor chain responsive to the interceptor chain being executed by the invocation chains manager.

2. The system of claim 1, wherein the client views manager comprises: a set of client view factory instances to create and destroy client view instances.

3. The system of claim 1, further comprising: a timeout manager to manage timeout invocations.

4. An apparatus to provide a runtime environment for an Enterprise JavaBean (“EJB”), the apparatus comprising: an invocation chains manager to invoke an invocation chain responsive to a request;an enterprise bean context to maintain a set of resources associated with the EJB;an instance life cycle manager coupled to the enterprise bean context to manage an instance of the EJB and resources associated with the instance of the EJB; anda component interface manager to manage factory objects associated with the instance of the EJB.

5. The apparatus of claim 4, wherein the factory objects comprise: a remote access factory object; anda local access factory object.

6. A method to run Enterprise Java Beans (“EJB”) applications, comprising: creating a set of interceptors, each interceptor encapsulating logic to service a request for a bean or a bean life cycle event;grouping interceptors in interceptor chains;requesting an interceptor chain responsive to receiving a request for the bean;associating the interceptor chain with an invocation context; andexecuting the interceptor chain to service the request.

7. The method of claim 6, further comprising obtaining a reference to a client view of the bean.

8. The method of claim 6, wherein requesting the interceptor chain comprises: invoking a proxy invocation handler to pass the request to an invocation chain manager;estimating if the received request is for a business logic operation or a lifecycle operation; andidentifying an interceptor chain to service the request based on the estimation of the type of the request.

9. A machine readable medium having instructions therein that when executed by the machine, cause the machine to: create a set of interceptors, each interceptor encapsulating logic to service a request for a bean or a bean life cycle event;group interceptors in interceptor chains;request an interceptor chain responsive to receiving a request for the bean; andexecute the interceptor chain to service the request.

10. The machine readable medium of claim 9, further comprising instructions that cause the machine to obtain a reference to a client view of the bean.

11. The machine readable medium of claim 9, wherein instructions causing the machine to request an interceptor chain, cause the machine to: invoke a proxy invocation handler to pass the request to an invocation chain manager;estimate if the received request is for a business logic operation or a lifecycle operation; andidentify an interceptor chain to service the request based on the estimation of the type of the request.