Browse Prior Art Database

Using EJBs as a generic portable runtime for simple Java* Beans

IP.com Disclosure Number: IPCOM000014879D
Original Publication Date: 2001-Nov-16
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 29K

Publishing Venue

IBM

Abstract

It is possible to provide a distributed runtime environment that supports Java* Beans running in parallel and communicating asynchronously by passing messages using "property change requests". These Java Beans are grouped together into "processes" and these processes may also contain other processes so that a nested hierarchy of processes and communicating Java Beans is created. The groupings within the hierarchy are important as they determine the lifecycle and transaction control of the Java Beans. It is desirable that this runtime is based on Enterprise JavaBeans** (EJB) so that the solution is good for many platforms. The problem is that EJBs are single threaded and have a synchronous call mechanism which means they can not be used to naively wrap the contents of a process as it requires multiple threads of execution. This problem may be addressed by not creating EJBs that reflect the application logic (that is in the Java Beans) but instead create EJBs which have an interface that allows the EJB to be passed a work item (such as "deliver this message to the following Java Bean"). The EJB processes the work item and returns. When it returns the EJB can be passed another work item. It is possible (probable) that new work items are generated during the processing of a single work item (for example, a Java Bean outputs a message that has to be sent asynchronously to another Java Bean). These are not processed, but are added to a queue to be passed to a different EJB (i.e. this is using a simple despatching mechanism). The advantages of this are that the benefits of EJBs (such as portability and distributed calls) can be exploited to provide a runtime for parallel activities with asynchronous message passing with only a small "buy-in" in some of the distributed EJB servers that are supporting this environment to support a "system" call that dispatches an EJB call on a new thread. It should be noted that EJBs do not support an event model to allow asynchronous message passing between EJBs. As a result adding asynchronous message support to EJBs would require an extension to the Sun Microsystems Inc Enterprise JavaBeans standard. However the method presented herein requires no change to the EJB spec and only a small enhancement to the implementation of some of the EJB Servers supporting the customer's code. Java is a registered trademark of Sun Microsystems Inc. JavaBeans is a registered trademark of Sun Microsystems Inc.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 60% of the total text.

Page 1 of 2

Using EJBs as a generic portable runtime for simple Java* Beans

It is possible to provide a distributed runtime environment that
supports Java* Beans running in parallel and communicating
asynchronously by passing messages using "property change
requests". These Java Beans are grouped together into
"processes" and these processes may also contain other processes
so that a nested hierarchy of processes and communicating Java
Beans is created. The groupings within the hierarchy are
important as they determine the lifecycle and transaction control
of the Java Beans. It is desirable that this runtime is based
on Enterprise JavaBeans** (EJB) so that the solution is good for
many platforms. The problem is that EJBs are single threaded
and have a synchronous call mechanism which means they can not be
used to naively wrap the contents of a process as it requires
multiple threads of execution. This problem may be addressed by
not creating EJBs that reflect the application logic (that is in
the Java Beans) but instead create EJBs which have an interface
that allows the EJB to be passed a work item (such as "deliver
this message to the following Java Bean"). The EJB processes the
work item and returns. When it returns the EJB can be passed
another work item. It is possible (probable) that new work items
are generated during the processing of a single work item (for
example, a Java Bean outputs a message that has to be sent
asynchronously to another Java Bean). These are not processed,
but are add...