For some time now, the existence of web services technologies has stimulated the discussion of Services Oriented Architectures (SOAs). The discussion isn't a new one; the concept has been developing for more than a decade now, ever since CORBA extended the promise of integrating applications on disparate heterogeneous platforms. Problems integrating those applications have always arisen, often because so many different (and non-CORBA-compliant) object models became popular; thus many architects and engineers became so bogged down in solving technology problems that the promise of developing a more robust architecture that would allow simple, fast, and secure integration of systems and applications was lost.
| ||express delivery|
| print comment|
SOA is more than any particular set of technologies, such as web services; it transcends them, and, in a perfect world, is totally independent of them. This article is an excerpt from "The case for developing a service-oriented architecture", the first in a series of white papers intend to help plan migration to SOA. The authors are Kishore Channabasavaiah, executive architect, IBM Global Services; Kerrie Holley, distinguished engineer and chief architect, eBusiness Integration Solutions, IBM Global Services; and Edward M Tuggle Jr, senior software engineer, IBM Software Group.
Glossary terms: SOA, CORBA, web services, B2B, lookup tool
The problems, however, persist, and become more complex every year. Basic business needs such as lowering costs, reducing cycle times, integration across the enterprise, B2B and B2C integration, greater ROI, creating an adaptive and responsive business model, and so on keep us looking for better solutions; but more and more, we are finding that "point solutions" won't solve the basic problem. The problem, in many cases, is the lack of a consistent architectural framework within which applications can be rapidly developed, integrated, and reused. More importantly, we need an architectural framework which allows the assembly of components and services for the rapid, and even dynamic, delivery of solutions.
The advent of web services has produced a fundamental change, because the success of many web services projects has shown that the technology does in fact exist, whereby you can implement a true service-oriented architecture. It lets you take another step back and not just examine your application architecture, but the basic business problems you are trying to solve. From a business perspective, it's no longer a technology problem, it is a matter of developing an application architecture and framework within which business problems can be defined, and solutions can be implemented in a coherent, repeatable way.
Beyond web services
First, though, it must be understood that web services does not equal service-oriented architecture. Web services is a collection of technologies, including XML, SOAP, WSDL, and UDDI, which let you build programming solutions for specific messaging and application integration problems. Over time, you can reasonably expect these technologies to mature, and eventually be replaced with better, more efficient, or more robust ones, but for the moment, they will do. They are, at the very least, a proof of concept that SOAs can finally be implemented. So what actually does constitute a service-oriented architecture?
SOA is just that, an architecture. It is more than any particular set of technologies, such as Web services; it transcends them, and, in a perfect world, is totally independent of them. Within a business environment, a pure architectural definition of a SOA might be something like "an application architecture within which all functions are defined as independent services with well-defined invokable interfaces which can be called in defined sequences to form business processes". Note what is being said here:
- All functions are defined as services. This includes purely business functions, business transactions composed of lower-level functions, and system service functions. This brings up the question of granularity, which will be addressed later.
- All services are independent. They operate as "black boxes"; external components neither know nor care how they perform their function, merely that they return the expected result.
- In the most general sense, the interfaces are invokable; that is, at an architectural level, it is irrelevant whether they are local (within the system) or remote (external to the immediate system), what interconnect scheme or protocol is used to effect the invocation, or what infrastructure components are required to make the connection. The service may be within the same application, or in a different address space within an asymmetric multiprocessor, on a completely different system within the corporate Intranet, or within an application in a partner's system used in a B2B configuration.
In all this, the interface is the key, and is the focus of the calling application. It defines the required parameters and the nature of the result; thus, it defines the nature of the service, not the technology used to implement it. It is the system's responsibility to effect and manage the invocation of the service, not the calling application. This allows two critical characteristics to be realized: first, that the services are truly independent, and second, that they can be managed.
The promise of SOA is true; that after all the hype has subsided, and all the inflated expectations have returned to reality, you will find that a SOA, at least for now, is the best foundation upon which an IT organization can take its existing assets into the future as well as build its new application systems.
More on this topic
The application of web services protocols doesn't guarantee the delivery of good services ...
Enterprises are adopting web services for short-term benefits ...