Adopting Architectural Event Modules for Modular Coordination of Multiple Applications

Nowadays, large-scale software systems consist of multiple applications, which interact with each other to fulfill desired system-level requirements. It is usually required to coordinate the interactions of the constituent applications to ensure that the system-level requirements are fulfilled. In this paper, we outline a set of requirements that must be fulfilled to facilitate the modular composition of multiple applications. We introduce the concept of architectural event modules, which are abstractions to represent constituent applications and their coordination logic in a modular and uniform way. We explain the implementation of this concept in the EventReactor language, and define their formal semantics in processing events using the UPPAAL toolset. We illustrate the suitability of architectural event modules in achieving modularity and loose coupling in the composition of multiple applications by means of a case study in the domain of energy-efficient computing

An Overview of Event-based Facades for Modular Composition and Coordination of Multiple Applications

Complex software systems are usually developed as systems of systems (SoS’s) in which multiple constituent applications are composed and coordinated to fulfill desired system-level requirements. The constituent applications must be augmented with suitable coordination-specific interfaces, through which they can participate in coordinated interactions. Such interfaces as well as coordination rules have a crosscutting nature. Therefore, to increase the reusability of the applications and to increase the comprehensibility of SoS’s, suitable mechanisms are required to modularize the coordination rules and interfaces from the constituent applications. We introduce a new abstraction named as architectural event modules (AEMs), which facilitate defining constituent applications and desired coordination rules as modules of SoS’s. AEMs augment the constituent applications with event-based facades to let them participate in coordinated interactions. We introduce the EventArch language in which the concept of AEMs is implemented, and illustrate its suitability using a case study

An Overview of Language Support for Modular Event-driven Programming

Nowadays, event processing is becoming the backbone of many applications. Therefore, it is necessary to provide suitable abstractions to properly modularize the concerns that appear in event-driven applications. We identify four categories of languages that support event-driven programming, and identify their shortcomings in achieving modularity in the implementation of applications. We propose gummy modules and their implementation in the GummyJ language as a solution. Gummy modules have well-defined event-based interfaces, and can have a primitive or a composite structure. Composite gummy modules are means to group a set of correlated event processing concerns and restrict the visibility of events among them. We provide an example usage of gummy modules, and discuss their event processing semantics

Resolving feature convolution in middleware systems

Middleware provides simplicity and uniformity for the development of distributed applications. However, the modularity of the architecture of middleware is starting to disintegrate and to become complicated due to the interaction of too many orthogonal concerns imposed from a wide range of application requirements. This is not due to bad design but rather due to the limitations of the conventional architectural decomposition methodologies. We introduce the principles of horizontal decomposition (HD) which addresses this problem with a mixed-paradigm middleware architecture. HD provides guidance for the use of conventional decomposition methods to implement the core functionalities of middleware and the use of aspect orientation to address its orthogonal properties. Our evaluation of the horizontal decomposition principles focuses on refactoring major middleware functionalities into aspects in order to modularize and isolate them from the core architecture. New versions of the middleware platform can be created through combining the core and the flexible selection of middleware aspects such as IDL data types, the oneway invocation style, the dynamic messaging style, and additional character encoding schemes. As a result, the primary functionality of the middleware is supported with a much simpler architecture and enhanced performance. Moreover, customization and configuration of the middleware for a wide-range of requirements becomes possible