ESB versus Fabric…Stop It!
Running in the SOA crowd, I notice a new debate brewing. As we work to create SOAs, there seems to be disagreement on the approaches and enabling technology one should use. In other words, should we leverage an ESB product or a Fabric product, or perhaps something else?
The truth of the matter is that all of the above is actually true. Let me explain why.
First, SOAs are complex, domain-specific architecture, and one technology or approach does not always fit. In many cases, creating an SOA is going to take a heck of a lot of redevelopment, and in other cases, not as much. In some instances, messaging layers (ESBs, really) are the proper technology to apply, for others, there is not as much need for structured information movement.
Second, SOAs are all about agility and not as much about the technology or approach. We build SOAs for one reason; it’s strategic technology that will make your business run better and accommodate change much better than traditional approaches. We do this by creating an infrastructure, somehow, that’s changeable as processes, services, and information changes.
Finally, we should consider the notion of an SOA as static, and technology and approach as dynamic. Let’s face it, the technology that we apply changes all the time. We should encapsulate those dynamics in their own domain and not get too wrapped around the axel about the latest and greatest, or manage our architecture by magazine articles and conferences.
Tough love, but we need to make sure we don’t get silly with this stuff.
Emerging Patterns
To my points above, the underlying message is that all SOAs are not the same. Indeed, as we begin to deploy SOAs, I’m seeing some emerging patterns that range from very primitive to very sophisticated, from low value to high value.
Level 0 SOAs are SOAs that simply send SOAP messages from system to system. There is little notion of true services, but instead, they leverage Web services as an information integration mechanism. Hardly SOA, but certainly a first step.
Level 1 SOAs are SOAs that also leverage everything in Level 0 but add the notion of a messaging/queuing system. Most ESBs are level 1 SOAs, leveraging a messaging environment that uses service interfaces, but really does not deal with true services (behavior), and instead moves information between entities as messages through queues.
Level 2 SOAs are SOAs that leverage everything in Level 1, and add the element of transformation and routing. This means that the SOA can move information from source and target systems, leveraging service interfaces, as well as transform the data/schemas to account for the differences in application semantics. Moreover, by adding the element of intelligent routing, you’re able to route the information based on elements such as source, content, and logical operators in the SOA.
Level 3 SOAs are SOAs that leverage everything in Level 2, adding a common directory service. The directory provides a point of discovery of processes, services, schemas, and such, allowing all those who leverage the SOA to easily locate and leverage assets such as services. Without directories, the notion of service reuse--the real reason for building SOAs--won’t work. Directories are typically standards-based, including UDDI, LDAP, and sometimes more proprietary directories such as Active Directory.
Level 4 SOAs are SOAs that leverage everything in Level 3, adding the notion of brokering and managing true services. Here is where the brokering of application behavior comes into play. In other words, at this level we are not only about managing information movement, but the discovery and leveraging of true services.
Finally, Level 5 SOAs are SOAs that leverage everything in Level 4, adding the notion of orchestration. Orchestration is key, providing the architect with the ability to leverage exposed services and information flows, creating, in essence, a “meta-application” above the existing processes and services to solve business problems.
Indeed, orchestration is really another complete layer on the stack, over and above more traditional application integration approaches we deal with at the lower levels. Thus, orchestration is the science and mechanism of managing the movement of information, and the invocation of services in the correct and proper order to support the management and execution of common processes that exist in and between organizations and internal applications. Orchestration provides another layer of easily defined and centrally managed processes that exist on top of existing processes, application services, and data within any set of applications.
So, it’s really a set of solutions, and even sub-patterns inside of those solutions that need consideration when building an SOA. Clearly, it’s not that “My technology is better than your technology.” The answer is that all types of technologies are applicable when solving the SOA problem. This is not about a debate, but an understanding of the end results of leveraging SOA, and the number of ways in which you can get there.
Trackback URL for this post: http://www.webservices.org/trackback/id/5766