An event binding file for easy creation, deployment and management of event specifications in an application server
Original Publication Date: 2009-Mar-06
Included in the Prior Art Database: 2009-Mar-06
This article describes the use of an "Event Binding File" to group together a related collection of event specifications. The event specifications contain information about interesting business events and how they can be detected at runtime. The event binding file provides shared information about how the events are to be formatted and emitted by the runtime, as well as other policy information, and acts as the unit of deployment and management for the group of events.
An event binding file for easy creation , deployment and management of event specifications in an application server
A mechanism is disclosed for grouping specifications of events to be detected and emitted by CICS Transaction Server for z/OS*. This allows related events to share policy about how and where they are to be emitted, and to be enabled or disabled, and managed, together.
CICS Transaction Server for z/OS will enable events to be emitted from existing applications. A business analyst will specify the sort of event that is interesting in business terms (for example, "an order over $100 is received in the order application") and the business data to be associated with the event (for example, "the order number and customer name"). Each business event will then be defined as an event specification, and have associated with this a "capture specification" which identifies the precise point in the application program or server runtime at which the event occurs and the application state is to be collected. The capture specifications may be stated as a conjunction of predicates in technical terms (for example, "application=order-system & module=order-data-entry & order-value>$100"). When the application executes, the event capture system will create an event instance whenever the predicates for a technical capture specification are found to be true.
Once an event has been captured, then it will be given to a separate execution thread to be prepared and emitted from the CICS runtime. We are calling this process adaptation and the program that performs it an adapter (which is consistent with the accepted industry terminology), or event processing (EP) adapter for clarity. The system will require the identity and characteristics of the EP adapter to be available at runtime.
As the EP adapter is invoked asynchronously to the application thread that causes the event, there may be a queue of such events if the rate of event capture exceeds the rate of event adaptation and emission. The system will need a policy specifying the processing resources to devote to the adaptation and emission, and what to do if those resources are insufficient to prevent the queue getting larger. Examples of what this policy may specify include calling for more resources to be provisioned, a degraded (more efficie...