460 likes | 977 Views
A Correlation Framework for the CORBA Component Model. Georg Jung, John Hatcliff, Venkatesh Prasad Ranganath, {jung,hatcliff,rvprasad}@cis.ksu.edu Department of Computing and Information Sciences Kansas State University. Current Component Frameworks. EJB (Enterprise Java Beans)
E N D
A Correlation Framework for the CORBA Component Model Georg Jung, John Hatcliff, Venkatesh Prasad Ranganath, {jung,hatcliff,rvprasad}@cis.ksu.edu Department of Computing and Information Sciences Kansas State University
Current Component Frameworks • EJB (Enterprise Java Beans) • Bonobo (Gnome Desktop Framework, e.g. debian-Linux) • KOM, KParts (KDE Desktop Framework) • Boldstroke, Prism (Boeing Company) • AADL (Avionics Architecture Description Language, Honeywell et al.) • SCA, JTRS (Software Communications Architecture, Joint Tactical Radio System) • CCM (CORBA Component Model)
Component Architecture Infrastructure layer located between applications and OS: Middleware Loosely coupled entities: components Java C++ C Middleware Layer Event Service Transaction Service Middleware Layer Heavily relying on events as major mean of communication Naming Service Synchronization Service C Java C++
Component-based Design Input event port Output event port Event Ports CCM Component Interface Ports Require an interface Provide an interface A software component is a unit of composition with contractually specifiedinterfaces and explicit context dependenciesonly. A Software component can be deployed independently and is subject to composition by third parties. --Szyperski. Component Software. 2nd ed. p. 195
Component-based Design Component Integration …up to 1000+ components
Middleware-based Implementation Event channel
Middleware-based Implementation Event channel Abstractly… consume produce
Middleware-based Implementation Proxy Supplier … … … … … Event channel In reality… proxy dispatch consume threading timer/ thread pool queuing filtering network multiplexing produce consumer references Proxy Consumer proxy
Challenges of Event Communication Consider the following situation: • Component C is receiving from two components A and B • A and B send at different rates • C needs both inputs to become active A a C ab b B
Challenges of Event Communication If we add correlations to the infrastructure Consider the following situation: We can: • Reduce network traffic • Simplify computation inside the component • Clarify the design • Define the components in a more general way A a a + b C ab b B
What is a Correlation “Event correlation is a process where a stream of primitive events is processed in order to detect composite events that correspond to event patterns in the event stream.” -- Unix-Manpage of SEC 2.2.0 http://kodu.neti.ee/~risto/sec/
What is a Correlation According to this definition we have: • A stream of primitive events (e.g. a, b) • The detection of composite events (ab) • Done according to event patterns (a+b) But there is more! • The performing of an action upon detection of a desired pattern in the input stream.
Previous Correlation Frameworks • GEM (Mansouri-Samani, Sloman, Generalized Event Monitoring language) • Event Correlation (Sankaranarayanan, Simpa, Zhang, Dill, Manna) • Reflex (Louvau, Chen, Jackson, Devanbu, Gertz, http://reflex.cs.ucdavis.edu/) • SEC (Risto Vaarandi, Simple Event Correlator, http://kodu.neti.ee/~risto/sec/)
Previous Correlation Frameworks In GEM, Event Correlation, and Reflex events are tuples of attributes: {number=3, source=“GPSModule”, color=green, …} Single events are matched against boolean expressions over the attributes (color == red)|(color == mauve) SEC uses regular expressions to match single events in the input stream (Unix file-stream) Events are combined by operators or policies or rules into compound events.
In Previous Frameworks Event attributes serve as characteristics rather than data containers These characteristics identify the event In a CCM environment Event attributes carry runtime data An event is identified by the port it comes from Events in CCM In CCM events are more complex! In a component architecture we need to enhance the idea of correlations to handle Content Data. Events in CCM are Asynchronous Messages
Summary • Component systems are used in many differentareas • We can improve design and efficiency of component systems by adding correlations • Previous frameworks are tailored at monitoring, they do not take into account payload
The Two-Phase Model Filter Stream of incoming events Transformer e1 e3 e1 e2 e2 Conceptually, the correlator divides into two distinct phases: • The Filter • The Transformer Reacting to a detected pattern • Information about: • which events arrived • what data is present Filter Transformer Generates new output events eout eout Detection of event patterns And performs internal actions • Information about: • which events arrived • what data is present
General Outline of the Correlator The filter is specified by an expression denoting what patterns are to be detected A correlation has an output type, and an identifier naming the correlation. A list of typed names specifies the types of all input ports connected to this correlation A set of rules specifies the actions to be taken whenever a pattern occurs We specify a correlator as follows: typecorrelation name (type name, type name, …) filter-expression { transformer- specification } Filter Transformer
The Filter • Listens to named, typed ports. (τ1 n1, τ2 n2, τ3 n3, …) • The names are used in an expression. This expression is constructed over a set of combinators. (n1 + n2) | n3 ; n2 • Labels can be used to identify subexpressions. l1:(n1 + n2) | l2:n3 ; n2
The Filter: Semantics The Basic Match: A stream of incoming events s =e1...en of events e1, …, enmatches a singleton expression a, iff an event a is in s, i.e. there is an i, 1 ≤i ≤n, such that ei = a. d a c c b a a d a b c
The Filter: Combinators • Accumulation: b + c match! d a c c b a a d a b c
The Filter: Combinators • Accumulation: b + c • Sequence: b ; c match! match! d a c c b a a d a b c
The Filter: Combinators • Accumulation: b + c • Sequence: b ; c • Collection: b | c match! match! match! d a c c b a a d a b c
The Filter: Combinators • Accumulation: b + c • Sequence: b ; c • Collection: b | c • A more complex expression: (a ; b | d) + (d ; c + b) match! match! match! match! d a c c b a a d a b c
The Filter: Semantics When we inspect the stream of incoming events, we want to react at the first instant where apattern iscomplete • We define the shortest match to specify a complete pattern • The shortest match then serves to identify the instant then the correlator triggers.
The Filter: Semantics The Shortest Match • A stream s matches an expression x, • but no proper prefix of s matches x. Example: (a + b) | (a + c) d c d a b c a b c Shortest Match
The Filter: Semantics not a trigger not a trigger trigger trigger trigger The Trigger • A shortest match is a trigger if it does not overlap with a previous trigger Example: a ; b ; a b a b b a b a a b b a b b b a b a We call this behavior Reset Semantics
The Filter: Result Consider the following filter expression: Subexpressions which are matched by the current trigger are called active. (a + b) | (a + c) And the following streams: matches: a + b a b a a c c … matches: a + c a c a b b a … matches: a + b and a + c c b b c a a …
The Filter: Result l1:(a + b) | l2:(a + c) Labels attached to active subexpressions are called active. Adding Labels to the expression (a + b) | (a + c) And again the streams: subexpression at l1 a b a a c c … subexpression at l2 a c a b b a … subexpressions at l1andl2 c b b c a a …
The Filter: Result Result of the filter is the set of active labels • Labels are the connection between filter and transformer • Active labels identify the subpatterns which are present in the input • The level of detail can be chosen easily
The Filter: Summary • The filter detects patterns in the input stream. • Patterns are specified by labeled expressions over the combinators+, |, ; (and on top level the parallel operator ||). • The correlator triggers on a complete shortest match. • Result of the evaluation is the set of active labels. • Note that it is easy to build an acceptor for a given filter expression, since they describe a subset of regular languages.
General Outline of the Correlator We specify a correlation as follows: typecorrelation name (type name, type name, …) filter-expression { transformer- specification }
The Transformer: Outline Each clause contains zero or more actions, e.g. the emission of an event (push) List of action clauses Or they can be new events constructed from the payload of input events Guarded by boolean expressions over labels Events can be forwarded input events { case l1: push b case l2: push newNotify { timeStamp := c.timeStamp } case !l1 &!l2: }
The Transformer: Example 1 Note that all clauses with satisfied guard are executed Consider the filter expression: l1:(a + b) | l2:(a + c) Option 1: ab ac bca case l1: push new NavData {air = a.air, nav = b.nav} case l2: push new NavData {air = a.air, nav = c.nav}
The Transformer: Example 1 Consider the filter expression: l1:(a + b) | l2:(a + c) Option 2: ac bca ab case l1: push new NavData {air = a.air, nav = b.nav} case l2 & !l1: push new NavData {air = a.air, nav = c.nav}
The Transformer: Example 1 Consider the filter expression: l1:(a + b) | l2:(a + c) Option 3: ac bca ab case true: push new DataAvailable {}
The Transformer: Example 2 We consider three subexpressions x1, x2, x3. x3 shall not interleave between x1 and x2. x1 ; (l2:x2 | l3:x3) Previous approaches offer a specific, distinct construct to express interleaving (e.g. {e1;e2}!e3 in GEM, fail{do{φ1}unless{φ2}}in Event Correlation) Due to the two-phase model a specific operator for interleaving is not necessary. case l2: push new success-event case l3: push new error-event case l2: push new success-event case l3: push new error-event
The Transformer: Summary • Boolean expressions over the active labels allow a flexible and versatile mean to fine-tune the reactions to occurring patterns • Being a communication device, the correlator can rearrange data into new events, but does no computation • Using data from incoming events, new events can be constructed, which match the type the receiving component expects
Dynamic Adaption … + An A3 A2 A1 Consider an array of redundant components A1, A2,…, An. and a single receiving component B, interested in the accumulation of all events a1, a2,…, an. The filter expression is then a1 + a2 + … + an B
Dynamic Adaption: Rationale … + An A3 A2 A1 a1 + a2 + … + an In a component system some components can be temporarily unavailable! We want to be able to adapt the pattern detection to this new situation. If one component does not send anymore the whole pattern is never satisfied! B
Dynamic Adaption: Idea + An Ai A1 Again, we use labels: l1:a1 + … + li:ai + … + ln:an Assume e.g. component Ai becoming unavailable. We want to “switch off” the corresponding subexpression For this we introduce the notion of labels and their respective subexpressions of being enabled or disabled … … B
Dynamic Adaption: Syntax We add the following commands to the transformer syntax: abortlabel, revive label, toggle label. abort disables a label, revive re-enables a label, and consequently toggle switches the status of a label.
Dynamic Adaption: Semantics Intuitively, a disabled subexpression is simply omitted l0disabled: • Filter: l0:x0● x1≡ x1 x1 ● l0:x0≡ x1 (for ● in {+,|,;,||}) • Guard: l0 ♦ e ≡ e e ♦ l0≡ e !l0 ♦ e ≡ e e ♦ !l0≡ e (for ♦ in {&,|})
Dynamic Adaption: Example C … An A3 B A2 A1 Notify correlation SensorArray (Notify a1, …, Notify an, Control c1, …, Control cn) l1:a1 + … + ln:an || m1:c1 || … || mn:cn { case l1 & … & ln: push new Notify {} case m1: toggle l1 … case mn: toggle ln } Sensor Array
Dynamic Adaption: Summary • Labels do not only serve as carrier from the filter to the transformer, the transformer can also communicate back changes to the filter • We can arbitrarily switch on and off subexpressions in the filter as well as in the guards inside the transformer • Standard tasks such as temporarily omitting input are easily specified
Synopsis • We presented a correlation service suitable to handle the requirements of component based systems • The specification of a correlator is intuitive and simple, but with a strict background • The correlation framework is implemented and used in and will probably be introduced into Prism