UNIT-2

Web Services Architecture

and its Characteristics

The basic principles behind the Web services architecture are based on
SOA and the Internet protocols. It represents a composable application
solution based on standards and standards-based technologies. This ensures
that the implementations of Web services applications are compliant to
standard specifications, thus enabling interoperability with those compliant
applications.
Characteristics of web services:
The Web services architecture represents the logical evolution of
traditional computer-based applications to services-oriented applications
over the Internet. It defines a distributed computing mechanism by adopting
a service-oriented architecture (SOA), where all of the applications are
encapsulated as services and made available for invocation over a network.
These services can be leveraged from different applications and platforms
with varying technologies adopting common industry standards and
platform-independent and language neutral Internet protocols for enabling
application interoperability, thus making them easily accessible over the
Internet.
Core Building blocks of Web services:

Some of the key design requirements of the Web services architecture are the following:

■■ To provide a universal interface and a consistent solution model to

define the application as modular components, thus enabling them
as exposable services

■■ To define a framework with a standards-based infrastructure model

and protocols to support services-based applications over the Internet

■■ To address a variety of service delivery scenarios ranging from

 e-business (B2C), business-to-business (B2B), peer-to-peer
(P2P),
and enterprise application integration (EAI)-based application com-
munication

■■ To enable distributable modular applications as a centralized and

decentralized application environment that supports boundary-less
application communication for inter-enterprise and intra-enterprise
application connectivity

■■ To enable the publishing of services to one or more public or private

directories, thus enabling potential users to locate the published ser-
vices using standard-based mechanisms that are defined by standards
organizations

■■ To enable the invocation of those services when it is required, subject

to authentication, authorization, and other security measures

A typical Web service architectural model consists of three

key logical components as building blocks mapping the
operational roles and relationships of a Web services
environment.
Figure 3.1 represents the core building blocks of a typical
Web services architecture.
Figure 3.1 Core building blocks of Web services architecture.

Services container/runtime environment. The services container

acts as the Web services runtime environment and hosts the service
provider. Typical to a Web application environment, it defines the
Web services runtime environment meant for client communication
as a container of Web services interfaces by exposing the potential
components of the underlying applications. It facilitates the service
deployment and services administration. In addition, it also handles
the registration of the service description with the service registries.
Usually, the Web services platform provider implements the services
container. In some circumstances, the Web application servers pro-
vide system services and APIs that can be leveraged as the Web
services container.

Services registry. The services registry hosts the published

services and acts as a broker providing a facility to publish and
store the description of Web services registered by the service
 providers. In addition, it defines a common access mechanism for
the service requestors for locating the registered services.

Services delivery. It acts as the Web services client runtime environ-

ment by looking up the services registries to find the required ser-
vices and invoking them from the service provider. It is represented
as a presentation module for service requestors, by exposing the
appropriate interfaces or markups for generating content and
delivery to a variety of client applications, devices, platforms, and
so forth.

WSDL. This resides in the services container and provides a

standardized way to describe the Web services as a service
description. In ebXML-based architecture, ebXML CPP/A
provides services descriptions including business partner profiles
and agreements.

UDDI. This provides a standard mechanism for publishing and

discovering registered Web services, and it also acts as the registry
and repository to store WSDL-based service descriptions. In
ebXML- based architecture, ebXML Registry & Repository provides
a facility to store CPP/CPA descriptions for business collaboration.

To build the Web services architecture with these logical

components, we need to use standardized components and a
communication model for describing and invoking the services that are
universally understood between the service providers and their potential
service requestors. It also requires a standard way to publish the services
by the service provider and store them in the service broker. In turn,
service requestors can find them.
Implementing Web Services
The process of implementing Web services is quite similar to
implementing any distributed application using CORBA or RMI.
However, in Web services, all the components are bound dynamically only
at its runtime using standard protocols. Figure 3.5 illustrates the process
highlights of implementing Web services.

As illustrated in Figure 3.5, the basic steps of implementing Web

services are as follows:

1. The service provider creates the Web service typically as SOAP-

based service interfaces for exposed business applications. The
provider then deploys them in a service container or using a
SOAP runtime environment, and then makes them available for
invocation over a network. The service provider also describes
the Web service as a WSDL-based service description, which
defines the clients and the service container with a consistent
way of identifying the service location, operations, and its
communication model.
2. The service provider then registers the WSDL-based service
description with a service broker, which is typically a UDDI
registry.

3. The UDDI registry then stores the service description as binding

templates and URLs to WSDLs located in the service provider
environment.
4. The service requestor then locates the required services by querying
the UDDI registry. The service requestor obtains the binding infor-
mation and the URLs to identify the service provider.

5. Using the binding information, the service requestor then invokes

the service provider and then retrieves the WSDL Service descrip-
tion for those registered services. Then, the service requestor creates
a client proxy application and establishes communication with the
service provider using SOAP.

6. Finally, the service requestor communicates with the service

