As Infoq has previously reported, Microsoft has recently released a new CTP of Azure services platform which is:
... a set of Microsoft-hosted, highly scalable, developer-oriented services that provide key building blocks required by many cloud-based and cloud-aware applications. Much like the .NET Framework provides higher-level class libraries that make developers more productive, .NET Services can help developers focus on their application logic rather than building and deploying their own cloud-based infrastructure services.
A centerpiece of Azura .Net Services is the Services Bus which:
... provides the familiar Enterprise Service Bus application pattern, while helping to solve some of the hard issues that arise when implementing this pattern across network, security, and organizational boundaries, at Internet-scale
According to Clemens Vasters, the most significant change in the March 2009 CTP is the addition of service bus routers and queues.:
... we’ve now started to add long-lived, system-inherent messaging primitives that exist and operate completely independent of any active listener that sits somewhere on some machine and is plugged into the Service Bus. That means that you can now leverage the Service Bus as an intermediary for push-pull translation, or as a publish/subscribe message distribution facility to optimize or facilitate messaging between places that are already "on the Web" or you can set up message distribution scenarios where some messaging destinations are existing Web Services and some receivers require the Service Bus’ relay capability to be reachable.
The implementation of Service service bus routers and queues is facilitated through a change in service bus namespace:
At its core, the Service Bus namespace is a federated, hierarchical service registry, whose structure is dictated and owned by "the project". The difference between the Service Bus namespace and a "classic" service registry system like DNS or UDDI or LDAP is that services or messaging primitives are (usually) not only referenced by the registry, but they are projected straight into the registry, so that you can interact with the registry and those services or messaging primitives projected into the registry using similar or identical programming interfaces and within the scope of a unified namespace... What makes the namespace "federated" is that services or messaging primitives can be projected into the shared namespace from "anywhere". Typically, the path portion of a URI represents a set of relatively tightly collocated set of resources that are residing across a web farm or a database cluster with the authority portion identifying (directly or indirectly) the target cluster.
Clemens Vasters explains, that:
The relationship between any messaging primitive and the Service Bus namespace is established by picking a name in your project’s Service Bus hierarchy... and then assign a role to that name... all names in a Service Bus namespace that can theoretically exist do already exist and their role is ‘none’. So when I’m assigning a role to a name, I don’t create the name itself. The name is already there, it’s just in hiding... Any name can play any role that’s supported by the system. We currently have a "metadata" role where you just stick an external reference such as a URI or a WS-Address endpoint reference into the name in the registry. We have a "connection point" role that’s established by the WCF listeners as they take over a name to listen on the Service Bus. And we’ve got these two new roles "queue" and "router".
He defines routers and queues:
A Router is a publish/subscribe message distribution primitive that allows "push" subscribers to subscribe and get messages that flow into the Router. A Queue is a " well " a queue that accepts messages and holds them until (a) consumer(s) come by and "pull" the messages off the queue. We’re explicitly allowing for Routers to subscribe to Routers and for Queues to subscribe into Routers. The resulting composite is typically quite a bit more powerful than any of the primitives alone. So we call these capabilities "primitives", because they explicitly allow for composition.
The capabilities of the Queue are defined by Queue policies which are somewhat similar to the policies of typical JMS queues and can be accessed and managed, using both WS* and Rest APIs.
Microsoft's views .NET Service Bus as an implementation of the ESB pattern, which has grown in popularity over the years because it simplifies the management of multiple service connections. One way it does this is by enabling publish/subscribe architectures, which provides for even looser-coupling throughout an enterprise. The introduction of the queuing support through Service Bus Routers And Queues in .Net Services March 2009 CTP, brings this vision one step closer to reality.