Overview

The eXtensible Service Bus (XSB) is a development and runtime environment dedicated to complex distributed applications. In the Future Internet (FI) such applications will be based, to a large extent, on the open integration of extremely heterogeneous systems, such as lightweight embedded systems (e.g., sensors, actuators and networks of them), mobile systems (e.g., smartphone applications), and resource-rich IT systems (e.g., systems hosted on enterprise servers and Cloud infrastructures).

Such heterogeneous systems are supported by enabling middleware platforms, particularly for their interaction. With regard to middleware-supported interaction, the client-service (CS), publish-subscribe (PS), and tuple space (TS) paradigms are among the most widely employed ones, with numerous related middleware platforms, such as: Web Services, Java RMI for client-server; JMS, SIENA for publish-subscribe; and JavaSpaces, LIME for Tuple space.

XSB provides support for the seamless integration of heterogeneous interaction paradigms (CS, PS and TS). A high-level representation of our approach is depicted in Figure 1.

Figure 1. Complex application interoperability.

How does it work

Our systematic interoperability approach is carried out in two stages. First, a middleware platform is abstracted under a corresponding interaction paradigm among the three base ones, i.e., CS, PS and TS. To this aim, we elicit a connector model for each paradigm, which comprehensively covers its essential semantics. Then, these three models are abstracted further into a single generic application (GA) connector model, which encompasses their common interaction semantics. Based on GA, we build abstract connector converters that enable interconnecting the base interaction paradigms.

Specifically, we realize our interoperability solution as an eXtensible Service Bus, which is an abstract service bus that employs the GA connector model as its common bus protocol. Furthermore, we provide an implementation of XSB, building upon existing SOA and ESB realizations. XSB features richer interaction semantics than common ESBs to deal effectively with the increased heterogeneity of FI. Moreover, from its very conception, XSB incorporates special consideration for the cross-integration of heterogeneous interaction paradigms. Services relying on different interaction paradigms can be plugged into XSB by employing binding components (BCs) that adapt between their native middleware and the common bus protocol. This adaptation is based on the abstractions, and in particular on the conversion between the native middleware, the corresponding CS/PS/TS abstraction, and the GA abstraction, as depicted in Figure 2.

Figure 2. eXtensible Service Bus.

Demo

Targeted audience

The architecture of an XSB Binding Component as provided by our architectural framework is depicted in Figure 3, where the main components are the interface description language (IDL) Processor, Core Engine, and Envelope for Substrate Bus:

• The xDL Processor processes the descriptions of services deployed on the XSB.
• The Core Engine provides mechanisms to:
1. transform and map between service data and CS/PS/TS/GA XML data
2. execute service primitives, and map between them and CS/PS/TS/GA primitives
3. manage connections to the service middleware
• Finally, the Envelope for Substrate Bus makes the BCs deployable on top of different substrate buses.

Figure 3. Binding Component architecture.

Thus, the developers who may use our framework may be classified in three categories:
Application developer: A developer wishing to deploy a new service on the XSB should write an xDL description of the service, and then invoke the tools provided by our solution to generate a service archive deployable on the bus.
Middleware developer: A developer wishing to develop a new XSB Binding Component in order to support a new middleware platform should refine the interaction paradigm level of the xDL Parsers, the Binding Component Core Engine, and the Envelope for EasyESB Binding Components, and thus produce a new middleware platform level for the specific middleware platform.
Interaction paradigm developer: A developer wishing to support a new interaction paradigm should refine the generic level of the xDL Parsers and the Binding Component Core Engine, and thus produce a new interaction paradigm level for the specific interaction paradigm.