Eventing on the Enterprise Service Bus

As we become more and more comfortable with embracing, or at least utilizing the Service Oriented Architecture paradigm to construct either islands of services or a complete Enterprise Service Bus within our organizations, things like design patterns become ever important for the architect to leverage.

One of the most interesting as of late to me is how to take the robust eventing model found in typical .NET development (especially in the UI to Business layer) and translate that when the construct are services rather than single process code.

I have been thinking a lot of about this as I approach a new solution at work that multiple core (and in some cases legacy) systems need to send/receive data to this new process that I am designing. My initial thoughts were to decouple completely from all existing systems with a solid service layer to communicate with core systems as well as to provide business functionality that becomes orchestrated together for the application in question.

I want to avoid pushing data into any core system and I don't want any core system pushing data directly into my database or application. Futhermore, there is very little in either direction that has to be synchronous, therefore, I want this service layer to sit on top of a database that is essentially a queue.

The one thing that I need to figure out is how to create an eventing type system leveraging these services so that I can publish events that can be subscribed to, either directly by the core systems, or through proxies that are written specifically for the legacy core systems.

While researching some ideas for this I ran across a great presentation speaking to this exact problem. It mentioned within the presentation WS- Eventing, which is also something that I definately need to spend some time researching for application in my current scenario at work.