Web Services: A Realization of SOA
This chapter is from the book
This chapter is from the book
This chapter is from the book
People often think of Web services and Service-Oriented Architecture (SOA) in combination, but they are distinct in an important way. As discussed in Chapter 1, "Service-Oriented Architectures," SOA represents an abstract architectural concept. It’s an approach to building software systems that is based on loosely coupled components (services) that have been described in a uniform way and that can be discovered and composed. Web services represents one important approach to realizing an SOA.
The World Wide Web Consortium (W3C), which has managed the evolution of the SOAP and WSDL specifications, defines Web services as follows:
A software system designed to support interoperable machine-to- machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards.
Although Web services technology is not the only approach to realizing an SOA, it is one that the IT industry as a whole has enthusiastically embraced. With Web services, the industry is addressing yet again the fundamental challenge that distributed computing has provided for some considerable time: to provide a uniform way of describing components or services within a network, locating them, and accessing them. The difference between the Web services approach and traditional approaches (for example, distributed object technologies such as the Object Management Group – Common Object Request Broker Architecture (OMG CORBA), or Microsoft Distributed Component Object Model (DCOM) ) lies in the loose coupling aspects of the architecture. Instead of building applications that result in tightly integrated collections of objects or components, which are well known and understood at development time, the whole approach is much more dynamic and adaptable to change. Another key difference is that through Web services, the IT industry is tackling the problems using technology and specifications that are being developed in an open way, utilizing industry partnerships and broad consortia such as W3C and the Organization for the Advancement of Structured Information Standards (OASIS), and based on standards and technology that are the foundation of the Internet.
This open, standards-based approach in which every Web services specification is eventually standardized by an industry-wide organization (such as W3C or OASIS) introduces the possibility that the specifications described in this book might undergo significant changes before becoming formal standards. This is a natural consequence of the standardization process in which both technology vendors and consumers provide input and push their requirements into the final standard. However, the basic concepts and the design supporting each of the specifications are unlikely to change in fundamental ways, even if the syntax is modified or the supported set of use cases is significantly expanded. At the time of publication, several of the specifications covered in this book have already been submitted to standards, and significant changes may ensue in some of them (for example, in the case of WS-Addressing, now being discussed at W3C). Readers interested in the details of the specifications should be aware of this fact and carefully follow the results of the standardization process. Please refer to the Web site, http://www.phptr.com, "Updates and Corrections," where you will find the latest updates to the specifications covered in this book.
3.1 Scope of the Architecture
The high-level schematic introduced in Chapter 1 (Figure 1-7) illustrates a layered view of the important foundational capabilities that are required of SOA. This chapter introduces a specific rendering of this conceptual framework with a particular collection of Web services specifications that are based on and extend basic Internet standards that were described in Chapter 2, "Background." Note that specifications used in this rendering are those that IBM has developed in a collaborative effort with other industry partners, most notably Microsoft. The description in this chapter is intended to give a high-level "fly by" only, with the express purpose of providing an overall summary perspective. The following chapters of this book discuss these Web services specifications in much greater detail.
Web services had its beginnings in mid to late 2000 with the introduction of the first version of XML messaging—SOAP, WSDL 1.1, and an initial version of UDDI as a service registry. This basic set of standards has begun to provide an accepted industry-wide basis for interoperability among software components (Web services) that is independent of network location, in addition to specific implementation details of both the services and their supporting deployment infrastructure. Several key software vendors have provided these implementations, which have already been widely used to address some important business problems.
Although the value of Web services technology has been demonstrated in practice, there is a desire to use the approach to address more difficult problems. Developers are looking for enhancements that raise the level and scope of interoperability beyond the basic message exchange, requiring support for interoperation of higher-level infrastructure services. Most commercial applications today are built assuming a specific programming model. They are deployed on platforms (operating systems and middleware) that provide infrastructure services in support of that programming model, hiding complexity, and simplifying the problems that the solution developer has to deal with. For example, middleware typically provides support for transactions, security, or reliable exchange of messages (such as guaranteed, once-only delivery). On the other hand, there is no universally agreed standard middleware, which makes it difficult to construct applications from components that are built using different programming models (such as Microsoft COM, OMG CORBA, or Java 2 Platform, Enterprise Edition (J2EE) Enterprise Java Beans). They bring with them different assumptions about infrastructure services that are required, such as transactions and security. As a consequence, interoperability across distributed heterogeneous platforms (such as .NET and J2EE) presents a difficult problem.
The Web services community has done significant work to address this interoperability issue, and since the introduction of the first Web services, various organizations have introduced other Web services–related specifications. Figure 3-1 illustrates a population of the overall SOA stack shown in Figure 1-7 with current standards and emerging Web services specifications that IBM, Microsoft, and other significant IT companies have developed. The remainder of this chapter provides a high-level introduction to these Web services specifications that realize more concretely the capabilities that are described in the SOA framework in Chapter 1 and that extend the earlier Web services technology of XML, SOAP, and WSDL to provide secure, reliable, and transacted interoperability. The specifications define formats and protocols that allow services to interoperate across those vendor platforms that provide conformant implementations, either natively or by mapping them onto existing proprietary middleware offerings.
)
Figure 3-1 Web services architecture.
<definitions targetNamespace="...">
<!-- WSDL definitions in this document -->
<!-- referenced using "tns" prefix -->
<types>
<!-- XSD definitions for this service -->
<!-- referenced using "xsd1" prefix -->
<xsd:schema>
<xsd:import namespace="http://www.purchase.com/xsd/svp-svc">
</xsd:schema>
</types>
<message name="purchaseResponse">
<part name="purchaseResponse" element="xsd1:PurchaseStatus"/>
</message>
<message name="purchaseRequest">
<part name="purchaseRequest" element="xsd1:PurchaseRequest"/>
</message>
<message name="ServicePacValidationInput">
<part name="spvDataInput"
element="xsd1:ServicePacValidationData"/>
</message>
<message name="ServicePacValidationOutput">
<part name="spvDataOutput"
element="xsd1:ServicePacValidationData"/>
</message>
<portType name="spvPortType">
<operation name="purchaseServicePacs">
<input name="purchaseInput" message="tns:purchaseRequest"/>
<output name="purchaseOutput"
message="tns:purchaseResponse"/>
</operation>
<operation name="validateServicePac">
<input name="Input"
message="tns:ServicePacValidationInput"/>
<output name="Output"
message="tns:ServicePacValidationOutput"/>
</operation>
</portType>
<binding name="spvBinding" type="tns:spvPortType">
<wsp:PolicyReference
URI="http://www.purchase.com/policies/DSig">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="purchaseServicePacs">
<wsp:PolicyReference URI=
"http://www.purchase.com/policies/Encrypt">
<soap:operation soapAction=
"http://www.purchase.com/spvPortType/purchaseServicePacsRequest"/>
</operation>
<operation name="validateServicePac">
<soap:operation soapAction=
"http://www.purchase.com/spvPortType/validateServicePacRequest"/>
</operation>
</binding>
<service name="spv-svc">
<port name="spv-svc-port" binding="tns:spvBinding">
<soap:address location="http://www.purchase.com/spv"/>
</port>
</service>
</definitions>