Looking around we see the term or acronym SOA becoming widely used, but there’s not a lot of precision in the way that it’s used. The World Wide Web Consortium (W3C) for example refers to SOA as ‘A set of components which can be invoked, and whose interface descriptions can be published and discovered’. We see similar definitions being used elsewhere; it’s a very technical perspective in which architecture is considered a technical implementation. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services.
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.
The components of a Service-Oriented Architecture include:
-
Service providers. A service provider is a component or set of components that execute a business function in a stateless fashion, accepting predefined inputs and outputs.
-
Service consumers. A service consumer is a set of components interested in using one or more of the services provided by service providers.
-
Service repository. A service repository contains the descriptions of the services. Service providers register their services in this repository and service consumers access the repository to discover the services being provided.
Figure 1. Service-oriented architectural components
What are the implementation Challenges of SOA?
While designing and implementing a service-oriented architecture, a company faces up to eight key challenges. These challenges align to the steps in a typical project deployment plan:
-
Service identification. What is a service? What is the business functionality to be provided by a given service? What is the optimal granularity of the service?
-
Service location. Where should a service be located within the enterprise?
-
Service domain definition. How should services be grouped together into logical domains?
-
Service packaging. How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services?
-
Service orchestration. How are composite services to be orchestrated?
-
Service routing. How are requests from service consumers to be routed to the appropriate service and/or service domain?
-
Service governance. How will the enterprise exercise governance processes to administer and maintain services?
-
Service messaging standards adoption. How will the enterprise adopt a given standard consistently?
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 in my opinion are:
-
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. -
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. -
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.
Service-oriented architectures are rapidly being accepted by the IT world as a sound, modularized approach for building and deploying services across the extended enterprise. However, practical implementation of these architectures requires careful planning. Interested enterprises must first make sure that they’re geared up to implement and support them in the long-term.
