US20080270986A1

US20080270986A1 - System and method for enterprise javabeans container

Info

Publication number: US20080270986A1
Application number: US12/111,127
Authority: US
Inventors: Ivo V. Simeonov; Hristo K. Sabev; Vladimir K. Pavlov; Krasimir I. Topchiyski; Vesselin P. Mitrov
Original assignee: Individual
Current assignee: SAP SE
Priority date: 2007-04-30
Filing date: 2008-04-28
Publication date: 2008-10-30
Also published as: US7962612B2; US9065843B2; US20080270600A1; US20080271044A1; US8082508B2; US20080270924A1; US20080270617A1; US20080270992A1; US20080270974A1; US8261272B2; US8510717B2

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

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:


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; and

an 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; and

a 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; and

a 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; and

executing 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; and

identifying 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; and

execute 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; and

identify an interceptor chain to service the request based on the estimation of the type of the request.