An Extended WBI Adapter Framework allowing multiple concurrent APIs support, multithreaded events data retrieval and event sequencing delivery
Original Publication Date: 2005-Oct-20
Included in the Prior Art Database: 2005-Oct-20
An Extended WBI Adapter Framework allowing multiple concurrent APIs support, multithreaded events data retrieval and event sequencing delivery.
An Extended WBI Adapter Framework allowing multiple concurrent APIs support , multithreaded events data retrieval and event sequencing delivery
The current suite of WBI Technology Adapters is based on a one technology (JDBC, JMS, CORBA, etc.) per adapter base. Typically, when using the WBI adapter for JMS, the dialog with the connected application can only be through the JMS messages. If the target application support JDBC or CORBA protocols, extra dedicated adapters are required. Worse, in some case, the application can provide event notification through JMS and the data associated with the event have to be obtained throug an JDBC or RMI. In that case, it is currently necessary to use the JMS adapter to start the process and during the process a preliminary step retrieve the data through the appropriate adapter leading a poor performances architecture. Each WBI Adapter are often intrusive because they rely on the connected application persistent layer technology (Queues for JMS, dedictated tables for JDBC, Siebel, SAP etc.).
The WBI Apapter Polling mechanism is often the broker bottleneck because the event and data retrieval is mono threaded.
This extended WBI Adapter Framework is based on the following new components :
get Next Event
Retrieve Thread Retrieve Thread
Retrieve Thread Retrieve Thread SendToBroker Thread
- Events Notifier thread picks up event in the target application events queue using the appropriate protocole, create new Event object and add it to the Events Queue. - Events Listener thread wait for new event to be created by external application and added to the Events Queue through the appropriate protocol (typically RMI, CORBA, Web Service, ...). - Event object is at least an id an the BusObj name, verb and key. The BusObj associated to the event is optionnal. The Event Object is persisted in an Event
repository. - The Events Queue manages the events data retrieval through the a BO Handler
Thread (if necessary) and its delivery to the broker through a SendToBroker thread calling the traditionnal gotApplEvent method. Events handling is based on the same event sequencing principle as the one of the InterChangeServer (the delivery of identical BusObj and key is hold as long as the previous events are not sent to the broker). - A BO Handler Thread is instanciated and started when an Event object is created without its associated BusObj. It calls the appropriate BO Handler and dies when the data are re...