SOA: Are We Reinventing the Wheel?
Pages: 1, 2
From the discussion of CORBA and J2EE, you see that both these technologies provide a way to build SOA. There have been several successful deployments of these technologies across different industry verticals. However, if you were to evaluate reuse at an enterprise level even within those enterprises that have deployed these technologies, the level of reuse is not where it should be. It is not uncommon to come across enterprises in which dozens of "services" do exactly the same thing from a business standpoint—validate credit cards, look up employees, and so on.
Why does this duplication exist? The duplication is due to two major reasons:
So though these distributed component technologies provide explicit support to build SOA and are based on industry-accepted standards, these two factors above have hindered reuse at an enterprise level. Note that the actual situation is much worse because along with these standards-based technologies, an enterprise may have systems based on proprietary middleware technologies such as MQ and TIBCO. All these systems, both standards-based and those based on proprietary technologies, should be considered as an enterprise's IT assets since much investment has gone into building these systems. Functionality already within these existing systems must be exposed as reusable services from which new systems can be easily composed. Experience with CORBA and J2EE has taught us that this will not be solved by introducing yet another set of APIs or yet another transport protocol. What we need to do is to standardize on the message format and use transport protocols already prevalent in an enterprise such as MQ and IIOP. You will see in the next section how Web services address this requirement.
Web services, which are based on many of the same technologies as the Internet and the Web, address many of the issues with distributed component models. I assume that you already have a basic understanding of Web services. For those who want a quick primer, refer to the references at the end of this article. In this section, I examine how Web services address the limitations of distributed component models such as CORBA and J2EE.
As you can see from the above discussion, Web services do indeed solve many of the problems associated with distributed component models. Web services are the best fit for deploying an SOA.
We aren't quite there yet, however. As I alluded to earlier, when discussing the complexity associated with distributed component models, one of the major contributors to complexity is the challenge of supporting the entire lifecycle of a service, which involves not only building it but also deploying, versioning, securing, and managing it. We also need to broaden the definition of what a service is, to embrace what an enterprise has even if it is not based on Web services technologies such as SOAP and WSDL. This would include things such as integrations built out of messaging solutions like .NET, MQ Series, TIBCO, and legacy and packaged applications. To enable true reuse, we need to break down the silos that exist within an enterprise. We also need to make discovery and usage of these services a lot easier—it should move out the realm of the programmer to operational staff and even to the business analyst.
We see that the industry continues to evolve based on the experiences and lessons learned collectively. The above discussion should not be taken to mean that older technologies don't have any value or place in the enterprise. We still need object-oriented programming languages such as Java, distributed component technologies, and messaging systems to build new systems. As mentioned in the last section, the challenge is to enable reuse across existing technology silos by treating the functionality within these systems as services and enabling the creation of new composite applications that leverage these services. Though it is certainly possible to hand-build this with existing technologies, it is neither easy nor cost effective. Just as we have J2EE as the infrastructure to build applications, we need a similar infrastructure to compose, consume, and manage the lifecycle of services that span an enterprise. In short, we need service infrastructure (see Figure 1). The essential characteristics of such a service infrastructure should include:
Figure 1. Essential elements of a service infrastructure
Service infrastructure goes a long way in enabling a SOA and promoting reuse. This represents the culmination of collective learning by the industry to enable reuse and make building systems less complex. This will no doubt continue to evolve based on experience deploying new applications that leverage such an infrastructure. Many companies are legitimately concerned about the number of Web services standards, some of which are driven by various competing vendor camps. More vendor cooperation is needed not only to quickly converge on some important standards in the Web services and security arena, but also to address actual testing and validation so that interoperability of products is not left as an exercise for the customer.
I listed a long set of requirements for the service infrastructure. The good news is that several products on the market already support a majority of these features. However, it is very important to recognize that your enterprise will not have a service infrastructure that delivers value in terms of flexibility and agility just by virtue of buying a product that claims to support these features. SOA and the service infrastructure that enables SOA can be transformational and therefore needs changes in organization, process governance, and culture. The IT organization should enforce architectural consistency and align itself more closely with its business stakeholders to get support and funding as it undergoes the transformation. Processes should be defined as to how services are delivered and how to manage the interdependencies of the participants in a SOA. Some services reused by most applications may be horizontal and generic; others may be specialized to a few select applications. A governance model that covers how these services are funded and developed is important. Finally, the culture should encourage and reward reuse of existing services instead of building everything from scratch.
If all this sounds daunting, it should—it is a daunting task. However, there are several pieces of promising developments. First, the Web Service Interoperability (WS-I) group is specifically charted to promote Web services interoperability across different implementations. Vendors do interoperability testing based on the profiles developed by WS-I. Though this may seem like an obvious thing to do, it was not the case with either CORBA or J2EE. It was worse with proprietary middleware and EAI products. The second piece of good news is that the tools on which to build a service infrastructure have become sophisticated yet easy to use. BEA's AquaLogic Service Bus product, for example, is entirely configuration-driven—almost all tasks can be done with a graphical user interface. Finally, SOA has already been deployed in many organizations where the benefits in terms of faster application development and cost benefits have been realized. The more mature IT organizations have captured such metrics and best practices around their implementations to learn and to demonstrate to their businesses how agile IT can be a competitive differentiator.
Nick Simha is the manager for the Systems Engineering group supporting partners at BEA. His interests include distributed computing, applicability of technology to solve business problems and Service Oriented Architecture. He holds a M.S. from the University of Missouri.