provider and exchanges data or messages by invoking the available
services in the service container.
In the case of an ebXML-based environment, the steps just shown
are the same, except ebXML registry and repository, ebXML messaging, and
ebXML CPP/CPA are used instead of UDDI, SOAP, and WSDL,
respectively. The basic steps just shown also do not include the
implementation of security and quality of service (QoS) tasks.
Developing Web Services-Enabled Applications
The design and development process of creating a Web
services-enabled application is not different from the typical process of
developing a dis- tributed application. In case of Web services, it can be
created as a new application or from using an existing application by
repurposing them as services.
In a Web services implementation, it also is possible to expose
existing/ legacy applications as services by encapsulating the core
business func- tionalities of those underlying applications. The underlying
applications can be of any application implemented in any programming
language and running on any platform.
Figure 3.6 represents a typical Web services implementation model
providing service-oriented interfaces supporting a variety of back-end
application environments.

The implementation steps generally involved in developing Web ser-

vices solutions by exposing back-end business applications are as follows:
1. The potential business component of the underlying application will
be encapsulated as service-oriented interfaces using SOAP and then
exposed as Web services by deploying them in a Web services
service container or a SOAP runtime environment. Using those
SOAP-based interfaces, the service container handles all the
 incoming SOAP requests/responses or messaging-based operations
and maps them as methods and arguments of the underlying business
application.

1. WSDL-based service descriptions will be generated and then reside in a

service container. WSDL defines the communication contract required
for invoking the SOAP-based service interfaces. These WSDL-based
service descriptions will be published in a UDDI registry as service
templates and its location URLs. The interfaces required for publishing
in the UDDI registry are usually provided by the Web service container
provider.

2. The service requester finds the services using the discovery

mechanisms (registry API) and obtains the service description and
its provider location URL. It then connects to the service provider
to obtain WSDL.

3. To invoke the services exposed by the service provider, the service

requestor (service delivery environment) is required to implement
SOAP-based client interfaces according to the service description
defined in the WSDL.

Standards and technologies available for implementing web services/Tools of the

Trade
The role of those Web services standards and technologies and how
they are represented in Web services architecture and its development
process.

Simple Object Access Protocol (SOAP)

The Simple Object Access Protocol, or SOAP, plays the role of the
messaging protocol for exchanging information between the service
provider and the service requestor. It consists of the following:
 SOAP Envelope. It describes the message, identifying the contents
and the envelope’s processing information.

SOAP Transport. It defines the bindings for the underlying transport

protocols such as HTTP and SMTP.

SOAP Encoding. It defines a set of encoding rules for mapping the

instances of the application-specific data types to XML elements.

SOAP RPC conventions. It defines the representation of the RPC

requests and responses. These SOAP requests and responses are mar-
shaled in a data type and passed in to a SOAP body.

Listing 3.1 represents a SOAP message using an HTTP post request for
sending a getBookPrice() method with <bookname> as an argument to
obtain a price of a book.
Listing 3.1 SOAP message using
POST /StockQuote HTTP/1.1
Host: www.acmeretailer.com

Content-Type: text/xml; charset=”utf-8”

Content-Length: 1000

SOAPAction: “getBookPrice”

<SOAP-ENV:Envelope

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=”http://www.w3c.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3c.org/2001/XMLSchema”

SOAP-ENV:encodingStyle

=”http://schemas.xmlsoap.org/soap/encoding/”>

<SOAP-ENV:Body>

<m:getBookPrice
xmlns:m=”http://www.wiley.com/jws.book.priceList”>

<bookname xsi:type=’xsd:string’>

Developing Java Web services</bookname>

</m:getBookPrice>

/SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Web Services Description Language (WSDL)

The Web Services Description Language, or WDDL, is an XML
schema- based specification for describing Web services as a collection of
operations and data input/output parameters as messages. WSDL also
defines the communication model with a binding mechanism to attach any
transport protocol, data format, or structure to an abstract message,
operation, or endpoint.
 Listing 3.2 shows a WSDL example that describes a Web service meant
for obtaining a price of a book using a GetBookPrice operation.

<?xml version=”1.0”?>

<definitions name=”BookPrice”
targetNamespace=”http://www.wiley.com/bookprice.wsdl”
xmlns:tns=”http://www.wiley.com/bookprice.wsdl”

Listing 3.2 A WSDL document describing a Service. (continues)

 xmlns:xsd=”http://www.w3.org/2000/10/XMLSchema”
xmlns:xsd1=”http://www.wiley.com/bookprice.xsd”
xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”
xmlns=”http://schemas.xmlsoap.org/wsdl/”>

<message name=”GetBookPriceInput”>

<part name=”bookname” element=”xsd:string”/>

</message>

<message name=”GetBookPriceOutput”>

<part name=”price” type=”xsd:float”/>

</message>

<portType name=”BookPricePortType”>

<operation name=”GetBookPrice”>

<input message=”tns:GetBookPriceInput”/>

<output message=”tns:GetBookPriceOutput”/>

</operation>

</portType>

<binding name=”BookPriceSoapBinding”

