Service-Oriented Architecture expands the vision of Web services, Part 2

The SOA connection architecture

This paper continues a detailed examination of Service-Oriented Architecture (SOA). Part 1 discussed characteristics of SOA. This article discusses the SOA Connection Architecture -- the roles in SOA, how a service requester and a service provider communicate, how a service provider specifies information needed for integrating the service into a service requester, and how a service requester can find services it needs. It also presents patterns of message exchange and compares synchronous and asynchronous exchanges.


Mark Colan (, e-business evangelist, IBM Corporation

Mark Colan is the lead e-business technology evangelist for IBM Corporation. He gives technical, keynote, and customer presentations on Web services and XML technologies and strategy. He has spoken at most XML conferences in 2000 and 2001, as well as Java One '98 and '99. You can download Mark's current presentations (PDF) from developerWorks.

Before joining IBM, Mark worked at Lotus Development Corporation for 12 years and helped to develop several commercial products. With over 20 years experience in designing and implementing commercial software products and technologies, Mark is well-versed in component software strategies, operating systems, and software tools. He served as the Lead Architect for the InfoBus Technology, a Java Standard Extension developed at Lotus. You can contact Mark at

28 June 2004

Also available in

The Chinese written language, which consists of ideograms rather than phonetics, is used to represent words from all Chinese dialects, even though the words are pronounced entirely differently among dialects. Though Emperor Qin’s goal of a common spoken language was never realized, the people of China can communicate with the common written language even when they do not understand each other’s spoken language.

Web services employs a similar idea. XML is a common data representation that can be used as the medium of exchange between programs that are written in different programming languages and execute different kinds of machine instructions. XML is the basis for all Web services technologies and the key to interoperability; every Web services specification is based on XML. In particular, SOAP formalizes the exchange of information written in XML, and WSDL describes the SOAP details in an XML vocabulary.

In Part 1 of this paper (see Resources), I defined SOA and some of its characteristics and explained its relationship to Web services technologies. From there you learned that SOA is an architectural style where services comprise application systems and are application functions packaged for reuse.

I described Web services as a set of emerging standards that is the best way to implement SOA today. Much has been written on Web services, so I rely on other papers (see Resources) to explain the details. As I examine the architectural concepts of SOA, you'll see some obvious overlap with Web services concepts, but the SOA perspective expands the Web services vision, which is the focus here.

Service roles

As with Web services, there are two key roles in SOA: service requestor and service provider. The requestor application invokes services offered by one or more provider applications by sending request messages and processing response messages.

Figure 1. The service requestor and the service provider
The service requestor and the service provider

Some service providers can also be service requestors: they aggregate capabilities from other service providers to construct composite, higher-level services. They can accomplish this composition using conventional languages like Java or C# or specialized choreography languages like Business Process Execution Language (BPEL).

Figure 2. An aggregated service requestor
An aggregated service requestor

Some SOA technologies, like UDDI and WS-Trust, introduce a third role called a service broker. A service broker is an intermediary between a service provider and a service requestor -- for service location, brokered trust arrangements, and so on.

Figure 3. A service broker as an intermediary
A service broker as an intermediary

The entities modeled with these three roles use Service Invocation (SOAP messages, for example) for communication.

Service invocation

The W3C SOAP 1.2 standard defines the use of XML-formatted messages for communication between a service requestor and a service provider. The application request (in XML) is put inside a SOAP envelope (also XML) and sent from the requester to the provider; the response that the provider sends back takes the same form. At the time of this writing, most products on the market support the earlier SOAP 1.1 specification, but SOAP 1.2 will be supported in future product releases. Since much has been written about SOAP, refer to the publications listed in the Resources for further explanation.

Figure 4. Service requests with SOAP
Service requests with SOAP

SOAP is the best way to support service invocation in loosely-coupled interactions between partners with separate IT infrastructures, because it is a platform-neutral and vendor-neutral standard. However, SOA does not require the use of SOAP.

Prior to SOAP, for example, some companies used IBM® WebSphere® MQ to send XML documents to another computer, where an application program causes actions to be carried out according to the content of the document. The eBay XML over HTTPS interface works in a similar way for posting items to be auctioned. While I would not call these Web services because they do not use SOAP, I would still call it service invocation in SOA. Today, of course, WebSphere MQ also has direct support for SOAP messages.

It is possible to build a SOA using nothing but the facilities available in J2EE, so long as all entities are written in Java language; however, such an approach does not provide a satisfactory solution for interoperability with non-Java applications.

Inside the enterprise, where you have control over the code for IT systems, you can consider approaches other than SOAP for service invocation, possibly without building and interpreting XML content. This can lead to better performance, and you avoid writing SOAP wrapper code around existing functions. In the interest of simplicity, it is good practice to have a single invocation API style that is capable of invoking services with other protocols.

Multi-protocol service invocation

The JAX-RPC specification (also known as JSR-101) defines a Java API that makes it easy to invoke a Web service from a Java program. As a minimum, a JAX-RPC implementation must support SOAP 1.1 using HTTP. However, it is possible to support other protocols for service invocation. Multi-protocol Service Invocation is the ability to specify a different protocol using the same API, for example by changing the URL.

The JAX-RPC implementation in the current release of WebSphere Application Server is JSR-101-compliant, but allows invocation of SOAP over JMS simply by changing the URL to a form that addresses a JMS server, such as WebSphere MQ. In the near future this multi-protocol style will allow service invocation using RMI over IIOP, resulting in efficient interaction with EJB services.

The key to simplicity is that you use the same API for services regardless of the protocol. What makes this possible is the ability to describe protocols in WSDL other than SOAP over HTTP.

Service description

The Web Services Description Language (WSDL) Specification defines an XML vocabulary for defining the contract between a service requestor and a service provider in terms of the request and response messages. You can define a Web service as software that provides a reusable application function by way of a WSDL document that describes a SOAP message interface, which is delivered using a standard transport protocol.

The WSDL description contains the details required in order for a service requestor to use a particular service:

  • Request message format
  • Response message format
  • Where to send messages

WSDL is based on XML, so WSDL documents are machine-readable. Thus development environments can use them to automate the process of integrating a service into a requester application. WebSphere Studio, for example, can generate a Java proxy object which behaves like a local object implementing the service, but it actually only handles the creation of the request and interpretation of the response message. A Java proxy object can be generated to invoke any Web service from its WSDL description, regardless of whether the service is implemented in Java, C#, or some other language. In fact, WSDL does not describe implementation details such as programming language.

Figure 5. Using WSDL documents
Using WSDL documents

WSDL, with its extension capabilities, supports definitions of services with protocols other than SOAP over HTTP. In terms of SOA, you could argue that any application function whose interface you can describe with WSDL can be called a service. While SOA does not require WSDL in particular -- you could use a different service description language -- most vendors and products today support WSDL.

Message exchange patterns

In one popular exchange pattern, called request-response, a service requester sends a request message to the service provider (or endpoint), and, after processing the request, the provider sends a response message to the requester. Service interactions can be conversational, consisting of several request-response pairs. However, in the interest of performance, simplicity of design, and gaining the benefits of loose-coupling, it is good practice to design coarse-grained interfaces that minimize the number of exchanges required for one transaction.

Figure 6. Request-response messaging
Request-response messaging

Aside from the request-response pattern, WSDL also defines the following:

  • A one-way message sent to an endpoint -- for example, a request that does not require a response:
    Figure 7. One-way request
    One-way request
  • A one-way message sent from an endpoint, called a Notification:
    Figure 8. Notification
  • The Solicit-Response model, where an endpoint sends a message and receives a response:
    Figure 9. Solicit-Response

Today’s SOA implementations commonly use HTTP, resulting in synchronous communications -- the requester waits for a response before proceeding. Synchronous exchange is used to invoke services which are expected to complete in a relatively short period of time -- seconds or minutes.

It is also possible to have asynchronous service interactions, in which the service requester does not wait for a response but expects it to be delivered later. This is appropriate for long-running transactions. For example, invoking a business process to request a quote for a custom passenger aircraft, involving many partners or human interaction in the process, could take days or weeks to complete. Using an asynchronous exchange avoids the risk of losing the connection (because of server maintenance and so on) and, thus, the response.

The WS-Addressing specification proposes a reply-to address as an extension for the SOAP envelope Header element, which can be used for this purpose. The service requestor enqueues a request to the port specified in the WSDL document but doesn’t wait; instead, it does other work until the response arrives. When the service provider is ready to send the response, it uses the reply-to address from the SOAP:Header of the request message.

Figure 10. Reply-to addresses in SOAP

When using a message queue product like WebSphere MQ, it is possible to implement asynchronous messages using JMS. The requester can choose to enqueue a request but not wait for processing to complete, then periodically check for a response in the response queue while it performs other work.

Figure 11. Asynchronous message with JMS
Asynchronous message with JMS

You could apply either means of asynchronous messaging to create other exchange patterns, such as a request to receive multiple notifications (such as notifications for changes in stock quotes).

Figure 12. Multiple response pattern
Multiple response pattern

Service discovery

Whereas Service Invocation and Service Description are usually considered to be requirements of SOA, Service Discovery is an optional capability. UDDI (Universal Description, Discovery, and Integration) defines a standard interface (based on SOAP messages) for publishing the availability of a service and for finding a required service. The UDDI implementation translates SOAP requests to publish and find services into data management function calls for the underlying data store.

UDDI implements a Service Registry by defining standard SOAP messages for publishing and finding other Web services. The registry is a service broker, an intermediary between the requester that needs to find services and the service providers that publish their availability on UDDI. Once a service requester has decided to use a particular service, the developer binds the service by creating code to access the service by sending requests and processing responses, usually with the help of development tools like IBM WebSphere Studio or Microsoft® Visual Studio .NET.

Figure 13. UDDI pattern
UDDI pattern

The result is like electronic yellow pages for discovering the services you need to build SOA applications. You can use tools such as the UDDI Browser in WebSphere Studio to search for an appropriate service at application design time. SOA does not require the use of UDDI, but UDDI is a good solution for Service Discovery, because it builds on SOA to do its work.

You can use UDDI in several different ways, as discussed in Steve Graham’s seminal paper, "Six Species of UDDI" (see Resources). In particular, the article notes its use inside an IT organization for managing internal services to encourage reuse and to further promote endpoint independence. For example, the location of a required service might be cached in the application. If the service is redeployed to a different server, the service requester can use UDDI to find the new location and cache it for future use. When UDDI is deployed internally, it can be used to allow service requester applications to automatically adapt to changes in deployment of services (for example, to maintain load balancing).

As it evolves, UDDI will be widely called upon to find publicly-available business services offered by other organizations in a marketplace model. It will also be useful for dynamic selection of services at runtime, as I will discuss in a future paper on Service Choreography.


This article discussed the basic elements of SOA and their means of finding each other and interacting. You can create an IT architecture based on SOA by developing an inventory of services -- internally or from partners -- and writing code that uses these services to develop new applications. Since a service provider can do its work by requesting other services, you can use a layered composition of services for your design. While the simple request-response message model is the most popular, you have the flexibility to design systems with other message models. The WSDL document tells you how to integrate a service; UDDI helps you find required services.

In the next installment, I will examine Service Choreography and the various means you have to build services and application systems from other services.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services
ArticleTitle=Service-Oriented Architecture expands the vision of Web services, Part 2