| One of the places where the ESB adds incremental value over a typical SOA is in the find/bind/invoke operations that ordinarily occur. To date, SOAs have typically been implemented using a client-server model. In an SOA that follows the client-server model, whether via web services or a predecessor, service clients contact other services through a process known as find, bind, and invoke. The find/bind/invoke model assumes that there is a registry or directory that stores the location and possibly other metadata about a service implementation. In the "find" operation, the service client does a lookup in the registry for the service, using certain criteria that may include names or characteristics such as "color dual sided." The next step is the "bind" operation, which for a web services request could simply mean doing an HTTP connect; and finally, the "invoke" operation, which means sending a message or invoking a remote procedure. With a web services approach to SOA, the bind and invoke are in the same operation. The problem with the find/bind/invoke approach is that it requires writing the routing and flow logic into the applications that need to be connected. Each service client needs to write code that does a lookup of the service; we saw the downside of that in Chapter 2. While it is certainly possible to do this, and it is even appropriate under certain circumstances within an ESB environment, it is not intended to be the norm. The basic design center of the ESB is that a service is not invoked directly by another service, but rather is part of a larger event-driven process flow. |
