Duplex Eventing

Topics: CAB & Smart Client Software Factory
Jul 14, 2005 at 9:58 PM
originally posted by: eilert

The event broker lets you publish and subscribe to events.

You can now publish events and subscribe to events responding to your published one, in a Pub-Sub manner.
However you never know whether the event you are receiving is in response to your published one or some other published event.

What I would like to see implemented in the event broker is a correlation between the Publisher and Subscriber, when a Pub-Sub event is subscribed to. This allows asynchronous correlated events (Duplex Events - similar to Duplex Messages)

You could do something similar to the 'AsyncEvntArgs', by rapping the correlation id and/or a timestamp (send by the publishing initiator) with the original EventArgs into a CorrelationEventArgs.
The EventSubscription- and EventPublicationAttributes must also be updated.
Jul 17, 2005 at 8:25 AM
originally posted by: eugeniop

Would you mind describing a particular use case where you'd benefit from this feature?
Jul 18, 2005 at 6:32 AM
originally posted by: eilert

The use case would be something like this:

Say you want to trigger a workflow from your class, which fetches some data from a database and then updates the ‘State’ of some other class, which you need to access later. You want to be notified ones this has been done. You do not care what the workflow is, so you do not want a reference in your class.

Your class would look something like this:

private string corrID;
private long timeNow;

EventPublication(“topic://Workflow/WorkflowStart”, EventScope.WorkItem, Correlated=true, ResponseTimeout=20000)
public event EventHandler<CorrelationEventArgs> WorkflowStart;

where the EventPublicationAttribute has two more properties:
public bool Correlated and
public long ResponseTimeout

There is also an event subscription in your class like:

EventSubscription(“topic://Workflow/WorkflowStop”, EventScope.WorkItem, Correlated=true) /// EventSubscription with added ‘bool Correlated’ property. ///
public OnWorkflowStop(object sender, CorrelationEventArgs e)
{
If (e.CorrelationId == corrID && e.InnerEventArgs != CancelEventArgs && Timer.Now <= timeNow + 20000)
{
…..
}
};

you would also have a method which fires the WorkflowStart event:

public RaiseWorkflowStart()
{
CorrelationEventArgs args = new CorrelationEventArgs;
args.InnerEventArgs = new EventArgs; // any EventArgs allowed
args.CorrelationID = corrID;
timeNow = Timer.Now;
args.TimeStamp = timeNow;
WorkflowStart (this, args);
…..
}

The CorrelationEventArgs has ‘CorrelationID’, ‘TimeStamp’ and ‘InnerEventArgs’ properties.

The workflow service will subscribe to the ‘WorkflowStart’ event and publish the ‘WorkflowStop’ event (the event attributes will have the same syntax as above).
When the workflow service raises the ‘WorkflowStop’ event, once it has finished processing, it will wrap the ‘CorrelationID’, received through the 'WorkflowStart', and the ‘TimeStamp’, into the ‘CorrelationEventArgs’, together with appropriate ‘InnerEventArgs’.

If in the meantime there is a 'TimeOut', the 'EventBroker' will itself fire a 'WorkflowStop' event, with a 'CorrelationEventArgs' wrapped with a 'CancelEventArgs' and the 'CorrelationID'.