locked
Event notification between servers RRS feed

  • Question

  • I have been asked to design an internal project that will have several components that all extend off a core business logic layer. 

    How can I have the core notify other components of events when they are deployed in different places?

    Explanation: 

    Project Structure: 
    • Core BLL 
    • Core DAL
    • Project A BLL
    • Project A DAL
    • Project A UI
    • Project B BLL
    • Project B DAL
    • Project B UI
    Project A & B BLLs have dependencies on Core BLL for common functionality. Ditto for Project A & B DAL with respect to Core DAL.

    They will be deployed on an internal server in separate folders, such as "internalServer/ProjectA" and "internalServer/ProjectB". 

    How do I handle the following case best?

    In Project A a user persists a change to an instance, for example a Company, that belongs to Core. Project B wants to watch for changes to Companies. How can the Core best notify Project B that a certain company was changed? 

    How would this change if Project A and Project B are on separate servers?

    Thanks much for any assistance.
    Tuesday, January 5, 2010 4:20 PM

Answers

  • You need to implement a publish-Subscriber design pattern.

    Each subcriber needs to register to the publisher for notification. Whenever there is a change published notifies to all subscriber for the change.

    Its kind of similar to event based model. If it would have been an in memory issue then you can always use Events or delegates.

    For out of process communication you need to rely on messaging technologies like WCF. You publisher and subscriber both needs to expose web services to communicate. The publsiher will expose a service to register for events. During registration subscriber will tell which web service, method, Other config to use. Then its pretty simple, whenever there is a new change, publisher will internally check for all the subscriber for that specific event and call their services to notify.

    The above implementation is just oneway to implement this scenario. For more scalable scenarios you need to consider alot of other things too.

    Thursday, March 11, 2010 5:01 PM

All replies

  • Primarily communicating between two processess independent of the location can be achieved by implementing a service either a WCF service or even a windows service. Here also core can implement a service which will be hosted both by A and B (maintaining the location of the hosted service in a central location e.g. database). So whenever change occurs the caller service can call the other service for change notification by looking the location of the service. This is a simple solution and effective for few clients. For more number of clients a pub-sub implementation will scale better.
    Wednesday, January 6, 2010 11:41 AM
  • In Addition to Vijay's comment, when anything gets change in the core, it can send a message to project B. here things go as notify mechanism. I.e. asynchronous mechanism. If both the services are in the same server I would suggest you to make a class instance and call the functionality. If they are in different server, make a MSMQ binding. You don’t need to worry about this after that. But queue management [dead queue and poison queue and all] is the other area where you need to concentrate.

     

     


    --
    Paras
    • Proposed as answer by Paras B Tuesday, January 12, 2010 10:09 AM
    Saturday, January 9, 2010 10:58 AM
  •  For more number of clients a pub-sub implementation will scale better.
    yes, but only when the pub-sub uses a messaging model like MSMQ .  pub-sub via RPC approaches such as SOAP XML WS , .net remoting or REST do not scale well.

    incidently messaging models scale well regardless of whether the message is one-to-one, command pattern, or pub-sub which is rather nice.

    Micky D
    Thursday, March 11, 2010 6:01 AM
  • You need to implement a publish-Subscriber design pattern.

    Each subcriber needs to register to the publisher for notification. Whenever there is a change published notifies to all subscriber for the change.

    Its kind of similar to event based model. If it would have been an in memory issue then you can always use Events or delegates.

    For out of process communication you need to rely on messaging technologies like WCF. You publisher and subscriber both needs to expose web services to communicate. The publsiher will expose a service to register for events. During registration subscriber will tell which web service, method, Other config to use. Then its pretty simple, whenever there is a new change, publisher will internally check for all the subscriber for that specific event and call their services to notify.

    The above implementation is just oneway to implement this scenario. For more scalable scenarios you need to consider alot of other things too.

    Thursday, March 11, 2010 5:01 PM