PCM Event-Based Communication

Aus SDQ-Wiki

Introduction

In 2010 the integration of event-based communications into the Palladio Component Model started and was finished in 2012. Before, components were only able to communicate synchronously through operation calls. The meta model has been extended with first class entities to model event-based communication as an explicit architectural decision.

To understand the characteristics of event-based communication, on can think of three dimensions defined by Eugster et al [EFGK03]. These dimensions describe the decoupled communication between two components:

  • space - The event producer and consumer(s) do not need to know each other
  • time - The event producer and consumer(s) do not need to be active at the same time
  • synchronisation - The event producer does not need to wait for the consumer(s) to process his event.

One of the main advantages of event-based communication is the gained scalability of the many-to-many communication that did not exist in the PCM before. Another big advantage is the asynchronous communication that does not block the event-producer while waiting for the consumer.

In comparison to general message oriented middleware, it should be noticed that events are only about information not about any processing instructions. An event can not include an operation instruction because the producer does not need to know who will consume the event. Furthermore, this concept provides more flexibility in adding new consumers with different event processings.

Events in the Palladio Component Model

Repository

Repository Editor with an EventGroup

The architect can specify EventGroups in the repository and EventTypes that belong to this EventGroup. As shown in the screenshot on the right, an EventGroup is identified with a white capital E on a green disc. This EventGroup contains the EventTypes specified with a grey capital E on a white sheet. The properties of an EventType contain a parameter that describes the EventType in more detail.

Comparable to the interfaces, components can be linked with EventGroups. These links represent the roles of a component in relation to the EventGroup. The possible roles are the SourceRole that identifies that a component emits a specific type of events. It is identified with a <<Emits>> label. The other roles is the SinkRole that identifies a component to be able to handle the events of an EventGroup. It is identified with an <<Handles>> label.

SEFF

SEFF Editor with an EventGroup

The PCM meta-model includes an EmitEventAction to specify the point in time when a component emits a new event. The figure on the right contains an example of a SEFF with an EmitEventAction. As illustrated, this action can contain VariableUsages to describe the performance relevant characterisations of the emitted event. Furthermore, the action contains a reference to the EventType it is able to emit and the SourceRole it will trigger.






System

System Editor with an event-based connection

In the system editor, the architect is able to connect source and sink roles that reference the same EventGroup. As illustrated in the screenshot on the right, there is a specific graphical notation for source and sink roles. A SourceRole is identified by a lollipop element with a triangle as a head. A SinkRole is identified by a lollipop with a counterpart for the triangle. The creation tool pallette of the editor provides a specific AssemblyEventConnector to linkt these two elements. As illustrated in the screenshot, the architect is able to connect one source with multiple sinks. He is also able to link multiple sources to one sink.






Middleware Repository

Transformation to handle Event-Based Communication

The PCM meta-model provides facilities to model event-based communication as an explicit design decision on a high architectural level. Nevertheless, to gain reasonable quality predictions, it is important to take middleware specific quality attributes into account. Furthermore, for a given architecture an architect might need to estimate the impact of different middleware products or configurations of the same product.

The palladio workbench performs a model transformation as part of the simulation to weave a middleware repository into the overall high-level architecture model. This architecture model is a reusable artifact and if modelled once, it can be weaved into different architectures.

Possible Middleware Design Decisions

The implemented concept to process the event related model elements, the architect can influence the middleware simulation in two different dimensions. Firstly, he is able to specify the middleware components that implement the middleware specific interfaces. Secondly, he is able to specify a dedicated middleware node in his resource environment and the transformation will deploy the middleware components providing the central interfaces on this infrastructure node.

Middleware Components

Middleware Interfaces, Components and Examples of Alternatives

During the transformation, the original event-based communication is replaced with a generic component chain that implements the data flow between the source and the sink components. This chain does not include any resource demands but takes care for the asynchrounous many-to-many connections. In addition, it defines possible hooks to call interface components that define the real resource demands of the middleware.
The concrete middleware configured in the process encapsulates the decision of using the hooks or not.
When the transformation is executed, it performs a lookup in the middleware repository for interfaces with specific names for the individual hooks. If there is a component that provides an interface according to a specific hook, it will be weaved into the generic component chain. If there is none matching the actual name, nothing will be weaved in.

The figure on the right illustrates the available hooks and their position in the component chain. The calls are always performed as a first action within a generic component. Furthermore, it illustrates that it is possible to weave in different middleware repositories. Only the names and parameters of the interfaces are fixed.

SBUS Middleware Example Repository

The names of the possible middleware interfaces are case sensitive. Each interface has to specify an according signature with a parameter named "event". The concrete type of the parameter does not matter but must not be a ComplexType. ComplexTypes are not supported yet by the wiring process.

  • IMiddlewareSourcePort
    • handleSourcePort(event)
  • IMiddlewareSourceCommunication
    • handleSourceCommunication(event)
  • IMiddlewareEventDistribution
    • handleEventDistribution(event)
  • IMiddlewareFilter
    • handleFilter(event)
  • IMiddlewareSinkCommuication
    • handleSinkCommunication(event)
  • IMiddlewareSinkPort
    • handleSinkPort(event)

The download section of this page provides an example middleware repository.

Resource Environment

The transformation automatically deploys the middleware components. If there is a central middleware server, the according resource container must have the name "Middleware". If such a resource container can not be found, the middleware components are deployed on the same resource containers as the sink and the source component.

Simulation

Completion Dialog for the Type Selection

The modelling and transformation presented above result in a classic pcm model that can be used as input for all available prediction techniques in the pcm. Nevertheless, the automated transformation is only integrated into the simulation. If other solution techniques are used the transformation script has to be downloaded executed manually.

Note: The usage of ComposedComponents is currently not supported by the transformation and therefore also not for the simulation.

Note: To review the result of the transformation that is used for the simulation itself, open the Configuration tab of the SimuCom run configuration and deactivate the checkbox "Delete generated code at simulation end". This will keep the temporary project after the simulation has finished. In this project a subdirectory named "model/" contains the transformation result that is used in the simulation.

Downloads

official PCM 3.4 release

PCM 3.2

References

  • [EFGK03] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec, The many faces of publish/subscribe, ACM Comput. Surv., vol. 35, no. 2, (2003)
  • [BK10] Benjamin Klatt, Modelling and Prediction of Event-Based Communication in Component Based Architectures (2010) [[2]]
  • [KR12] Benjamin Klatt and Christoph Rathfelder: “Predicting Event-Based Communication with Palladio”, invited talk PalladioDays 2012 [[3]]
  • [RK+13] Christoph Rathfelder, Benjamin Klatt, Kai Sachs, and Samuel Kounev. Modeling event-based communication in component-based software architectures for performance predictions. Journal of Software and Systems Modeling (SoSyM), 2013. accepted for publication. [[4]]
  • [Ra13] Christoph Rathfelder. Modelling Event-Based Interactions in Component-Based Architectures for Quantitative System Evaluation, volume 10 of The Karlsruhe series on software design and quality. KIT Scientific Publishing, Karlsruhe, 2013. under publication.
Keywords: Palladio, PCM, Event-Based Communication, Events, Asynchronous Communication
Abgerufen von „https://sdq.kastel.kit.edu/mediawiki-sdq-extern/index.php?title=PCM_Event-Based_Communication&oldid=30686“