What is a Service Bus?
The Service Bus is a common pattern in Enterprises. It is never just one product – despite some products that position themselves as such – but rather a composed set of components used for application integration. For example, Active Directory + UDDI or some other service directory + queues + pub/sub + a messaging stack.
The key components of the ESB pattern – Federated Identity and Access Control, Naming, Service Registry and the Messaging Fabric – are components we can build in the cloud, with cloud scale, to augment an existing ESB or for applications to use directly as their primary service bus.
The Internet Service Bus is also a pattern rather than a product. Microsoft is delivering pieces that enable you to build your Service Bus with some components in the cloud. Exactly how you build out the service bus will depend on your business needs and existing infrastructure. For example, you may have some components of your bus on premise, such as your directory, or BizTalk Server or WebSphere, as well as using some or all of the .NET Services: access control for identity federation, service bus naming, registry and messaging fabric for connectivity and .NET Services workflow for service orchestration.
In most environments, especially with partnerships between small and medium businesses, apps in the consumer space, and with mobile workforces, connectivity is a real challenge.
Whereas with a LAN you have everything under your control, when you go outside the corporate LAN you typically no longer have a static IP address (unless you pay through the nose). If you use an ISP you often do not even have a public IP address as you are sitting behind a NAT on, for example, DSL. This makes locating and using services extremely difficult. You can use Dynamic DNS but it names a whole network. It does not address individual services in that network.
Add to that network and machine firewalls, locked down tightly by IT staff in the interests of security, accessing services can be a nightmare. The .NET Service Bus is built to address these challenges.
People currently try to deal with these issues by using Dynamic DNS, port mappings, universal plug and play and inbound firewall ports. None of these is an effective solution.
Q: Who needs bi-directional connectivity, irrespective of location?
A: Very many applications – anything beyond a simple web app. And, in particular, business applications. You can’t solve these with just the web.
There are three parts to the Service Bus:
- Naming – how to resolve a service
- Registry – how to find a service
- Fabric – how to connect to a service
For service bus naming, there is a federated, hierarchical, DNS-integrated, transport-neutral naming system. What does this mean exactly and why do we need to do this?
Anything wrong with DNS?
DNS works well but for exposing individual service endpoints (be it via SOAP, REST or even a TCP socket) it has limitations. DNS names hosts not services. While it’s true that you can name services such as mail servers using an MX record, and you could conceivably name all kinds of services in this way, the reality is that it would be difficult to get these defined and implemented across all the existing infrastructure.
DNS also has a very high update propagation latency. Bringing up a service endpoint and registering with DNS takes a while. Setting the Dynamic DNS TTL to zero forces the client to re-resolve the name but in reality most networking stacks just cache the IP address.
DNS is also “broken”. If I type in a non-existent DNS name, rather than failing my ISP serves me a search page with ads on it. This is not good for a communication system and is difficult to change.
DNS names hosts not services. So it may name the gateway to your network but not the machines behind that gateway except via port patching.
Updating DNS depends on the Dynamic IP address provider that you have but is typically based on an out-of-band write model.
So, in conclusion, while DNS is in many ways a good system it is not suitable for services.
The Service Bus naming system integrates with, and layers on top of, DNS, providing a means to name a service endpoint, while addressing latency issues and providing a secure write mode.
Service Registry and Discovery
The canonical form of URI projections is that we have a DNS-integrated naming scope and then an arbitrary tree of names. DNS-integrated means that is the method by which the naming scope is resolved. The whole system is URI-based. It’s a federated forest of naming trees where every path through the forest maps to a URI.
As of Milestone 5 (March 2009 release) you can create a root. This allows you to define a policy at the root which allows services to be callable by a Silverlight or a script client (where you have to have a policy at the root). However, there are some other security issues that have to be resolved around Silverlight (cross-site policy). The team is also considering being able to expand names out to the left (e.g. a.b.c.servicesbus.windows.net).
There is no API for the naming system directly. Rather, you use names when you access the relay and via the service registry.
The Service Registry is a registry of service endpoints. For each solution you have an ATOM feed and you can register services into that ATOM feed using either the Atom Publishing Protocol (APP) or WS-Transfer.
In Part II we will discuss:
- Connectivity and
Migrating an WCF Service to .NET Services Bus (based on Dec 2008 TCP)