Web Services Essentials

Web Services Essentials

Table of Contents
Part I: Introduction to Web Services ........................................................................................

Chapter 1. Introduction .............................................................................................................

1.1 Introduction to Web Services ..............................................................................................
1.2 Web Service Architecture ...................................................................................................
1.3 XML Messaging ..................................................................................................................
1.4 Service Description: WSDL ................................................................................................
1.5 Service Discovery: UDDI ...................................................................................................
1.6 Service Transport .................................................................................................................
1.7 All Together Now ................................................................................................................

Part I, Introduction to Web Services

Chapter 1 provides an overview of web services, the web service architecture, and the web
service protocol stack. It also provides a snapshot of current standardization efforts of the
World Wide Web Consortium (W3C).

Chapter 1. Introduction
Today, the principal use of the World Wide Web is for interactive access to
documents and applications. In almost all cases, such access is by human
users, typically working through Web browsers, audio players, or other
interactive front-end systems. The Web can grow significantly in power
and scope if it is extended to support communication between
applications,from one program to another.

- From the W3C XML Protocol Working Group Charter

Welcome to the world of web services. This chapter will ground you in the basics of web
service terminology and architecture. It does so by answering the most common questions,
including:

 What exactly is a web service?

 What is the web service protocol stack?
 What is XML messaging? Service description? Service discovery?
 What are XML-RPC, SOAP, WSDL, and UDDI? How do these technologies
complement each other and work together?
 What security issues are unique to web services?
 What standards currently exist?

1.1 Introduction to Web Services

A web service is any service that is available over the Internet, uses a standardized XML
messaging system, and is not tied to any one operating system or programming language.
(See Figure 1-1 .)

1
 Web Services Essentials
Figure 1-1. A basic web service

There are several alternatives for XML messaging. For example, you could use XML
Remote Procedure Calls (XML-RPC) or SOAP, both of which are described later in this
chapter. Alternatively, you could just use HTTP GET/POST and pass arbitrary XML
documents. Any of these options can work. (See Figure 1-2.)

Figure 1-2. XML messaging for web services

Although they are not required, a web service may also have two additional (and desirable)
properties:

 A web service should be self-describing. If you publish a new web service, you
should also publish a public interface to the service. At a minimum, your service
should include human-readable documentation so that other developers can more
easily integrate your service. If you have created a SOAP service, you should also
ideally include a public interface written in a common XML grammar. The XML
grammar can be used to identify all public methods, method arguments, and return
values.
 A web service should be discoverable. If you create a web service, there should be
a relatively simple mechanism for you to publish this fact. Likewise, there should
be some simple mechanism whereby interested parties can find the service and
locate its public interface. The exact mechanism could be via a completely
decentralized system or a more logically centralized registry system.

2
 Web Services Essentials
To summarize, a complete web service is, therefore, any service that:

 Is available over the Internet or private (intranet) networks

 Uses a standardized XML messaging system
 Is not tied to any one operating system or programming language
 Is self-describing via a common XML grammar
 Is discoverable via a simple find mechanism

1.1.1 The Web Today: The Human-Centric Web

To make web services more concrete, consider basic e-commerce functionality. For
example, Widgets, Inc. sells parts through its web site, enabling customers to submit
purchase orders and check on order status.

To check on the order status, a customer logs into the company web site via a web browser
and receives the results as an HTML page. (See Figure 1-3.)

Figure 1-3. The human-centric Web

This basic model illustrates a human-centric Web, where humans are the primary actors
initiating most web requests. It also represents the primary model on which most of the
Web operates today.

1.1.2 Web Services: The Application-Centric Web

With web services, we move from a human-centric Web to an application-centric Web.

This does not mean that humans are entirely out the picture! It just means that
conversations can take place directly between applications as easily as between web
browsers and servers.

For example, we can turn the order status application into a web service. Applications and
agents can then connect to the service and utilize its functionality directly. For example,
an inventory application can query Widgets, Inc. on the status of all orders. The inventory
system can then process the data, manipulate it, and integrate it into its overall supply
chain management software. (See Figure 1-4.)

Figure 1-4. The application-centric Web

3
 Web Services Essentials

There are numerous areas where an application-centric Web could prove extremely
helpful. Examples include credit card verification, package tracking, portfolio tracking,
shopping bots, currency conversion, and language translation. Other options include
centralized repositories for personal information, such as Microsoft's proposed .NET
MyServices project. .NET MyServices aims to centralize calendar, email, and credit card
information and to provide web services for sharing that data.

1.2 Web Service Architecture

There are two ways to view the web service architecture. The first is to examine the
individual roles of each web service actor; the second is to examine the emerging web
service protocol stack

1.2.1 Web Service Roles

There are three major roles within the web service architecture:

Service provider

This is the provider of the web service. The service provider implements the service
and makes it available on the Internet.

Service requestor

This is any consumer of the web service. The requestor utilizes an existing web
service by opening a network connection and sending an XML request.

Service registry

This is a logically centralized directory of services. The registry provides a central

place where developers can publish new services or find existing ones. It therefore
serves as a centralized clearinghouse for companies and their services.

Figure 1-6 shows the major web service roles and how they interact with each other.

Figure 1-6. Web service roles

1.2.2 Web Service Protocol Stack

A second option for viewing the web service architecture is to examine the emerging web
service protocol stack. The stack is still evolving, but currently has four main layers.
Following is a brief description of each layer.

4
 Web Services Essentials
Service transport

This layer is responsible for transporting messages between applications. Currently,

this layer includes hypertext transfer protocol (HTTP), Simple Mail Transfer
Protocol (SMTP), file transfer protocol (FTP), and newer protocols, such as Blocks
Extensible Exchange Protocol (BEEP).

XML messaging

This layer is responsible for encoding messages in a common XML format so that
messages can be understood at either end. Currently, this layer includes XML-RPC
and SOAP.

Service description

This layer is responsible for describing the public interface to a specific web service.
Currently, service description is handled via the Web Service Description Language
(WSDL).

Service discovery

This layer is responsible for centralizing services into a common registry, and
providing easy publish/find functionality. Currently, service discovery is handled
via Universal Description, Discovery, and Integration (UDDI).

As web services evolve, additional layers may be added, and additional technologies may
be added to each layer. Figure 1-7 summarizes the current web service protocol stack.
Each layer is described in detail later in this book.

Figure 1-7. Web service protocol stack

1.3 XML Messaging

XML has exploded onto the computing scene in recent years. It has gained rapid
acceptance because it enables diverse computer systems to share data more easily,
regardless of operating system or programming language. There are dozens of XML tools,
including parsers and editors that are available for nearly every operating system and every
programming language, including Java, Perl, Python, C#, C, C++, and Ruby. When
developers decided to build a web service messaging system, XML was therefore a natural
choice. There are two main contenders for XML messaging: XML-RPC and SOAP. The
following sections provide descriptions of both protocols.

1.3.1 XML-RPC

XML-RPC is a simple protocol that uses XML messages to perform RPCs. Requests are
encoded in XML and sent via HTTP POST. XML responses are embedded in the body of

5
 Web Services Essentials
the HTTP response. Because XML-RPC is platform-independent, it allows diverse
applications to communicate. For example, a Java client can speak XML-RPC to a Perl
server.

XML-RPC is the easiest way to get started with web services. In many ways, it is simpler
than SOAP and easier to adopt. However, unlike SOAP, XML-RPC has no corresponding
service description grammar. This prevents automatic invocation of XML-RPC services -
a key ingredient for enabling just-in-time application integration.

1.3.2 SOAP

SOAP is an XML-based protocol for exchanging information between computers.

Although SOAP can be used in a variety of messaging systems, and can be delivered via a
variety of transport protocols, the main focus of SOAP is RPCs transported via HTTP.
Like XML-RPC, SOAP is platform-independent and therefore enables diverse applications
to communicate.

1.4 Service Description: WSDL

WSDL currently represents the service description layer within the web service protocol
stack. In a nutshell, WSDL is an XML grammar for specifying a public interface for a
web service. This public interface can include information on all publicly available
functions, data type information for all XML messages, binding information about the
specific transport protocol to be used, and address information for locating the specified
service. WSDL is not necessarily tied to a specific XML messaging system, but it does
include built-in extensions for describing SOAP services.

