SCA Assembly Extensions for Event Processing and Pub/Sub€¦ · What is Event Processing and...
Transcript of SCA Assembly Extensions for Event Processing and Pub/Sub€¦ · What is Event Processing and...
SCA Assembly Extensions for Event Processing and Pub/Sub
Specification Location
http://osoa.org/download/attachments/35/SCA_Assembly_
Extensions_for_Event_Processing_and_PubSub_V1_0.pd
f?version=1
Delta on SCA Assembly Model Specification 1.0
Outline
What ?
Why ?
Motivation
Use cases
Comparison with the service-reference model
Why the service-reference model isn’t sufficient
Overview of the SCA Event Processing spec
Examples
Details
Event processing in Java-based component
What is Event Processing and
Pub/Sub
Event processing consists of computing/performing
operations on events or event messages
Creating, reading, transforming event objects/representations
Components interact via events
Pub/sub is a style of organizing components
Components produce and consume events
Producers and consumers are decoupled from each other
NxM
Dynamic
Consumers specify subscriptions (may contain filters)
Blind Men and Pub/Sub
Why ?
Very common and well accepted model
Decoupling of producers and consumers
Pull vs. push
Integration with existing infrastructure and
computing/interaction models
Application integration involving composite applications
require it
Components may interact in a mixed model (service
invocation and pub/sub)
Events don’t impose any operational semantics
launchMissile() vs. [WMD found]
Scenario 1 – Sales Event
Processing Phase 1
Phase 1 focuses on order processing flow
Phase 1 is successfully deployed to production
Because order processing is at the core of the company business:
any modification to this flow has to go through long and stringent testing.
Performance is paramount –no new service can be introduced if it implies a degradation of the customer experience.
Scenario 1 – Phase 2
After a few months,
Marketing decides to
introduce a new real-time
business intelligence
tool.
Just needs to “tap” into
existing events
Non-intrusive: No need
to modify/version/re-test
core order capture
process (with associated
costs savings)
Addition of new services
has no performance
impact on core order
capture process
(repeat with Fraud
Detection, and again,
and again)
Scenario 2 – New Employee Provisioning
Scenario 3: Complex Event
Processing Application
Real time responses required
Multiple event streams processed by multiple consumers
E.g.: Multi-player gaming systems, algorithmic trading
applications
Invocations vs. Events
Invocations
A client component wired to a service component invokes operations
on the service.
The operation has some implied semantics – there’s an expectation
that something specific will happen.
Operations of related semantics typically grouped together –
component expected to process any operation request
There may be a response directly back to the client
Invocations vs. Events (2)
Events
Not directed at any single component
Maybe received by more than one component
No implied semantics – each receiving component may react very
differently
No way to respond directly to the producer
A component doesn’t have to receive all events from the same source
Decoupling of “interfaces” between producers and consumers
Consumers can set filters
Can Service-Reference model be
used for Event Processing?
Service => consumer
Reference => producer
Reference cardinality is 0..n
Autowire
Can Service-Reference model be
used for Event Processing?
Impedance mismatch => no maximum power transfer
Different model / way of thinking: wires not included
No decoupling
Requires interfaces for typing
Interface/operations have processing semantics, events don’t
Doesn’t allow addition of producers/consumers dynamically
No ability to set filters
Various issues crop up because of the model mismatch. For
example, sca:reference (0..n) is mapped to an array in Java
Subscribers do not offer services they offer callbacks
Services do not subscribe they make software functionality
available for others to use.
A subscribe message will be sent from a service to a
reference: a direction reversal
Changes are hard to manage
Overview
New concepts:
Events
Event types
Event Description Language (EDL)
Producers
Consumers
Channels
Filters
Diagram
Component
services
producer
properties
Implementation
- Java
- BPEL
- Composite
…
references
consumer
Events
Message sent to zero or more parties that contains
information about a situation that has occurred
Events must have one or both of:
a type, to identify the situation (a QName)
Sometimes a type isn’t required or wasn’t present when
the event was generated
a body containing details of the situation
Sometimes a body is not required, just knowing the type
is good enough
Canonical representation is XML
Event Type
An event can have an associated event type
Is identified by a unique QName
Can have an associated body type or shape and
constraints on the event
A body type/shape may be used for multiple event types
Body type are defined in an existing type system like XML
Schema or Java
EDL
Simple Event Type Definition Language (EDL) to express
association of event types and body types
Extensible
<sca:eventDefinitions targetNamespace="anyURI">
<sca:eventType name="NCName"? >*
...
</sca:eventType>
</eventDefinitions>
EDL (2)
Can use XML Schema
<sca:eventDefinitions targetNamespace="anyURI">
<sca:eventType.xsd name="NCName"? element="Qname" />*
</eventDefinitions>
<eventDefinitions
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:foo="http://foo.com"
targetNamespace="http://foo.com">
...
<sca:eventType.xsd name=“EarthQuakeType”
element="foo:EarthQuake"/>
</eventDefinitions>
Producer
Entity that creates events
Implementations/ComponentType can declare producers
Are configured by specifying the target
Can be promoted to produce composite producers
Can be configured to send events to multiple destinations
Consumer
Entity that receive events
Implementations/ComponentType can declare consumers
Are configured by specifying the source
Can be promoted to produce composite consumers
Can receive events from multiple destinations
Can specify filters
Channel
Channels connect zero or more producers to zero or more
consumers
A channel may have filters to define what events it will
pass on
A Channel is either a Domain channel or private channel
Domain Channels are visible to all components regardless
of nesting of that component in another component
Private channels are only visible within the component that
defines them
An SCA Domain always has a default channel “//” which
any component can use
if there’s no reason to partition your space you don’t
have to
Filters
Selects a subset of events from a source
Consists of filter expressions of type boolean
Each filter expression is on
event type (sca:NULL is a special value signifying no type)
business data
metadata
Multiple filter expressions are logically ANDed
Filters have no side-effects and no state
Filters specify three things: dialect, subject & expression
QName of the filter => dialect and subject
Filters (2)
<filters>
<type qnames="list of xs:QName"?
namespaces="list of xs:anyURI"? />*
<body.xpath1> xs:string </body.xpath1>*
<metadata.xpath1> xs:string </metadata.xpath1>*
<any/>*
</filters>
Filters (3) -- Examples
<type qnames="ns1:printer ns2:printer" />
<type qnames="sca:NULL" />
<type qnames="sca:NULL ns1:printer" />
<type namespaces="http://example.org/ns1
http://example.org/ns2" />
<type qnames="ns1:printer sca:NULL"
namespaces="http://example.org/ns2" />
Example 1: Connection via Local
Channel (diagram)
Composite X
Component
4
Channel
A
Component
2
Component
3
Component
1
Example 1: Connection via Local
Channel (XML)
<composite ...>
<component name="Component1">
<implementation.java class="..."/>
<producer name="Foo_Events" target="ChannelA"/>
</component>
<component name="Component2">
<implementation.java class="..."/>
<producer name="Foo_Events" target="ChannelA"/>
</component>
<component name="Component3">
<implementation.java class="..."/>
<consumer name="Foo_Handling" source="ChannelA"/>
</component>
<component name="Component4">
<implementation.java class="..."/>
<consumer name="Foo_Handling" source="ChannelA"/>
</component>
<channel name="ChannelA"/>
</composite>
Example 2: Promotion (diagram)
Composite X
Component
2
Component
3
Component
1
Channel
A
Example 2: Promotion (XML)
<composite ...>
<component name="Component1">
<implementation.java class="…"/>
<consumer name="Bar_Handling"/>
<producer name="Foo_Events" target="ChannelA"/>
</component>
<component name="Component2">
<implementation.java class="..."/>
<consumer name="Bar_Handling"/>
<producer name="Foo_Events" target="ChannelA"/>
</component>
<channel name="ChannelA"/>
<component name="Component3">
<implementation.java class="…"/>
<consumer name="Foo_Handling" source="ChannelA"/>
<producer name="Special_Events"/>
</component>
<consumer name="Bar_Handling“
promotes="Component1/BarHandling
Component2/Bar_Handling"/>
<producer name="Special_Events“
promotes="Component3/Special_Events"/>
</composite>
ComponentType Pseudo-schema
<componentType ... >
…
<consumer name="xs:NCName"
requires="list of xs:QName"?
policySets="list of xs:QName"?>*
<filters/>?
<binding/>*
</consumer>
<producer name="xs:NCName"
typeNames="list of xs:QName"?
typeNamespaces="list of xs:anyURI"?
requires="list of xs:QName"?
policySets="list of xs:QName"?>*
<binding/>*
</producer>
</componentType>
Component Pseudo-schema
<component ... >
...
<consumer name="xs:NCName" source="list of xs:anyURI"?
requires="list of xs:QName"?
policySets="list of xs:QName"?>*
<filters/>?
<binding/>*
</consumer>
<producer name="xs:NCName" target="list of xs:anyURI"?
typeNames="list of xs:QName"?
typeNamespaces="list of xs:anyURI"?
requires="list of xs:QName"?
policySets="list of xs:QName"?>*
<binding/>*
</producer>
</component>
Composite Pseudo-schema
<composite ... >
...
<consumer name="xs:NCName"
promotes="list of xs:anyURI"
requires="list of xs:QName"?
policySets="list of xs:QName"?>*
<filters/>?
<binding />*
</consumer>
<producer name="xs:NCName" promotes="list of xs:anyURI"
requires="list of xs:QName"?
policySets="list of xs:QName"?
typeNames="list of xs:QName"?
typeNamespaces="list of xs:anyURI"?>*
<binding />*
</producer>
<channel name="xs:NCName"
requires="list of xs:QName"?
policySets="list of xs:QName"?>*
<filters/>?
<binding/>*
</channel>
</composite>
Event Processing in Java
Components
Non-normative
New annotations
@Producer
@Consumer
@EventType
What is lacking in the
contribution?
No conformance criteria
RFC 2119 statements to be completed when conformance
defined
Aligned with SCA version 1.0
Specific detailed proposals for C&Is (for other OASIS SCA
TCs)
Bugs (?)