About J2EE EJB Event Listener Applications

Typically, the monitoring and notification is achieved using the SDK APIs as documented in this guide. These APIs include a mechanism by which an application can define an asynchronous callback (or event handler) that is called by the API infrastructure when various interesting job events occur. This mechanism is asynchronous because the event handler (callback) is called at some arbitrarily later point in time on a separate thread of execution. The APIs that support job event callbacks are designed for an unrestricted client JVM environment with full access to the JVM thread management systems.

However, there are some programming environments that cannot use asynchronous callback-style APIs because of environment constraints. For example, an EJB running in a J2EE application server is prohibited from establishing an asynchronous listener because it implicitly uses multiple threads of execution, which is not allowed in an EJB container. These server environments impose constraints on the use of JVM threads and, therefore, are not suitable for the SIMULIA Execution Engine client event-based APIs.

To support asynchronous job event notification in the J2EE EJB programming environment, a mechanism supported by the J2EE container must be used. The only such mechanism that currently exists is a Message Driven Bean (MDB). This is a portion of Java code deployed in the server that will be allowed to receive asynchronous messages under control of the container (J2EE server). A full discussion of MDB technology is beyond the scope of this guide. However, an MDB can exist only within a J2EE EJB container and is not supported in basic web servers such as Tomcat. A J2EE server platform such as WebSphere or WebLogic must be used to host the MDB.

The remainder of this section assumes familiarity with J2EE in general, JMS messaging technology, and Message Driven Beans.

To receive job status events in a J2EE EJB application, an MDB must be developed, deployed, and configured as described in the following sections (and shown below).

A sample application is delivered with the SIMULIA Execution Engine, but it is assumed that the developer has the appropriate skills to develop and deploy such an application. The application can be hosted in the same server JVM as the SIMULIA Execution Engine, or it can be deployed in a separate server instance on the same or different server machine. However, the application must be deployed in the same administrative “cell” (WebSphere) or “domain” (WebLogic) as the SIMULIA Execution Engine. The SIMULIA Execution Engine is configured to deliver job status messages to a predefined message queue on which the application will be configured as a listener.

The application (in the form of an MDB) will receive job status events by the normal J2EE MDB delivery mechanism. The event will carry job identification and status information in such a form that the Isight SDK is not required to process the events. The job status information will be delivered to the application in the form of XML text.

Only major job status events are generated. Events are not generated for each workitem within a job.