Figure1: A Service-Oriented Architecture
A service-oriented architecture is an information technology approach or strategy in which applications make use of (perhaps more accurately, rely on) services available in a network such as the World Wide Web. Implementing a service-oriented architecture can involve developing applications that use services, making applications available as services so that other applications can use those services, or both.
A service provides a specific function, typically a business function, such as analyzing an individual's credit history or processing a purchase order. A service can provide a single discrete function, such as converting one type of currency into another, or it can perform a set of related business functions, such as handling the various operations in an airline reservations system. Services that perform a related set of business functions, as opposed to a single function, are said to be "coarse grained." Multiple services can be used together in a coordinated way. The aggregated, or composite, service can be used to satisfy a more complex business requirement. In fact, one way of looking at an SOA is as an approach to connecting applications (exposed as services) so that they can communicate with (and take advantage of) each other. In other words, a service-oriented architecture is a way of sharing functions (typically business functions) in a widespread and flexible way
A service-oriented architecture is a way of sharing functions (typically business functions) in a widespread and flexible way.
The concept of an SOA is not new. Service-oriented architectures have been used for years. What distinguishes an SOA from other architectures is loose coupling. Loose coupling means that the client of a service is essentially independent of the service. The way a client (which can be another service) communicates with the service doesn't depend on the implementation of the service. Significantly, this means that the client doesn't have to know very much about the service to use it. For instance, the client doesn't need to know what language the service is coded in or what platform the service runs on. The client communicates with the service according to a specified, well-defined interface, and then leaves it up to the service implementation to perform the necessary processing. If the implementation of the service changes, for instance, the airline reservations application is revised, the client communicates with it in the same way as before, provided that the interface remains the same. Loose coupling enables services to be document-oriented (or document-centric). A document-oriented service accepts a document as input, as opposed to something more granular like a numeric value or Java object. The client does not know or care what business function in the service will process the document. It's up to the service to determine what business function (or functions) to apply based on the content of the document.
However what is relatively new is the emergence of web services-based SOAs. A web service is a service that communicates with clients through a set of standard protocols and technologies. These web services standards are implemented in platforms and products from all the major software vendors, making it possible for clients and services to communicate in a consistent way across a wide spectrum of platforms and operating environments. This universality has made web services the most prevalent approach to implementing an SOA.
Web services standards are implemented in platforms and products from all the major software vendors. This universality has made web services the most prevalent approach to implementing an SOA.
Optionally, an SOA can also include a service that provides a directory or registry of services. The registry contains information about the service such as it's interface. A client can discover services by examining the registry. A registry can also be coupled with a repository component that stores additional information about each service. This additional "metadata" can include business process information such as policy statements.
Why SOA?
There are many reasons for an enterprise to take an SOA approach, and more specifically, a web services-based SOA approach. Some of the primary reasons are:
Reusability What drives the move to SOA is reuse of business services. Developers within an enterprise and across enterprises (particularly, in business partnerships) can take the code developed for existing business applications, expose it as web services, and then reuse it to meet new business requirements. Reusing functionality that already exists outside or inside an enterprise instead of developing code that reproduces those functions can result in a huge savings in application development cost and time. The benefit of reuse grows dramatically as more and more business services get built, and incorporated into different applications. A major obstacle in taking advantage of existing code is the uniqueness of specific applications and systems. Typically, solutions developed in different enterprises, even different departments within the same enterprise, have unique characteristics. They run in different operating environments, they're coded in different languages; they use different programming interfaces and protocols. You need to understand how and where these applications and systems run to communicate with them. The work involved in doing this analysis and the development effort in tying these pieces together can be very time consuming. Witness the pain IT organizations generally encounter when they try to integrate their applications with systems from business partners (or even with legacy systems from other parts of their own company). In an SOA, the only characteristic of a service that a requesting application needs to know about is the public interface. The functions of an application or system (including legacy systems) can be dramatically easier to access as a service in an SOA than in some other architecture. So integrating applications and systems can be much simpler.
The functions of an application or system (including legacy systems) can be dramatically easier to access as a service in an SOA than in some other architecture. So integrating applications and systems can be much simpler.
Interoperability The SOA vision of interaction between clients and loosely-coupled services means widespread interoperability. In other words, the objective is for clients and services to communicate and understand each other no matter what platform they run on. This objective can be met only if clients and services have a standard way of communicating with each other -- a way that's consistent across platforms, systems, and languages. In fact, web services provide exactly that. Web services comprise a maturing set of protocols and technologies that are widely accepted and used, and that are platform, system, and language independent. In addition, these protocols and technologies work across firewalls, making it easier for business partners to share vital services. Promising to make things even more consistent is the WS-I basic profile, introduced by the Web Services Interoperability Organization (an organization chartered to promote web services interoperability). The WS-I basic profile identifies a core set of web services technologies that when implemented in different platforms and systems, helps ensure that services on these different platforms and systems, and written in different languages, can communicate with each other. The WS-I basic profile has widespread backing in the computer industry, virtually guaranteeing interoperability of services that conform to the profile.
Scalability Because services in an SOA are loosely coupled, applications that use these services tend to scale easily -- certainly more easily than applications in a more tightly-coupled environment. That's because there are few dependencies between the requesting application and the services it uses. The dependencies between client and service in a tightly-coupled environment are compounded (and the development effort made significantly more complex) as an application that uses these services scales up to handle more users. Services in a web services-based SOA tend to be coarse-grained, document-oriented, and asynchronous. As mentioned earlier, coarse-grained services offer a set of related business functions rather than a single function. For example, a coarse-grained service might handle the processing of a complete purchase order. By comparison, a fine-grained service might handle only one operation in the purchase order process. Again, as mentioned earlier, a document-oriented service accepts a document as input, as opposed to something more granular like a numeric value or Java object. An example of a document-oriented service might be a travel agency service that accepts as input a document that contains travel information for a specific trip request. An asynchronous service performs its processing without forcing the client to wait for the processing to finish. A synchronous service forces the client to wait. The relatively limited interaction required for a client to communicate with a coarse-grained, asynchronous service, especially a service that handles a document such as a purchase order, allows applications that use these services to scale without putting a heavy communication load on the network.
Flexibility Loosely-coupled services are typically more flexible than more tightly-coupled applications. In a tightly-coupled architecture, the different components of an application are tightly bound to each other, sharing semantics, libraries, and often sharing state. This makes it difficult to evolve the application to keep up with changing business requirements. The loosely-coupled, document-based, asynchronous nature of services in an SOA allows applications to be flexible, and easy to evolve with changing requirements.
Cost Efficiency Other approaches that integrate disparate business resources such as legacy systems, business partner applications, and department-specific solutions are expensive because they tend to tie these components together in a customized way. Customized solutions are costly to build because they require extensive analysis, development time, and effort. They're also costly to maintain and extend because they're typically tightly-coupled, so that changes in one component of the integrated solution require changes in other components. A standards-based approach such as a web services-based SOA should result in less costly solutions because the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because services in an SOA are loosely-coupled, applications that use these services should be less costly to maintain and easier to extend than customized solutions. In addition, a lot of the Web-based infrastructure for a web services-based SOA is already in place in many enterprises, further limiting the cost. Last, but not least, SOA is about reuse of business functions exposed as coarse-grained services. This is potentially the biggest cost saving of all.
DPM - The Business Architects @ Quadrobay
