Designing for parallel execution

InterChange Server provides a parallel-execution environment: it can run multiple collaborations concurrently in separate threads and it can also run multiple threads of the same collaboration (known as multithreading).

Attention:
The thread pool for collaborations is used only for event-triggered flows and not for call-triggered flows. However, call-triggered flows are also multi-threaded in execution in that they use the thread pool of the IBM Java Object Request Broker (ORB).

Multithreading capabilities

Each server has a maximum number of threads that can be simultaneously spawned to process business object subscriptions. You can set your own maximum number of threads to be spawned, based on your individual situation and what you determine to be optimal for performance. Of course, the number you set cannot be greater than the number of threads allowed by the server.

To set the maximum number of threads that can potentially be spawned, specify the number of threads in System Manager.

Note:
If the destination connector is configured for parallel processing, code the collaboration template to verify that the request was successfully sent to the application. Add this code to the node immediately following the exception transition link for the service call. For more information, see getSubType() in CollaborationException class.
Important:
If the destination connector is single-threaded, it must be configured for parallel processing to take advantage of a multi-threaded collaboration. For more information, see the Implementation Guide for WebSphere InterChange Server.

Problems in concurrent processing

In any concurrent processing environment, there is always the danger of data inconsistency. Data inconsistency can occur whether the concurrent processing is by means of multiple processes or multiple threads. If two programs or two threads access the same data at the same time, there is always the possibility that one may modify the data and adversely affect the operations of the other program or thread in unexpected ways. Concurrent processing environments handle this problem by synchronizing access to shared data; a thread or process locks a portion of data so that another thread or process cannot simultaneously access it.

For a simple example of the problem as it might occur in the business integration environment, consider the following situation:

InterChange Server has the following features to ensure data consistency and address this problem:

Event sequencing

Event sequencing ensures that two threads of the same collaboration do not work on the same data concurrently. If multiple events have the same business object type and key values, the server queues them and delivers them in order of arrival. The collaboration thread that receives the first event must complete before the collaboration receives the next event. Event sequencing thereby preserves execution order, even in the presence of multi-threaded execution, despite that the various threads could execute at varying speeds.

You do not need to design a collaboration in any special way to take advantage of event sequencing; it is done automatically.

Event isolation

Event isolation ensures that two collaborations do not work on the same data concurrently. Sometimes multiple collaborations handle the same types of business objects. An event arrives and triggers a particular collaboration. This collaboration starts its execution and, while it executes, it has sole access to that business object instance in InterChange Server. If another event relating to the same data arrives, InterChange Server queues the newly arrived event until the executing collaboration completes its processing of the first event. Some restrictions apply to this feature; they are described in the following sections.

InterChange Server does not do event isolation automatically. Collaboration developers must design templates in a certain way to take advantage of event isolation. This section describes the rules and gives some examples of design decisions that help achieve this goal.

Note:
These guidelines apply only to collaborations that perform operations that change data and operate in an environment where multiple collaborations are in use. If you are developing a collaboration that performs only retrieve operations and will always be the sole collaboration using that business object type on its server, you can disregard these guidelines.

When event isolation is applied

InterChange Server determines the application of event isolation at runtime, based on an analysis of the events that arrive and the ports of active collaborations. The criteria for event analysis is the same as for event sequencing: events are the same when the business object type and key values are the same.

The analysis of active collaborations considers the set of each collaboration's ports that are bound to connectors. In port matching, InterChange Server checks whether:

For example, two collaborations have matching ports if both have these port bindings:

Connector1/Business object type A

Connector2/Business object type B

It is not important whether a port is used for incoming events or outgoing requests and responses; only the connector binding and the business object type matters.

Ports bound to other collaborations are not considered when determining the collaborations for which event isolation applies.

Port matching example: ports that match

Figure 11 illustrates two collaborations, X and Y, for which event isolation would apply. The small black rectangles at the edges of the collaborations indicate ports.

