XML and Java: Developing Web Applications, Second Edition

13.1 Emergence of Web Services

In Chapter 12, we described XML messaging, especially addressing the Simple Object Access Protocol (SOAP). With SOAP, you can integrate applications distributed on the network in a decentralized manner because no particular platforms are assumed for SOAP. This indicates that you can integrate applications on the Internet with SOAP. However, SOAP alone is not sufficient for such integration. When you want to access an application, you have to know what the application is. You may not even know about the existence of the application on the Internet. The concept of Web services is proposed to solve such issues.

The key technologies of Web services are SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). Because we have already covered SOAP, in this chapter we cover WSDL and UDDI, showing example programs. Before discussing them, we describe why the Web services concept is necessary and provide a conceptual architecture of Web services.

13.1.1 Publishing, Finding, and Integration

While the Web has been growing for connecting computers and humans, it is not strange for someone to start thinking about using the same technology background and infrastructure for connecting computers by simply replacing HTML with XML. This concept is called Web services. More exactly, in contrast with a Web server accepting an HTTP GET/POST message as input and returning an HTML document as output, a Web services server accepts and returns XML messages. In this sense, XML messaging, described in Chapter 12, plays an important role in Web services. Note that Web services do not require HTTP as their network transport protocol even though the term "Web services" seems to imply HTTP as the transport protocol. Rather, being transport protocol朼gnostic is an important feature of Web services. For example, a Web services server can accept the same XML message via more than one transport protocol, such as HTTP and SMTP.

There is another important feature of Web services that we have not yet described. Before we explain this feature, let's consider the fact that the Web exists for reference. What do you want to do first when you create your home page? You will not hesitate to submit the URL of your home page to search sites like Yahoo if you want people to visit your home page as often as possible. Otherwise, no one will know about your home page, and only a few people will visit it.

The same thing happens for Web services. For example, suppose that you create a Web service to provide hotel reservations, and you plan to offer a special travel package as an opening sale. Your Web service accepts and returns XML messages as a request and its response. Naturally, you also create a home page and submit its URL to many search sites. Is that enough?

Even if someone finds your home page by chance and becomes interested in your service, that person might be upset with it because it requires an XML message as a request form. That reaction is natural because your service is not tailored for humans. How can you deal with that?

The answer is simple. You need a search site for Web services that is also a Web service. You can register your Web service with the site so that other computers can find it. You may feel that the answer is so simple and nothing seems new about it. It is, however, very new and revolutionary for traditional intercompany business deals, which are usually closed and static. For example, when you ask a travel agency for a vacation plan, the agency usually selects possibilities only from the list of hotels and flights that have a business contract with the agency, and the list does not change frequently. As a result, the vacation plan offered by the agency may not be the best for you.

You may go to a travel search site, such as Yahoo Travel, to find a list of hotels that match your preferences (such as place, date, and cost), choose one or more hotels from the search result, and go to their home pages to get more detailed information. You may get the best deal, but it takes long time. Web services allow you to automate such time-consuming manual operations. You can create a simple program by dynamically integrating Web services available on the Internet, such as hotel- and flight-finding services and their reservation services. If this scenario became true, Web services would change the traditional closed and static business environment. If so, it would become the second explosion of the Internet.

13.1.2 What Are Web Services?

In 2000 and 2001, major vendors announced their support for Web services. IBM announced its Web services architecture and Microsoft announced Microsoft .NET in 2000. Sun Microsystems announced Sun One in 2001. It is interesting that the overall objectives in their announcements are very similar. They seem to share the same view for Web services but try to differentiate them by providing different tools and programming languages.

We'll describe the architectural detail of Web services based on IBM's Web services architecture. Figure 13.1 illustrates the three important roles in the Web services architecture (service provider, service requestor, and service broker) and three operations between the roles (publish, find, and bind). We explain each role in more detail.

Service provider

A service provider describes its service based on the specification prepared by a service broker and registers it with the service broker for searching (publish operation). A service provider defines its API (for example, network protocol and data format). The API is also registered with the service broker so that a service requestor can connect to invoke the service (bind operation). The hotel reservation service described in the previous subsection can be regarded as a service provider.

Service requestor

A service requestor creates a new service by integrating services provided by service providers. The travel agency is an example of a service requestor. A service requestor invokes a service broker to get a list of service providers it is interested in (find operation), selects one or more service providers from the list, and then invokes the selected service providers (bind operation). Note that a service requestor is not just client software such as a Web browser. It becomes a new service provider if it registers itself with a service broker.

Service broker

A service broker registers service descriptions submitted by service providers (publish operation) and executes a search based on a request from a service requestor (find operation). The search site for the Web services described in the previous subsection can be regarded as a service broker. A service broker defines a service description format and an API for registering and searching services. Unlike existing search sites for humans, this format and API must be defined as strictly as possible so that a service provider and a service requestor can use it without human intervention. In Figure 13.1, a service broker is shown as an independent role because it plays an important role in the Web services architecture, but it is also a service provider.

Because this architecture only summaries the concept of Web services, the data formats and APIs still need to be defined to make it real. For that purpose, IBM and Microsoft jointly defined the following three XML-based specifications: SOAP, UDDI, and WSDL. SOAP is designed as a network transport朼gnostic envelope to convey XML messages. UDDI corresponds to a service broker. It defines a service description format and an API to invoke its registry. WSDL corresponds to CORBA's IDL for describing the API of a service provider. The following sections explain the details of UDDI and WSDL with programming examples. SOAP is described in Chapter 12.

13.1.3 Status of Web Services

Before we cover the technologies of Web services, you may want to know how mature this technology area is. For now, we only have some basic specifications, such as SOAP, WSDL, and UDDI, and it is often insufficient to build real applications with them. For instance, in the security area, we only have SOAP Digital Signature as a W3C Note, and we do not yet have other technologies such as SOAP encryption. In addition, for Web services composition, IBM and Microsoft have each proposed their own specifications, but they have not reached an agreement.

There is also a big question about Web services: How can we integrate Web services technologies into existing enterprise systems? J2EE is a good vehicle for performing Enterprise Application Integration (EAI) with Java. This indicates that we may need a means to integrate Web services into the J2EE architecture. To address this issue, Java Specification Request (JSR) 109 has been formed to come up with an enterprise Web services architecture (we describe it in greater detail in Section 13.5.). Although it is one of the most promising directions, no final specification has been published.

In summary, the technology basis of Web services is not mature enough. However, many software vendors are actively investing in this area because it is likely to drastically change system development in the near future. From a developer's point of view, you may want to know how long you should wait. Unfortunately, we expect that for a while a large number of technologies will be proposed but will go away. Accordingly, you have to judge whether each technology will survive. From this perspective, it is not enough for you to know how to use the basic Web services technologies such as SOAP, WSDL, and UDDI. Rather, you should be comfortable with discussing their technical details, including the implementation aspects. In the previous chapter, we looked at the implementation details of SOAP by means of a prototype. In the same manner, we review a fairly large number of programs here. Through the examples shown here, you should be able to make sense of Web services technologies. As a result, you can consider which standardization activities and proposals are promising, and see the direction of this area.