Performance Modeling and Benchmarking of Event-Based ... - DVS

More documents

Recommendations

Info

12 CHAPTER 2. BACKGROUND 2.2 Technology Platforms of Event-based Systems Many different technologies have contributed to the field of event-based systems. We review the contributions of the following platforms in this section: • Active databases • Continuous queries, stream processing • Distributed event-based systems (DEBS) • Materialized views • Message-oriented middleware (MOM) • Reactive middleware Since our work presented in this thesis is focusing on MOMs and DEBS, we discuss them in more detail than the others. 2.2.1 Active Databases Active databases were developed in the mid to late 1980s [174, 233]. Two distinct strands can be identified: • Relational and • Object-oriented active databases. Relational active databases were limited mainly to basic database events, such as update, insert and delete. They could express conditions on either the old or new state of a relation, and the action was always some SQL statement. Today’s triggers in SQL are the relational incarnation of simple ECA rules. Relational active databases introduced the notions of before, after or instead execution, meaning that the rule should be executed accordingly before, after or instead of the triggering statement. Object-oriented active databases had a richer event type system. It included any method invocation, state changes effected through generic accessor functions, temporal events, control flow events, arbitrary user defined events, and composition of events through event algebras of varying expressiveness. The first generation of active ooDBMSs assumed a central clock, point semantics for the events, and a complete ordering of events. Active ooDBMSs introduced coupling modes to define when a rule should be executed (immediately or deferred) and whether it should be executed within the scope of the triggering transaction or as a separate transaction. If rules execute in separate transactions this can occur independently or be causally dependent, in which case the triggered transaction may only begin or end execution depending on the fate of the triggering transaction. The various causal dependence modes take care of violations of ACID properties that occur when uncommitted data is made visible to independent transactions. Another major contribution was the notion of event consumption, referring to the way in which events are consumed during event composition. Four consumption modes (originally termed contexts) were defined: chronicle, recent, continuous, and cumulative. These determine that the events be consumed either in chronological order (typical in workflow-like applications), always using the most recent occurrence (typical in control applications), in form of windows (typical in financial applications) or accumulating the effects of incoming events until another event occurs (typical in inventory control situations).
2.2. TECHNOLOGY PLATFORMS OF EVENT-BASED SYSTEMS 13 Sender Sender Msg x Msg y Queue 1 Msg y, Msg x Receiver Publisher Publisher Msg x Msg y Topic 1 Msg y, Msg x Msg y, Msg x Msg y, Msg x Subscriber Subscriber Subscriber Queue n JMS Server Topic m JMS Server Figure 2.2: Point-to-point messaging. Figure 2.3: Example for Pub/Sub Messaging. 2.2.2 Continuous Queries, Stream Processing Continuous queries [52] can be seen as an attempt to change the processing paradigm from issuing a single non-persisting query against stored, persistent data to storing the query persistently in the database and applying it to streams of incoming data. Continuous/continual queries were expressed in variants of the SQL language modified to operate on windows [140]. These can be defined either through temporal events or through a count of incoming events. While early work on continuous queries assumed that the continuous queries would operate on the stored data and would be executed by the traditional query engine, work on streaming queries has changed the processing paradigm: queries defined in a SQL dialect, such as StreamSQL, process streams of data or events before they are placed in the database and results of this processing step are only selectively stored in the database. Many of the extensions to the relational operators and how to process for example joins on windows in continuous queries, have carried over to current products for stream processing and have been extended there for high volume applications [45]. 2.2.3 Materialized Views Materialized views can be seen as a particular application of active database principles. Views are typically subsets of a database that are defined in the database schema. They are computed on the fly from the stored base tables. As an optimization, views were materialized, i.e., stored, resulting in the need for maintaining them whenever the base data changed. Propagation of base-table updates to the materialized views was accomplished using the mechanisms developed for active relational databases [86]. 2.2.4 Message-Oriented Middleware (MOM) Message-oriented middleware (MOM) is a specific class of middleware that supports loosely coupled communication between distributed software components by means of asynchronous message-passing as opposed to a request/response metaphor. This allows a producer to send a message (event notification) and then continue working while the message is being delivered and processed. Optionally the message producer can be notified later when the message is completely processed. The decoupling of communicating parties has several important advantages: • Message producers and consumers do not need to know about each other. • They do not need to be active at the same time to exchange information. • They are not blocked while sending or receiving messages [67]. Message-oriented Middleware contains notification services supporting two message models:
Page 1: Performance Modeling and Benchmarki
Page 4 and 5: priorities. Finally, we validated o
Page 6 and 7: 4.3.4 Tool Extension . . . . . . .
Page 8 and 9: 5.7 Proportions of the Interactions
Page 11 and 12: List of Acronyms Acronym λ t,k j A
Page 13 and 14: Acronym SPEC-OSG SPE SPN SQL ST SUT
Page 15 and 16: Chapter 1 Introduction 1.1 Motivati
Page 17 and 18: PC Server 310 PC Server 310 PC Serv
Page 19 and 20: 1.3. APPROACH AND CONTRIBUTIONS OF
Page 21 and 22: 1.4. THESIS ORGANIZATION 7 • Stan
Page 23 and 24: Chapter 2 Background In this chapte
Page 25: 2.1. EVENT-BASED SYSTEMS 11 is gene
Page 29 and 30: 2.2. TECHNOLOGY PLATFORMS OF EVENT-
Page 35 and 36: 2.3. INTRODUCTION TO QUEUEING PETRI
Page 37 and 38: 2.3. INTRODUCTION TO QUEUEING PETRI
Page 39 and 40: Chapter 3 Related Work In this chap
Page 41 and 42: 3.2. BENCHMARKING OF EVENT-BASED SY
Page 43 and 44: 3.2. BENCHMARKING OF EVENT-BASED SY
Page 45 and 46: 3.4. CONCLUDING REMARKS 31 hierarch
Page 47 and 48: Chapter 4 Performance Engineering o
Page 49 and 50: 4.1. MODELING METHODOLOGY FOR EBS 3
Page 57 and 58: 4.2. PERFORMANCE MODELING PATTERN 4
Page 77 and 78:
4.2. PERFORMANCE MODELING PATTERN 6
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
4.3. EXTENSIONS OF QPNS 73 ,-).$%&'
Page 89 and 90:
4.4. CONCLUDING REMARKS 75 Without
Page 91 and 92:
Chapter 5 Benchmarking of Event-Bas
Page 93 and 94:
5.1. SPECJMS2007 - A STANDARD BENCH
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
5.2. CASE STUDY I: SPECJMS2007 101
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
5.3. JMS2009-PS - A PUBLISH /SUBSCR
Page 127 and 128:
5.3. JMS2009-PS - A PUBLISH /SUBSCR
Page 129 and 130:
5.4. CASE STUDY II: JMS2009-PS 115
Page 131 and 132:
5.4. CASE STUDY II: JMS2009-PS 117
Page 133 and 134:
Chapter 6 Performance Modeling of E
Page 135 and 136:
6.2. MODELING SPECJMS2007 121 Scena
Page 137 and 138:
6.2. MODELING SPECJMS2007 123 BASE*
Page 139 and 140:
6.2. MODELING SPECJMS2007 125 1‘O
Page 141 and 142:
6.2. MODELING SPECJMS2007 127 Sc. 1
Page 143 and 144:
6.2. MODELING SPECJMS2007 129 Perce
Page 145 and 146:
6.2. MODELING SPECJMS2007 131 Serve
Page 147 and 148:
6.3. CONCLUDING REMARKS 133 the mod
Page 149 and 150:
Chapter 7 Conclusions and Outlook W
Page 151 and 152:
7.1. ONGOING AND FUTURE WORK 137 JA
Page 153 and 154:
7.1. ONGOING AND FUTURE WORK 139 th
Page 155 and 156:
Bibliography [1] J. Abbott, K. B. M
Page 157 and 158:
BIBLIOGRAPHY 143 [29] BiCEP Researc
Page 159 and 160:
BIBLIOGRAPHY 145 [61] G. Cugola and
Page 161 and 162:
BIBLIOGRAPHY 147 [92] R. Henjes, M.
Page 163 and 164:
BIBLIOGRAPHY 149 [128] S. Kounev an
Page 165 and 166:
BIBLIOGRAPHY 151 [162] Object Compu
Page 167 and 168:
BIBLIOGRAPHY 153 [197] K. Sachs, S.
Page 169 and 170:
BIBLIOGRAPHY 155 [228] P. Tran, P.
Page 171:
Erklärung Hiermit erkläre ich, di
show all

Performance Modeling and Benchmarking of Event-Based ... - DVS

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?