DEFINING SERVICE ORIENTED ARCHITECTURE
Service Oriented Architecture is a strategy for organizing IT resources into a set of services, each of which performs an individual business function. To the business user, this means that a business process can be created by linking together appropriate services in a coordinated fashion to achieve a business goal. Services become the building blocks for the analyst savvy in the operation of the business to create and manage business processes. To this end, services are defined in terms that the business analyst understands, such as “check inventory”, “apply credit to account”, or “notify customer of ship date”. Services are defined by the business analyst, not the technologist.

To a technologist, a Service Oriented Architecture can be seen as the most recent evolution of computing strategies. Over the last 50 years, computing strategies have continually reduced the burden on the programmer. This evolution has incrementally increased the level of abstraction involved in the programming task, making programming easier by hiding unimportant details, thus helping programmers more rapidly create programs that solve business problems.

SOA is the most recent paradigm along the continuum of programmer productivity enhancement. What started as machine coding in binary form evolved to assembly language programming, which over the years moved through high level programming languages, object oriented programming, component-based programming, to arrive at Service Oriented Architecture.

As details get abstracted away, the programming task requires less and less detailed knowledge of the underlying implementation. SOA strives to achieve a level of abstraction where the traditional programmer is no longer involved in the creation of business automation for many classes of business problems. Instead, a business analyst (not a programmer) builds new business processes out of existing services.

SOA carries a number of technical characteristics that distinguish it from other computing strategies. While the definition of a service is in terms the business analyst understands, it is the technologist who implements the service, and makes it available for participation in business processes. Once implemented, services are “published” in a manner that lets potential users of the service discover them on the network, and properly interact with them. Figure 1 below illustrates this process.

With a Service Oriented Architecture, services are rendered and consumed in the manner shown in Figure 1. This process involves the following steps:

1. Publish Service. When a service is fully developed and ready for use, the implementor “publishes” the service into a “Service Directory”. This is typically a searchable directory that stores detailed information about the service and its interface. The published information includes the details a computer program or user needs to invoke the service.

2. A service user, which is typically a computer program, in the coarse of its processing may have a need to invoke a particular process. It searches the Service Directory for an appropriate service, and when found, obtains the published information about the service’s interface, in particular, the technical requirements for invoking the service.

3. The interface information obtained from the Service Directory describes in detail the inputs, outputs, and transport details of the service. Using this information, the Service User invokes the Service Implementation.

SOA Characteristics
Best practices for the implementation of SOA have evolved to include a number of technical requirements:

1. Services should be implemented using industry standards to enable seamless interoperability between consumers of the service and providers of the service

2. Service definitions should be loosely coupled to their implementation

3. Services should be coarse-grained

4. Multiple channel delivery. Services should be callable by a number of methods, in real-time, in response to events, or in batch mode. Further, delivery of information should be via a number of channels or transports like HTTP, message bus, FTP, etc, and these calling mechanisms can be synchronous or asynchronous. Tools have to support all three

5. Service Management. Services are created based on underlying resources within the IT environment. Effective management requires a full-featured Service Management Repository (SMR) to manage all information related to the environment, the services, and users of those services. The SMR provides far more than the UDDI registries in use today. The SMR provides configuration management and versioning, and enables information to be analyzed once, and effectively used many times in any number of services.

Use of Industry Standards
The growth of SOA in recent years is due in large part to a convergence around standard technologies that have gained wide-spread acceptance across the computing industry. The standards have given new birth to the old idea of SOA. Now there are standards for each part of the SOA as shown in Figure 1 below.




The standards include XML-based Simple Object Access Protocol (SOAP) to invoke the service, Web Service Description Language (WSDL) to describe the technical requirements of the service interface, and Universal Description, Discovery, and Integration (UDDI) for the Service Directory. In addition, the Web Services Interoperability Organization (WS-I) has published guidelines and conformance tests to provide implementers with specific recommendations to ensure cross-platform compatibility for Web Service implementers and service users.

