This section explains how an incoming message is processed inside the xBus. The most important modules are introduced here. It is very important to understand them, because users have to control them by configuring the xBus.

When xBus receives data, it is processed internally through a chain of modules. Each module has a certain, exactly defined responsibility. The following figure shows a very simple data flow. The is received from one system, converted and sent to another system.

legend

The xBus is capable of more complex data flows. Such samples are described on the Data flows page.

Systems are not components of the xBus itself. They represent the interfaces to counterparts. Some systems send data to the xBus, some systems receive data from the xBus and some systems have bidirectional access.

Systems are defined by important properties:

• Each system gets a logical name under which it can be referenced.
• The data is send or received by using one technical protocol, for example HTTP or a file.
• All technical ways usually have an address (URL, filename etc.) and sometimes need authentication.
• The format of the data is also defined by the system. The most common formatting used by current systems is XML. Legacy systems often format their data in so-called record type format. In this case, every field has a fixed length.

Each system has to be configure by these and some more parameters in the xBus configuration.

Receivers are modules of the technical layer. They are responsible for receiving data from other systems. Every technical protocol has a special receiver module. When a trigger activates a receiver, it reads the data from the source and passes it to the protocol layer.

Two kinds of triggers for activating receivers exist:

• Many receivers run as service processes in the background and wait for data. They process the data in near-time. A good example is the HTTP receiver. A servlet-engine like Tomcat is used. Background services are currently available for receiving data via HTTP, message queues, POP3 and files.
• The other kind of trigger is, to start a receiver on request or via a scheduler like cron. Such trigger makes sense, when data is available at fixed times and the counterpart does not require a response. File receivers are a typical example.

All different receiver modules are explained in the Technical Layer section.

General Receiver Types

Internally the XBus distunguishes between three different types of receivers:

• Text - for exchanging strings
• Object - for all other content types, e.g. file or stream references and ByteArrayLists

All receivers use exactly one of these types. This type defines the general receiver behavior.
Senders also use the same internal types. .
The general receiver type define the (easily) possible combinations of receivers, messages and senders. Transformers extend the combination variants.

Message modules belong to the protocol layer. They are related to the format of the data and are able to understand the syntax of the data format and parse the data. The extraction of the information is important for routing. Additionally, Transformers often rely on a structured storing of the data.

Every message stores some data internally. The most important information is:

• A Message ID is generated, when a message is received. This makes it easier to track a data flow in the Journal, since all actions of one data flow have the same message id.
• Request data is the data received from a receiver. Every message module can have its own format. Currently, most of the message classes store the request data internally in the XML format.
• A Function sign is extracted out of the request data. It is used afterwards to decide the routing destination. .
• The Source is the name of the source system as it has been specified in the configuration. If additional address information is available, it is stored as well.
• The Returncode contains the acknowledgment, whether the sender was able to deliver the data to the destination (OK) or not (not OK).
• Response data can be set after execution of a sender, if the sender is capable of returning a response.

The available message types are explained in the Protocol Layer section.

General Message Types

Internally the XBus distinguishe between three different message content types:

• Text - for exchanging strings
• Object - for all other types of content than the other two, e.g. file or stream references and ByteArrayLists
• XML - for structured interface content

Eache message is of these types. This defines the general message behavior. A concrete message can support different types. E.g. a RecordTypeMessage can be any of these types. In such cases the order of precedence in the above list is from top to the bottom. The first applicable entry of the list is chosen to treat the message. For example RecordTypeMessages are internally treated as XMLMessages.
The supported types define the (easily) possible combinations of receivers, messages and senders. Transformers extend the combination possibilities.

The router is currently the only available module of the application layer. Its task is, to route the data to one or more destinations. Two working modes are supported:

• Sending the data to a destination and waiting for a response including content is called Invoke. This mode can be seen as a RPC (remote procedure call).
• The second mode is called Distribute. Here the data is sent to a destination but the router waits only for the acknowledgment that the system on the other side has received the data.

One received message can lead to several invocations and distribution, even mixed. More on this powerful capabilities can be found in Concepts and Data flows.

Data often has to be transformed into another format, before sending data it to a destination system. Special transformer modules do this work. They transform the received data into the target format, required for sending it to the destination.

Example: If both message objects store their data in the XML format (like most do), the transformation between these XML-dialects can be done with the XSLTTransformer, using XSLT stylesheets.

Which transformer module is used, depends on the involved message modules. The xbus.conf defines which transformer is used by default. This PDF-file lists the default dependencies. However, it is also possible to overwrite the default behavior by specifying a different transformer in standard.conf.

More information about the transformer modules is available on the Protocol Layer page.

Sender modules are the counterparts of the receivers in the technical layer. They receive the data from the protocol layer and send it via a technical protocol to the destination. Typically the same technical protocols are available as sender modules as for the receivers, like HTTP, files, message queues etc.

The available sender modules are explained on the Technical Layer page.

General Sender Types

Internally the XBus distunguishes two different types of senders:

• Text - for exchanging strings
• Object - for all other types of content than the other two, e.g. file or stream references and ByteArrayLists

All sender use exactly one of these types. This type defines the general sender behavior..
These types are exactly the same as for the receivers.
They define the (easily) possible combinations of receivers, messages and senders. Transformers extend the combination possibilities.