| Objectives |
Our work on dynamic CONNECTor synthesis aims at devising associated automated and compositional approaches, which can be performed at run-time. Starting from (i) the respective interaction behaviour of networked systems modelled as a LTS, and (ii) their ontology-based specification, we want to synthesize the behaviour of the CONNECTors needed for them to interoperate.. These CONNECTors serve as mediators of the interactions of networked systems at both application- and middleware-layers.
|
| |
Our objectives subdivide into :
- Synthesis of application-layer conversation protocols: the goal here is to identify connectors patterns that allow the definition of methodologies to automatically synthesize, in a compositional way and at run-time, application-layer CONNECTors.
- Synthesis of middleware-layer protocols: our objective here is to generate adequate protocol translators (mappings) that enable heterogeneous middleware to interoperate, and realize required non-functional properties, thus successfully interCONNECTing networked systems at the middleware level.
- Model-driven synthesis tools: we exploit model-to-model and model-to-code transformation techniques to automatically derive, at run-time, a CONNECTor’s actual code from its synthesized model. This step should guarantee the correctness-by-construction of the CONNECTor’s implementation with respect to the functional and non-functional requirements of the networked applications that are made interoperable through the CONNECTor.
Overview of the Automated CONNECTor Synthesis Approach
Starting from two protocols, P and Q, that differently implement similar functionalities, if possible, we want to automatically synthesize at run-time a mediator that makes the two protocols able to interoperate. The figure below depicts the overall idea.
|
| The dynamic CONNECTor synthesis process |
| Step1: Middleware Abstraction |
 |
abstract from the middleware specific information hence producing a middleware-agnostic LTS
the applied middleware abstraction rules are stored in order to reuse them backwards when performing concretization (see Step4). |
Step2: Common Abstraction
The objective is to check (in Step 3) whether the middleware-agnostic LTSs model (even partially) a common interaction protocol, or not. Thus, in order to perform this check, in this step, we want to check first if the middleware-agnostic LTSs can share, at least partially, the same alphabet, at a certain level of abstraction. |
 |
By taking into account the ontology-based specification of each networked system and the common ontology specification, this step checks whether the middleware-agnostic LTSs can (at least, partially) be expressed in terms of a common alphabet. If it is the case, each middleware-agnostic LTS is accordingly abstracted hence producing its corresponding abstract LTS. |
Step1 and Step2 allows for reasoning on more abstract models of the networked systems’ interaction behavior hence addressing, to some extent, scalability issues. |
Step3: Abstract Connector Synthesis |
 |
matching check: the existence of common traces that lead the two systems to achieve a common goal is automatically checked
mapping: if at least one common trace has been found (and it leads to achieve the specified common goal), the mapping between the two LTSs, over the common traces, is automatically performed hence producing the LTS that models the interaction behavior of the abstract connector. At this stage, the connector LTS is abstract since it is expressed in terms of the common (abstract) alphabet inferred at Step 2.
|
Step4: Abstract Connector Concretization |
 |
First, concretization exploits the ontological descriptions, previously used as means for abstraction, in order to apply them backwards and automatically produce a refined connector LTS
Second, by applying the previously stored midleware-absractionrules backwards, concretization also injects the middleware-specific information into the refined connector LTS hence producing the LTS of the concrete connector. |
Step5: Concrete Connector Code Generation |
 |
Automatically generate the actual code implementing the concrete connector out of the synthesized concrete connector LTS and a description of the networked systems to be connected and made interoperable. It exploits Model-To-Text transformation techniques. For instance, but not limited to, JET for a Java-based connector implementation. |
| |
Selected Publications
|
| Further Information |
| More information about the work on dynamic CONNECTor synthesis can be found from the Publications page. |