type=”tns:BookPricePortType”>

<soap:binding style=”rpc”
transport=”http://schemas.xmlsoap.org/soap/http”/>

<operation name=”GetBookPrice”>

<soap:operation

soapAction=”http://www.wiley.com/GetBookPrice”/>

<input>

<soap:body use=”encoded”
namespace=”http://www.wiley.com/bookprice”

encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/>

</input>

<output>

<soap:body use=”encoded”
namespace=”http://www.wiley.com/bookprice”

encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/>

</output>

</operation>>

</binding>

<service name=”WileyBookPriceService”>
Listing 3.2 A WSDL document describing a Service. (continued)

Universal Description, Discovery, and Integration (UDDI)

Universal Description, Discovery, and Integration, or UDDI,
defines a mechanism to register and categorize Web services in a general-
purpose registry that users communicate to in order to discover and locate
regis- tered services. While querying a UDDI registry for a service, the
WSDL description describing the service interface will be returned. Using
the WSDL description, the developer can construct a SOAP client
interface that can communicate with the service provider.
UDDI can be implemented as a public registry to support the
requirements of a global community or as a private registry to support an
enterprise or a private community.
At the time of this book’s writing, the current version of UDDI is UDDI
2.0 and it will be discussed throughout this book. (For more information
on UDDI, refer to Chapter 5, “Description and Discovery of Web
Services.”)

ebXML
ebXML provides a standard framework for building an electronic
market- place by enabling the standardization of business processes,
business part- ner profiles, and partner agreements. In general, ebXML
complements other Web services standards like SOAP, WSDL, and UDDI.
The following are major features of ebXML:

■■ ebXML Messaging Service (MS) is a value-add over SOAP

that provides reliability and security mechanisms.
■■ ebXML BPSS enables business processes to be described.
 ■■ ebXML CPP/CPA is a value-add over WSDL that enables
business partner profiles and partner agreements to be described.

■■ ebXML reg/rep provides a registry and repository, while UDDI is

just a registry.

■■ ebXML Core components provide a catalogue of business

process components for the business community.

Web Services Communication Models

In Web services architecture, depending upon the functional
requirements, it is possible to implement the models with RPC-based
synchronous or messaging-based synchronous/asynchronous
communication models. These communication models need to be
understood before Web services are designed and implemented.

RPC-Based Communication Model

The RPC-based communication model defines a

request/response-based synchronous communication. When the client
sends a request, the client waits until a response is sent back from the
server before continuing any operation. Typical to implementing CORBA
or RMI communication, the RPC-based Web services are tightly coupled
and are implemented with remote objects to the client application. Figure
3.3 represents an RPC-based communication model in Web services
architecture.
The clients have the capability to provide parameters in method
calls to the Web service provider. Then, clients invoke the Web services by
sending parameter values to the Web service provider that executes the
required methods, and then sends back the return values. Additionally,
using RPC- based communication, both the service provider and requestor
can register and discover services, respectively.

Web Service Requester Web Service Provider

REQUEST

RESPONSE

Figure 3.3 RPC-based communication model in Web services.

Messaging-Based Communication Model

The messaging-based communication model defines a loosely
coupled and document-driven communication. The service requestor
invoking a messaging-based service provider does not wait for a response.
Figure 3.4 represents a messaging-based communication model in Web
services architecture.
In Figure 3.4, the client service requestor invokes a messaging-
based Web service; it typically sends an entire document rather than
sending a set of parameters. The service provider receives the document,
processes it, and then may or may not return a message. Depending upon
the imple- mentation, the client can either send or receive a document
asynchro- nously to and from a messaging-based Web service, but it
cannot do both functionalities at an instant. In addition, it also is possible
to implement messaging with a synchronous communication model where
the client makes the service request to the service provider, and then waits
and receives the document from the service provider.
Adopting a communication model also depends upon the Web service
provider infrastructure and its compliant protocol for RPC and Messaging.
 The current version of SOAP 1.2 and ebXML Messaging support these
communication models; it is quite important to ensure that the protocols
are compliant and supported by the Web services providers. It also is
important to satisfy other quality of services (QoS) and environmental
requirements like security, reliability, and performance.
The process steps of implementing a Web services model.

Web Service Requester Web Service Provider

MESSAGE

Figure 3.4 Messaging-based communication model.

Develop Java-Based Web Services

With the overwhelming success of Java in Web and pervasive applications

running on a variety of platforms and devices, the Java platform has become the
obvious choice for

enterprise architects and developers. In addition to the Java platform, today the
J2EE-based

application environment also has become the preferred solution for running Web

servicesbased solutions.

Building Web Services in the J2EE Environment

The process of building Web services using a J2EE environment involves

exposing J2EE components such as servlets and EJBs. In addition, J2EE
applications also can access these exposed services using standard protocols.

In a typical implementation, a J2EE-based Web services model defines

