ws-eventing

Introduction

This HOWTO was to create a demo for MDC, see the slides for more information.

A Notification defined in WS-Eventing can be a real event produced by the event source or a heartbeat event to be sent in a fixed interval. It is an obvious and reasonable idea to put the two functions in two separate threads. So the notification manager can be designed to consist of the notification manager and the heartbeat threads.

The Event Pool is responsible for events storage. All events except heatbeats generated by the service are put here before they are sent eventually. Notification Manager gets events from Event Pool, while Plug-in adds events to it.

Workflow

When a subscription request is received, if it is a valid request, it will be saved in the subscription repository and in the memory at the same time and a response message will be returned with expiration time(if any) and corresponding subscription identifier. If it is not, an error message will be returned with causes.

Renew request message should include subscripton identifier which is returned by the subscription manager when subscription is made.

In this implementation openwsman acts as an Event Source, which is responsible for receiving a subscription from a subscriber and sending a notification to an event sink. As there are different events created by different applications in the real world, it is important to make this process as general as possible.

In an implementation or environment supporting WS-Eveneting there are three actors:

• Subscriber,
• Event Source and
• Event Sink.

The Event Sink subscribes an interest with the Event Source by operation contract, such as Subscribe. Event Source is responsible for controlling the information that Event
Sinks are interested in. The event sink can be the receiving end and the initiator of a subscription, however it is also possible that the subscription comes from a seperate component.