There’s a perception that Service- Oriented Architecture (SOA) is composed of Web services following a set of standards such as SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). While this is an approach to SOA, it certainly isn’t the only way of implementing an SOA.
Part of the problem is that there isn’t an agreed upon definition of SOA. Searching Wikipedia.org for “service-oriented architecture” yields this: “There is no widely agreed upon definition of service-oriented architecture other than its literal translation that it is an architecture that relies on service-orientation as its fundamental design principle. Service-orientation describes an architecture that uses loosely coupled services to support the requirements of business processes and users.”
In spite of the vague definition of SOA, there are three important characteristics:
- Services are modular, granular components with the emphasis on creating a larger number of smaller services rather than a few large services. This is highly subjective, but like most things in this business, there’s a balance between generating too many or too few components to avoid having either performance suffer or making reuse of services difficult.
- There’s some mechanism (catalog) to allow consumers to find services. This is the crux of the “loosely coupled” concept. In the “old days,” components were compiled or link-edited during development. This forced static relationships between components. In an ideal SOA implementation, components would never need to know the location of services until they needed them and then wouldn’t care where the service was located.
- Service users don’t need to know the actual location of the service. It may not be possible to allow any service consumer to call any service provider anywhere; the performance considerations and logistical difficulty of managing this environment are daunting.
So, while it’s certainly possible to implement SOA using Web services, that’s only one of several possibilities that include:
- Using message queuing systems (e.g., WebSphere MQ)
- Accessing legacy CICS and IMS transactions
- Taking advantage of robust DBMS capabilities, including those available in the DB2 product line (the focus of this article).
Technologies come and go; the successful ones have been those that provide cost-effective solutions to real problems without a requirement for completely changing the world. So, with SOA, what problems are we solving and at what cost (time and money)?
From a problem perspective, there are two key areas:
- Speed of development, maintenance, and evolution of applications
- Optimization of resources across the IT infrastructure to meet service requirements.
SOA improves the speed of development by allowing for a higher degree of reuse. This is a goal IT has been chasing since the early days of object-oriented programming. By pushing the coupling between components to run-time, SOA facilitates a looser binding, making reuse more viable.
SOA allows for better balancing between IT infrastructure components by eliminating some (or all) dependency on the location of services. It becomes possible to move services around without having to change the applications using the services.
So there are real problems SOA can address. The challenge of course is the cost of solving those problems. A key cost is infrastructure. In the case of a Web services SOA implementation, a number of the required components may not exist in the environment and, even if they do, they’re probably not configured for SOA use.