Introduction
Event-based communication styles are potential solutions for facilitating high flexibility, scalability, and concurrency of distributed systems due to the intrinsic loose coupling of the participants. Moreover, the loose coupling nature enables better support for changes at run-time. Unfortunately, there are numerous modeling and development challenges. On the one hand, software engineers often find the event-driven communication style unintuitive (with respect to other paradigms such as remote procedure calls, remote method invocations, or messaging), especially for large and complex systems with numerous constituting elements, because of its non-deterministic characteristics. On the other hand, existing methods and techniques for analyzing and understanding event-based software systems mainly focus on low-level interactions such as Pub/Sub and/or message passing models. The lack of high-level abstractions and notations hinder the maximum leverage of event-based systems.
Dynamic Event-driven Actors (DERA) is an approach aiming at providing adequate means for modeling and developing (distributed) event-based systems. DERA exploits the intrinsic loose coupling of event-driven communication styles to support various kinds of run-time evolution and adaptation (i.e., enabling run-time flexibility) while minimizing the non-deterministic nature of traditional event-based applications (for supporting formal analysis).
In particular, well-defined communication interfaces of actors are introduced in order to enable us to capture a representation of a DERA system at a certain point in time for a variety of purposes such as monitoring and formal analysis. This does not reduce the flexibility of event-based systems as actors’ interfaces can be changed at any point in time. For describing an event-based system, DERA provides graphical notations and identical textual constructs that are based on traditional behavior abstraction, and therefore, close to the perception of the developers.
Interested in pursuing your bachelor or master thesis, doctoral dissertation, or discussing the aforementioned topics? Please us send an email or drop by our offices (Huy Tran @ 5.40, Uwe Zdun @ 5.29, Simon Tragatschnig @ 5.21)
Basic concepts
The first-class concepts of DERA are event actors and events. An event actor (or actor for short) is the abstraction of a computational unit that performs a certain task (e.g., invoking a service, accessing data, transforming data, etc.). The execution of an event actor is often triggered by its input events. At the end of its execution, an actor will emit some events that in turn may trigger other actors.
A DERA system can be considered as either a collection of related event actors and events. The flexibility of DERA relies on the idea that each event actor concentrates on its own task, its required events, and the events that it is going to emit. There are no physical dependencies among actors except the conceptual links that are captured by analyzing their inputs and outputs. The loose coupling among event actors aims at a better scalability of DERA. That is, event actors can be distributed for better load balancing and/or optimal performance. For better run-time governance activities such as deployment, management, monitoring, and so on, event actors and events can be grouped into logical units, namely, DERA execution domain. An execution domain can embrace one or many DERA actors and events and is enacted by an underlying DERA engine. Two different DERA execution domains can interact by having appropriate event bridges–special actors that can transport events (with or without filtering the flow of events) from one execution domain to another.
DERA in Action
Distributed Execution
Inside a typical DERA execution domain, there are several event actor sharing one or many event channels. An actor can wait for (or require) one or a number of events. Its execution will be triggered whenever the required events are available. After its execution, the event actor will emit all of its output events, which in turns can trigger the execution of other actors. As a result, the particular flow of execution of a number of event actors can be used to fulfill a certain business task. We can logically define a DERA application by specifying one or many starting events and ending events. The execution of a DERA application can be distributed over several DERA execution domains in order to achieve better performance or throughput. The connection between DERA execution domains is achieved by using event bridges.
Formal Analysis Support
For formal verification, DERA concepts and notations can be mapped to existing formalisms for concurrent systems such as CSP, CCS, Π-calculus, Petri Nets, to name but a few.
One of our recent studies reported our first attempt in mapping a DERA description onto Petri nets. Petri nets provide sufficient expressiveness for modeling the DERA constructs, and they are extensively studied and used in both academia and industry in various application domains. As a result, we can benefit from numerous analysis techniques that have been developed for Petri Nets as well as a plethora of verification tools.
The picture depicts a snapshot of a DERA application captured at certain point in time and translated into Petri nets for verification using the tool WoPeD.
Related Techniques
The notion of action is borrowed from the Actor model proposed by Carl Hewitt and follow-on studies. The distinction between DERA model and Actor model can be summarized as following.
- DERA actors (or more precisely, event-based actors) do not know each other (i.e. a DERA actor is unaware of the existence of the other actors)
- Communication among DERA actors are carried out by sending/receiving events via event channels
- The interfaces of a DERA actor is explicitly defined and can be changed at any point in time.
- A DERA actor is not allowed to create new actors
- The computation attached to a DERA actor is triggered by the incoming events, not by the will of the containing actor.
- The output events are emitted after the execution of the computation attached to a DERA actor (if any), not by the will of the containing actor (in some special cases, for instance, actors defined for describing control flow such as decision/if-then-else, the output events depend on the value of the predicate attached to the corresponding actors).
Publications
- H. Tran and U. Zdun, “Event-driven Actors for Supporting Flexibility and Scalability in Service-based Integration Architecture“. In CoopIS: Proceedings of the 20th International Conference on Cooperative Information Systems, 2012, pp. 164–181. [pdf] [slides]
- S. Tragatschnig, H. Tran, and U. Zdun, “Change Patterns for Supporting the Evolution of Event-based Systems“. In CoopIS: Proceedings of the 21st International Conference on Cooperative Information Systems (CoopIS), pp. 283-290, Graz, Austria, 2013. [pdf]
- H. Tran and U. Zdun, “Event Actors Based Approach for Supporting Analysis and Verification of Event-Driven Architectures“. In EDOC: Proceedings of the 17th IEEE International Enterprise Distributed Object Computing Conference (EDOC), Vancouver, Canada, pp. 217-226, 2013. [pdf] [slides]
- S. Tragatschnig, H. Tran, and U. Zdun, “Impact Analysis for Event-based Systems using Change Patterns”, in Proceedings of the 29th Annual ACM Symposium on Applied Computing – SAC’14, Gyeongju, Korea, 2014. [pdf]
- S. Tragatschnig and U. Zdun. Modeling change patterns for impact and conflict analysis in event- driven architectures. In 24th IEEE International Conference on Enabling Technologies: Infrastructure for Collaborative Enterprises, International track on Adaptive and Reconfigurable Service-oriented and component-based Applications and Architectures., June 2015.
Development
Source
- GIT (authentication needed)