Above The Cloud

To understand the Internet Service Bus Application Pattern we must first understand the concepts of an Enterprise Service Bus (ESB). An ESB is essentially a brokering service that facilitates communication between entities (usually services). Imagine a situation where there is a service that only communicates via TCP on port 1000 and a client that can only make requests over HTTP due to a corporate firewall. An ESB can broker such communication.

For an ESB to be successful it must be flexible. It needs to support many different protocols, be able to communicate synchronously and asynchronously, manage security, translate messages between services, and be programming language agnostic. For more information on what an Enterprise Service Bus is, refer to the Wikipedia article for a detailed description.

So what happens if we want to take these concepts and make them available on the Internet? How would one design an Internet Service Bus (ISB)?

Taking an existing ESB and simply "Internet enabling" it is one such approach, but this doesn’t make it much different from an ESB. One of the key differences is that some of the services need to be hosted in the ISB. That is, users can move some of their service applications into the cloud. Another consideration is security: authentication to use the ISB itself, but also end-to-end security around the brokered communications.

Microsoft have implemented an ISB as a part of their Azure offering, and this naturally manifests itself in the Microsoft .NET Services platform. The ISB is a critical piece of infrastructure in brokering communication and managing workflow. Microsoft has established some important concepts as part of the high level pattern for its own ISB (BizTalk Services):

• Service Registry
• Naming
• Identity and Access Control
• Connectivity

Service Registry
This is a common registry for storing services hosted by the ISB. This helps mediate the brokering process.

Naming
Applying human readable naming conventions such as a URI to easily identify a particular service

Identity and Access Control
This helps identify what kinds of security mechanisms will be available (for example, Active Directory, Live ID, OpenID, etc) and how to manage the authentication and authorization of various services.

Connectivity
The ISB needs to provide brokering services, but also needs to be able to step out of the picture once a connection is established. Or sometimes having all communications going through the relay can help optimize performance.

Each of the above areas is a blog post unto itself, but the most complicated and detailed aspects of the Microsoft ISB definitely lie in Identity and Connectivity. For example, to create a connection between 2 services, the relay within the ISB must be employed to make that connection. But after this we can control how the connection continues: via the relay or via a direct connection. Sometimes maintaining a relay is important because of services that sit behind firewalls. There are now a whole bunch of new protocols for Windows Communication Foundation (WCF) that support connecting via the ISB.

For more information about the Microsoft ISB, please check these articles/videos:

The Internet Service Bus
InternetServiceBus.org
Architecture of the .NET Services – PDC2008 Video

I recommend the 3rd link above which is a video from PDC which describes the ISB extremely well with practical examples in .NET.