2

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??

  • not sure I understand your set up. are you trying to do interprocess communication between seperate wcf services? – Ewan May 30 '15 at 21:37
  • Trying to get clear on the question. WCF will instantiate objects when needed to handle incoming requests. Your services are simple objects, can be instantiated when handling a WCF request / inbound message. Where's the problem, or the need for more framework? Probably just not understanding the question. – joshp May 30 '15 at 21:38
  • @Ewan yes i think you can say that but the communication between the services will take place when an event is raised. Simply, put say I have a service X and service Y. An incoming request comes to X which triggers an event which is subscribed by service Y (or more) it does some handling and returns some output. – Syed Osama Maruf May 31 '15 at 7:31
  • @joshp you are right that the wcf will instantiate the objects to handle incoming requests. but the problem arises when say I have three services X(publisher), Y(subscribers) and Z(subscribers). the request comes to X which publishes (triggers) an event now if before the event triggers say there were previously no req for Y and Z then though they are registered subscribers they won't be instantiated so the event goes unheard as i have subscribed in their ctors. This gives rise to the other problem mentioned. – Syed Osama Maruf May 31 '15 at 7:36
  • 1
    Its still not clear. you say the interaction is "not through a channel"? but your problem sounds like its caused by the wcf pub/sub model. basicialy the answer is probably "use a message queue" or convert the events to a state whoch is persisted and can be queried – Ewan May 31 '15 at 9:33
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.