Figure 11. Matching ports


In Figure 11, X has two ports and Y has three ports. However, port matching considers only the two ports of Y that are bound to connectors; it disregards the port that is bound to collaboration Z. Both collaborations have the following ports bound to connectors:

This example meets the criteria for event isolation, and the server isolates the incoming or triggering event. Therefore, event A instances would be subject to isolation in these two collaborations.

Port matching example: ports that do not match

Keep in mind that the server considers all ports when comparing collaborations; it does not confine port matching analysis to ports that receive triggering events. If two collaborations receive the same type of event from the same connector but send an outgoing business object to two different connectors, their events are not isolated.

Figure 12 illustrates two collaborations whose outgoing ports are bound to different connectors. Their event instances are not isolated.

Figure 12. Unmatched ports


Design rules

You must design collaborations in a certain way if you want to benefit from event instance isolation. This section describes how to:

Using delegation

Each collaboration template that modifies a business object should be dedicated to modifying only that type of business object. If the collaboration needs to modify another type of business object, such as a child business object, then you should create a separate collaboration whose purpose is to modify the other business object. Then, have the first collaboration delegate (pass) the other business object to the second collaboration for modification.

The rule of dedicating a single collaboration to modifying only one type of business object helps maintain data consistency. It prevents multiple collaborations from concurrently modifying the same instance of the same type of business object. Delegation ensures that the data consistency of a child business object is maintained with respect to instances of the same business object that are processed by other collaborations. Remember that you can use a business object in one context as a child and in another context on its own.

Imagine that you need to write a business process that deals with a business object A and a set of information, B, associated with it as a child business object. The business object structure might look similar to the illustration shown in Figure 13, where the B business object is a child of the A business object.

Figure 13. Example of a hierarchical business object


If a collaboration already exists that processes B business objects, you should delegate work on the B child business object to that collaboration. Alternatively, you might need to create another collaboration.

When you want to work on the data associated with the A business object, you must work on both the A business object and its set of B data, or the child business object. You would therefore create two different collaboration templates--one collaboration modifies business object A and the other modifies the child business object B--and you might combine these two templates into a collaboration group. Each collaboration template handles the operations on one business object.

Figure 14 illustrates a collaboration group, A/B, that contains an A-Processor collaboration and a B-Processor collaboration. The A-Processor collaboration processes the A business object. When the A-Processor collaboration needs to modify the B child business object, it uses a service call to send the B business object to the B-Processor collaboration. In Figure 14, a dotted line shows delegation.

Figure 14. Delegation of a child business object


Handling child business objects as reference-valued

When a collaboration receives a delegated child business object (such as the case of the B-Processor collaboration in Figure 14), it should treat the business object as a reference-valued business object. A reference-valued business object contains only the values for attributes that are defined as primary keys for the business object. A full-valued business object, in contrast, contains values for other attributes.

In the figures in this chapter, reference-valued business objects are marked (r) and full-valued business objects are marked (f). Figure 15 is an example of a business object with a reference-valued child.

Figure 15. Hierarchical business object with a reference-valued child


Depending on the originating connector, events might be sent with reference-valued or full-valued child business objects. A collaboration that receives a delegated child business object might therefore receive all of its attribute values or only its primary key values. However, the collaboration should always treat the delegated child business object that it receives as reference-valued. It should assume only that the primary key values are correct; it should ignore attribute values that are not primary keys.

If the collaboration needs to perform operations on the child business object's non-key attributes, it must resolve the reference by retrieving the full-valued version of the business object from the source application. If the child business object is reference-valued, the retrieve operation obtains the additional attribute values. If the child business object is full-valued, the retrieve operation ensures that the associated data is current and valid.

Figure 14 illustrates the delegation of B as a reference-valued business object and the collaboration's resolution of the reference by retrieval from the source collaboration.

Figure 16. Resolving the reference


Copyright IBM Corp. 2003, 2004