When sending messages to a system, the feedback can be of two different types:

• Request/Response: The first type is like a function call. Data is sent to a destination which returns a response including a content. A good example for this behavior is a remote procedure call using SOAP. An XML document(including request) is sent to an URL . The counterpart immediately returns an XML document (including response).
• Request/Acknowledgment: The second possibility is to send the data and get an acknowledgment only. The response indicates, whether the data could be delivered or not. This is a usual behavior when writing data into a file or message-queue or sending it via email.

The xBus can work with both communication modes. This has effects on receivers and senders in the technical layer and on the router in the application layer:

• All senders and receivers process the acknowledgment, whether the data could be delivered or not. If a sender could not deliver the data to the intended destination, it reacts on the error. Useful reactions are retries or sending an email to an administrator.
• Some senders and receivers are able deal with a response. If using responses is useful, depends on the technical protocol. The HTTP protocol for example is based on requests and responses. HTTPSender and HTTPReceiver therefore support responses. Sending an email or receiving data from a message queue are contrary examples. Resposes do not make sense in connection with them.
• The router is capable of establishing data flows in two different modes:
  • Invoke is the mode for the Request/Response type. The response is the base for the next step in the process chain.
  • Distribute is the mode for the Request/Acknowledgement type.
  Multiple invokes and distributes or a combination of these two can be set in the configuration. This makes routing very flexible and provides a multitude of possibilities to handle the data.

Some examples show these possibilities in detail. Each example has a figure to show the data flow. A legend is available for the elements of the figures.

The first example is the easiest model for the Request/Response mode. It is a simple function call.

Data is received from system 1. The incoming data is delivered to system 2, which answeres with a response. This response is transferred back to the initiating system 1.

When the systems have different data formats, two transformations must be performed:

1. The request of system 1 (format a) must be transformed to format b. The result is the request for system 2.
2. The response from system 2 (format b) must be transformed back to format a needed as response for system 1.

legend

The case gets more complicated, if more than one system is needed, to fulfill a request.

Once again, system 1 sends a request to the xBus. The message is routed to system 2. The response from system 2 is used in this case as a request to call system 3. In the end the response from system 3 is given back to system 1.

In this case you can have up to three transformations, if all three systems use different data formats:

1. First the request of system 1 (format a) must be transformed to format b as the request for system 2.
2. Then the response of system2 (format b) must be transformed to format c as the request for system 3.
3. Finally the response from system 3 (format c) must be transformed back to format a needed as response for system 1.

This chain can be longer. Many invocations may be processed until the response from the final system is converted back to system 1.

legend

One of the most simple modes is the distribution of data from one receiver to one sender. The first example for the Request/Acknowledgment mode shows this process.

Similar to Invoke simple, data is received from system 1 and delivered to system 2. System 2 does not deliver a response. The feedback is only an acknowledgment, whether the system 2 has accepted the data (OK) or if an error occured (not OK). This acknowledgment is sent back to system 1.

If the systems use different data formats, one transformation is required:

1. The request of system 1 (format a) must be transformed to format b as a request for system 2.

legend

A distribution of a message to two or more systems is possible too.

Data is received from system 1 and delivered to system 2. Additionally, the data from system 1 is delivered to system 3. The feedback sent to system 1 is the acknowledgment OK, if the data has successfully been sent to both systems. not OK is sent, if one or both sender processes failed. In case of an error, a rollback is done on all resources.

If all systems have different data formats, two transformations are required:

1. The request of system 1 (format a) must be transformed to format b as request for system 2.
2. The request of system 1 (format a) must be transformed to format c as request for system 3.

Certainly, a message can be distributed to three or more systems too.

legend

This example shows, how to mix both communication modes.

Similar to the previous examples, system 1 sends a request to the xBus, which is routed to system 2 in invocation mode. The response from system 2 is used as a request to call system 3 in distribution mode. Finally the acknowledgment from system 3 is given back to system 1.

In this case you can have up to two transformations, if all three systems have different data formats:

1. The request of system 1 (format a) must be transformed to format b as a request for system 2.
2. The response of system2 (format b) must be transformed to format c as a request for system 3.

Long chains with more invocations and distributions to several systems can be built. However, one limitation is important: When mixing both communication modes, all invocations have to be processed prior to the distributions. Mixtures with alternating invocations and distributions are not allowed.

legend

All previous examples used synchronous communication. This means that system 1 always gets feedback, whether the message has received all destinations. This is often not a suitable behavior, as some systems are not available at certain times. In this cases, an asynchronous communication is needed. When using asynchronous communication, the initiating system gets only the feedback, that the xBus has received the message. It is up to the xBus, to deliver the message to the receivers.

An easy way to achieve asynchronous communication is with the help of message queues. The message received from system 1 is first send to a message queue by a MQSender. The XBUSXMLMessage is an appropriate data format for writing data in a message queue, because it contains all internal data of the message module. The MQReceiver reads the message out of the message queue and distributes it to system 2. When system 2 is not available, the MQReceiver will try again after some time, until the message can be delivered.

Some facts of synchronous communication are important:

• Only the Request / Acknowledgment mode is supported. The mode returning a response with content is not possible.
• A first in / first out strategy is implemented in the message queue. The messages are received from the message queue by system 2 in the same order as sent to the queue by system 1.
• The second fact leads to the consequence that all following messages have to wait in the message queue, until the first one has been delivered successfully. This is even the case, if the first message in the queue can not be delivered to system 2.

legend