xBus

Architecture

The xBus is both: An application as well as a framework. It is written in the Java programming language. The architecture of the framework consists of layers, which clearly contain the functions for transformation and routing of data. Other basic functions are also included, which assure an easy handling during development and production.


Architecture


All layers of the framework are implemented by a Java classes. xBus satisfies three important basic design principles:

  • Every class which can be called from another layer implements one or more special interfaces.
  • The instantiation of these classes is done by so-called factory classes. The factory class learns, which class to instantiate, by reading the configuration file. Then it creates an object of the read class. Using this mechanism, the class definition for a function (communication, intepreting, transforming) can be exchanged easily (plug-in behavior)
  • The whole execution process is controlled by a few base classes.

 Services

Services are programs running in the background and helping the xBus doing its work. Typically the background service is a product from an other vendor. The xBus uses standardized API's to keep them exchangeable.

Currently the following types of services can used with the xBus:

  • A servlet engine is used for accessing HTTP requests.
  • A message queue server can buffer messages internally. Additionally it can be used to communicate with other systems in an asynchronous way.
  • The database is currently only used as one possibility to store the journal of the data flows.
  • Mail servers can be used to send emails via SMTP and to receive emails using POP3.
  • Files on remote filesystem can be accessed(reading and writing) by using theFTP protocol.
  • Data can be searched in an LDAP databases.

All services are optional. The xBus can run without these services, when it doesn't require these functions.

 Technical Layer

The technical layer is responsible for the communication with other systems. This includes both: sending data as well as receiving data from other systems. One class implementation exists for every technical protocol (e.g. HTTP, File, MQ). This class includes all technical aspects of the specific communication protocol.

The classes of the technical layer do neither interpret nor format the data. Receiver classes receive the data from the technical counterpart and pass it directly to the protocol layer. Sender classes receive the data from the protocol layer and send it by using the respective technical channel.

Technical Layer has more details about all modules of this layer.

 Protocol Layer
The protocol layer handles the the format of the data. It executes two main tasks:
  • Interpreting the data: The data is parsed and internally stored in a structured way. The protocol layer finds out the information, necessary for routing and transformation of the data. Every data type (e.g. XML or record type) has its own class implementations, responsible for the interpretations. Some data types, which are self-explaining (e.g. XML), can be handled by generic parsers. Some data types, like record type, need additional information about the structure. This information has to be set in configuration files. Using the information of the structure definition, the protocol layer can convert the input data into a generic format (mostly XML).
  • Transforming the data: Data structures can be transformed into other data structures. xBus supports a very flexible way to do this. It is using XSL transformations for transforming XML data. To be able to take advantage of this mechanism for other data types like record type or CSV, the data is stored internally in the XML format and therefore processible by XSL.

Protocol Layer has details about all modules of this layer.

 Application Layer

The only task of the application layer is currently the routing of the data. The responsible class decides, based on the source and contents of the message, in which format and to which destination the message must be transferred. The decision process is based on settings made in a configuration file.

Since the router is just a plug-in, it is possible to exchange it with an other class with different functions, for example a workflow engine.

Application Layer has more details about all modules of this layer.

 Base Functions

As written before, some basic functions are included in this framework, which assure an easy handling during development and productive operation.

Base Functions has more details about all modules of this layer.