Eventing

Web services often want to receive messages when events occur in other services and applications. A mechanism for registering interest is needed because the set of Web services interested in receiving such messages is often unknown in advance or will change over time. This section defines a protocol for one Web service (called "subscriber") to register interest (called "subscription") with another Web service (called "event source") in receiving messages about events (called "notifications" or "event messages"). The subscriber may manage the subscription by interacting with a Web service (called "subscription manager") designated by the event source.

To improve robustness, a subscription may be leased by an event source to a subscriber and the subscription expires over time. The subscription manager provides the ability for the subscriber to renew or cancel the subscription before it expires.

There are many mechanisms by which event sources may deliver events to event sinks. This specification provides an extensible way for subscribers to identify the delivery mechanism they prefer. While asynchronous pushed delivery is defined here, the intent is that there should be no limitation or restriction on the delivery mechanisms capable of being supported by this specification.

Key concepts of eventing:

• Delivery Mode - The mechanism by which event messages are delivered from the source to the sink.
• Event Source - A Web service that sends notifications and accepts requests to create subscriptions.
• Event Sink - A Web service that receives notifications.
• Notification - A one-way message sent to indicate that an event has occurred.
• Push Mode - A delivery mechanism where the source sends event messages to the sink as individual, unsolicited, asynchronous SOAP messages.
• Subscriber - A Web service that sends requests to create, renew, and/or delete subscriptions.
• Subscription Manager - A Web service that accepts requests to manage get the status of, renew, and/or delete subscriptions on behalf of an event source.

EDA

Event Driven Architecture (EDA) is an architectural pattern build on top of the asynchronous publisher-subscriber integration pattern. EDA is an extended version of basic eventing that integrates systems, subsystems and modules. EDA introduces vertical integration of systems using events, and horizontal integration of modules and subsystems in the same system using events.

Horizontal integration using events:

Vertical integration using events:

EDA boosts the loosely coupling of systems, subsystems and modules. EDA does not only talk about integration using events, event processing is also a main topic.

EDA contains:

• Event generation
• Event processing
• Event distribution
• Execution of the subsequent processes by event clients (sink)

EDA categorizes event processing into three categories:

• Simple Event Processing (SEP)
• Event Stream Processing (ESP)
• Complex Event Processing (CEP)

Simple event processing distributes events to matching subscribers without any extended processing of those events. This way the distribution mechanism becomes really light-weight and simple and uses matching subscription and event filters. Event stream processing processes real-time data and creates sub sets of events to then publish for the subscribers. Trading data is a good example for ESP. Complex event processing processes events using existing data (events or any other information in master databases) and generates new events or filter incoming events. Generating market data by referring real-time trading data and stored tick data is a good example for CEP.

EDA with SOA

Service Oriented Architecture (SOA) brings the capability of building loosely coupled systems using services. In a SOA + EDA integrated system services can invoke when a specific event received by using the data inside the event or a service can create a new event based on the result of an invocation of a service. In the first scenario based on the subscribed topic the target operation of the service can determine and the message payload will be the parameters for the operation. That way filtering of events to pick the service operation will be eliminated.

Service invoke:

In the second scenario, Services will invoke by other sources and based on the state changes of the business operation service will act as an event generator and publish events to a event broker system. External event sink(s) that has subscribed to the relevant event topics via a subscription manager will capture the events and do the relevant back end operations based on the content of the events.

Services as Event generator:

See more information about WS-eventing in WS-Eventing Specification.