What Is a Web Service?

I’ll start by defining a web service by describing what a service is not. For example, a web service is not a subscription service but rather represents some kind of business logic processing on a web server. The key word to understanding “process” is “functionality.” It defines what process is. “Web,” of course, indicates some kind of event that exposes functionality and occurs on a server residing somewhere on the Internet in response to a client’s request. The event requires an event handler (a server-side process that manages client requests by forwarding those requests to the appropriate server where a specified web server exposes its services to interested parties). The event (a web service) is invoked at the behest of a client or some application-based invocation. For example, International Foreign Currency Exchange (IFCE) submits requests to a service provider such as Reuters for the most recent stock quote. Reuters, herein now defined as a service provider, resides somewhere on the Web on a wide area network (WAN). Because service providers offer many kinds of services, they must reside on a network so they can expose their services to clients on a large scale.

The term “service” obfuscates the true meaning of a web service because it contains several different meanings, depending on context. Viewing a web service from a developer’s perspective is one point of view and differs from a user’s point of view, or that of a service provider. For example, in J2EE, the name “component” replaces the term service, whereas in Microsoft .NET, web services use “service.”

Web services are accessed by calling a listener (a service provider) capable of providing a contract that describes the particular web service a client seeks. The contract specifies both parameters and data types that the listener anticipates receiving, as well as the return type (if any) it sends back to the client. In addition, the listener facilitates incoming requests, and returns responses to clients. Figure 7-1 is a visual representation of a service provider’s functionality.

Figure 7-1: A service provider’s functionality

Creating a Web Service

Microsoft designates ASP.NET as the technology for building web services. Both business logic and presentation layer are bundled together within ASP.NET. The developer begins the web service process by applying attributes that inform the Common Language Runtime (CLR) back to treat a defined class and its methods as a web service. (Refer to Chapter 5 for a complete discussion about the CLR and its functionality.) Web service business logic is stored in an .asmx file. The code can dwell either within the .asmx file or in a precompiled class. The developer applies the following directive to the file containing the class name and namespace in which the class for the web service resides. It looks like this:

<%@ WebService Language = "VB" Class ="IFCE" %>

Then, the developer declares a method that includes the number of parameters and its data types, as shown here:

<WebMethod()> Public Function ConvertCurrency
(ByVal x As Double, ByVal y as Double) As Double
  //write the code to implement the method
End Function

The code is compiled to Microsoft Intermediate Language (MSIL) and to its own specific assembly. Typically, the assembly should be placed in a bin file so others can reference it. Creating a web service class looks like this:

Imports System.Web.Services
Public Class IFCE
  Inherits WebService
  'declare the methods here exposed by the Web Service
End Class

XML-based web services use the namespace mechanism for defining an end point for the web service, the namespace to whom a client forwards requests. Here is the syntax:

<WebService (Namespace="http://www.IFCE.com/Webservices/") _
  Public Class IFCE: WebService {} 

ASP.NET uses reflection to inspect metadata attributes. Attributes facilitate access to web services by applying the WebMethod metadata attribute to declare methods, as previously demonstrated.

By examining this process, it is clear that the client requests a server-side provider to expose its services. The provider is mandated to issue the client a contract (a WSDL file) that lists the services it exposes. This information informs the client how to communicate with the service provider and utilize its services.

Therefore, it is possible to add to our definition of a web service by describing it as a discrete piece of business logic written in Java, managed C++ .NET, C# .NET, or some other programming language. Depending on the language, a function or method is typically decorated with a web method attribute, thereby designating it as eligible to initiate a call to a web service provider. This process informs the CLR that this call is to be treated as a valid web service invocation.

Defining a Service-Oriented Architecture (SOA)

What is a service-oriented architecture? Web services reside somewhere on the Internet in a registry. Registries contain numerous web services, and each individual service exposes its own services to requestors (clients). The services represent publishable and discoverable interfaces.

Let’s digress for a moment to define an interface (more about interfaces later in the chapter). An interface is an abstract class containing a function or method declaration, which includes a list of parameters, for example:

int max( int, int);

Every operation declared by an object specifies the following items:

• The operation’s name

• The objects it accepts as parameters

• The operation’s return values

This is known as the operation’s signature. By assembling the set of all signatures, we can define them as an interface. However, an interface does not provide an implementation, but only provides the abstract class’s method name and a set of signatures.

Perhaps the most important functionality a web service provides is supporting a well-defined business process. Here is a quote describing the benefits SOA offers:

Service-Oriented Solutions…Applications are constructed as groups of interacting services providing well-defined interfaces to users. (Java Web Services, O’Reilly & Associates, 2002.)

SOA is implemented as a discoverable software entity that exists as a single instance. The instance interacts with web applications and represents a loosely coupled message-based communication model.

Conceptually, each individual web service has two parts:

• Service This represents the implementation for a web service. The basic requirement is that it must be accessible on a network by a service provider.

• Service description Typically, this exists as an XML file containing a complete description of data types, communication protocols, and a URI where the web service implementation resides. This file is called Web Services Description Language (WSDL).

The terminology used to describe SOA elements in web services is specific, as demonstrated in the following.

• Service provider A software entity implements the service specification. Any chunk of logic is exposed as a web service residing within the SOA. It could be either a complete mainframe-based business process, such as processing a request to convert a specified currency quote to another type of currency quote, such as the euro equivalent of 100 American dollars, or servicing a mortgage loan request. Providers publish metadata about services they keep in a registry. Typically, these providers are standards-setting organizations like ebXML, W3C.org, WS-1, software vendors, and developers. Several different mechanisms are used to publish service descriptions. Among them:

  • HTTP Get request The public repository http://www.xmethods.com is where developers can test their own web services.

  • Dynamic discovery Perhaps the most used registry is Universal Description, Discovery, and Integration (UDDI).

  • Direct A service requestor retrieves the service description from the service provider directly via email, FTP, or other such direct methods.

• Service requestor This entity calls a service provider.

• Service locator This serves as a registry manager and allows a client to locate registries, service provider interfaces, and service locations.

• Services broker This service provider maintains a list of registries and passes on client requests to other service providers.

SOA Web Services

The following items constitute the building blocks for constructing service-oriented architecture web services:

• Encoding XML-ized data transmitted between client and server requires encoding. Typically, the decoding is UTF-8. In J2EE it is ISO-8859-1.

• Description Web services represent an end point. Once the point is located, the service provider describes metadata about the service and requirements needed by the client in order to leverage its services.

• DISCO This is a proprietary Microsoft method for discovery. In order to use DISCO, a URL is required before the document can be located. Use the Disco.exe command-line utility to generate the WSDL contract. Syntax for this is as follows:

  Disco [options] URL

In contrast, UDDI does not require the URL to locate a web service or registry. A registry normally provides a tool for searching by name, location, URL, keyword, and other search criteria. It is possible to search for the keyword wsdl. These URLs will always point toward WSDL contracts available for web services.

• Messaging format Both client and business partner must agree on a mutual protocol before they can encode, format, and transmit messages to each other via HTTP and SOAP.

Fortunately, Microsoft and Sun Microsystems are assisting developers by releasing software solutions that enable a company to face numerous Internet business challenges.

SOA Best Practices

Service providers not only set forth a description of services but also impose constraints dependent on context. The following list presents some of the primary characteristics for efficient utilization of these services:

• Interface design SOA services implement defined interfaces. This is important because multiple web services can implement a commonly shared interface. Conversely, a single service can implement numerous interfaces.

• Asynchronous calls Generally speaking, best practices suggest message passing via asynchronous remote calls. This is important because asynchronous calls allow developers to continue working with other development tasks while awaiting a return result from the server. Synchronous calls are less desirable because all other tasks are blocked until the request fulfillment is completed.

• Coarse-grained services Object-oriented technologies such as Java expose their services through individual methods. Using an individual method, however, is too fine an operation for processing large quantities of data. It is better to assemble individual methods into a cohesive coarse-grained service and process large amounts of data.

• Remote Procedure Calls Web services enable clients to invoke procedures, methods, and functions on remote objects employing an XML-based protocol. RPCs expose both input and output parameters.