Future software systems must be responsive to events and must be able to adapt the software to enhance business processes. Examples are production and logistics processes that must be rescheduled based on relevant tra c information. It is therefore essential that relevant events are detected and transported to the software components responsible for dynamic changes. The trust in such reactive systems depends to a large extent on the Quality of Service (QoS) provided by the underlying event system. This paper introduces QoS aspects in event-based systems and discusses ways of identifying and evaluating QoS needs. This is done by identifying the di erent system layers, and the quality requirements at each layer based on the layer's functionality.
Research in event-based systems can be categorized into
three broad areas: event production, event transportation
and event consumption. Typical event producers are
wireless sensor nodes and RFID readers but also complex event
processors (CEPs) producing, e.g., composite events. Event
consumers are, for example, complex event processing
engines or business applications in general. To connect
producers and consumers a middleware is necessary and also
responsible for transporting the event noti cations. Events
are represented by event objects which are packaged into
noti cations [
For the communication between producers and consumers
the paradigm of choice is publish/subscribe, allowing a
decoupled many-to-many communication. The pub/sub
middleware must provide a certain QoS [
Event-Based Interaction
[
Besides JMS, the Data Distribution Service (DDS) [
Although JMS, AMQP, and DDS support a variety of QoS
features, important QoS needs, e.g., ordering events from
multiple producers or the occurrence of false positives and
false negatives, are not addressed and still topics of research
and of interest for future systems. JMS and DDS are used
in QoS research: [
ADiWa started with the identi cation of business processes
which can be dynamically supported by an event-based
system. From the technical perspective this is a high-level view
and many common QoS criteria, like performance of the
EBS, are not applicable at this early stage. To address this
issue we categorized features of EBSs to enable a QoS-aware
speci cation and development process. The used features
are based upon an analysis of real-world event-based
systems [
Comprehensive Understanding
of Quality Needs Event Types General Requirements (Legal) Limitations and Specifications
Technical Properties
Runtime Requirements & Performance
- Development Process Figure 2 shows the above mentioned categories with respect to the time line of a development process. As it can be seen, general requirements as well as event types should be identi able rather early, during the rst steps of requirements engineering. Later on, legal limitations and further system speci cations can be determined before technical properties can be addressed. As last step, runtime requirements and performance needs can be identi ed. A comprehensive understanding of QoS is only possible after all required features have been identi ed. A detailed speci cation of QoS requirements can now be produced.
Event-based System
EarlyFiltering Low Response Time IntervalEvent Support …
Accuracy Efficiency
… Response Time
Yes / No …
Based on the relevance of the various features in a given application scenario a speci c EBS can be con gured that conforms to the required QoS. Figure 3 shows the conceptual approach of de ning QoS for certain features. For each feature one or more metrics are necessary to measure and monitor this feature. For some features the metric to measure QoS might be as simple as Is supported [yes/no], for other features multiple metrics might be necessary. An example is the support of the feature early ltering with lter merging and the tradeo between reduced number of lters and increased number of false positives.
By merging lters we reduce the number of lters that must be maintained and evaluated but increase the number of false positives and the number of forwarded messages because the lter is now less precise. As shown in Figure 2, early ltering results in multiple QoS attributes such as accuracy and e ciency. E ciency is ultimately measured through resource utilization of the broker node.
Features
Metrics
Qualityof Service … A major problem that must be considered when addressing QoS in EBSs is the fact that features and derived QoS requirements are not orthogonal, i.e. they may in uence each other. However, the more concrete the requirements for an EBS are speci ed and as more design decisions are made during the design process, the easier it becomes de ning and monitoring QoS.
So far we limited the scope to event transport (MOM) and complex event processing (CEP). As shown in Figure 4, the complete system includes also the event production layer and the dynamic business process layer.
At the lowest level the events enter into system; at this point there is an associated production quality. This quality is determined by the event producers, for example wireless sensor nodes. These nodes can monitor the environment and have, for example, a limited accuracy (Temperature +/- 1 degree) which might in uence later event processing. The highest levels of the system are the business processes driven by events where the goal is to dynamically adapt these processes according to occurring events. The adaption of processes is associated with QoS again: controlling quality. Associated QoS metrics describe how well processes are adapted and whether changes lead to improvements. This can be measured with Key Performance Indicators (KPI) assigned to processes. The two remaining levels of QoS conQUALITY CATEGORY Controlling Quality
Processing
Quality (e.g. Throughput,
Accuracy) Notification Quality (e.g. Latency,Reliability) Production Quality (e.g. accuracyof sensors)
Dynamic Business Processes
Subscribe
Publish Complex Event
Processing Subscribe
Publish Message-oriented Middleware (MOM) / Event Bus
Publish EventProducer
… RFIDReader WirelessSensorNetworks MobileDataEntry OtherProducers
Publish
Publish
Publish cern the inner parts of the system: the event transporting layer as well as the event processing layer.
Since QoS a ects all layers of a system a system-wide approach for managing quality information is needed. Every single event has its related production quality and is then transported and processed with a certain quality. During all these steps quality information for each event has to be maintained either directly at the event level or at higher granularity like event streams. The complexity of the QoS information suggests that in addition to attaching quality data to events a central registry for QoS data is helpful (Figure 5).
Event TransportingMiddleware
TransportQuality Data Event Quality
Data Producer
CEP
Complex Event Quality Data
Consumer
Quality DataRepository
QoS data can be archived. This QoS history is then
accessible and the middleware might draw conclusions during the
event transport: events originating from a sensor reporting
critical situations might require a highly reliable real-time
handling within the middleware. To support features along
these lines an appropriate event format and a system-wide
understanding of the existence of QoS is necessary.
A special challenge in terms of QoS is the support of
transactions since transactional processing does involve producers,
middleware, and consumers and thus a ects all QoS
layers. Transactions are, for instance, needed in case event
producers require acknowledgments from a consumer before
publishing another event (e.g., shipment event before billing
event). To support this functionality in a exible and
reliable way, transaction management has to be supported by
the middleware [
To ensure the compliance of a system with the QoS requirements techniques based on modeling, benchmarking and monitoring are used.
Various techniques exist for the modeling of event-based
systems. A promising approach is the use of Queuing Petri Nets
(QPNs) [
Another approach is the use of benchmarks to evaluate the
performance and QoS of systems. At rst, a benchmark can
test whether the promised QoS is provided by the
underlying EBS, e.g., in terms of latency. Second, a well designed
benchmark has a scalable workload allowing determining the
limits of systems and comparing implementations of di
erent vendors in an independent way. One of the challenges
when developing a benchmark is choosing an appropriate
workload. Since building separate workloads for various
application scenarios is usually not possible, a benchmark uses
a workload with properties which are characteristic for many
applications. Further, it can be designed to support
software developers and architects during the development
process. When choosing a current middleware which supports
pub/sub, e.g., following the JMS standard, the developers
still have the choice whether to use a single topic for all
messages or various topics. In terms of ADiWa the decision
would be whether to use an event bus where all events ow
through the same stream (destination), or whether to
structure events and use various streams (destinations) forming
the overall event bus. To evaluate, amongst others, these
di erent alternatives jms2009-PS was developed [
Besides modeling and benchmarking the monitoring of a productive event-based system is important to ensure QoS. Collected data can be incorporated with models, validated by simulations, and utilized to develop a characteristic benchmark workload. Further, monitoring allows the early detection of potential bottlenecks and gives developers the possibility to adapt and extend the system in advance. Monitoring is done by collecting runtime information. This can be accomplished in a pub/sub manner: each event producer or consumer does not only publish events but also statistical information. In addition, the event transporting middleware itself can publish data accounting for QoS. Parties interested in statistical data can then simply subscribe to messages and perform further analysis. The middleware can act as a consumer, too. By this a self-adapting middleware can be realized which dynamically recon gures to constantly assure the required QoS.
To allow the reporting of statistical data middleware implementations need to be adapted. Unfortunately monitoring a system introduces an overhead. The overhead increases with the granularity of monitoring, thus a tradeo between monitoring granularity and potential monitoring bene ts has to be found in productive systems. It is also possible to build a system with adjustable monitoring capabilities. If such a monitoring framework exists, it becomes possible to increase the monitoring granularity either on a regular basis or whenever an in-depth problem analysis is needed.
Dynamically enhancing business processes using events originating from a variety of producers requires a middleware for transporting the data. Within the ADiWa project requirements for those middleware systems are a topic of research. In this paper an approach for identifying, de ning and ensuring QoS needs is presented. At rst, relevant features of an EBS are identi ed; this can be accomplished stepwise as the requirements engineering process proceeds. Based upon the determined functionalities, QoS metrics can be developed and evaluated using, e.g., benchmarking, modeling, and monitoring mechanisms. This QoS-aware software development process assures that quality needs are taken into consideration early in the design process. In addition to the identi cation of QoS needs the management of QoS relevant data is a challenge. QoS data does occur at various places in systems and thus collecting relevant parts of it in a central repository is necessary. Based upon archived QoS data the system can be evaluated and tuned.