Chapter 33. Web Services

For some time now, Web Services have been the buzzword technology that everyone is scrambling to support. For good reason Web Services expose the inner workings of any application so they can work with external forces. Think of Web Services as a self-contained set of methods that can reside anywhere on the Internet and can be invoked remotely.

Web Services also bridge the technology gap. They offer a way for distributed applications to communicate from any platform or geographical location with any other platform or geographical location. Web Services are built on open protocols and standards. This makes it possible for any vendor to provide their version of a Web Service, and because they must follow the standards for their product to be classified as a Web Service, everyone can interact with it. For instance, communication is done over HTTP, a well-known, open protocol for communication. The method call and its parameters are done using SOAP, a well-known, open protocol for remote procedure calls based on XML, a well-known, open language for exchanging structured data. Since XML is just plain ASCII text, it can be generated and consumed by any platform regardless of programming language, Web server choice, or operating system. Web Services do require an HTTP (port 80) or HTTPS (port 443) exposure to the World Wide Web, also commonly, albeit inaccurately, referred to as the Internet (the Internet includes a much broader set of technologies, like FTP and SMTP). That global network is what makes Web Services compelling and is quite commonplace today in nearly every workplace and even most homes.

The World Wide Web also allows a Web Property's content to frequently be part of a much larger ecosystem with local, regional, and even global reach. Each partner uses different hardware and software enabled by disparate technologies and programming languages using diverse data stores. Trying to get tab A to squarely fit into slot B is a time-tested challenge. But the Internet introduced the world to connectivity unlike anything that preceded it. However, rampant use of that connectivity was hampered because of the unprecedented threat that same connectedness provides. Through it all, HTTP (port 80) remains the most ubiquitous stronghold for information exchange between parties anywhere, anytime. Out of that, Web Services emerged as a compelling means to allow the quasi-secure exchange of data throughout the global ecosystem.

This chapter explores how Web Services can be used by MCMS sites to exchange information. An entire alphabet soup of acronyms associated with Web Services is listed in Table 33-1, but we are not going to discuss them in depth.

Fortunately, we don't have to become experts in all these technologies to create a Web Service, because VS.NET and IIS handle much of the dirty work for us. For instance, although we will be using WSDL, SOAP, and XML in our code sample, we will hardly even know that they were needed. Anyway, much has been written about these standards and can be easily found on the Internet, should additional information about them be required.

Table 33-1. Web Services Acronym Soup Defined





HyperText Transport Protocol

This protocol allows us to send a SOAP message to a Web Service requesting information or processing, and allows the Web Service to send us a response.


Simple Object Access Protocol

This includes the name of the method we want the Web Service to execute and any parameters we are passing to that method.


Universal Data Description Interface

This centralized repository catalogs Web Services, allowing others to discover a Web Service we have written or for us to discover a Web Service that others have written. This works somewhat like the Yellow Pages.


Web Service Definition Language

This describes the methods available from a Web Service, what protocols can be used to call them, what the methods do, what parameters are allowed or required, and what data type those parameters need to be so that our SOAP message can correctly call a specific Web Service method.


Web Service Inspection Language

This relative newcomer is similar to UDDI in that it allows for the discovery of Web Services, but it uses a decentralized model. This works more like a business card. In many ways, WSIL is like an RSS Weblog for Web Services.


eXtensible Markup Language

This language follows a standard that can be validated, and although typically used to describe data, it is also used to format our SOAP message.


eXtensible Stylesheet Language

This language is used for creating a style sheet that describes how data sent over the Web using XML is to be presented to the user.

Microsoft Content Management Server 2002. A Complete Guide
Microsoft Content Management Server 2002: A Complete Guide
ISBN: 0321194446
EAN: 2147483647
Year: 2003
Pages: 298 © 2008-2017.
If you may any questions please contact us: