Starlink: Runtime Interoperability between Heterogeneous Middleware Protocols

Yerom-David Bromberg, Paul Grace, Laurent Réveillère
2011 2011 31st International Conference on Distributed Computing Systems  
Interoperability remains a challenging and growing problem within distributed systems. A range of heterogeneous network and middleware protocols which cannot interact with one another are now widely used; for example, the set of remote method invocation protocols, and the set of service discovery protocols. In environments where systems and services are composed dynamically, e.g. pervasive computing and systems-of-systems, the protocols used by two systems wishing to interact is unknown until
more » ... ntime and hence interoperability cannot be guaranteed. In such situations, dynamic solutions are required to identify the differences between heterogeneous protocols and generate middleware connectors (or bridges) that will allow the systems to interoperate. In this paper, we present the Starlink middleware, a general framework into which runtime generated interoperability logic (in the form of higher level models) can be deployed to 'connect' two heterogeneous protocols. For this, it provides: i) an abstract representation of network messages with a corresponding generic parser and composer, ii) an engine to execute coloured automata that represent the required interoperability behaviour between protocols, and iii) translation logic to describe the exchange of message content from one protocol to another. We show through case-study based evaluation that Starlink can bridge heterogeneous protocol types. Starlink is also compared against base-line protocol benchmarks to show that acceptable performance can still be achieved in spite of the high-level nature of the solution. • Abstract message representations. A domain specific language, Message Description Language (MDL), is used to describe protocol messages in terms of field content. This is used to dynamically generate message parsers and composers which correctly read and write messages to/from an abstract representation that is machine processable. • Coloured automata. Each protocol is described as an automaton that represents the sequence of received or sent abstract messages. The correct concrete sending and receiving of messages requires knowledge of lower level network semantics (e.g. address, port, multicast?), these are added as annotations to the transitions that 'colour' the automata; hence, an automata for the execution of multiple protocols will have more than one colour. • Translation logic. Starlink provides a translation language to model the translation from one protocol to another; this is described in two parts: i) a merged automata that represents the interoperability between two protocols in terms of the required exchange of messages, and ii) the translation logic for mapping the message content from messages in one protocol to the messages of the other. MDL: Protocol B Protocol A Automata Protocol B Models Protocol A Automata Protocol B Models Protocol A Abstract Abstract Application Network Engine Message Application Concrete Abstract Message Abstract Application Message Concrete Messages Abstract Messages Message Abstract Messages
doi:10.1109/icdcs.2011.65 dblp:conf/icdcs/BrombergGR11 fatcat:ftfyqs7wxndpriv6s5unzeoszy