Application-to-adapter communication

The Adapter for FRONT ARENA allows the WebSphere InterChange Server to exchange business objects with the FRONT ARENA application.

The Adapter for FRONT ARENA consists of the WebSphere MQ Adapter, the bridge component, and the data handler. The adapter makes use of the WebSphere MQ implementation of the Java Message Service (JMS) . JMS is an open-standard API for accessing enterprise messaging systems. It is designed to allow business applications to asynchronously send and receive business data and events.

The bridge component of the adapter forwards messages from the FRONT ARENA AMB messaging system to the WebSphere MQ messaging system and vice versa. It does not deal with the content of messages. No message content transformation is performed; only messaging system dependent headers are exchanged. As the messages, or more accurately, the payload of the messages, originate from or eventually end up in the FRONT ARENA system, they have the native FRONT ARENA format, in either case. The application communicating with FRONT ARENA by way of the adapter must be able to cope with this format. The messages on the queue can then be accessed by either the WebSphere MQ Adapter or other third party applications.

The FRONT ARENA application has a middleware layer of its own, the ARENA Message Broker (AMB). This is an asynchronous messaging system following the publish and subscribe paradigm. External applications are recommended to access FRONT ARENA through the APIs provided by the AMB. An API is provided for accessing and utilizing the AMB. This is the point of integration recommended for any applications electronically feeding data (for example, trades) or extracting data.

The API can be used for synchronizing a FRONT ARENA system with other financial market applications or vice versa. If FRONT ARENA is set up correspondingly, any newly created FRONT ARENA objects, or changes to existing FRONT ARENA objects, for example, trades, positions, are published on the AMB. External applications can register to the AMB and subscribe to all or subsets of these notifications. In the opposite direction, external applications can create new FRONT ARENA objects or change existing ones by putting appropriate messages on the AMB.

The AMB APIs are low level C interfaces and extensive memory management is required around API calls. The bridge component of the adapter connects to the FRONT ARENA AMB on one side, and by way of the WebSphere MQ queues - to the adapter on the other side. The bridge component of the adapter subscribes to create, update, and delete notifications for a configurable set of FRONT ARENA objects, and passes all notification event messages received from FRONT ARENA to the WebSphere MQ queue. The bridge also forwards service request messages received from the adapter to FRONT ARENA, and optionally returns the results of the requests to the adapter. The data handler component of the adapter copes with the native FRONT ARENA message formats.

Figure 3. Direct use of the bridge component


The bridge can be used in two contexts:

Message request

Figure 4 illustrates a message request communication. When the doVerbFor() method receives a business object from a collaboration, the adapter passes the business object to the data handler. The data handler converts the business object into a FRONT ARENA native text message and the adapter issues it as a message to a queue. There, the JMS layer makes the appropriate calls to open a queue session and route the message.

Figure 4. Application-to-adapter communication method: Message request


Message return

Figure 5 illustrates the message return direction. The pollForEvents() method retrieves the next applicable message from the input queue. The message is staged in the in-progress queue where it remains until processing is complete. Using either the static or dynamic meta-objects, the adapter first determines whether the message type is supported. If so, the adapter passes the message to the configured data handler, which converts the message into a business object. The verb that is set reflects the conversion properties established for the message type. The adapter then determines whether the business object is subscribed to by a collaboration. If so, the gotApplEvents() method delivers the business object to InterChange Server, and the message is removed from the in-progress queue.

Figure 5. Application-to-adapter communication method: Message return


Copyright IBM Corp. 1997, 2004