Invited talk by Paola Inverardi. As my PhD dissertation was all about components and their (asynchronous) interaction, I’m very curious. Social means that you come together to do enjoyable things together. So, imagine systems that on the fly want to interact or cooperate, how can architecture play a role in this?
Software architecture defines the structures, components and their interactions. Politeness then can be translated to e.g. the absence of deadlocks, or desired behavior. It reminds me of one of my propositions: the ideal partner may give the answer before the question has been raised (but for the protocol, the question still needs to be asked).
Okay, back to the talk. Interactions are protocols of observable actions, and connectors define which protocols can be used. This notion is quite close to the topic of behavioral types in the computing science research. The purpose should be everytime simple proofs, so keep protocols simple (but it is not, as can be seen in many of my papers). In process algebra, one can define roles (or processes), but also need a “glue”-process that binds these processes. This is inherent to the synchronous communication in process algebra.
An initial case study was done on gzip, by modelling each of the components with automata, and then check whether their composition does not have any deadlocks. But, this is done with complete knowledge of the system. What if we have incomplete knowledge? Can we guarantee politeness? The idea is yes: if we filter on masking un-polite behavior (through connectors, mediators, adapters, etc.). This can be enforced by synthesis filters once we know the SA style we rely on.
The synthesis problem is as follows. Given some components, how can we define the connectors?. One way can be to add a coordinator, which should be manually defined. This coordinator should enforce good behavior. She calls this the Coordinator Based Architecture (CBA). Coordinator Free Architectures is the direct synchronous composition of these components. The idea is that the composed system should have equivalent behavior, except for the bad behavior. But then, the behavior of the context is just the behavior of the coordinator. This can be extended to a reference architecture that designs the coordinator, but then distributed:
The notion of components became old-fashioned, and more interest came into systems-of-systems: systems that need to cooperate on the fly, to achieve a common goal G. Then, interoperability is the problem both at middleware and application level. Therefore, they switch to labeled transition systems, with final states. The final state then resembles the desired goal. In that case, one can use the “old” coordinator style, but also for mediators. Given two protocols, a mediator creates a mapping (through ontologies) and then generates a coordinator. Thus, in fact a mediator is an adapter that is generated on the fly through ontologies, which sounds very much like the SEA-rules by Arjan Mooij, e.g. [1], [2].
So, is this useful for the future? In Paola’s opinion, yes! The developer becomes more and more an integrator. Such theory can help in building, but we need mining: models through experimental observation. How can we mine protocols? That will be the future!
This all resulted to the development of choreography languages: choreography-based service oriented architecture. Realizability then becomes an important problem:
Coordinators / mediators can help in creating filters to prevent these interactions.
There is a lot of theoretical knowledge in the scientific domain, but this need to be brought to practice. It can be practical for software production thanks to composability, architecture and advancing in formal methods.