Chapter Description

A web service is a web-based application or a network-accessible interface that can communicate and exchange data with other such applications over the Internet without regard for application, platform, syntax, or architecture. ColdFusion supports most of the messaging frameworks and protocols required to effectively communicate with different platforms, and web services are no exception.This chapter focuses primarily on using ColdFusion 10 with SOAP-based web services.

Integration has always been a key strength and an important focus for ColdFusion. ColdFusion supports most of the messaging frameworks and protocols required to effectively communicate with different platforms, and web services are no exception.

On the basis of architectural style, two primary categories of web services are available: traditional Simple Object Access Protocol (SOAP)–based services and Representational State Transfer (REST)–complaint services. ColdFusion has long made it easy to create and consume SOAP-based web services. ColdFusion 10 builds on this foundation by upgrading the underlying engine for SOAP-based web services and supporting creation of REST-based web services. In this chapter we focus primarily on SOAP-based web services. Chapter 5 covers REST-based web services in detail.

What Are Web Services?

A web service is a web-based application or a network-accessible interface that can communicate and exchange data with other such applications over the Internet without regard for application, platform, syntax, or architecture.

At its core, it’s a messaging framework built on open standards through which different applications interact with each other over the Internet, abiding by a definite contract. As simple as it may sound, it truly enabled disparate applications to seamlessly interact and provide integrated solutions. It streamlined the integration of new applications among vendors, partners, and customers without the need for the centralized or proprietary software of enterprise application integration (EAI).

There are many reasons for the success of the web services framework, but these are the most important:

Standard communication: It is based on widely adopted open standards such as Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML).

Platform independence: It provides an unambiguous way of defining, invoking, and consuming a service through Web Services Description Language (WSDL) and SOAP.

Loose coupling: Web services components are loosely coupled. A web service requires almost no knowledge of the definitions of other separate components.

Effortless integration: It’s widely adopted and has great tooling support. Creating, publishing, and consuming a web service on any platform is basically like creating any other component, with no additional effort.

For now, don’t worry about all the acronyms referred to here; we will look at them closely in subsequent sections.

A Typical Web Service Invocation

Let’s now look at the steps involved in a complete web service invocation and see how the process works (Figure 4.1).

(Optional) If a client has no knowledge of a web service it is going to invoke, it may ask a discovery service (usually on a separate server) to provide a service registered with it that meets the client’s requirements. However, in most cases, clients will know which service they want to invoke; hence, this step is optional.

(Optional) On receiving an inquiry, the discovery service will return the available service details registered with it.

The client needs to know how to invoke the service. It asks the web service to describe itself.

The web service replies with an XML document describing the methods, arguments, and types in WSDL.

Now that the client knows where the service is located and how to invoke it, using the WSDL provided the web service creates the artifacts necessary to invoke and consume the web service. It then sends a request over HTTP with all the details required in its body in SOAP format.

The web service returns the result of the operation in a response over HTTP, again in SOAP format.

Web Services Architecture

Now let’s look at the web services architecture and the key technologies that make web services possible. For completeness, Figure 4.2 shows the main components of the architecture.

Figure 4.2. Web services architecture.

A web service uses a transport medium such as HTTP to send messages in SOAP format, which is based on XML, abiding by the contract between a client and a server described using WSDL.

Several technologies are absolutely central to the distributed architecture of web services. Among these are HTTP, XML, and SOAP. Additionally, WSDL, a descendent technology, standardizes the syntax for describing a web service and its operations.

HTTP

HTTP is a communications protocol for exchanging information over the Internet. It is the common transport mechanism that allows web service providers and consumers to communicate.

XML

XML is similar to HTML in that it uses tags to describe and encode information for transmission over the Internet. HTML has preset tags that define the way that information is displayed. XML lets you create your own tags to represent not only data but also a multitude of data types, which helps ensure accurate data transmission among web service providers and consumers.

SOAP

SOAP is a lightweight protocol for the exchange of information in a distributed environment. SOAP can be used in messaging systems or for invoking remote procedure calls. It is based on XML and consists of three logical parts:

A framework for describing what is in a message and how to process it

A set of encoding rules for interpreting application-defined data types

A convention for representing remote procedure calls and responses

SOAP handles the onerous job of translating data and converting data types between consumers and web service providers.

Currently, two versions of SOAP are available: Version 1.1, and Version 1.2, which was an upgrade of Version 1.1. Both are World Wide Web Consortium (W3C) standards, and web services can be deployed using either version. However, Version 1.2 offers some significant advantages over its predecessor, as you will see in the coming section.

WSDL

WSDL is an XML-based language specification that defines web services and describes how to access them.

WSDL is used to explain the details needed to invoke a web service over the Internet. WSDL defines XML syntax for describing services between a set of endpoints: usually a client and a server that exchange messages. This documentation can then act as a road map for automating the details of a web service. WSDL describes the service interaction rather than the formats or network protocols used to communicate. It simply defines the endpoints and their data, regardless of the implementation detail.

Thankfully, today’s ColdFusion developers do not need to concern themselves with such intricacies, or with the need to write documentation by hand, because ColdFusion generates WSDL automatically. To view the generated WSDL for a ColdFusion component deployed as a web service, append the string ?wsdl to the component’s URL. The WSDL document is then displayed in your web browser.

The W3C’s Web Services Description Working Group has published a new specification, WSDL Version 2.0, which is based on SOAP Version 1.2. It is significantly different and not compatible with WSDL’s earlier specification (Version 1.1); hence, it is called Version 2.0, not Version 1.2. We will look at the differences between the two versions and the advantages provided by WSDL 2.0 in the next section.