By Brian Schaffner
Tuesday, November 11 2003 12:00 PM
URL: http://www.zdnetasia.com/builder/architect/object/0,39044554,39156954,00.htm

I previously discussed how to build a service oriented architecture (SOA) that aligns with your business processes. Now, I'll elaborate on the SOA architecture and describe how to implement the components. Using Web services technology, I’ll explain how to create the design for implementing a service agency, service provider, and service requestor.

Implementing services with Web technology
Web technology has matured to the point that it can provide a rich set of tools for delivering services. Web services technology is built largely on other technologies, specifically XML and HTTP. Services are commonly delivered as wrappers for existing applications. Figure A illustrates the relationship between the various components of a Web service and how they work together to deliver a service architecture.

In the above figure, you can see that UDDI provides the discovery agency, that Web and application servers deliver the service provider, and that applications act as the service requestor—fulfilling the SOA model.

Abstracting application functionality in the service provider
Web services essentially provide a service wrapper that abstracts functionality across one or more applications. Some Web services may provide functionality from a single application while others provide an aggregate interface for multiple applications. The mapping of applications to services allows applications and technology to align with the business processes. Figure B shows an example of how application functionality is mapped to a service implementation.


Component architectures, like Enterprise Java Beans (EJBs), provide an encapsulation of services that can be delivered in an application server environment. A Web server provides the HTTP network transport for accessing the service. The application server hosts the SOAP interface and the object components that make up the service. The object components provide the business service layer above the applications.

The end result is that the Web service abstracts underlying applications to provide richly defined services. These services then map into well-defined business processes. Creating an abstraction layer above applications enables them to deliver functionality in a more meaningful way—defined as business services.

Define service contracts with WSDL
The service provider publishes its interface contract in the form of a Web Services Description Language (WSDL) document. The WSDL document defines the characteristics of the service including the location of the service and how to access it. From a development perspective, WSDL provides the contract that both the service requestor and service provider agree upon.

Once you define the business processes and organize services that can implement those processes, the next step is defining services and specific methods within the services. The WSDL document is an XML format of the specifications for the services. Within the WSDL document, you specify how to access the service, what methods it has available, how to access the methods, what parameters to pass to the methods, and so on.

Service requestors locate services by using a service registry. In a Web services implementation, the service registry is implemented using Universal Description, Discovery, and Integration (UDDI). The UDDI server contains the database of service descriptions and provides them to the service requestor application. The requestor uses the WSDL document to understand the interface contract with the Web Service.

In general, WSDL documents aren't physically stored in the UDDI server; rather the UDDI server provides URLs which identify to the service requestor where to find the WSDL document.

In programmer terms, the WSDL document defines the abstract interface used to access the service. From a design perspective, the WSDL must come before the service requestor and the service provider since it defines the contract between them. Once the WSDL has been designed and agreed upon, the service provider developers and the service requestor developers can work somewhat in parallel.

Service discovery
Services are discovered by querying the UDDI server and accessing the WSDL documents for the services. By using a central registry, client applications can dynamically discover and bind to services. The UDDI server and protocol is reasonably generic. For a service architecture, the UDDI component provides a central service agency that knows about all the services within its domain. Whenever a service requestor needs to access or locate a service, the UDDI server is queried for information. UDDI provides a variety of ways to search the registry.

Once an organization and service have been located, the service requestor extracts the WSDL location. The WSDL is usually located with the service itself. Next, the requestor accesses the WSDL document to understand the specifics of the service. Using the information in the WSDL document, the requestor will understand how to access the service, what methods it has, and what parameters need to be sent, among other things. Figure C illustrates how this process works.

The challenge
Implementing an SOA can be quite a challenge. By understanding the components that make up an SOA and by understanding the technologies behind Web services, you can create a solid architecture and design that meets business needs and challenges while providing a rich and strategic solution.