Project Topics
Get Complete Project Material File(s) Now! »
The Software Architecture Perspective: Understanding Interoperability
Software architecture abstractly describes the structure of software systems in terms of components and connectors: components are meant to encapsulate computation while connectors are meant to encapsulate interaction [Sha93].
In order to facilitate software composition and reuse, a component encapsulates some functionality to which it restricts access via an explicit interface [TMD09]. The interface of a component specifies the set of observable actions that the component uses to interact within its running environment in order to perform its functionality.
This set is partitioned into required and provided actions, with the understanding that required actions are received from and controlled by the environment, whereas provided actions are emitted and controlled by the component.
The architectural element tasked with effecting and regulating interactions between components is a connector [TMD09]. The implementation of a connector is often based on middleware [MDT03] since middleware provides reusable solutions that facilitate communication and coordination between components. For this purpose, middleware defines [ICG07]: (i) an Interface Description Language (IDL) for specifying the interfaces of components and the associated operations, and data types, (ii) a discovery protocol to address and locate the components that are available in the environment, (iii) an interaction protocol that coordinates the behaviour of different components and enables them to collaborate, and (iv) additional protocols to manage non-functional requirements such as dependability, security, fault-tolerance, and performance optimisation. However, while components and connectors are conceptually separate, the middleware used to implement a connector is often invasive in that it influences the implementation of the components. For example, the language used to describe the component’s interface differs according to the middleware implementation used, e.g., CORBA IDL in the case of CORBA-based middleware and WSDL in the case of SOAP-based middleware.
Figure 2.3 depicts the interaction between C2 and Weather Service. The interface of C2 includes three required actions req:login, req:getWeather, and req:logout. The interface of Weather Service encompasses three provided actions prov:login, prov:getWeather, and prov:logout. The connector Weather_Connector1 models the
interaction between C2 and Weather Service. Weather_Connector1 is implemented using SOAP, which also implies that C2 acts as a SOAP client when performing its required actions and Weather Service acts as a SOAP service when providing these same actions.
Similarly, Figure 2.4 depicts the interaction between the Weather Station component and its specific client. The interface of Weather Station specifies four provided actions prov:login, prov:getT emperature, prov:getHumidity, and prov:logout.
Weather Station Client exhibits the dual interface with required actions. The interaction between Weather Station and Weather Station Client is abstracted using
Weather_Connector2. The use of CORBA to implementWeather_Connector2 means that Weather Station Client carries out its required actions by sending CORBA requests and receiving CORBA responses while Weather Station provides its actions by receiving CORBA requests and sending CORBA responses.
Formal Reasoning about Interoperability
The first step towards reasoning about interoperability is by formalising component interactions. The behaviour of a component specifies its interaction with the environment and models how the actions of its interface are coordinated to achieve its functionality.
Different languages may be considered for the specification of a component’s behaviour.
Formal languages are a prerequisite for automated analysis of the component’s behaviour while standard, well-established languages (e.g., BPEL1 and CDL2) are easier for developers to deal with. We build upon pioneering work by Allen and Garlan [AG97], which uses process algebra to model the behaviours of components together with their interaction. More specifically, we use FSP (Finite State Processes) [MK06] based on the follow-up work by Spitznagel and Garlan, which in particular considers the transformation of connectors in order to address dependability as well as interoperability concerns [SG03]. It is worth noticing that there further exists a tool, WS-Engineer [Fos08], to convert BPEL and CDL specifications into FSP descriptions automatically. In this section, we present FSP and show how it is used to model interactions between components and reason about interoperability.
Formalising Components and Connectors using FSP
Based on pioneering work for formalising component interactions in software architecture [AG97], the behaviour of a component is modelled using ports while a connector is modelled as a set of roles and a glue. The roles specify the expected behaviours of the interacting components while the glue describes how the behaviours of these components are coordinated. More specifically, we consider the specification of the ports, roles, and glue as FSP processes.
To return to the example in Figure 2.4. To achieve the required weather functionality, C2 first logs in, invokes getWeather several times, and finally logs out. We specify this behaviour as follows: Since C2 interacts using SOAP, then each of the required actions is realised by invoking the appropriate operation op, which belongs to the set {login; getWeather; logout}, by sending a SOAP request and receiving a SOAP response, which is formalised as follows: SOAPClient (X =0 op) = (req:[X] ! sendSOAPRequest[X] ! receiveSOAPResponse[X] ! SOAPClient).
Reasoning about Architectural Mismatches
A component can be attached to a connector only if its port is behaviourally compatible with the connector role it is bound to. Behavioural compatibility between a component port and a connector role is based upon the notion of refinement, i.e., a component port is behaviourally compatible with a connector role if the process specifying the behaviour of the former refines the process characterising the latter [AG97].
This refinement implies the inclusion of the traces of the expected behaviour of the component in those of the observed behaviour of the component. In other words, it should be possible to substitute the role process by the port process. Refinement gives an intuitive notion of correctness (at least for safety properties), and it has been applied in the stepwise design and implementation of software systems, starting from their more abstract specification. Such reasoning exploits the expressive and deductive power of the mathematics of sets and sequences [Hoa04].
For example, C2 can be attached toWeather_Connector1 since C2_weather_port refines C2_weather_role —they are actually defined the same way. Likewise, WeatherStation_port refines WeatherStation_role defined by Weather_Connector2. However, WeatherStation_port cannot be attached to Weather_Connector1 since it does not refine any of its ports, nor can C2_weather_role be attached to Weather_Connector2. Hence, in the case of C2 willing to interact with Weather Station, none of the available connectors can directly be used, resulting in an architectural mismatch. Verifying behavioural compatibility between components’ ports and connectors’ roles allows us to check the presence or absence of architectural mismatches and also to suggest a solution. To solve architectural mismatches, we must find or create a connector whose roles are refined by components’ ports. Such a connector is called a mediator.
Mediators to Support Interoperability
To enable interoperability between functionally-compatible components, the mediator must solve architectural mismatches by reconciling the conflicting assumptions that the components make about their environment. We recall that these assumptions relate to: (i) the interfaces and behaviours of the components involved, (ii) the behaviours and implementations of the connectors used, and (iii) the operating systems and the hardware of the devices on top of which the components are deployed. To solve the differences between the interfaces of components, the mediator must translate the actions required by each of them into actions provided by the other. Note that the mediator facilitates interaction —it is a connector— but does not provide any action itself since it does not encapsulate computation. To solve the differences between the behaviours of components, the mediator must coordinate the exchange of information between these components by controlling which action should be delivered to which component at which time. To solve the differences between the behaviours and implementations of connectors, the mediator must provide
a concrete solution to coordinate the interaction patterns of these connectors acting as middleware, which not only makes the application agnostic to the operating systems, but also to the middleware used by other components.
For example, Figure 2.5 depicts a mediator between C2 andWeather Station. This mediator translates the getWeather action required by C2 into the getT emperature and getHumidity actions provided by Weather Station. The mediator also ensures that whenever C2 requires getWeather, both getT emperature and getHumidity are executed. Finally, the mediator transforms the SOAP requests emitted by C2 into CORBA requests that can be processed by Weather Station, and transforms the CORBA responses sent by Weather Station into SOAP responses expected by C2. It is not always possible to find an existing connector for managing interaction about functionally-compatible components and it is difficult and time consuming to design and implement a new connector from scratch, especially if the components already exist and are implemented using different middleware solutions [MDT03]. Compositional approaches for connector construction facilitate the development of mediators by reusing existing connector instances.
Table of contents :
Contents
List of Figures
List of Tables
1 Introduction
1.1 Motivation
1.2 Case Studies
1.3 Influences
1.4 Contributions
1.5 Thesis Outline
2 Interoperability: A Landscape of the Research Field
2.1 The Software Architecture Perspective: Understanding Interoperability
2.1.1 Formal Reasoning about Interoperability
2.1.2 Mediators to Support Interoperability
2.1.3 Mediation in Ubiquitous Computing Environments
2.2 The Middleware Perspective: Implementing Mediators
2.2.1 Universal Middleware
2.2.2 Middleware Bridges
2.2.3 Service Buses
2.3 The Formal Methods Perspective: Synthesising Mediators
2.3.1 Mediator Synthesis Using a Specification of the Composed System
2.3.2 Mediator Synthesis Using a Partial Specification
2.4 The Semantic Web Perspective: Mediation at Runtime
2.4.1 Ontological Modelling and Reasoning
2.4.2 Semantic Web Services
2.4.3 Semantic Mediation Bus
2.5 Summary
3 Achieving Eternal Interoperability: The Role of Automated Mediator Synthesis
3.1 The Connect Approach to Eternal Interoperability
3.2 Modelling Components
3.3 Emergent Middleware
3.4 Emergent Middleware Enablers
3.4.1 Discovery Enabler: Locating Components
3.4.2 Learning Enabler: Completing Component Models
3.4.3 Synthesis Enabler: Synthesising Mediators
3.5 Summary
4 Automated Synthesis of Mediators
4.1 The File Management Example
4.2 Specification of Interface Matching
4.2.1 One-to-One Matching
4.2.2 One-to-Many Matching
4.2.3 Many-to-Many Matching
4.3 Computation of Interface Matching using Constraint Programming .
4.3.1 Complexity of Interface Matching
4.3.2 Interface Matching as a Constraint Satisfaction Problem .
4.3.3 Leveraging Constraint Programming for Ontological Reasoning
4.4 Synthesising Correct-by-Construction Mediators
4.5 Summary
5 From Abstract to Concrete Mediators
5.1 The Case of the Same Middleware
5.1.1 From Ontological Relations to Data Translation Functions .
5.1.2 Application to the File Management Example
5.2 The Case of Different Middleware Based on the Same Interaction Pattern
5.2.1 Ontology-based Modelling of Middleware Interaction Patterns
5.2.2 Application to the Weather Example
5.3 The Case of Middleware Based on Different Interaction Patterns
5.3.1 Coordination across Interaction Patterns
5.3.2 Application to the Positioning Example
5.4 Summary
6 Implementation & Assessment
6.1 The MICS tool
6.2 Case Studies
6.2.1 Instant Messaging: One-to-One Matching
6.2.2 File Management: One-to-Many Matching
6.2.3 Purchase Order: Mediation of Semantic Web Services
6.2.4 Event Management: Unified Application-Middleware Mediation
6.2.5 GMES: Runtime Mediation
6.3 Performance of MICS
6.4 Summary
7 Conclusion
7.1 Contributions
7.2 Future Work
7.2.1 Mediator Synthesis as a Service
7.2.2 Mediator Evolution
7.3 One More Thing..
Appendix A FSP Syntax & Semantics
Appendix B DL Syntax & Semantics
References
