Reusable Coordination Components: Reliable Development of Cooperative Information Systems

Abstract

Today's emerging trends like factory of the future, big data, Internet-of-things, intelligent traffic solutions, cyber-physical systems, wireless sensor networks, smart home, smart city and smart grid raise new challenges on software development. They are characterized by high concurrency, distribution and dynamics as well as huge numbers of heterogeneous devices, resources and users that must collaborate in a reliable way. The management of the interactions and dependencies between the participants is a complex task posing massive coordination problems. The here proposed approach is twofold: (i) to analyze similarities in the communication and synchronization behavior of such applications and to identify coordination patterns; and (ii) to give a precise specification of them by means of a suitable coordination model which enables the development of coordination pattern-based software components as solutions. The vision is to compose advanced cooperative information systems from proven, configurable, reusable, generic components that run on a suitable target platform, in order to reduce software development time, risks and costs. In this paper we delimit the idea of "coordination patterns" from other related pattern approaches and motivate the need for a well-defined model to specify them. Several coordination models to achieve this goal are discussed, and the advantages of a new coordination model termed the "Peer Model" are pointed out. The feasibility of the approach to identify coordination patterns, to model them and to provide generic components that can be reused in different scenarios through configuration and composition is evaluated by means of a coordination pattern found in several industrial use cases.

Distributed Coordination Runtime Assertions for the Peer Model

“…The Peer Model [15] is a coordination model that relies on known foundations like shared tuple spaces [10,11,17], Actor Model [2], and Petri Nets [20]. It clearly separates coordination logic from business logic and is well suited to model reusable coordination solutions in form of patterns.…”

“…The development of coordination is complex because of the asynchronous nature of distributed systems. Coordination models like the Actor Model [2], Petri Nets [20], Reo [3] and the Peer Model [15] are well suited to model the interactions in concurrent systems. They allow reasoning about coordination at a certain abstraction level.…”

Flexible Transactional Coordination in the Peer Model

“…The Peer Model [2,8] is a coordination model with high-level modeling abstractions for concurrent and distributed systems: A peer relates to an actor in the Actor Model [5]. It is an autonomous worker with ingoing and outgoing mailboxes, termed input and output containers (PIC and POC).…”

“…Lprop is a set of system properties, e.g. : tts (time-to-start: how long the link execution must wait to start; default is 0), ttl (time-to-live: how long the link execution may be retried until it succeeds; if it expires, a system entry of type exception is created that wraps the original entry and provides the type of the original entry in a property termed ettl; default is infinite), dest (specifies the id of a destination peer to which all selected entries on an action link are automatically transported via intermediary I/O peers [2]), flow (if true (default), the link transports only "flow-compatible" [2] entries -this means that the fid of all entries transported by links of this WTX must be the same or not set), and mandatory (if true (default), the fulfillment of the link is obligatory).…”

“…Separating coordination from application logic and providing precise models of the coordination is crucial in order to gain robust, distributed software systems [1]. The coordination pattern approach [2] suggests generalizing the aspects of how the participating and distributed processes interact. This enables coordination generics to become reusable among different applications and domains.…”