another way of exposing their business components similar to Web applications
and RMI/IIOP-based application connectivity and without changing the
architectural model or code of the existing J2EE components. For example, in a
J2EE-based application server environment, J2EE components can be exposed for
remote access through RMI/IIOP. In the case of a Web service provider using a
J2EE environment, in addition to RMI/IIOP, it also is possible to expose those
components as a service via WSDL and handle the exposed service by sending and
receiving SOAP-based requests/responses or messages.

The following steps are commonly involved in creating Web services from a
J2EE-based application component:

1. Select a Web services platform provider, which provides a consistent platform

for building

and deploying Web services over the J2EE applications.

2. Define a Web service-enabled application and its behavior.

a. Select the potential J2EE components (for example, EJBs, Servlets, and JMS
applications) that are required to be exposed as services or are using the existing
services.

b. Choose the communication model (RPC-based synchronous or messaging-based

asynchronous) depending upon the required behavior of the underlying

components (for example, Session or Entity EJBs using RPC-based
communication or JMS applications using messaging-based communication).

c. Ensure that the service uses only built-in/custom data types mapping for XML
and Java supported by the Web services container. This applies only to RPC-based
communication models.

3. Develop the Web service by writing the interfaces required for accessing the
exposed components (for example, EJBs, Servlets, and JMS applications).

a. Develop the potential J2EE component (for example, EJBs, Servlets, and JMS

applications) that are required and deploy them in a J2EE-compliant container.

Ensure that the data types used by the components are supported in the XML/Java
mappings defined by the provider.

b. Implement the SOAP message handlers.

4. Assemble the required components into a required structure (defined by the

Web services platform provider), additionally creating the deployment descriptors
for the services (as defined by the Web services platform provider) and package
them as a deployable EAR.
a. Most Web service platform vendors provide utility tools to generate Web
services components (SOAP interfaces) by introspecting the components
(especially its methods and values) and mapping them to its supported data types.

b. Also it is important to note, the upcoming release of the J2EE 1.4 specification
is expected to provide a complete J2EE-based Web services platform and would
enable the deployment

of J2EE components as Web services.

5. Deploy the Web service components in the Web services container and make
them available to its remote clients (based on the required protocol bindings such
as HTTP and SMTP).

6. Create test clients for invoking the deployed Web services.

7. Register and publish your Web service in a UDDI registry, in case you require
enabling the service available by searching public/private UDDI registries for Web
services.

J2EE and Java Web Services Developer Pack (JWSDP)

Sun Microsystems as part of its Java community process has already

released its Java API for

Web Services for the developer community as the Java Web Services Developer
Pack

(JWSDP). It provides a full-fledged solution package for developing and testing

Web

services using the Java APIs. In addition, leading Web services platform providers
like

Systinet, CapeClear, and Mind Electric and leading J2EE vendors like BEA, IBM,
and Sun

iPlanet also released their Web services capabilities, adopting a Java platform and
supporting

Java APIs for Web services as per JWSDP.

JWSDP 1.0 provides a one-stop Java API solution for building Web
services using a Java platform. The key API components include the following:

■■ Java API for XML Messaging (JAXM)

■■ Java API for XML Processing (JAXP)

■■ Java API for XML Registries (JAXR)

■■ Java API for XML Binding (JAXB)

■■ Java API for XML-Based RPC (JAX-RPC)

■■ Java WSDP Registry Server (JWSDP)

■■ Java Server Pages Standard Tag Library (JSTL)

Leading J2EE application server vendors have announced their support to this
effort and also started releasing their JWSDP API implementation. This helps the
developers to build Web services by exposing their existing J2EE applications.

Exposing J2EE Components as Web Services

The J2EE environment delivers platform-independent Java component-

based applications providing a multi-tiered distributed application model with
several advantages like security, scalability, administration tools, portability
between vendor implementations, and reliability of deployed applications.

In general, it defines the following components residing in different logical tiers:

■■ JavaServer Pages (JSP) and Java Servlet-based components act as Web

components running on the Web/Servlet container of the J2EE server.

■■ Enterprise JavaBeans (EJB)-based components act as business or persistence

components running on the EJB container of the J2EE server.

■■ JDBC (Java Database connectivity) and J2EE connector architecture based

components act as the integration tier of the J2EE server for integrating database
applications and enterprise information systems.

The key differences between J2EE components and traditional Java

applications is that J2EE components are assembled and deployed into a J2EE
application server in compliance with the J2EE specification. These components
are managed by J2EE server system services such as synchronization,
multithreading, and connecting pooling. Additionally, the J2EE server
implementation also provides capabilities like clustering, transaction coordination,

messaging, and database connection pooling.

In short, developing Web services from J2EE-based applications requires

the implementation of components using J2EE component APIs (such as EJBs and
servlets), then packaging and deploying them in a J2EE container environment as
target enterprise applications. The components are then hosted in a J2EE-
compliant application server. Exposing these J2EE components as Web services
also requires a Web services container environment, which enables the creation
and deployment of SOAP-based proxy interfaces.

A typical scenario, exposing a J2EE-based application component as Web services

involves the steps in the following list:

