         
@ 2011 - 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 therefore 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.
The CONNECT project aims to resolve the heterogeneity barrier and enables 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 our work regarding the definition of the CONNECT architecture 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, we also investigate the role of ontologies in underpinning the interoperability solution.
Finally, the architecture solution acts as the point of integration for all the CONNECT contributions to ensure that they 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 can make significant contributions to the state of the art in distributed systems. |
The CONNECT Architecture |
In our elaboration of the initial CONNECT architecture, we have opted for an approach that – at this step – makes the fewest possible assumptions and sets minimum constraints on the produced architecture. This has been motivated by the open, dynamic nature of the environments targeted by CONNECT, and by CONNECT's aim to make a breakthrough beyond technology and time barriers for enabling eternal systems
|
|
Accordingly, we identify the following actors in the CONNECT architecture:
- 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 enviromment of networked systems that incorporate all the intelligence and logic offered by CONNECT for enabling connection between heterogeneous networked systems. Enablers constitue the CONNECT enabling architecture.
- CONNECTors are the emergent connectors produced by the action of enablers.
- CONNECTed systems are the outcome of successful creation and deployment of CONNECTors.
|
The CONNECT process then behaves as follows to create the eternal CONNECTor between two systems:
- Triggered by one or more networked systems manifesting their will to connect, interoperable discovery and matching identifies the networked systems that are likely to be associated based on their a priori descriptions, and communicates this information to learning.
- Learning infers the interaction behaviour of the identified networked systems and completes their a priori descriptions, thus eliciting – as precisely as possible – their partial connector models, which it feeds into synthesis.
- Synthesis 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
- These models are required by verification & validation (V&V), which 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 performs a model-to-code transformation to generate an executable CONNECTor.
- Synthesis then deploys the CONNECTor code accomplishing a CONNECTed system, which executes; during this execution, the CONNECTor is able to self-reconfigure to respond to changes in its environment.
- The CONNECTed system execution feeds into the monitoring process.
- V&V monitors and evaluates the running system (including networked systems and CONNECTor) online.
- At the same time, learning also monitors the CONNECTed system to update and improve its learned models of the constituent networked systems (specifically, V&V and learning apply similar monitoring and model-based testing mechanisms).
- An evaluation of the networked systems or an update of the learned networked system models will be shared between V&V and learning.
- In case of negative evaluation of the CONNECTed system, or some problem detected during its execution, or some significant update of the learned networked system models, or some change of the networked systems or their environment, V&V provides feedback to synthesis triggering a resynthesis of the Connector model and consequently re-execution of all the steps that follow.
|
Further Information |
| More information about the work on CONNECT architecture can be found from CONNECT Publications and in the following presentation:
|
|
