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.
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
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
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
The entities modeled with these three roles use Service Invocation (SOAP messages, for example) for communication.
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
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.
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
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
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
- 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
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
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
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.
- Read the article "New to Service-Oriented Architectures" for more information and resources on SOA (developerWorks, April 2004).
- See Part 1 of this article, "Service-Oriented Architecture expands the vision of Web services, Part 1" (developerWorks, April 2004).
- Review the SOAP 1.1, SOAP 1.2, and WSDL 1.1 specifications, as well as the WSDL 2.0 working drafts, all from the World Wide Web Consortium.
- Find out about the OASIS UDDI 2.0 specification, another basic Web services protocol.
- Explore the different ways to use UDDI in Steve Graham's articles, The role of private UDDI nodes in Web services, Part 1: Six species of UDDI.
- Learn how to implement messaging using WebSphere Studio in the Redbook WebSphere Version 5.1 Application Developer 5.1.1 Web Services Handbook.
- Discover how the interaction between Web services and business processes is defined in the BPEL 1.1 Specification.
- Read the JAX-RPC 1.1 Specification, part of the J2EE standard.
- Read "Migrating to a Service-Oriented Architecture, Part 1" (developerWorks, December 2003) to better understand the value of Service-Oriented Architectures.
- Read "Migrating to a Service-Oriented Architecture, Part 2" (developerWorks, December 2003) to understand why a Service-Oriented Architecture is the best platform for carrying existing assets into the future, as well as enabling the rapid and correct development of future applications.