Web Services Overview | Professional ASP.NET MVC 1.0 (Wrox Programmer to Programmer)

Today the most common way to access information on the Internet is via a browser that sends and receives messages via HTTP. The browser receives HTML that is then parsed and used to render the user interface.

The web browser only begins to scratch the surface of what can be done with the Internet when it comes to building applications. You can already see a migration to other Internet applications that use a similar set of underlying protocols but don't always rely on HTML to control the user interface or exchange data. Examples include PDAs, cellular phones, blackberry devices, and rich-client peer-to-peer applications.

Web services are designed to facilitate the move to this next generation of the Internet. Using web services it's simple to enable peer-to-peer and distributed application development, as you can use a common protocol for all these applications. It's easy to envision applications that use a broad set of web services for authentication, email, buddy lists, and so on.

As the protocol format is standardized, any application that understands SOAP can take advantage of web services. For example, if eBay built an auction web service, or Hotmail built an email web service, SOAP-aware applications would be able to utilize these services. However, various implementations can interpret the meaning of the SOAP specification differently. Microsoft has worked to ensure that ASP.NET web services are compatible with other common SOAP implementations. As great as all this sounds, there are some common issues and questions that surround web services.

Common Issues

Solving the problem of exposing application logic and details of services through XML and HTTP isn't difficult. You could use classic ASP, Java, and Perl (to name a few) to write a simple application that exposed data via XML. For example, you could use ASP to write a simple application that accepted values passed on the query string, and generated an XML return document that represented a specific database table. Other applications could then make calls against an end-point (say a URL exposing your database tables) to fetch, parse, and derive values from the document.

However, designs like this are tightly coupled . The client expects a highly structured XML document, and if the application providing this document is changed, the client implementations may be broken. In most cases, this can be addressed by using public XML schemas, but maintaining a set of schemas for each application would be cumbersome. Also, the XML document will be dependent upon the server implementation.

Typically, even minor changes to the application logic can require large changes in the code used to expose that application logic as an XML document. The classic example of this problem is encountered with screen-scraping, in which the HTML of a site is parsed for specific values. As long as the HTML remains static, the known values can easily be extracted, but if the HTML changes, it usually breaks the application that consumes the HTML. Other common issues include:

Publishing the service :Once the service is available, how do clients find or discover the web service? Just as web sites such as MSN and Yahoo, which publish the location of web sites, shouldn't there be 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? Does the web service require a schema?
The network :One of the problems with other protocols such as DCOM, RMI, or CORBA is that they use TCP/IP ports that are closed or restricted, or in some cases require additional software or a specific operating system. Administrators use firewalls to lock down their Internet exposure, usually leaving only ports 80 and 443 open for HTTP and HTTPS traffic, respectively. If the required ports are not accessible or are blocked, building successful distributed applications becomes difficult. Additionally, most web applications are an amalgamation of technologies and operating systems.
The development framework and tools :Given some application logic, is there a common development framework “ as opposed to a choice of language, or even platform “ that can be used to easily create web services.

These challenges are not particularly difficult to overcome . In fact, Microsoft, IBM, Intel, and HP (to name just a few) have worked to address many of these issues through development frameworks (such as Microsoft .NET) or through specifications that have been submitted to standards organizations. The specifications form part of the solution to the problems we listed. Rather than each company driving its own view of the world, they can agree on a single specification and provide an implementation of it. Standards-based specifications work especially well at the network level since each application can then leverage all the features provided by its native platform.

Specifications

To solve these types of integration, protocol, discovery, and description problems, Microsoft is working with companies that believe that web services are the key to building the next generation of web applications. The specifications they are creating 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 a directory that you can use to publish and 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 that may be required by the services it describes. We'll discuss both of these 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 to find the web service (its 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 the next chapter. The WSDL specification is available at http://www.w3.org/TR/wsdl.
Protocol :As already mentioned, SOAP 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. The specification is available at http://www.w3.org/TR/SOAP.

Using Discovery, Description, and Protocols

Figure 19-1 shows a scenario for using a Credit Card Validation Web service:

Figure 19-1:

When building a web service, UDDI, DISCO, and WSDL are for the most part the technologies to be used at design time. The steps here are as follows :

A consumer's interest in a Credit Card Web service is communicated to a UDDI node (nodes maintain the available services), either through UDDI's public web services, or through the browser.
UDDI responds with a listing of credit card services (if they're available “ let's assume they are).
The list of services returned by UDDI provides URIs that map to either DISCO or WSDL documents. We'll use the DISCO documents. In addition to the programmatic details provided by UDDI, you can also discover documentation for the web service at one of the UDDI.org nodes.Hopefully the provider of the service would provide additional details about what the service offered .
Follow the URI for the DISCO document. A listing of the location of WSDL documents is given within the DISCO document.
After parsing the DISCO document, follow the URI for the WSDL document related to the Credit Card Validation Web service.
Parse the WSDL document, and build a proxy object based on the details provided within the WSDL.

Although the DISCO and the WSDL documents can reside on the same server as the web service, it is not a requirement. The DISCO document can be stored 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).

You now have a proxy object that can be used locally within the 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. You're now ready to use the web wervice at runtime.

You can build an application that uses the proxy (let's call it the CreditCardWebService proxy). The proxy encapsulates all the details of how to use the remote web service. From our perspective, we're working with a local object. If the company providing the Credit Card Web service decides to add some more functionality to the web service, it can simply update the WSDL. If it only adds new members, and doesn't change the signatures of existing members , our proxy will continue to work fine.

A lot of companies, including Microsoft and IBM, believe strongly that web services will be the next great enabler of the Internet. Support for web services is one of the most important features in ASP.NET. In the next chapter, you'll look at how to use the services you build. First though, we need to discuss how to use ASP.NET to build web services.