| The key importance of the ESB approach to SOA is that the service definition is separated from the mechanism for locating and invoking services. The role of the integration architect is to administratively define a composite business process flow by plugging services together into a message itinerary. The itinerary represents a set of discrete message routing operations, such as the basic steps introduced in Chapter 4 (see Figure 7-1). Figure 7-1. An ESB itinerary represents a distributed business process Message itineraries are key to enabling a highly distributed SOA across an ESB. The details of the itinerary are stored as XML metadata and carried with the message as it travels across the bus from one service container to the next. An itinerary can begin with any entry point or event that can happen on the bus, including the creation and posting of a message, initiated by any service that is accessible on the bus. An itinerary can even be attached to an inbound message as it arrives into the domain of the ESB. This could be an external event, such as the receipt of a SOAP message from an external business partner. The logical steps of an itinerary can represent service endpoints in an SOA that are physically spread out across geographic locations and accessible from anywhere on the bus, as illustrated in Figure 7-2. Figure 7-2. Service endpoints in an SOA, accessible from anywhere on the bus, are represented as logical steps in an itinerary Gartner has used the term "microflow" to indicate a short-lived, transient process segment. The ESB itinerary process is well suited for such microflows. Message itineraries are very handy for a discrete set of operations in which simple branching decisions can be made, and where the separation of time between service invocations is not a significant factor. For simple branching, an itinerary may also support the notion of a subprocess. Figure 7-3 shows the flow of control whereby a parent process can temporarily be suspended to invoke a subprocess, and then resumed when the subprocess returns. Figure 7-3. Flow of control in an itinerary subprocess A message itinerary contains metadata that describes how to route the message, including a list of forwarding addresses described as abstract endpoints or as rules to evaluate along the way. The ESB container is a "smart" container, meaning that it knows how to evaluate the itinerary of a message based on the metadata that gets carried with the message, combined with configuration knowledge that is cached locally at each container. This makes for a highly distributed routing network that doesn't rely on a centralized rules engine. A message itinerary is analogous to a travel itinerary that you carry when going on a trip. Your travel itinerary tells you where to proceed at each step of a journey: your flight information, rental car, hotel, etc. Imagine that, instead of carrying an itinerary, you would stop and call your travel agent at each step of the way: "OK, I'm off the plane...what's my rental car agency?...OK, I have the car...what hotel am I staying at?" That would be the equivalent of a centralized hub-and-spoke routing engine. The fact that there is no single "travel agent" to refer back to is a key differentiator that helps make the ESB approach highly distributed. It means that different parts of the ESB network can operate independently of one another without relying on any centralized routing engine that could potentially be a single point of failure. The management capabilities that are inherent in an ESB make it simple to remotely manage the distributed containers to push out changes in itinerary configurations. Since the message carries the itinerary and process state with it, only new messages entering the business process will get the newly configured instructions. Older messages already in process will not be affected. |