This is actually the exact same scenario I have been using nServiceBus for. From the research I did nServiceBus is the most appropriate .Net solution for the problem apart from possible building a custom architecture.

Our setup at the moment (still developing) involves a single publisher on the database server which essentially does nothing except handle subscription messages to fill the subscription database. Everything else is essentially both a publisher and subscriber, however we have a fair few message types so some nodes will publish some messages and subscribe to others. The only thing publishers and subscribers need to know is where the database server is, which allows complete seperation between the two.

It is not the standard use of nServiceBus from what I have seen but so far it has been working very well. I have encountered a few problems which I am yet to find a solution for but overall everything looks to do its job well.

I am interested to hear if you find any other alternatives to nServiceBus or how you go implementing it. Hopefully within the next few weeks I will be able to spend some time working on our implementation and be able to provide some help if needed :)

--- In nservicebus@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@...> wrote:
>
> Stephen,
>
>
>
> Actually all messages already derive from a common base - IMessage. You can
> write a handler for IMessage and all messages will be dispatched to it.
>
>
>
> -- Udi Dahan
>
>
>
> From: nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] On
> Behalf Of swoolhead
> Sent: Friday, June 26, 2009 10:26 PM
> To: nservicebus@yahoogroups.com
> Subject: [nservicebus] Re: Central "ESB' with NServicebus
>
>
>
>
>
>
>
>
>
> I have a tier of front end web servers that receive messages from hardware
> we have scattered over the internet and then have a set of back end services
> that subscribe to this information.
>
> Rather than have each back end service subscribe to each of these front end
> web servers, what I have done is have these servers send, rather than
> publish their messages to a central repeater, then all the back end services
> subscribe to the repeater.
>
> If you derive all your messages from a common base class, you can add a
> generic handler in the repeater that just receives and publishes all
> messages sent to you. This does be become a single point of failure now so
> you should consider things like failover clustering for it.
>
> Cheers,
>
> Stephen.
>
> --- In nservicebus@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ,
> "rmontgomery429" <rmontgomery429@> wrote:
> >
> > Specifically we have a couple web applications that right now share
> information through database integration. For many reasons we would like to
> move away from this.
> >
> > So EcomAppA, and EcomAppB need to know about customer shipping
> information. We have another web app, CustomerManager that we use to manage
> customer information including shipping information.
> >
> > So the idea is to have the CustomerManager publish a
> CustomerShippingInfoUpdated message to "the bus" and any interested parties
> (subscribers) would pick up on that change.
> >
> > Later when we add a new app that needs Customer Shipping Information, we
> just have it subscribe to "CustomerShippingInfoUpdated" messages.
> >
> > I guess the subscribers would have to subscribe to something like
> messageBus@TheCustomerManagerMachine?
> >
> > This is fine, but the idea with something "central" was that maybe we add
> another application that can also update Customer Shipping Info. So now
> everybody has to change to listen to another machine.
> >
> > Is my goal just not practical?
> >
> > I appreciate your help.
> >
> > Ryan
> >
> >
> > --- In nservicebus@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> , "Udi Dahan" <thesoftwaresimplist@> wrote:
> > >
> > > > My goal is to have our apps that publish messages be ignorant of who
> is
> > > subscribing to them
> > >
> > > > and also have my subscribing apps remain ignorant of who publishes
> > > messages.
> > >
> > >
> > >
> > > It sounds like what you're looking for is an EAI broker (enterprise
> > > application integration).
> > >
> > >
> > >
> > > MSMQ isn't that.
> > >
> > > Neither is nServiceBus.
> > >
> > >
> > >
> > > A bus isn't a broker - there is no central bus. That's actually an
> oxymoron.
> > >
> > >
> > >
> > > With the current implementations in the box of nServiceBus, you'd have a
> > > queue on every machine (more or less - probably more).
> > >
> > >
> > >
> > > If you could describe what you're system does, I could suggest places
> where
> > > nServiceBus would provide you the most value.
> > >
> > >
> > >
> > > Hope that helps,
> > >
> > >
> > >
> > > -- Udi Dahan
> > >
> > >
> > >
> > > From: nservicebus@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> [mailto:nservicebus@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ]
> On
> > > Behalf Of Ryan Montgomery
> > > Sent: Wednesday, June 24, 2009 6:57 PM
> > > To: nservicebus
> > > Subject: [nservicebus] Central "ESB' with NServicebus
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Do applications using NServiceBus have to target a specific machine when
> > > publishing messages?
> > >
> > > Is there a way to publish a message to a global bus and have all the
> other
> > > apps that subscribe to that message type just pick up on it? It seems I
> > > would have to set up an actual machine with MSMQ running and a queue
> named
> > > MessageBus to do this. But then every machine that wants to publish
> messages
> > > to the bus will have to target MessageBus@CentralMechineName - is this
> the
> > > only way? Does MSMQ provide a logical "global" queue that is distributed
> > > across machines or something like that?
> > >
> > > My goal is to have our apps that publish messages be ignorant of who is
> > > subscribing to them and also have my subscribing apps remain ignorant of
> who
> > > publishes messages.
> > >
> > > Maybe this question is more about MSMQ than NServicebus - I don't know.
> > >
> > >
> > > Thank you for your input.
> > >
> > > Ryan Montgomery
> > >
> >
>