|
THE NEXT REVOLUTION IN INFORMATION TECHNOLOGY
Businesses are looking to service-oriented architectures (SOA) as the best way to leverage their Information Technology (IT) assets and to provide their organizations with the agility needed to be competitive in today's economy.
This white paper explores why service-oriented architecture has emerged as one of the most significant developments in IT, and is followed by an overview of how businesses can make the transformation to service-orientation.
Growing Momentum
There is a remarkable consensus on the importance of SOA. Customers, vendors and analysts are united in the conviction that SOA is the dominant theme in IT today.
Consider that:
- In an April 2003 report, Service-Oriented Architecture: Mainstream Straight Ahead, Gartner, Inc. predicted that "by 2008, SOA will be the prevailing software engineering practice, ending the 40-year domination of monolithic software architecture (0.7 probability)."
- An article in the October 2003 edition of CIO Magazine noted that over 50% of clients in a survey were already engaged in some form of SOA development.
- A report in the Wall Street Journal in November 2003 noted that 85% of large North American companies planned to use Web services in the coming year.
- A March 2004 survey of 100 CIOs by Smith Barney found that service-oriented architecture was their number one priority in the area of emerging technologies.
- Almost every software vendor on the market has claimed some association with service-oriented architecture (some more legitimately than others).
But what exactly is "service-oriented architecture," and why has it generated such interest?
Quite simply, SOA is an approach to software design ("architecture") where applications are assembled from reusable components ("services"). A service is a software building block that performs a distinct function - such as retrieving customer information from a database - through a well-defined interface (basically, an electronic description of how to call the service from other programs).
SOA differs from other forms of computing in a few fundamental ways. First, software is organized into modular components. This is not a novel concept, but the difference with SOA is that the components, or services, are loosely coupled. Loose coupling is significant because it underlies the flexibility behind SOA. Loose coupling means services can be linked together dynamically at run-time, with few dependencies on how the services are actually implemented. For example, a company could create a "Customer Lookup" service to return information about a customer. With an SOA, any application needing customer information would be able to find, link to, and call the Customer Lookup service, regardless of whether the service was built using the same or different programming technologies as the calling application. Tight coupling, in contrast, results when there are dependencies between software modules that are designed, coded, or compiled into application programs.
Loosely coupled services can be linked together easily and quickly as business requirements demand. Tightly coupled systems are less flexible, usually involving recoding or recompilation when interdependent components are modified. Tight coupling makes it hard for applications to adapt to changing business requirements.
An important consequence of loose coupling is that services can run anywhere on the network and they are not restricted to a specific hardware or software platform or programming language. In an SOA, services can (and in many cases will) originate from different technology suppliers. Tightly coupled systems, on the other hand, usually involve a commitment to a specific software environment, which creates interoperability issues when different platforms need to be integrated.
The second defining feature of SOA is that services exist as two distinct elements - a well-defined service interface and the service implementation.
The service interface describes how to call the service, specifying, among other things, where the service is located and the format of input/output parameters. The service interface is what provides another program with the information it needs to make a request to the service and get a response. The Customer Lookup service interface, for instance, might specify different ways of querying customer information (by customer id, by customer name, etc.), and the structure of the customer data that is returned by the service.
The service implementation is the actual code that fulfills the functionality of the service. It is the logic that resides on a computer somewhere on the network and executes when called (subject, of course, to appropriate security constraints).
|