STEPS FOR THE SERVICE PROVIDER

1. The potential J2EE component deployed in an application server environment

will be

encapsulated as a service-oriented interface using SOAP and then deployed in a

Web

services runtime environment.

2. WSDL-based service descriptions are generated and then reside in the services

runtime environment. The service requestor clients create SOAP-based client

interfaces using the WSDL-based descriptions.

3. Using registry APIs, WSDLs are used for publishing the services in a
public/private

UDDI registry.

STEPS FOR THE SERVICE REQUESTOR

1. The service requestor clients create SOAP-based client interfaces using the
WSDLbased descriptions exposed by the service provider.

2. The service requestor may choose to use any language for implementing the
client

interfaces, but it must support the use of SOAP for communication.

3. These client interfaces then are used to invoke the service provider deployed
services

Web Services Description Language (WSDL)

WSDL, as we know, is a description language for Web services.
This means that WSDL represents information about the interface and
semantics of how to invoke or call a Web service.

A WSDL definition contains four important pieces of information about

the Web service:

■■ Interface information describing all the publicly available functions

■■ Data type information for the incoming (request) and outgoing

(response) messages to these functions

■■ Binding information about the protocol to be used for invoking the

specified Web service
■■ Address information for locating the specified Web service
 Web Service Life Cycle
Figure 5.1 illustrates the steps of the Web service life cycle.

In Figure 5.1, all of the communication over the wire takes place on
SOAP. The following list explains the steps depicted in Figure 5.1:

■■ Step 1 illustrates a service provider publishing its Web service to a

UDDI registry. This is when the service provider would create a
WSDL definition and publish a link to this definition along with the
rest of the Web service information to a UDDI registry.

■■ Step 2 illustrates an interested service user locating the Web service

and finally obtaining information about invoking the Web service
from the published WSDL definition. This step involves download-
ing a WSDL definition to the service user system and deserializing
WSDL to a Java class (or any other language). This Java interface
serves as a proxy to the actual Web service. It consists of the binding
 information of the Web service.
■■ Step 3 shows the service user binding at runtime to the Web service.
In this step, the service user’s application would make use of the
Java interface representing WSDL as a proxy, in order to bind to the
Web service.

■■ Step 4 finally shows the service user invoking the Web service
based on the service invocation information it extracted from the
Web service WSDL definition. This is when the service user’s
application would make use of the Java interface representing
WSDL as a proxy, in order to invoke the methods/functions
exposed by the Web service.

Anatomy of a WSDL Definition Document

A WSDL definition document consists of the following seven key struc-

tural elements:

<definitions>. A WSDL document is a set of definitions. These

definitions are defined inside the <definitions> element, which is the
root element in a WSDL document. It defines the name of the Web
service and also declares the namespaces that are used throughout the
rest of the WSDL document.

The following are the two important namespaces that

the <definitions> element defines:

WSDL instance specific namespace. The

targetNamespace attribute of the <definitions> element
lets the WSDL document make references to itself as an
XML Schema namespace. Note how- ever that it is not
required for the WSDL document to actually exist at the
 address specified by the targetNamespace attribute. This
attribute is just a mechanism to refer to our WSDL
definition in a unique way.

Default namespace for a WSDL document. The default

namespace is specified by
xmlns=”http://schemas.xmlsoap.org/wsdl/”. The default
namespace indicates that all of the elements in this WSDL
definition without a namespace prefix, such as <types>,
<message>, and <portType>, are part of this namespace.

<types>. This element defines all of the data types that would be
used to describe the messages that are exchanged between the Web
service and the service user. WSDL does not mandate the use of a
specific typing system. However, as per the WSDL specification,
XML Schema is the default typing system.

XML Schema was discussed in Chapter 4, “Developing Web Services

Using SOAP,” in the context of SOAP encoding.
<message>. This element represents a logical definition of the data
being transmitted between the Web service and the service user. This
element describes a one-way message, which may represent a request
or response sent to or from the Web service. It contains zero or more
message <part> elements, which basically refer to the request
parameters or response return values.

<portType>. This element defines the abstract definition of the oper-

ations supported by a Web service, by combining various request and
response messages defined by <message> elements. Each operation
refers to an input message and an output message.
Four types of operations are supported by WSDL:

One-way operation. One-way operation represents a

service that just receives the message, and thus a one-way
 operation is typically defined by a single <input> message
element.

Request-response operation.A request-response

operation repre- sents a service that receives a request
message and sends a response message. Typically, a
request-response operation is defined by one
<input> message followed by one <output> message. An optional
<fault> element also can be included in the definition of a
request- response operation to specify the abstract
message format for any error messages that may be output
as a result of the operation.

The GetWeatherInfo operation follows the request-

response transmission pattern.

Solicit-response operation. A solicit-response operation

represents a service that sends a request message and that
receives the response message. Such operations are
therefore defined by one <output> message, followed by an
<input> message. A solicit-response opera- tion also can
include a <fault> element in order to specify the for- mat
of any error messages resulting from the operation.

