The Basic Web Services Stack
- Service-Oriented Architecture (SOA)
- Extensible Markup Language (XML)
- Universal Description, Discovery, and Integration (UDDI)
- Web Services and Other Technologies
- Phases of Adoption
- Summary
Many of the challenges presented in the previous chapter revolve around interoperability challenges on multiple operating systems and/or middleware packages. These include high integration costs, lack of industry standards, and high deployment costs. Web Services have the potential of addressing many of these issues, and this chapter discusses the cornerstone technologies that are essential for Web Services. These include Extensible Markup Language (XML), Service-Oriented Access Protocol (SOAP), Web Services Definition Language (WSDL), and Universal Description, Discovery and Integration (UDDI). Chapter 3 then follows with emerging standards around security, scalability, and so on. This chapter concludes with a discussion on how Web Services can augment the technologies discussed in Chapter 1.
Before delving into the underlying technologies, let's take a broad view of the various roles of a Web Services architecture, which is also sometimes referred to as a service-oriented architecture.
Service-Oriented Architecture (SOA)
An SOA is called service oriented because the central idea is that a client (which can be a person or a computer) needs a particular set of services to be fulfilled. Of course, before the client can request the service, it needs to find the provider (which previously published the service); this location service is provided by a service broker, who typically operates a repository. Upon request, the service broker returns a document that allows the client to first locate and then bind to the provider. Thus, the three key roles in an SOA are
- Client
- Service broker
- Service provider
Figure 21 illustrates the roles and the sequence of events in an SOA.
Figure 21 The roles in an SOA.
The role of the broker may not be immediately obvious, especially for a small set of services. However, keep in mind that a client may ask for multiple services, each of which may have a different provider. Registering the services in a central registry that can be searched by clients provides them with the flexibility needed to perform queries based on a dynamically changing set of criteriathey do not have to statically bind themselves to the provider. Without a registry, the client would have to hard-code the location of the service provider, which can obviously lead to maintenance difficulties.
SOAs have been present for a number of years, but, again, they have been used with proprietary protocols and technologies. For example, both CORBA and DCOM provide a naming service and a location service. With the advent of Web Services, the idea has been more widely adopted because of the use of standards-based technologies. The most fundamental standard of all is a common language for describing datathis is the role of XML.