       
@ 2013 - Site Map - Credits |
 |
CONNECTing Eternal Systems |
| |
|
| Objectives |
|
Complex pervasive systems are characterised by two important properties:
- extreme heterogeneity in terms of device types, networking technologies, network protocols, middleware protocols, and applications;
- spontaneous communication, where systems and services only become aware of each other at runtime, and must connect and communicate dynamically.
A fundamental requirement is that these technology dependent islands must be able to interoperate with one another at runtime i.e. they are able to: connect, understand and exchange data.
Middleware has generally been used as the enabling technology in terms of achieving interoperability. However, today’s middleware technologies are demonstrably unsuited to this task; in practice they add to the heterogeneity problem e.g. CORBA middleware does not interoperate with Web Services middleware.
Objectives
The CONNECT project aims to resolve the heterogeneity barrier and enable the continuous composition of networked systems independently of the deployment and implementation technologies. Rather than create a middleware solution destined to be yet another legacy platform, CONNECT proposes emergent middleware, i.e.,where such middleware provides runtime interoperability between two systems that spontaneously interact on the fly. CONNECT synthesizes CONNECTors that resolve interoperability at the data (e.g., heterogeneous data formats), application protocol (for example, different instant messaging or printing protocols) and middleware protocol (e.g., different service discovery or RPC protocols) layers.
The aim of WP1 is to provide the overall technology-independent architecture for these CONNECTors, and the system principles and techniques that will realise their dynamic deployment. Semantics play an important role in the understanding of heterogeneous applications and middleware data and protocols; hence WP1 also investigates the role of ontologies in underpinning the interoperability solution. Finally, WP1 acts as the point of integration for all the CONNECT work packages to ensure that the contributions of each WP can work together to complete the CONNECT approach.
|
|
Tackling Interoperability |
Our analysis of complex pervasive scenarios has shown that if interoperability is to be achieved the following dimensions of interoperability must be resolved:
- Discovery protocol interoperability. It should be possible for services to advertise to, and find one another irrespective of the discovery protocol they themselves employ.
- Interaction protocol interoperability. Two or more services whose interaction protocol (e.g. RMI, messaging, etc.) differ can be bound together in order to interoperate.
- Data interoperability. The application data of the services must be semantically equivalent between the two parties, and transformed to a format that the receiver can understand and process (after the binding between the heterogeneous protocols has been created).
- Application Interoperability. Differences between application interfaces can be resolved.
- Interoperability of Non-functional properties. Interoperability can be achieved between systems while maintaining the non-functional properties of each.
Many interoperability solutions have looked at one or more of these dimensions; but none has considered all of them. Hence, it is here that Connect makes significant contributions to the state of the art in distributed systems.
|
The CONNECT Architecture |
The CONNECT architecture is a distributed system that seeks to ensure that Networked systems are able to interoperate. Where these networked systems are systems that manifest the will to connect to other systems for fulfilling some intent identified by their users and the applications executing upon them.
Enablers are networked entities in the environment of networked systems that incorporate all the intelligence and logic offered by CONNECT for enabling connection between heterogeneous networked systems. Enablers constitute the CONNECT Enabler architecture. Each is implemented as a software component that communicates using the Java Messaging Service.
|
|
From a high-level perspective, the enabler architecture behaves as follows to create the eternal CONNECTor between two systems (the Connector is the software deployed between two systems to resolve heterogeneity and achieve interoperability):
- Triggered by one or more networked systems manifesting their will to connect, the Discovery enabler identifies the networked systems that have similar goals and intents, and communicates this information to the Learning enabler.
- Learning infers the interaction behaviour of the identified networked systems; an active learning algorithm that interacts directly with each networked system (using the Interaction enabler to distribute these communications correctly) to learn its behaviour. This elicits (as precisely as possible) a partial CONNECTor model, which the Learning enabler sends to the Synthesis enabler.
- The Synthesis enabler then generates a CONNECTor model able to bridge the heterogeneous partial CONNECTor models. By successive model-to-model transformations, synthesis generates appropriate models of the CONNECTor.
- The models are then sent to the DePer, Security and Trust enablers which analyse them against the required non-functional properties. This verification & validation (V&V) evaluates the CONNECTor offline and provides feedback to synthesis, which may lead to reconfiguration or resynthesis of the CONNECTor model.
- At the end of this synthesis and evaluation cycle, Synthesis produces an executable CONNECTor in the form of a k-Coloured automaton that is sent to the Deployment enabler which deploys it as a CONNECTor between the two networked systems.
- The CONNECTor is monitored by the Monitoring enabler and events of interest sent to the DePer, Security and Trust enabler which analyse the running behavior against the non-functional requirements. In case of negative evaluation these enablers provide feedback to synthesis triggering a resynthesis of the CONNECTor model and consequently re-deployment.
 |
A CONNECTor is a composed of the following key architectural elements:
- A Listener receives network messages (from the Network Engine) in the form of data packets and parses them according to the message format employed by the protocol that this message is specified by. Hence, each Listener parses messages from a single protocol, e.g., a SOAP listener parses SOAP messages. A listener produces an Abstract Message that contains the information found in the original data packet, providing a uniform representation that can be manipulated and understood by the other elements in the CONNECTor.
- An Actuator performs the reverse role of a listener, i.e., it composes network messages according to a given middleware protocol, e.g., the SOAP Actuator creates SOAP messages. Actuators receive the Abstract Message and translate this into the data packet to be sent on the network via the Network Engine.
- The Mediator forms the central co-ordination element of a generated CONNECTor. Its role is to translate the content received from one protocol (in the form of an AbstractMessage) into the content required to send to the corresponding protocol. The mediator therefore addresses the challenges of: different message content and formats, and different protocol behaviour, e.g., sequence of messages. A mediator is specified as a merged k-Coloured Automaton understandable by the Starlink framework (http://starlink.sourceforge.net).
- The Network Engine provides a library of transport protocols with a common uniform interface to send and receive messages. Hence, it is possible to receive messages and send messages from multicast (e.g. IP multicast), broadcast and unicast transport protocols (e.g. UDP and TCP).
- The Mediator engine dynamically interprets the specification of a mediator; coordinating the execution of transitions in order to send and receive messages specific to the underlying middleware protocols.
 |
Further Information |
More information about the work of WP1 can be found in the following publications:
|
|