Notification operation. This operation represents a service

that sends a message, hence this kind of operation is
represented by a single
<output> element.

Figure 5.2 provides the pictorial representation of the

previous four transmission types.
 <binding>. This element specifies a concrete protocol and data for-
mat used for representing the operations and messages defined by a
particular <portType>, on the wire.

<port>. This element specifies an address for binding to the Web

service.

<service>. This element aggregates a set of related <port> ele-

ments, each which uniquely specify the binding information of the
Web service. A <service> consisting of multiple <port> elements
essentially represents the capability of the service to be invoked over
multiple bindings. More information on WSDL bindings is discussed
in the next section.

5.1, which shows a WSDL document describing a weather information

Web service, WeatherInfoService. This WSDL definition is present in the
WeatherInfo.wsdl file.

<?xml version=”1.0”?>

<definitions name=”WeatherInfo”
targetNamespace=”http://myweather.com/weatherinfo.
wsdl”
xmlns:tns=”http://myweather.com/weatherinfo.wsdl”
xmlns:xsd1=”http://myweather.com/weatherinfo.xsd”
xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”
xmlns=”http://schemas.xmlsoap.org/wsdl/”>

<types>
<schema targetNamespace=
“http://myweather.com/weatherinfo.xsd”
xmlns=
“http://www.w3.org/2000/10/XMLSchema”
>

<element name=”WeatherInfoRequest”>
<complexType>
<all>
<element name=”Country”
type=”string”/>

<element
name=”Zip”
type=”string”/>

<element name=”Instant”
type=”string”/>

</all>
</complexType>
</element>

<element name=”WeatherInfo”>
<complexType>
<all>
 <element
name=”FTemp”
type=”float”/>

<element name=”Humidity”
type=”float”/>

</all>
</complexType>
</element>
</schema>
</types>

<message name=”GetWeatherInfoInput”>
<part
name=”WeatherInfoRequestSpec”
element=”xsd1:WeatherInfoReque
st”/>

</message>

<message name=”GetWeatherInfoOutput”>
<part name=”WeatherInfo”

Listing 5.1 WeatherInfo.wsdl.

element=”xsd1:WeatherInfo”/>
</message>
<portType name=”WeatherInfoPortType”>
<operation name=”GetWeatherInfo”>
<input message=”tns:GetWeatherInfoInput”/>
<output message=”tns:GetWeatherInfoOutput”/>
</operation>
</portType>

<binding
name=”WeatherInfoSoapBinding”
type=”tns:WeatherInfoPortType”>

<soap:binding style=”document”
transport=”http://schemas.xmlsoap.org/soap/http”
/>

<operation name=”GetWeatherInfo”>

<soap:operation soapAction=
“http://myweather.com/GetWeatherInf
o”/>

<input>
<soap:body use=”literal”/>
</input>

<output>
<soap:body use=”literal”/>
</output>
</operation>
</binding>

<service name=”WeatherInfoService”>

<documentation>
 Provides Weather Information
</documentation>

<port name=”WeatherInfoPort”
binding=”tns:WeatherInfoSoapBindi
ng”>

<soap:address location=
“http://myweather.com/provideweatherinf
o”/>

</port>
</service>
</definitions>

Listing 5.1 WeatherInfo.wsdl.

WSDL Bindings
In WSDL, the term binding refers to the process of associating
protocol or data format information with an abstract entity such as
<message>,<operation>, or <portType>. In this section, we examine the
support for bindings in the WSDL 1.1 specification.
The base specification of WSDL defines three WSDL binding
extensions, which are as follows:
■■ SOAP binding
■■ HTTP GET & POST binding
■■ MIME binding

SOAP Binding
WSDL 1.1 defines a binding for SOAP 1.1 endpoints. This
binding provides the following SOAP protocol specific
information:
■■ An indication that the binding is bound to the SOAP 1.1 protocol
■■ A way of specifying an address for a SOAP endpoint
■■ The URI for the SOAP action HTTP header for the HTTP
binding of SOAP
■■ A list of definitions of headers that are transmitted as
 part of the SOAP envelope

WSDL Tools

WSDL tools typically provide functionality in terms of the following:

WSDL generation. Generating WSDL from an existing service

component—for example, a J2EE component or a Java Bean
compo- nent or from scratch.

WSDL compilation. A typical WSDL compiler would generate the

necessary data structures and a skeleton for the implementation of the
service. The generated implementation skeleton contains all the meth-
ods (operations) that are described in the given WSDL definition.

WSDL proxy generation. This functionality can read a WSDL

and produce a specific language binding (for example, Java or
Perl) consisting of all the code required to bind the Web service
and to invoke the Web service functions at runtime. This
functionality is typically used at the client end.

Many WSDL tools provide support for these three functionalities.

Table 5.1 lists some of the famous ones in the Java Web Services space.

Systinet WASP provides two tools for working with WSDL: Java2WSDL
and WSDL Compiler. Both of these tools accomplish two different types
of functionalities related to WSDL:
Generating WSDL from a Java class that is a potential candidate for
a Web service. This functionality is taken care of by the Java2WSDL
 tool.
Generating Java code from an existing WSDL. This functionality
is taken care of by the WSDL Compiler.
We will check out both these tools in the following two sections.

Generating WSDL from a Java Class

In situations in which an implementation of the Web service has already
been created first, the Java2WSDL tool can be used to generate WSDL.
This tool provides a lot of options for generating WSDL from an existing
Java implementation.
To understand the functioning of this tool, consider the following
Java class:

package jws.ch5;

public class WeatherInfoJavaService

{
public float GetWeatherInfo (String sCountry, String sZip,
String sInstance)
{
// Talk to some backend services to get hold
// of the weather information

// Return the weather information;

// a manipulated value for
now. return 65.0f;

}
public void SetWeatherInfo (String sCountry, String
sZip, String sInstance, String sTemperature)

{
// Update the backend weather databases
// with this information
 }
}
The following command line instruction shows the usage of the
Java2WSDL tool such that it would generate a WeatherInfo.wsdl from the
WeatherInfoJavaService class:

> Java2WSDL jws.ch5.WeatherInfoJavaService --package-

mapping “jws.ch5=http://www.myweather.com/WeatherInfo” --
output-file-mapping “http://www.myweather.com/WeatherInfo=
WeatherInfo.wsdl” —output-directory jws/ch5
 <?xml version=’1.0’?>

<wsdl:definitions name=’jws.ch5.WeatherInfoJavaService’
targetNamespace=’http://www.myweather.com/WeatherInfo’
xmlns:wsdl=’http://schemas.xmlsoap.org/wsdl/’
xmlns:tns=’http://www.myweather.com/WeatherInfo’
xmlns:ns0=’http://systinet.com/xsd/SchemaTypes/’
xmlns:soap=’http://schemas.xmlsoap.org/wsdl/soap/’
xmlns:map=’http://systinet.com/mapping/’>

This command would generate WeatherInfo.wsdl and place it in the

%DEMO_DIR%/jws/ch5 directory. Table 5.2 gives the explanation of the
arguments used in the previous command.

<?xml version=’1.0’?>
<wsdl:definitions name=’jws.ch5.WeatherInfoJavaService’
targetNamespace=’http://www.myweather.com/WeatherInfo’
xmlns:wsdl=’http://schemas.xmlsoap.org/wsdl/’
xmlns:tns=’http://www.myweather.com/WeatherInfo’
xmlns:ns0=’http://systinet.com/xsd/SchemaTypes/’
xmlns:soap=’http://schemas.xmlsoap.org/wsdl/soap/’
xmlns:map=’http://systinet.com/mapping/’>

<wsdl:types>
<xsd:schema elementFormDefault=”qualified” targetNamespace=
“http://systinet.com/xsd/SchemaTypes/”
xmlns:tns=”http://systinet.com/xsd/SchemaTypes/”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

<xsd:element name=”sCountry” nillable=”true”

 <?xml version=’1.0’?>

<wsdl:definitions name=’jws.ch5.WeatherInfoJavaService’
targetNamespace=’http://www.myweather.com/WeatherInfo’
xmlns:wsdl=’http://schemas.xmlsoap.org/wsdl/’
xmlns:tns=’http://www.myweather.com/WeatherInfo’
xmlns:ns0=’http://systinet.com/xsd/SchemaTypes/’
xmlns:soap=’http://schemas.xmlsoap.org/wsdl/soap/’
xmlns:map=’http://systinet.com/mapping/’>

Table 5.2 Java2WSDL Command Line Options

The Java2WSDL tool supports many more arguments than what are
shown in Table 5.2.
The output WeatherInfo.wsdl generated by the Java2WSDL tool is
shown in Listing 5.2.

Listing 5.2 WeatherInfo.wsdl generated by the Java2WSDL tool.

type=”xsd:string”/>

<xsd:element name=”sZip” nillable=”true”

type=”xsd:string”/>

<xsd:element name=”sInstance” nillable=”true”

type=”xsd:string”/>

<xsd:element name=”float_res” type=”xsd:float”/>

<xsd:element
name=”sTemperature”
 nillable=”true”
type=”xsd:string”/>

</xsd:schema>
</wsdl:types>

<wsdl:message name=
‘WeatherInfoJavaService_GetWeatherInfo_1_Request’>

<wsdl:part name=’sCountry’ element=’ns0:sCountry’/>

<wsdl:part name=’sZip’ element=’ns0:sZip’/>
<wsdl:part name=’sInstance’ element=’ns0:sInstance’/>
</wsdl:message>
<wsdl:message name=
‘WeatherInfoJavaService_GetWeatherInfo_Response’>

<wsdl:part name=’response’ element=’ns0:float_res’/>

</wsdl:message>

<wsdl:message name=’WeatherInfoJavaService_SetWeatherInfo_Response’/>

<wsdl:message name=
‘WeatherInfoJavaService_SetWeatherInfo_1_Request’>

