I’ve been thinking a lot lately about how to present the ideas of the Enterprise Service Bus (ESB) in a way that parallels what we say about loose coupling for SOA in general. I think most people are to used to the idea that SOA supports a layer of abstraction between a service and the user of that service, be it a device, an application, or another service. The basic idea that most people latch onto is the loose coupling between a browser and the web servers that feed it the information it needs to display. As I’ve said before, except for annoying pages that only work with a particular browser, typically Internet Explorer, there is a wonderful degree of standardization that allows different browsers to display the same content, perhaps with varying user experiences such as the tabbed browsing in Firefox.
For example, if the provider of an online newspaper decides to change the underlying hardware, operating system, or application server that handles the requests for web pages, readers of the newspaper should have to do nothing different to view the text. The newspaper provider has his or her reasons for changing the infrastructure, perhaps to improve performance, availability, content management, or security. As the reader, I don’t really care as long as I get my information, though I would certainly hope that it is delivered faster than it was before.
So if we look at service invocation in SOA, we want the same thing: a consistent user interface that hides the underlying implementation. When we talk about the ESB, we hope to eventually get the same same thing: consistent communication that hides the underlying implementation but gives us the quality of service characteristics we need. This could be fairly minimial in cases where throughput requirements are low and perhaps it is not even necessary for the communication to be one hundred percent reliable (perhaps simple queries that are repeated on a regular basis, say for local restaurants). On the other hand, if we need very fast, secure, and reliable communications we will probably need an underlying infrastructure that is more powerful than the proverbial XML equivalent of two cans connected by a string.
As you might expect, I use Lotus Notes for my IBM internal email. There are various delivery options available when I send mail, such as whether I want the mail encrypted or signed, and what sort of delivery priority I want. I can also choose to be notified when the recipient gets the note. I don’t need to think about how all these works, I can just indicate that I want them. I don’t have to think about how the delivery priority is actually implemented nor about the exact route the note follows from me to the person to whom I am sending it. The system takes care of the communicatiosn details once I give a rough idea of what I want.
In the future I anticipate an ESB to operate something like this:
- A potential user of a service gets a handle to the service either statically or via a dynamic lookup. For example, I might be a retailer using multiple services to process credit card authorizations. I might walk down the list of services in a round-robin fashion when I need to do consecutive authorizations. I might have gotten the list from my internal UDDI registry that I queried at the beginning of the day. If a new bank is added to the registry, I’ll pick that up next I refresh the list. There are more sophisticated ways of doing this, but you get the idea. Nevertheless, you have what I’ve called a handle to the service, which may be a URL. In the simplest case, this might be hard coded, but that has its own inherent dangers.
- Next we deal with policy negotiation. Suppose we specify that the communication between the client and the service must be one second or less. This means that ESB might have to reroute the communication through a higher throughput channel or else bump lower priority service calls so that ours gets through fast enough. This means we need some way of specifying what we mean by relative priorities, such as saying that the service is being invoked on behalf of a Platinum Plus customer. It also might involve additional charges since in theory one might be willing to pay more for faster communication. By the way, these concerns might also be specified for the service itself. Some of the things we’re doing in WebSphere Extended Deployment (XD) relate to making sure that high priority jobs get more and faster attention. Eventually we’ll think of these XD capabilities as part of the ESB implementation itself.
- We now need to know if we can talk the same language as the service we wish to use. In the simplest case, it means we directly support one of the formats specified by the WSDL for the service. In case we do not, we can either call a data transformation service before we send our message or, more likely, the ESB itself will be able to tell us if the transformation can be done in flight. This may be more or less possible if the data is encrypted or signed, but it is a possibility. What we do not want to do is directly teach every potential client how to do data transformations unless there are performance or security issues.
- Speaking of security, we’ll need to make sure we both support the same protocols and use an intermediate bridge if necessary. This handshaking will eventually be facilitated by the WS-Security family of standards.
- Another area where we might want to specifiy that we want particular behavior is in the reliability of the message delivery. When we say reliable in this way, we usually mean that we want the message delivered once and only once. The other possibilities are that the message is possibly not delivered at all or else multiple copies might get there. If the recipient is not always connected to the network (say on a cellphone), then the message might need to be queued until the link is available. This adds a wrinkle to the communication, but we have dealt with it before (see, for example, WebSphere MQ Everyplace).
This is not an exhaustive list of the QoS things we may want to call out, but it gives you an idea of what we need to look at when we focus on the communication to and from services. The important thing to note are the following:
- It is highly unlikely that you will be working with only new applications, so you need an ESB infrastructure that can deal with legacy protocols and transports.
- As we think about mobile devices being services (for example, via the JSR 172 J2ME Web Services Specification), then we will have to realize that we may have occasionally connected services and deal with the QoS appropriately.
- Ultimately, we want to be able to say “I don’t care how I talk to the service, I just want it to happen fast enough, reliably enough, and securely enough. You take care of the details.”
Travel notes: I got home Tuesday morning from Hong Kong but I wish I could say the same about my luggage. It’s now been three days since I rechecked the luggage after Customs in LA and the airline still doesn’t have a clue where it is. This is starting to be problematic since I leave for Germany, Italy, and Norway on Sunday. The last thing I want to do is to go shopping on the weekend after Thanksgiving, but it’s looking more and more likely that I’ll be doing just that.