Exposing Web Services

These challenges are not particularly difficult to overcome. In fact, with the work being done by Microsoft, IBM, Intel, and HP (to name just a few), many of these issues have already been addressed. This is either through development frameworks (such as Microsoft's .NET) or through specifications that have been submitted to standards organizations.

The specifications address how to solve many of the problems listed above. Rather than each company driving its own view of the world, each can agree upon the specification and provide an implementation of that specification. Standards-based specifications work especially well at the network level since each application can then leverage all the features provided by the platform.

Specifications
To solve these types of integration, protocol, discovery, and description problems, Microsoft is working with companies like those listed above, who believe that Web Services are the key to building the next generation of web applications.

Using Discovery, Description, and Protocols ;
When we want to build a Web Service, UDDI, DISCO, and WSDL are, for the most part, solutions that are used at design time. Here is a common scenario of usage for a theoretical Credit Card Web Service:

We now have a proxy object that we can use locally within our code, which looks and feels like the application logic it represents – it exposes the same methods and properties, but rather than the application logic executing locally, the proxy encapsulates the calls to the Web Service.

Publishing the service. Once the service is available, how do clients find or discover the Web Service? Just as we have web sites such as www.msn.com or www.yahoo.com for publishing the location of web sites, shouldn't we have something similar for Web Services?
Describing the service. How do consumers of the service call the service? For example, what protocol does the service support? How does the protocol serialize data? What data types does the service support? That is, should binary data be treated as big endian or little endian (the byte ordering of data – the big/little endian terms come from an analogy to Gulliver's Travels' Big-Endians and Little-Endians, who bickered over which end to crack open a hardboiled egg)? Does the Web Service require a schema?
Network. One of the problems with other protocols such as DCOM, RMI, or CORBA is that technologies such as these use TCP/IP ports that are closed or restricted, or in some cases require additional software or a specific OS. Administrators use firewalls to lock down their Internet exposure, with only ports 80 and 443 left open for HTTP/HTTPS traffic respectively. If the required ports are not accessible, or are blocked, building successful distributed applications is more difficult. Additionally, most web applications are an amalgamation of technologies and operating systems.
Development Framework/Tools. Given some application logic, is there a common development framework – as opposed to a choice of language, or even platform – that we can use to easily enable the creation of Web Services (as opposed to writing the framework ourselves)?
Plumbing. Most developers don't have time to deal with building all of the underlying HTTP, XML, and serialization mechanisms and so forth; not to mention security! That's not necessarily due to a lack of interest, but rather time. We don't reinvent the engine every time we decide to buy a new car – we understand how the engine works, but we trust someone else to put it together.

Let's review some of the specifications.

The specifications fall into three categories:

Discovery. There are two specifications that address the discovery of Web Services. Universal Description, Discovery and Integration (UDDI – see http://www.UDDI.org for more details) is the (soon to be) well-known directory in the sky that we'll use to either publish or discover public Web Services. Another specification, DISCO (abbreviated from Discovery) can also be used to group common services together on a server, and provide links to the schema documents the services it describes may require. We will discuss DISCO and UDDI in the next chapter.
Description. Web Service Description Language (WSDL), another Microsoft co-submitted W3C specification, defines an XML grammar for describing Web Services. This description includes details such as where we find the Web Service (URI), what methods and properties that service supports, the data types, and the protocols used to communicate with the service. Tools can consume this WSDL, and build proxy objects that clients use to communicate with the Web Services. We'll talk more about what proxies are and how to build them in Chapter 15. You can also see the WSDL specification at http://www.w3.org/TR/wsdl for more details.
Protocol. As we've already mentioned, a specification called Simple Object Access Protocol (SOAP) submitted to W3C in May 2000 describes an extensible XML serialization format that uses HTTP to transport data. We will discuss SOAP in this chapter, but not in any great detail. Please see the public specification – http://www.w3.org/TR/SOAP – for more information.

Credit Card Web Service

The steps here are as follows:

Step 1. Either through UDDI's public Web Services, or through the browser, we communicate our interest in a Credit Card Web Service to a UDDI node (nodes maintain the available services).
Step 2. UDDI responds with a listing of credit card services – if they're available, which we'll assume they are.
Step 3. The list of services returned by UDDI provides us with URIs that map either to DISCO documents or to WSDL documents. We'll use the DISCO documents. In addition to the programmatic details provided by UDDI, we can also discover documentation for the service at one of the UDDI.org nodes. Hopefully the provider of the service would give us additional details about what the service offered.

Step 4. We follow the URI for the DISCO document. Within the DISCO document we find a listing of the location of WSDL documents.
Step 5. After parsing the DISCO document, we follow the URI for the WSDL document related to the credit card validation and posting Web Services.
Step 6. We parse the WSDL document, and build a proxy object based on the details provided within the WSDL.

Note: Although the DISCO and the WSDL documents can reside on the same server as the Web Service, it is not a requirement. Rather, the DISCO can live anywhere since it is only responsible for linking to WSDL documents. Similarly the WSDL document can exist anywhere as long as it accurately describes the Web Service (the description includes the end point of the Web Service).

We're now ready to use our Web Service at runtime.