<wsdl:part name=’sCountry’ element=’ns0:sCountry’/>

<wsdl:part name=’sZip’ element=’ns0:sZip’/>
<wsdl:part name=’sInstance’ element=’ns0:sInstance’/>
<wsdl:part name=’sTemperature’
element=’ns0:sTemperature’/>

</wsdl:message>

<wsdl:portType name=’WeatherInfoJavaService’>
<wsdl:operation name=’GetWeatherInfo’ parameterOrder=’sCountry
sZip sInstance’>
<wsdl:input message=‘tns:WeatherInfoJavaService_GetWeatherInfo_1_Request’/>

<wsdl:output message= ‘tns:WeatherInfoJavaService_GetWeatherInfo_Response’/>

</wsdl:operation>

<wsdl:operation name=’SetWeatherInfo’ parameterOrder=’sCountry

sZip sInstance sTemperature’>

<wsdl:input message= ‘tns:WeatherInfoJavaService_SetWeatherInfo_1_Request’/>

<wsdl:output message= ‘tns:WeatherInfoJavaService_SetWeatherInfo_Response’/>

</wsdl:operation>
</wsdl:portType>

<wsdl:binding name=’WeatherInfoJavaService’
type=’tns:WeatherInfoJavaService’>

<soap:binding transport= ‘http://schemas.xmlsoap.org/soap/http’

style=’document’/>

<wsdl:operation name=’GetWeatherInfo’>
<map:java-operation name= ‘GetWeatherInfo’ signature=’KExq...’/>

<soap:operation soapAction=’_10’ style=’document’/>

<wsdl:input>
<soap:body use=’literal’ namespace=’http://www.myweather.com/
WeatherInfoWeatherInfoJavaService’/>

</wsdl:input>

<wsdl:output>
<soap:body use=’literal’ namespace= ‘http://www.myweather.com/
WeatherInfoWeatherInfoJavaService’/>

</wsdl:output>
</wsdl:operation>

<wsdl:operation name=’SetWeatherInfo’>
<map:java-operation name=’SetWeatherInfo’ signature=’KExq...’/>

Listing 5.2 WeatherInfo.wsdl generated by the Java2WSDL tool.

 <soap:operation soapAction=’_11’
style=’document’/>

<wsdl:input>

<soap:body use=’literal’ namespace=

‘http://www.myweather.com/
WeatherInfoWeatherInfoJavaService’/>

</wsdl:input>

<wsdl:output>

<soap:body use=’literal’ namespace=

‘http://www.myweather.com/
WeatherInfoWeatherInfoJavaService’/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name=’JavaService’>

<wsdl:port name=’WeatherInfoJavaService’
binding=’tns:WeatherInfoJavaService’>

<soap:address location=
‘urn:unknown-location-uri’/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Listing 5.2 WeatherInfo.wsdl generated by the Java2WSDL tool. (continued)

Generating Java Code from an Existing WSDL
In situations in which WSDL definitions are created before
actually imple- menting a Web service, the WSDLCompiler tool of WASP
can be used to generate the skeleton of a Java interface. A Java class
consisting of the actual method implementations then can implement this
generated Java interface.
The usage of the WSDLCompiler tool is as follows:
 > WSDLCompiler WeatherInfo.wsdl

In this case, a Java interface with the name WeatherInfoJavaService

is created as shown in Listing 5.3.

/**

*/

public interface WeatherInfoJavaService {/

/**

*/

float GetWeatherInfo(java.lang.String sCountry, java.lang.String

sZip, java.lang.String sInstance);

/**

*/

void SetWeatherInfo(java.lang.String sCountry, java.lang.String

sZip, java.lang.String sInstance, java.lang.String sTemperature);

/*

* Generated by WSDLCompiler, (c) 2002, Systinet Corp.

* http://www.systinet.com
*/

Listing 5.3 WeatherInfoJavaService Java class generated by the WSDLCompiler tool.

This tool also has various options that enable fine-tuning of the genera- tion of the Java interface. Also,
WSDLCompiler supports the generation of Java Bean components from WSDL definitions.
The following lists some of the important enhancements of WSDL 1.2
over WSDL 1.1:
■■ WSDL 1.2 provides support for W3C Recommendations,
 including XML Schemas and XML Information Set.
■■ WSDL 1.2 removes non-interoperable features from WSDL 1.1.
■■ WSDL 1.2 clearly defines HTTP 1.1 binding.
Limitations of WSDL
WSDL 1.1 has an obvious limitation: its incapability of being able to
describe complex business Web services, which typically are constituted
by orchestrating multiple finer-grained Web services. This drawback is
due to the lack of support for workflow descriptions in WSDL. To
overcome these limitations of WSDL, standards such as ebXML
Collaborative Protocol Profile/Collaborative Protocol Agreement
(CCP/A), Business Process Specification Schema (BPSS), and Web
Services Choreography Interface (WSCI) can be leveraged. An EbXML
set of technologies can be used to build business Web services.