C# WCF Service Architecture – Events on Server Side

Architecturecdesignprogramming practiceswcf

Problem:
Now, I have some events that will take place when the client submits a request to the server. These events will arise on the server and they will be subscribed by the services themselves (the services on the server interact with one another not through a channel but as simple objects i.e instantiating a class) who will do some work and the return the result to client if need be.

In the event aggregator pattern the subscribers and publishers are unaware of each other.

Now I was looking at the options that I have to implement this problem and event aggregators got my attention. Plus, I want to have a way to notify multiple services when an event has occurred without explicitly calling them.

Edit:

Example:
In my current setup say I have three services X(publisher), Y(subscriber) and Z(subscriber). I have an incoming request for service Y before X. Since It was a registered subscriber (I have subscribed to the event in ctor) it gets instantiated and thus it is a live subscriber. Now a request comes for X and it gets instantiated and publishes the event. Y is alive to listen and handles the event. But, though Z was also a subscriber but had no alive instance when X published the event the call goes unheard. For this below I have given a possible solution but don't know if its a viable one. This is happening at the server.

Edit 2:

// Service X and Service Y and Service Z are not linked through a channel
// All services are WCF services and client call them through a channel
public class ServiceX{


publi void DoSomeWork(){


MyEventAggregator<MyEvent>.Instance.Publish(Payload);  //Some event is triggered and the subscribers will be notified


//if event aggregator is not used normal call would go like

ServiceY obj=new SerivceY();  // no channel creation

obj.CallSomeMethod(Payload);
}

}

public class ServiceY(){

public ServiceY(){
//subscribers register for event
MyEventAggregator<MyEvent>.Instance.Subscribe(MyHandler,true);  //true is a flag that keeps subscriber ref alive

}

MyHandler(dynamic obj){
//Do work

}

}


public class ServiceZ{
public ServiceZ(){
//subscribers register for event
MyEventAggregator<MyEvent>.Instance.Subscribe(MyHandlerZ,true);  //true is a flag that keeps subscriber ref alive

}

MyHandlerZ(dynamic obj){
//Do work

}

}
public class MyEvent:PubSubEvents<dynamic>{
//from prism library
//My Event
}


public class MyEventAggregator{

//implements singleton that returns the event aggregator instance.

}
//By using event aggregators the there can be multiple subscribers to an event without them knowing about each other

Possible Solution:
I could use the Prism Event Aggregators to publish and subscribe to events but that in itself will give rise to a problem i.e though I will have my subscribers registered they will only function if they are instantiated before the event is triggered (published).

So now I will have to make sure that my subscribers are alive when
the event is published which could be handled with an infrastructure module together with the unity application block(don't know if it will be required though) that deals with subscriptions though instantiating a ton of objects will have its overhead

Now what I wanted to know is am I thinking in the right direction because I haven't seen a lot of people using WCF and Prism Event Aggregators together (Prism is mostly considered to be client side framework as far as I know).

Edit 3:

Solution Code (to instantiate subscriber before publisher):
I could use unity to resolve this dependency say in the global.asax.cs file's application_start method I could do something like this:

IUnityContainer uContainer = new UnityContainer()
   .RegisterType<ISubscriber, ServiceY>("Abc")
   .RegisterType<ISubscriber, ServiceZ>("Xyz");

ISubscriber myInstance = uContainer.Resolve<ISubscriber>("Abc");
ISubscriber myInstance = uContainer.Resolve<ISubscriber>("Xyz");

where all subscribers will extend and ISubscriber interface like:

ServiceY:ISubscriber{}

This would ensure that the subscriber instance is alive when an event is published.

How would you go about dealing with events in WCF?

Are there any other options that I have??

Best Answer

I posted this question on codeplex forum and got the answer from Bryan Noyes. It is:

I'm afraid you are cleanly outside what Prism pub-sub events were designed for. They were designed for loosely coupled components that are all in memory at the same time on the client side but you don't want to introduce coupling between those client components for them to communicate. For the kind of scenario you are talking about server side queues of some sort are the right answer, whether they are MSMQ-based, RabbitMQ, or Service Bus queues for Service Bus for Windows Server (or many other options along those lines depending on whether you want the queue to be on premise or in the cloud).

So in short prism pubsubevents aren't a good idea when it comes to server side events.