Loose Coupling
Coupling between systems occurs whenever a dependency exists between those systems, as in the case when one system uses a function in another system. Systems are “tightly coupled” if a change in one system forces a change in another. Coupling between systems has proven to be a huge problem in the enterprise, as even minor changes to a system potentially cause a ripple effect throughout many IT systems.

A better way for systems to interact is to minimize this dependency. “Loose coupling” is a principle of interaction that dictates that systems carefully define the interface between one another in a kind of electronic “contract”. The contract defines the block of functionality provided by one system, and the precise information exchanged between the systems. Importantly, the contract does not specify details of how the function is implemented, such as what programming language is used. And, the exact location of the service provider is often not determined until the service is actually requested.

Loose coupling provides a number of important benefits. Applications consuming services are “future-proofed”, because evolving infrastructure improvements can be applied to services without affecting the applications that use them. More robust systems are possible, because run-time conditions can dictate which service provider is used. If one provider fails, requests can be directed to other providers of the same service. Finally, management of both applications and services becomes easier, as both can be developed in parallel according to the “service contract”.

Coarse-Grained
Services are coarse-grained, meaning they provide significant blocks of functionality with a simple invocation. It is instructive to contrast this against fine-grained computing resources, such as accessing a programming library. In this scenario, multiple calls into the programming library must be invoked to set up and execute an operation. There is a tradeoff between the two styles. Fine-grained interfaces are highly flexible, and don’t assume any particular intended result. In contrast, coarse-grained interfaces are specialized, and as a result, somewhat less flexible.

Coarse-grained interfaces are very easy to use because design decisions have been rolled up into a higher level object, ready for use. All the detailed decisions have been made in advance, and the result is a block of functionality specified in terms the business analyst understands. In addition, the information exchanged with the service is coarse-grained, and also specified in terms the business analyst understands. The information is generally representing a type of business entity, like a customer, policy, or invoice. Importantly for adoption of SOA, most industries are defining the business entities used in typical process steps. In insurance, the ACORD standard defines how insurance entities are represented in XML. In capital markets, MDDL and RIXML define XML-based representations of security information and research.

Multiple Channel Service Delivery
Just as systems can be tightly coupled due to a functional dependency on one another, systems can be coupled based on a time dependency. If one system calls a function in another system and waits for the result, it potentially is operating with less than optimal throughput. If dozens or even hundreds of systems must continually call and wait amongst each other, overall system throughput can be severely degraded.

For this reason, it is important that services can be invoked asynchronously or based on events in the enterprise. In this way, components in the system work to their capacity to the greatest extent possible, minimizing time dependencies among them.

It is important to note that some services will require a call-and-wait style of operation. The key to enabling an SOA is to ensure flexibility, so that architects and designers can select the appropriate invocation style, whether it be synchronous, asynchronous, or event-driven.

Service Management
To manage services in an enterprise environment, information resources must be analyzed and documented once, and used efficiently in any number of services. Analysts estimate that a large portion of integration time is spent simply documenting what data elements are available, and how they relate to other applications within the enterprise.

When changes occur to an underlying system, effective management requires that impacts to existing services be discovered and analyzed. In addition, consumers of a business service must have access to the lineage of information retrieved from a service. It is important to understand where a particular information field is derived from, in order to provide an audit trail of information, and confidence that proper sources are used during information retrieval for a particular purpose.

The SOA X-Factor
The agile enterprise, powered by a comprehensive library of business-oriented services, is positioned to react quickly to a changing environment. But the SOA promise does not stop there. SOA, coupled with creative and energetic business people, will have opportunities to contribute value in unanticipated ways.

While today these business managers and analysts are slaves to long IT development cycles, SOA will present them with the ability to create new processes to solve business problems in a matter of days or weeks, rather than over a number of years. They will have an outlet for their creativity, and will be empowered to solve business problems in new ways. These potential, yet unknown benefits can be called the SOA X-Factor.

While hard to quantify, it is likely that this mix of highly motivated business analysts and the powerful tool of SOA will provide unanticipated contributions with sometimes significant and strategically important value.

(Part II of this article starts examines SOA adoption strategies.)