1.5 Service Discovery: UDDI

UDDI currently represents the discovery layer within the web service protocol stack.
UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical
specification for publishing and finding businesses and web services.

At its core, UDDI consists of two parts. First, UDDI is a technical specification for
building a distributed directory of businesses and web services. Data is stored within a
specific XML format. The UDDI specification includes API details for searching existing
data and publishing new data. Second, the UDDI Business Registry is a fully operational
implementation of the UDDI specification. Launched in May 2001 by Microsoft and IBM,
the UDDI registry now enables anyone to search existing UDDI data. It also enables any
company to register itself and its services.

1.6 Service Transport

The bottom of the web service protocol stack is service transport. This layer is responsible
for actually transporting XML messages between two computers.

1.6.1 HTTP

Currently, HTTP is the most popular option for service transport. HTTP is simple, stable,
and widely deployed. Furthermore, most firewalls allow HTTP traffic. This allows XML-
RPC or SOAP messages to masquerade as HTTP messages. This is good if you want to
easily integrate remote applications, but it does raise a number of security concerns. (See
Section 1.7 later in this chapter.)

6
 Web Services Essentials

While HTTP does get the job done, a number of critics have argued that HTTP is not ideal
for web services. In particular, HTTP was originally designed for remote document
retrieval, and is now being reworked to support RPCs. RPCs demand greater efficiency
and reliability than document retrieval does.

1.6.2 BEEP

One promising alternative to HTTP is the Blocks Extensible Exchange Protocol (BEEP).
BEEP is a new IETF framework of best practices for building new protocols. In particular,
BEEP is layered directly on TCP and includes a number of built-in features, including an
initial handshake protocol, authentication, security, and error handling. Using BEEP, one
can create new protocols for a variety of applications, including instant messaging, file
transfer, content syndication, and network management.

1.7 All Together Now

Once you understand each layer in the web service protocol stack, the next important step
is to understand how all the pieces fit together. There are two ways of approaching the
issue, either from the service requestor perspective or the service provider perspective. In
this section, we examine both perspectives and look at a typical development plan for
each.

1.7.1 Service Request Perspective

The service requestor is any consumer of web services. Here is a typical development plan
for a service requestor:

1. First, you must identify and discover those services that are relevant to your
application. This first step therefore usually involves searching the UDDI Business
Directory for partners and services.
2. Once you have identified the service you want, the next step is to locate a service
description. If this is a SOAP service, you are likely to find a WSDL document. If
this is an XML-RPC service, you are likely to find some human-readable
instructions for integration.
3. Third, you must create a client application. For example, you may create an XML-
RPC or SOAP client in the language of your choice. If the service has a WSDL file,
you also have the option of automatically creating client code via a WSDL
invocation tool.
4. Finally, run your client application to actually invoke the web service.

A snapshot of the service requestor perspective is provided in Figure 1-14.

7
 Web Services Essentials
Figure 1-14. Developing web services: the service requestor perspective

1.7.2 Service Provider Perspective

The service provider is any provider of one or more web services. Here is a typical
development plan for a service provider:

5. First, you must develop the core functionality of your service. This is usually the
hardest part, as your application may connect to databases, Enterprise JavaBeans™
(EJBs), COM objects, or legacy applications.
6. Second, you must develop a service wrapper to your core functionality. This could
be an XML-RPC or a SOAP service wrapper. This is usually a relatively simple step,
as you are merely wrapping existing functionality into a larger framework.
7. Next, you should provide a service description. If you are creating a SOAP
application, you should create a WSDL file. If you are creating an XML-RPC
service, you should consider creating some human-readable instructions.
8. Fourth, you need to deploy the service. Depending on your needs, this could mean
installing and running a standalone server or integrating with an existing web server.
9. Fifth, you need to publish the existence and specifications of your new service. This
usually means publishing data to a global UDDI directory or perhaps a private UDDI
directory specific to your company.

A snapshot of the service provider perspective is provided in Figure 1-15.

Figure 1-15. Developing web services: the service provider perspective