Tuesday, August 1, 2017

How to Ensure Message Ordering on a Cluster Environment Using JCA Adapters in Oracle SOA Suite

The right configuration of Oracle SOA Suite JCA-adapters for ensuring message ordering on a cluster is presented in the article.

During an integration project especially if some involved information systems are legacy, a database is often employed. Oracle SOA Suite contains a number of adapters built on the JCA technology which provides the database polling capability. The examples are the DB- and AQ-adapters.

And sometimes the order messages are processing in must be the same as the messages were generated inside a source application and, therefore were written to the database. Let me illustrate the sentence by the following: an information system creates an object, e.g. a consumer's bill. Then the object is modified and in some time deleted at all (so, the bill was generated by mistake). Obviously, the message about the object removal cannot reach the destination before the message about the creation. Otherwise, data integrity could be compromised.

To ensure the right ordering of message polling, the JCA-adapter must work exactly in one thread and the adapter must exist within the cluster exactly alone. The NumberOfThreads parameter specifies a number of threads for retrieving database records. The default value of the parameter equals 1, so every instance of the adapter works in one thread. The activationInstances parameter controls how many instances of the adapter are active on a WebLogic Server instance. The default value also set to 1, one instance of the adapter is active on a server. Thus, the right message ordering on a standalone WebLogic Server is guaranteed by default but if a cluster environment is considered, every server runs its own instance of the adapter and it may disturb message ordering since each WebLogic Server instance works independently. To ensure the adapter works only on one server instance, set the singleton parameter to true.

At the same time, in case an abnormal or planned outage happens, the active instance of the adapter will migrate on another WebLogic Server instance belongs to the cluster.

The above picture presents the first digit in the number of Instance ID is changed, indicating the instance was created by another WebLogic Server.

Note! During the migration process sometimes both adapter instances may work: a new instance of the adapter had started before the previous instance completely halted. Therefore some records would be retrieved repeatedly. Distributed Polling protects from processing the same records again.

To ensure message handling in order, the adapter must be configured to reading the next message only after the handling of the current message is completed. The DB-adapter supports synchronous processing of retrieved messages. This mode is activated by Do Synchronous Post to BPEL (Allow In-Order Delivery).

The DB-adapter waits for a response from the message handler, for example, a BPEL-process, and will send the next message only after gets the response. The Reply activity allows the BPEL-process to send a message in reply to a message that was received through a receive activity. The combination of a receive activity and a reply activity forms a request-response operation for the process.

It is important to note that the singleton mode for the adapter (i.e. environment singleton) isn't a best practice and usually highlights there are some problems in the architecture of the integration solution. This mode significantly reduces the scalability factor. Expertise confirms two active DB-adapters even though they run on the same machine achieve 1.5x throughput compared with an adapter working only on one server instance. However, there are cases where message ordering is entirely necessary. The loss of performance might be repaired by the utilization of other kinds of adapters.

Would you like to give a 'Like'? Please follow me on Twitter!