UNIT 1

Unit 1 Syllabus
Evolution and emergence of Web Services
 Evolution of Distributed computing
 Core Distributed Computing Technologies-
Client Server ,CORBA, JAVA RMI ,Microsoft DCOM,MOM
 Challenges in Distributed Computing
 Role of J2EE and XML in Distributed Computing
 Emergence of Web Services and Service oriented Architecture(SOA)
Introduction to Web Services
 The definition of Web Services
 Basic operational model of Web Services
 Tools and technologies enabling Web Services
 Benefits and challenges of using Web Services
Web Services Architecture
 Web Services Architecture and its characteristics
 Core building blocks of Web Services
 Standards and technologies for implementing Web Services
 Web Services communication model
 Basic steps of implementing Web Services
Evolution of DISTRIBUTED COMPUTING
“Distributing Computing is a type of computing in
which
different components and objects comprising an
application can be located on different
computers connected to network

Today, Sun Java RMI (Remote Method Invocation), OMG

CORBA (Common Object Request Broker Architecture),
Microsoft DCOM (Distributed
Component Object Model) and
Message-Oriented Middleware (MOM)
have emerged as the most common distributed
computing technologies.
distributed computing model that provides an infrastructure enabling
invocations of object functions located anywhere on the network. The objects
are transparent to the application and provide processing power as if they
were local to the application calling them
 The Importance of Distributed Computing

The distributed computing environment provides many significant

advantages compared to a traditional standalone application. The
following are some of those key advantages:

Higher performance. Applications can execute in parallel

and distribute the load across multiple servers
Collaboration. Multiple applications can be connected
through standard distributed computing mechanisms
Higher reliability and availability. Applications or
servers can be
clustered in multiple machines
Scalability. This can be achieved by deploying these reusable
distributed components on powerful servers
Extensibility. This can be achieved through dynamic
(re)configuration
of applications that are distributed across the network.

.
Higher productivity and lower development cycle time. By
breaking up large problems into smaller ones, these individual
components can be developed by smaller development teams in
isolation.

Reuse. The distributed components may perform various

services that can potentially be used by multiple client
applications. It saves repetitive development effort and
improves interoperability between components.

Reduced cost. Because this model provides a

lot of reuse of once developed components
that are accessible over the network,
significant cost reductions can be achieved
 Client-Server Applications

In a two-tier architecture model, the first(upper) tier handles the presentation

and business logic of the user application(client), and the second/lower tier
handles the application organization and its data storage (server). This
approach is commonly called client-server applications architecture

Generally, the server in a client/server application model is a database

server that is mainly responsible for the organization and retrieval of data.

The application client in this model handles most of the business processing
and provides the graphical user interface of the application.
It is a very popular design in business applications where the user interface
and business logic are tightly coupled with a database server for handling
data retrieval and processing.

For example, the client-server model has been widely used in enterprise
resource planning (ERP), billing, and Inventory application systems where a
number of client business applications residing in multiple desktop systems
interact with a central database server
 Some of the common limitations of the client-server
application model are as follows:

Complex business processing at the client side demands robust client

systems

Security is more difficult to implement because the algorithms and

logic reside on the client side making it more vulnerable to hacking

Increased network bandwidth is needed to accommodate many

calls to the server, which can impose scalability restrictions

Maintenance and upgrades of client applications are extremely

difficult because each client has to be maintained separately

Client-server architecture suits mostly database-oriented

standalone applications and does not target robust reusable
component oriented applications
 CORBA Common
ObjectRequestBrokerArchitecture

It is an industry wide, open standard initiative, developed by the Object

Management Group (OMG) for enabling distributed computing that supports a
wide range of application environments.

CORBA differs from the traditional client/server model because it provides an

object-oriented solution that does not enforce any proprietary protocols or any
particular programming language, operating system, or hardware platform.
By adopting CORBA, the applications can reside and run on any hardware
platform located anywhere on the network, and can be written in any
language that has mappings to a neutral interface definition called the
Interface Definition Language (IDL).

An IDL is a specific interface language designed to expose the services

(methods/functions) of a CORBA remote object.

CORBA also defines a collection of system-level services for handling low-

level application services like life-cycle, persistence, transaction, naming,
security, and so forth
In a CORBA-based solution, the Object Request Broker (ORB) is an object
bus that provides a transparent mechanism for sending requests and
receiving responses to and from objects, regardless of the environment
and its location.

The ORB intercepts the client’s call and is responsible for finding
its server object that implements the request, passes its parameters,
invokes its method, and returns its results to the client.

The ORB, as part of its implementation, provides interfaces to the

CORBA services, which allows it to build custom-distributed application
environments.
The CORBA architecture is composed of the following
components:

IDL
CORBA uses IDL contracts to specify the application
boundaries and to
establish interfaces with its clients.
The IDL provides a mechanism by which the distributed
application component’s interfaces, inherited classes, events,
attributes, and exceptions can be specified in a standard
definition language supported by the CORBA ORB

ORB.
It acts as the object bus or the bridge, providing the
communication infrastructure to send and receive
request/responses from the client and server

It establishes the foundation for the distributed

application objects, achieving interoperability in a
heterogeneous environment.
Some of the distinct advantages of CORBA over a traditional
client/server application model are as follows:

OS and programming language independence.

Legacy and custom application integration
Rich distributed object infrastructure
Location transparency

Network transparency

Remote callback support

Dynamic invocation
interface

High initial investment

Availability of CORBA services
 Java RMI

RMI provides a distributed Java application environment by calling remote

Java objects and passing them as arguments or return values.
It uses Java object serialization—a lightweight object persistence
technique that allows the conversion of objects into streams.

Java RMI uses Java Remote Method Protocol (JRMP) as the

interprocesscommunication protocol, enabling Java objects living in
different java Virtual Machines (VMs) to transparently invoke one
another’s methods.

Because these VMs can be running on different computers anywhere on

the network, RMI enables object-oriented distributed computing. RMI also
uses a reference-counting garbage collection mechanism that keeps track of
external live object references to remote objects (live connections)
using the virtual machine

When an object is found unreferenced, it is considered to be a

weak reference and it will be garbage collected.
In RMI-based application architectures, a registry (rmiregistry)-
oriented mechanism provides a simple non-persistent naming
lookup service that is used to store the remote object
references and to enable lookups from client applications.

The RMI infrastructure based on the JRMP acts as

the medium between the RMI clients and remote objects. It
intercepts client requests, passes invocation arguments,
delegates invocation requests to the RMI skeleton, and finally
passes the return values of the method execution to the client
stub

It also enables callbacks from server objects to client

applications so that the asynchronous notifications can be
achieved.
The Java RMI architecture is composed of the following
components:

RMI client

RMI stub.

RMI infrastructure

RMI skeleton

RMI server.
Although RMI had inherent advantages provided by the distributed object
model of the Java platform, it also had some limitations:

RMI is limited only to the Java platform. It does not provide language
independence in its distributed model as targeted by CORBA.

RMI-based application architectures are tightly coupled because of

the connection-oriented nature. Hence, achieving high scalability in
such an application model becomes a challenge

RMI does not provide any specific session management

support. In a typical client/server implementation, the server
has to maintain the session and state information of the
multiple clients who access it. Maintaining such information
within the server application without a standard support is a
complex task.
 Microsoft DCOM
Distributed Common Object Model

DCOM applies a skeleton and stub approach whereby a defined

interface that exposes the methods of a COM object can be invoked
remotely over a network

The client application will invoke methods on such a

remote COM object in the same fashion that it would with a local
COM object.

The stub encapsulates the network location information of the

COM server object and acts as a proxy on the client side

The servers can potentially host multiple COM objects, and

when they register themselves against a registry, they become
available for all the clients, who then discover them using a
lookup mechanism.
 DCOM is quite successful in providing distributed computing support on the
Windows platform. But, it is limited to Microsoft application environments. The
following are some of the common limitations of DCOM:

Platform lock-in
State management
Scalability
Complex session
management issues
 Message-Oriented Middleware

Message-Oriented Middleware (MOM) is based upon a loosely coupled

asynchronous communication model where the application client does
not need to know its application recipients or its method arguments.

MOM enables applications to communicate indirectly using a

messaging provider queue.

The application client sends messages to the message queue

(a message holding area), and the receiving application picks
up the message from the queue.

In this operation model, the application sending messages to

another application continues to operate without waiting for
the response from that application.

In MOM-based architecture, applications interacting with its

messaging infrastructure use custom adapters.
Client applications communicate with the underlying
messaging infrastructure using these adapters for sending
and receiving messages.

For reliable message delivery, messages can be

persisted in a database/file system as well.

Some of the common challenges while implementing a

MOM-based application environment have been the
following:

Most of the standard MOM implementations have

provided native APIs for communication with their core
infrastructure. This has affected the portability of
applications across such implementations and has led to
a specific vendor lock-in.

The MOM messages used for integrating applications are

usually based upon a proprietary message format without
any standard compliance.
 Common Challenges in Distributed Computing

Maintenance of various versions of stubs/skeletons in the client

and server environments is extremely complex in a
heterogeneous network environment

Quality of Service (QoS) goals like Scalability, Performance, and

Availability in a distributed environment consume a major
portion of the application’s development time.

Interoperability of applications implementing different protocols

on heterogeneous platforms almost becomes impossible. For
example, aDCOM client communicating to an RMI server or an
RMI client communicating to a DCOM server.

Most of these protocols are designed to work well within local

networks. They are not very firewall friendly or able to be
accessed over the Internet.
 The Role of J2EE and XML in Distributed Computing

In the Internet-based enterprise application model, the focus

was to move the complex business processing toward centralized
servers in the back end.

The first generation of Internet servers was based upon Web servers that
hosted static Web pages and provided content to the clients via
HTTP(Hyper Text Transfer Protocol).

HTTP is a stateless protocol that connects Web browsers to Web

servers, enabling the transportation of HTML content to the user.

With many organizations moving their businesses to the Internet, a

whole new category of business models like business-to-business (B2B)
and business-to-consumer (B2C) came into existence
This evolution lead to the specification of J2EE architecture, which
promoted a much more efficient platform for hosting Web-based
applications. J2EE provides a programming model based upon Web
and business components that are managed by the J2EE application
server

The application server consists of many APIs and low-level services

available to the components. These low-level services provide security,
transactions, connections and instance pooling, and concurrency
services, which enable a J2EE developer to focus primarily on business
logic rather than plumbing.

J2EE also provides excellent client connectivity capabilities,

ranging from PDA to Web browsers to Rich Clients (Applets,
CORBA applications, and Standard Java Applications).
A typical J2EE architecture is physically divided in to three logical tiers, which
enables clear separation of the various application components with defined
roles and responsibilities. The following is a breakdown of functionalities of
those logical tiers:

Presentation tier. The Presentation tier is composed of Web components,

which handle HTTP requests/responses, Session management,
Device independent content delivery, and the invocation of business tier
components.

Application tier. The Application tier (also known as the Business

tier) deals with the core business logic processing, which may typically deal with
workflow and automation. The business components retrieve data from the
information systems with well-defined APIs provided by the application server.

Integration tier. The Integration tier deals with connecting and

communicating to back-end Enterprise Information Systems (EIS), database
applications and legacy applications, or mainframe applications
The emergence of the Extensible Markup Language (XML) for defining
portable data in a structured and self-describing format is embraced by the
industry as a communication medium for electronic data exchange

UsingXML as a data exchange mechanism between applications

promotes interoperability between applications and also enhances the
scalability of the underlying applications

Combining the potential of a J2EE platform and XML offers a

standard
framework for B2B and inter application communication across
networks.

With J2EE enabling enterprise applications to the Internet and XML

acting as a “glue” bridges these discrete J2EE-based applications by
facilitating them to interoperate with each other.

XML, with its incredible flexibility, also has been widely adopted
and accepted as a standard by major vendors in the IT industry
 The Emergence of Web Services

The increasing demands of the industry for enabling B2B, application-to

application(A2A), and inter-process application communication has led to a
growing requirement for service-oriented architectures.

Enabling service-oriented applications facilitates the exposure of business

applications as service components enable business applications from other
organizations to link with these services for application interaction and data
sharing without human intervention.

By adopting Web technologies, the service-oriented architecture model

facilitates the delivery of services over the Internet by leveraging standard
technologies such as XML

It uses platform-neutral standards by exposing the underlying application

components and making them available to any application, any platform, or
any device, and at any location
 Introduction to Web Service
Web services are based on the concept of service-oriented architecture
(SOA). SOA is the latest evolution of distributed computing, which
enables software components, including application functions, objects,
and processes from different systems, to be exposed as services.

According to Gartner research “Web services are loosely coupled

software components delivered over Internet standard technologies.”

In short, Web services are self-describing and modular business

applications that expose the business logic as services over the
Internet through programmable interfaces and using Internet
protocols for the purpose of providing ways to find, subscribe, and
invoke those services
Consider the simple example shown in Figure2.1 where a travel
reservation services provider exposes its business applications as
Web services supporting a variety of customers and application
clients. These business applications are provided by different travel
organizations residing at different networks and geographical
locations
The following is a typical scenario:
1.The Travel service provider deploys its Web services by exposing the business
applications obtained from different travel businesses like airlines, car-rental, hotel
accommodation, credit card payment, and so forth.

2.The service provider registers its business services with descriptions using a
public or private registry. The registry stores the information about the services
exposed by the service provider.

3.The customer discovers the Web services using a search engine or by locating
it directly from the registry and then invokes the Web services for performing
travel reservations and other functions over the Internet using any platform or
device.

4.In the case of large-scale organizations, the business applications

consume these Web services for providing travel services to their own
employees through the corporate intranet
 Motivation and Characteristics

Web-based B2B communication has been around for quite some time.
These Web-based B2B solutions are usually based on custom and proprietary
technologies and are meant for exchanging data and doing transactions over
the Web.
For example, in B2B communication, connecting new or existing
applications and adding new business partners have always been
a challenge.
Ideally, the business applications and information from a partner
organization should be able to interact with the application of the
potential partners seamlessly without redefining the system or its
resources.

To meet these challenges, it is clearly evident that there is a need for

standard protocols and data formatting for enabling seamless and scalable
B2B applications and services. Web services provide the solution to resolve
these issues by adopting open standards.
Web services enable businesses to communicate, collaborate, and conduct
business transactions using a lightweight infrastructure by adopting an
XML-based data exchange format and industry standard delivery
protocols.

The basic characteristics of a Web services application model are as

follows:
Web services are based on XML messaging, which means that the
data exchanged between the Web service provider and the user
are defined in XML.
Web services provide a cross-platform integration of business
applications over the Internet
To build Web services, developers can use any common
programming language, such as Java, C, C++, Perl, Python,
C#, and/or Visual Basic, and its existing application
components.
Web services are not meant for handling presentations like HTML
context—it is developed to generate XML for uniform
accessibility through any software application, any platform, or
device.
Because Web services are based on loosely coupled application
components, each component is exposed as a service with its unique
functionality.

Web services use industry-standard protocols like HTTP, and they can
be easily accessible through corporate firewalls.

Web services can be used by many types of clients.

Web services vary in functionality from a simple request to a

complex business transaction involving multiple resources.

All platforms including J2EE, CORBA, and Microsoft .NET

provide extensive support for creating and deploying Web services.

Web services are dynamically located and invoked from public and
private registries based on industry standards such as UDDI and
ebXML
 Basic Operational Model of Web Services

Web services operations can be conceptualized as a simple operational

model that has a lot in common with a standard communication
model

Operations are conceived as involving three distinct roles and

relationships
that define the Web services providers and users

These roles and relationships are defined as follows:

Service provider. The service provider is responsible for developing
and deploying the Web services. The provider also defines the
services and publishes them with the service broker.
Service broker. The service broker (also commonly referred to as a service
registry) is responsible for service registration and discovery of theWebservices.
The broker lists the various service types, descriptions, and locations of the
services that help the service requesters find and subscribe to the required
services.

Service requestor. The service requestor is responsible for the service invocation. The
requestor locates the Web service using the service broker, invokes the required
 Core Web Services Standards&Technologies

The five core Web services standards and technologies for building and
enabling Web services are XML, SOAP, WSDL, UDDI, and ebXML

Extensible Markup Language (XML)

In February 1998, the Worldwide Web Consortium (W3C) officially endorsed

the Extensible Markup Language (XML) as a standard data format.

XML uses Unicode, and it is structured self-describing neutral data that can
be stored as a simple text document for representing complex data and to
make it readable.
Today, XML is the de facto standard for structuring data, content, and data
format for electronic documents. It has already been widely accepted as
the universal language for exchanging information between applications,
systems, and devices across the Internet

In the core of the Web services model, XML plays a vital role as the
common wire format in all forms of communication. XML also is the
basis for other Web services standards
 Simple Object Access Protocol (SOAP)

Simple Object Access Protocol, or SOAP, is a standard for a lightweight

XML-based messaging protocol.

It enables an exchange of information between two or more peers and enables

them to communicate with each other in a decentralized, distributed
application environment.

Like XML,SOAP also is independent of the application object model,

language, and running platforms or devices. SOAP is endorsed by W3C and
key industry vendors like Sun Microsystems, IBM, HP, SAP, Oracle, and
Microsoft
In the core of the Web services model, SOAP is used as the messaging
protocol for transport with binding on top of various Internet protocols
such as HTTP, SMTP, FTP, and so on.
SOAP uses XML as the message format, and it uses a set of encoding
rules for representing data as messages.

Although SOAP is used as a messaging protocol in Web services, it also

can operate on a request/response model by exposing the functionality
using SOAP/RPC based on remote procedural calls.
 Web Services Definition Language (WSDL)

The Web Services Definition Language (WSDL) standard is an XML

format for describing the network services and its access
information

It defines a binding mechanism used to attach a protocol, data format,

an abstract message, or set of endpoints defining the location of
services

In the core of the Web services model, WSDL is used as the

metadata language for defining Web services and describes how
service providers and requesters communicate with one another
WSDL describes the Web services functionalities offered by the
service provider, where the service is located, and how to access the
service.

Usually the service provider creates Web services by generating

WSDL from its exposed business applications.

A public/private registry is utilized for storing and publishing the

WSDL based information
 Universal Description, Discovery, and Integration (UDDI)

Universal Description, Discovery, and Integration, or UDDI, defines the standard

interfaces and mechanisms for registries intended for publishing and storing
descriptions of network services in terms of XML messages
It is similar to the yellow pages or a telephone directory where businesses list their
products and services. Web services brokers use UDDI as a standard for registering
the Web service providers. By communicating with the UDDI registries, the
service requestors locate services and then invoke them.

In the core Web services model, UDDI provides the registry for Web services to
function as a service broker enabling the service providers to populate the
registrywithservicedescriptions and service types and the service requestors to
query the registry to find and locate the services.

It enables Web applications to interact with a UDDI-based registry using SOAP

messages. These registries can be either private services within an enterprise
or a specific community, or they can be public registries to service the whole
global business community of the Internet.
 EBXML

EbXML defines a global electronic marketplace where enterprises find

one another and conduct business process collaborations and transactions
It also defines a set of specifications for enterprises to conduct electronic
business over the Internet by establishing a common standard for business
process specifications, business information modeling, business process
collaborations, collaborative partnership profiles, and agreements and
messaging.
In the Web services model, ebXML provides a comprehensive framework for the
electronic marketplace and B2B process communication by defining standards
for business processes, partner profile and agreements registry and repository
services, messaging services, and core components.
It complements and extends with other Web services standards like SOAP,WSDL,
and UDDI. In particular :
ebXML Business Process Service Specifications (BPSS) enable business
processes
to be defined
ebXML CPP/CPA enables business partner profiles and agreements to be
defined, and it provides business transaction choreography.

ebXML Messaging Service Handler (MSH) deals with the transport, routing,
 Web Services Software and Tools

Web services software and tool vendors offering solutions for developing and deploying
Java-based Web services solutions. The following is a list of the most popular software
solutions commercially available for implementing Web services

BEA Systems Products

BEAWebLogic Server 7.0 provides the infrastructure solution for Web

services supporting the standards and protocols of Web services.

The BEA Web Logic Integration Server also enables complex Web
services to be deployed with transactional integrity, security, and
reliability while supporting the emerging ebXML and BTP
standards.
 Cape Clear Products

Cape Clear provides Web services infrastructure and product solutions such as
Cape Connect and Cape Studio, which enable the development of
Web services solutions based on industry standards such as XML, SOAP,
WSDL, and UDDI

Cape Clear also enables business applications from diverse technologies

such as Java, EJB, CORBA, and Microsoft .NET. These components
can be exposed as Web services over the Internet.

IBM Products

IBM Web Sphere Application Server4.5provides an infrastructure

solution for deploying Web services-based applications

IBM also provides a Web Services Tool Kit (WSTK) bundle (now part of Web
Sphere Studio) for developers as a runtime environment that creates, publishes,
and tests Web services solutions based on open standards such as XML,SOAP,
WSDL, and UDDI.
 IOPSIS Products

IOPSIS provides B2Beyond suite iNsight and W2Net, an Integrated Services

Development Framework (ISDF), that enables the creation, assembly, deployment,
and publication of Web services based on open standards such as XML, SOAP,
WSDL, and UDDI.

It also provides tools for the deployment of Web Services to popular J2EE-based
Web application servers.

Oracle Products
Oracle’s Oracle9i Release 2 application server provides the J2EE-based
infrastructure solution for Web services supporting Web services standards
including SOAP, UDDI, and WSDL.

It also has features that define and coordinate business processes using Web
services integrating legacy applications and back-end systems.
 Sun Products

As part of the Java community process, Sun has already released its Java
and XML technology-based APIs and its implementation referred to as
JAX Pack for developing and testing Java and open standards-based Web
services solutions.

The suite of products of Sun ONE Application Server 7.0, formerly

called iPlanet Application Server 6.0, provide a J2EE- and open
standards-based infrastructure for implementing Web services

Systinet Products

Systinet provides Web services infrastructure and product solutions such

as WASP Server, WASP Developer, and WASP UDDI, which develops
Web services solutions based on industry standards such as XML,
SOAP,WSDL, and UDDI.

Systinet also enables business applications from diverse technologies

such as Java, EJB, CORBA, and Microsoft .NET to be exposed as Web
services over the Internet.
 Key Benefits of Web Services

The key benefits of implementing Web services are as follows:

Provides a simple mechanism for applications to become services that

are accessible by anyone, anywhere, and from any device.

Defines service-based application connectivity facilitating EAI, and intra-

enterprise and inter-enterprise communication.

Defines a solution for businesses, which require flexibility and agility in

application-to-application communication over the Internet

Enables dynamic location and invocation of services through

service brokers (registries).

Enables collaboration with existing applications that are

modeled as services to provide aggregated Web services.
 Known Challenges in Web Services

Web services present some key challenges associated with the mission-critical
business requirements. Some of the key challenges are as follows:
Distributed transactions.
If the environment requires distributed transactions with heterogeneous
resources, it should be studied and tested with standard solutions based on BTP,
WS- Transactions, and WS-Coordination.
Quality of Service (QoS)
In case of a mission-critical solution, the service providers must examine the
reliability and performance of the service in peak load and uncertain conditions
for high availability. The exposed infrastructure must provide load balancing, and
failover and fault tolerance, to resolve these scenarios

Security.
Web services are exposed to the public using http-based protocols. As Web
services is publicly available, it must be implemented using authentication
and authorization mechanisms and using SSLenablingencryption of the
messages for securing the usage. Adopting open security standards like
SAML, XML Encryption, XMLSignature, or XACML may be a solution.
 Web Services Architecture
and Its Core Building Blocks

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

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 communication

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 services 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

To handle these requirements, a typical Web service architectural model

consists of three key logical components as core building blocks
mapping the operational roles and relationships of a Web services
environment
Core Building Blocks
The core building blocks of a typical 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 provide 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 environment by looking
up the services registries to find the required services 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

Web services standards and technologies

• Simple Object Access Protocol (SOAP)

• Web Services Description Language (WSDL)

• Universal Description, Discovery, and Integration (UDDI)

• ebXML
 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 marshaled in a data type and passed in to a SOAP body.
SOAP message using an HTTP post request forsending a
getBookPrice() method with <bookname> as an argument to obtain a
price of a book.
 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

a WSDL example that describes a Web service meant

for obtaining a price of a book using a Get Book Price operation
 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 registered 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
 ebXML

ebXML provides a standard framework for building an electronic

marketplace by enabling the standardization of business
processes, business partner 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

 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.
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.
 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

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 implementation, the client can either send or

receive a document asynchronously 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
 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.

The basic steps of implementing Web services are as follows:

1The 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.

1.1The 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 information 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 description 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.
 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 distributed
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 functionalities of
those underlying applications. The underlying applications can be of any
application implemented in any programming language and running on any
platform.

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.

1.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
2.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.

1.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.

3.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

4. 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.
The Web services container/runtime environment provider generally
provides the tools required for creating SOAP-based services interfaces
from existing applications and generating WSDL-based service
descriptions.
Depending upon the Web services runtime environment, some providers also include
test environments for UDDI and interfaces for publishing services interfaces
The previous steps are usually common at all levels of Web services development,
irrespective of the target application environment such as J2EE, CORBA, Microsoft
.NET, or standalone applications based on Java, C++, Microsoft Visual Basic, and
legacy applications based on, the Mainframe environment. As a result, implementing
Web services unifies J2EE,CORBA, .NET, and other XML-based applications with
interoperability and data sharing.
The figure represents a typical Web services implementation model providing
service- oriented interfaces supporting a variety of back-end application
environments
UNIT 2
 Anatomy of a SOAP
Message
SOAP defines the structure of an XML document, rules, and mechanisms that can be
used to enable communication between applications. It does not mandate a single
programming language or a platform, nor does it define its own language or
platform.
The example shown in Listing 4.1 is a SOAP request/response message for
obtaining book price information from a book catalog service provider. The SOAP
request accepts a string parameter as the name of the book and returns a float as the
price of the book as a SOAP response

In the scenario in Listing 4.1, the SOAP message is embedded in an HTTP request for
getting the book price information from www.wiley.com for the book Developing Java
Web Services.
Listing 4.2 shows the SOAP message embedded in an HTTP response
returning the price of the book

In Listing 4.2, you might have noticed that the SOAP message contains a
SOAP Envelope SOAP-ENV: Envelope as its primary root element, and it relies on
defined “XML Namespaces” commonly identified with a keyword xmlns and specific
prefixes to identify the elements and its encoding rules. All the elements in the
message are associated with SOAP-ENV-defined namespaces
Note that a SOAP application should incorporate and use the relevant SOAP
namespaces for defining its elements and attributes of its sending messages;
likewise, it must be able to process the receiving messages with those specified
namespaces.
These namespaces must be in a qualified W3C XML Schema, which facilitates the
SOAP message with groupings of elements using prefixes to avoid name
collisions.
Usually a SOAP message requires defining two basic namespaces: SOAP
Envelope and SOAP Encoding. The following list their forms in both versions
1.1 and 1.2 of SOAP.
SOAP ENVELOPE
http://schemas.xmlsoap.org/soap/envelope/ (SOAP 1.1)
http://www.w3.org/2001/06/soap-envelope (SOAP 1.2)
SOAP ENCODING
 Structure of a SOAP
message
The structural format of a SOAP message (as per SOAP version 1.1
with attachments )contains the following elements:
Envelope
Header (optional)
Body
Attachments (optional)
Figure 4.1 represents the structure of a SOAP message with attachments. Typically, a
SOAP message is represented by a SOAP envelope with zero or more attachments.
The SOAP message envelope contains the header and body of the message, and the
SOAP message attachments enable the message to contain data, which include
XML and non-XML data (like text/binary files). In fact, a SOAP message package
is constructed using the MIME Multipart/Related structure approaches to separate
and identify the different parts of the message.

SOAP Envelope

The SOAP envelope is the primary container of a SOAP

message’s structure and is the mandatory element of a SOAP
message. It is represented as the root element of the message as
Envelope

it is usually declared as an element using the XML namespace

http://schemas .xmlsoap.org/soap/envelope/. As per SOAP 1.1
specifications, SOAP messages that do not follow this namespace
declaration are not processed and are considered to be invalid. Encoding
styles also can be defined using a namespace under Envelope to
represent the data types used in the message
 SOAP Header

The SOAP header is represented as the first immediate child

element of a SOAP envelope, and it has to be namespace qualified.
In addition, it also may contain zero or more optional child elements, which are referred to
as SOAP header entries. The SOAP encoding Style attribute will be used to define the
encoding of the data types used in header element entries. The SOAP actor attribute and
SOAP must Understand attribute can be used to indicate the target SOAP application
node(Sender/Receiver/Intermediary) and to process the Header entries.

In Listing 4.4, the SOAP header represents a transaction semantics entry

using the SOAP must Understand attribute. The must Understand attribute
is set to “1”, which ensures that the receiver (URI) of this message must
process it.
SOAP Body

A SOAP envelope contains a SOAP body as its child element, and it may contain
one or more optional SOAP body block entries
The Body represents the mandatory processing information or the payload intended
for the receiver of the message.

A Body block of a SOAP message can contain any of the

following: RPC method and its parameters
Target application (receiver) specific data
SOAP fault for reporting errors and status information

Listing 4.5 illustrates a SOAP body representing an RPC call for getting the
book price information from www.wiley.com for the book name
Developing Java Web Services
SOAP Attachments

a SOAP message contains the primary SOAP envelope in an XML

format and SOAP attachments in any data format that can be ASCII or
binary (such as XML or non-text). SOAP attachments are not part of the
SOAP envelope but are related to the message.

As the SOAP message is constructed using a MIME multipart/related

structure, the SOAP attachment part of the message is contained to a
MIME boundary (defined in the Context-Type header). Each MIME part in
the structure of the SOAP message is referenced using either Content-ID
or Content-Location as labels for the part. Both the SOAP header and
body of the SOAP message also can refer to these labels in the message

Each attachment of the message is identified with a Content-ID (typically

an href attribute using a URL scheme) or Content-Location (a URI
reference associated to the attachment).
Listing 4.11 uses “WileyCoverPage.gif” as an attachment and illustrates
the use of the Content-ID (CID) reference in the body of the SOAP 1.1
message using absolute URI-referencing entities labeled for using Content-
Location headers.
SOAP Encoding

The SOAP encoding defines a set of rules for expressing its data types. It is a
generalized set of data types that are represented by the programming languages,
databases, and semi-structured data required for an application. SOAP encoding also
defines serialization rules for its data model using an Encoding Style attribute under
the SOAP-ENV namespace that specifies the serialization rules for a specific
element or a group of elements.

SOAP encoding supports both simple- and compound-type values.

Simple Type Values

The definition of simple type values is based on the “W3C XML Schema, Part -2:
Datatypes” specification. Examples are primitive data types such as string, integer,
decimal, and derived simple data types including enumeration and arrays. The
following examples are a SOAP representation of primitive data types:
<int>98765</int>
<decimal> 98675.43</decimal>
<string> Java Rules </string>
The derived simple data types are built from simple data types and
are expressed in the W3C XML Schema.
Enumeration
Enumeration defines a set of names specific to a base type. Listing 4.12 is
an example of an enumeration data type expressed in a W3C XML Schema

Array of Bytes
Listing 4.13 is an example of an array data type of an array of binary data that
is represented as text using base64 algorithms and expressed using a
W3C XML Schema.
Polymorphic Accessor

The polymorphic accessor enables programming languages to access data types

during runtime. SOAP provides a polymorphic accessor instance by defining an
xsi: type attribute that represents the type of the value.
The following is an example of a polymorphic accessor named price
with a value type of "xsd:float" represented as follows:
<price xsi:type=”xsd:float”>1000.99</price>
And, the XML instance of the price data type will be as follows:
<price>1000.99</price>
Compound Type Values
Compound value types are based on composite structural patterns
that represent member values as structure or array types. The
following sections list the main types of compound type values.

Structure Types
Listing 4.14 is an XML Schema of the Structure data type representing the
“Shipping address” with sub elements like “Street,” “City,” and “State.”
 And, the XML instance of the Shipping Address data type is shown
in
Listing 4.15.

The structure also can contain both simple and complex data type values
that can reference each other (see Listing 4.16). The structure uses the “href” attribute
to reference the value of the matching element.
SOAP Message Exchange Model

Basically, SOAP is a stateless protocol by nature and provides a composable one-

way messaging framework for transferring XML between SOAP applications which
are referred to as SOAP nodes
These SOAP nodes represent the logical entities of a SOAP message path to
perform message routing or processing.

In a SOAP message, SOAP nodes are usually represented with an endpoint URI as
the next destination in the message. In a SOAP message, a SOAP node can be any
of the following:

SOAP sender. The one who generates and sends the message.
SOAP receiver. The one who ultimately receives and processes
the message with a SOAP response, message, or fault.
SOAP intermediary. The one who can play the role of a SOAP
sender or SOAP receiver. In a SOAP message exchange model, there
can be zero or more SOAP intermediaries between the SOAP sender
and receiver to provide a distributed processing mechanism for SOAP
messages.
In a SOAP message exchange model, the SOAP message passes from
the initiator to the final destination by passing through zero to many
intermediaries.

In a SOAP messaging path, the SOAP intermediaries represent certain

functionalities and provide routing to the next message destination

It is important to note that SOAP does not define the actual SOAP
senders, intermediaries, and receivers of the SOAP message along
its message path or its order of destination.

However, SOAP can indicate which part of the message is meant

for processing at a SOAP node

Thus, it defines a decentralized message-exchanging model that

enables a distributed processing in the message route with a
message chain.
Figure 4.2 represents a basic SOAP message exchange model with
different SOAP nodes
SOAP Intermediaries

SOAP defines intermediaries as nodes for providing message processing

and protocol routing characteristics between sending and receiving
applications.

Intermediary nodes reside in between the sending and receiving

nodes and process parts of the message defined in the SOAP header. The
two types of intermediaries are as follows:
Forwarding intermediaries. This type processes the message by describing and
constructing the semantics and rules in the SOAP
header blocks of the forwarded message.
Active intermediaries. This type handles additional processing by
modifying the outbound message for the potential recipient SOAP
nodes with a set of functionalities.
In general, SOAP intermediaries enable a distributed processing
model to exist within the SOAP message exchange model.

By using SOAP intermediaries, features can be incorporated like

store and forward, intelligent routing, transactions, security, and
logging, as well as other value additions to SOAP applications.
SOAP Communication

SOAP is designed to communicate between applications independent of

the underlying platforms and programming languages
To enable communication between SOAP nodes, SOAP supports the
following two types of communication models:

SOAP RPC. It defines a remote procedural call-based synchronous

communication where the SOAP nodes send and receive messages using
request and response methods and exchange parameters and then return
the values.

SOAP Messaging
It defines a document-driven communication where SOAP nodes send and
receive XML-based documents using synchronous and asynchronous
messaging
SOAP RPC

The SOAP RPC representation defines a tightly coupled

communication model based on requests and responses.
Using RPC conventions, the SOAP message is represented by
method names with zero or more parameters and return
values.

Each SOAP request message represents a call method to a remote object in

a SOAP server and each method call will have zero or more parameters

Similarly, the SOAP response message will return the results as return
values with zero or more out parameters.

In both SOAP RPC requests and responses, the method calls are serialized
into XML-based data types defined by the SOAP encoding rules.

Listing 4.24 is an example of a SOAP RPC request making a method

call GetBookPrice for obtaining a book price from a
SOAPservernamespacehttp://www.wiley.com/jws.book.priceList
using a ”bookname”parameter of ”Developing Java Web Services”
The SOAP message in Listing 4.25 represents the SOAP RPC response after
processing the SOAP request, which returns the result of the Get- Book Price
method from the SOAP server namespace http://www.wiley.com/jws.book.priceList
using a “Price” parameter with
“$50” as its value.
SOAP Messaging

SOAP Messaging represents a loosely coupled communication model based on

message notification and the exchange of XML documents.
The SOAP message body is represented by XML documents or literals
encoded according to a specific W3C XML schema, and it is produced and
consumed by sending or receiving SOAP node(s).
The SOAP sender node sends a message with an XML document as its
body message and the SOAP receiver node processes it.
The message contains a header block Inventory Notice and the body
product, both of which are application-defined and not defined by
SOAP.

The header contains information required by the receiver node and

the body contains the actual message to be delivered.
SOAP Security
Security in SOAP messages plays a vital role in access control,
encryption ,and data integrity during communication

using the SOAP headers provides a way to define and add features enabling the
implementation of application-specific security in a form of XML-based
metadata.

The metadata information can be application-specific information

incorporating message security with associated security algorithms
like encryption and digital signatures

More importantly, SOAP supports various transport protocols for

communication, thus it also is possible to incorporate transport protocol-
supported security mechanisms like SSL/TLS for SOAP messages.

It also defines the three security element tags <SOAP-

SEC:Encryption>, <SOAP-
SEC:Signature>, and <SOAP-SEC:Authorization>.
Use of these security tags enables the incorporation of encryption,
digital signatures, and authorization in SOAP messages
SOAP Encryption
The use of XML-based encryption in SOAP permits secure communication and access
control to be implemented by encrypting any element in the SOAP envelope.
The W3C XML Encryption WG (XENC) defines the mechanisms of XML encryption
in the SOAP messages.
In SOAP communication, encryption can be done at the SOAP sender node
or at any of the intermediaries in the message path.
Listing 4.33 is a sample representation of a SOAP message using XML encryption
for encrypting its data elements.
Listing 4.33 illustrates a SOAP message with a <SOAP-SEC: Encryption> header entry
to encrypt data referred to in the SOAP header. It uses a symmetric key for encrypting the
body element referred to in the <xenc:EncryptedData> element.

The <xenc:EncryptedData> element in the header entry provides the reference to the
<xenc:EncryptedData> element and the symmetric key is defined in the
<xenc:EncryptedKey> element.

On the SOAP receiver node, the receiver decrypts each encrypted element by
associating a Decryption-Info URI, which indicates <xenc:DecryptionInfo>
for providing information on how to decrypt it.

SOAP Digital Signature

The use of an XML-based digital signature in SOAP messages provides message

authentication, integrity, and non-repudiation of data during communication.

The SOAP sender node that originates the message applies an XML-based
digital signature to the SOAP body and the receiver node validates the
signature

Listing 4.34 is a sample representation of a SOAP message using XML

digital signatures
Listing 4.34 illustrates a SOAP message with a <SOAP-SEC: Signature> entry
applying an XML-based digital signature for signing data included in the SOAP
envelope.
It uses <ds:CanonicalizationMethod>, <ds:SignatureMethod>, and
<ds:Reference> elements for defining the algorithm methods and signing
information

The <ds:CanonicalizationMethod> refers to the algorithm for canonical zing the

Signed- Info element digested before the signature.

The Signature Method defines the algorithm for converting the canonicalzed
Signed Info as a Signature Value.

SOAP Authorization
Using XML-based authorization in SOAP messages enables the authorization of
the SOAP messages using certificates from the originating SOAP sender nodes
SOAP authorization applies an XML-based digital certificate from an
independent authorization authority to the SOAP message from the sender.

Listing 4.35 is a sample representation of a SOAP message

using an XML-based authorization.
Listing 4.35 illustrates a SOAP message with a <SOAP-SEC: Authorization>entry in
the SOAP header applying an XML-based authorization to authorize the SOAP
message. It uses an <AttributeCert > element to define the certificate from an
independent authorization authority.

And, it can be encrypted using the receiver node or an actor’s public key. On
the SOAP receiving node, the actor uses its private key to retrieve the
certificate.
Building SOAP Web Services

SOAP provides an XML-based communication protocol solution for bridging

disparate applications in a distributed environment using XML-based messaging or by
remotely invoking methods.
From a Web services point of view, it defines and provides the following

A standardized way to transmit data using Internet-based protocols and a

common- wire format (XML) between the Web service provider and its
requestors.

An extensible solution model using an XML-based framework enabling the Web

service providers and requestors to interoperate with each other in a loosely
coupled fashion and without knowing the underlying application architecture
(such as programming languages and operating systems)

This enables the creation of Web services over existing applications without
modifying the underlying applications

In a Web services implementation model, SOAP can be implemented as a

client, as a server application, or both, as follows:
A SOAP-based client application plays the role of a Web services requestor, which
typically handles an XML-based request/response, a message containing a XML document,
parameters required to invoke a remote method, or the calling of a SOAP server
application.

A SOAP client can be a Web server or a traditional application running a SOAP-based

proxy, which send SOAP requests or SOAP messages using HTTP or any other
supporting protocol.
ASOAP server application plays the role of a Web services provider, which
processes the SOAP requests and messages from calling SOAP based clients.

The SOAP server application interacts with its encapsulated applications to

process the requests or messages and then sends a response to the calling SOAP
client

SOAP server applications also can act as SOAP intermediaries, which allows the
extensibility of the application to enable the processing and forwarding of
messages through a series of SOAP nodes or a final destination

In case of acting SOAP intermediaries, the SOAP server application typically works as
a SOAP client application to the final destination of the message
 Developing SOAP Web Services Using Java

SOAP does not mandate a single programming model nor does it define
programming language-specific bindings for its implementation.
It is up to the provider to choose a language and to define the
implementation
of its language-specific bindings.
In this context, to use Java as a language for developing SOAP
applications requires its Java implementation for SOAP specific bindings.
As of today, there are many SOAP application vendors that have made Java-based
SOAP implementations for developing Web applications to Web services.
In general, the use of Java for developing SOAP applications enables
scalable and portable applications to be built that also can interoperate with
heterogeneous applications residing on different platforms by resolving the
platform-specific incompatibilities and other issues

Additionally, having SOAP-based applications that adopt a J2EE-based

infrastructure and component framework allows the inheritance of the
characteristics of J2EE container- based services such as transactions, application
security, and back-end application/databases connectivity
The release of the Java Web Services Developer Pack (JWSDP) also provides a
full-fledged API solution for developing SOAP-based Web services.

A long list of open source communities, Web services platform providers, and J2EE
vendors also have released their SOAP implementations adopting Java platform
and Java based APIs

Developing Web Services Using Apache Axis

Apache Axis is an open-source implementation that provides a Java-based
SOAP implementation for developing Web services.
To implement Web services, it facilitates a SOAP runtime environment and Java-
based API framework for implementing the core components of Web services
adopting compliant standards and protocols.
As a packaged solution, the Apache Axis environment provides
the following:

A SOAP-compliant runtime environment that can be used as a standalone

SOAP server or as a plug-in component in a compliant
Java servlet engine (such as Tomcat, iPlanet, and Weblogic)
An API library and runtime environment for developing SOAP RPC
and SOAP messaging-based applications and services

A transport-independent means for adopting a variety of

transport protocols (such as HTTP, SMTP, and FTP)

Automatic serialization and deserialization for Java objects to

and from XML in SOAP messages
Support for exposing EJBs as Web services, especially the methods
of stateless session EJBs

Tools for creating WSDL from Java classes and vice-versa

Tools for deploying, monitoring, and testing the Web services

 Installing Axis for Web Services
The process of installing Axis for building a Web services environment
is quite simple.
Axis can be installed as part of a Java servlet engine or as a
J2EE-compliant application server, or it also can run as an independent
server.

Because our focus is creating Web services using Axis, we require Axis installation
using a Java servlet engine.

For illustration, we will be using the Apache Tomcat 4.0.3 servlet engine available
for download from
http://jakarta.apache.org/tomcat/index.html.

Now, let’s take a look at the steps involved in installing Axis within
an Apache Tomcat server environment:

1. Download the Apache Axis tool kit (current release) from

http://xml.apache.org/axis/. Unzip (Windows) or untar (UNIX)
the package to your local system directory (for example, d:\
xmlaxis) and set an environment variable as AXIS_HOME
2. Download Apache Tomcat 4.0.3(or current release) from
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/ and
then install it to your local system directory (that is, d:\tomcat4) and
set an environment variable as TOMCAT_HOME. After
installation, start the Tomcat server and ensure that it is working by
locating http://localhost:8080/index.html with your browser. The
browser will display the screen shown in Figure 4.9.
3.Navigate to your Axis installation home directory and copy the axis folder from
AXIS_HOME\webapps\ to TOMCAT_HOME\webapps\
to deploy the Axis libraries as an Axis servlet.

4.To deploy the Axis libraries as a servlet in the Tomcat container, create a context in
the Tomcat server configuration by editing TOMCAT_HOME/conf/server.conf with the
following lines:
<Context path=”/axis” docBase=”axis” debug=”0”
reloadable=”true” crossContext=”true”>
</Context>

5.Add axis-specific supporting class libraries (JARs) in the Tomcat

environment. The required supporting class libraries include the
following:

■■ Apache Xerces parser for Java (Xerces2) with JAXP 1.1

support, which is available for download a http://xml.apache.org
/xerces2-j/index.html. Unzip the download and copy
the xerces.jar file to TOMCAT_HOME\webapps\axis
\WEB-INF\lib.
■■ If your application requires database connectivity or other
application
access, ensure that you copy all of the JDBC drivers
and required class libraries to TOMCAT_HOME\
webapps\axis\WEB-INF\lib.

■■ As part of the kit, Axis provides class libraries for JAXRPC

and JAXM as jaxrpc.jar and saaj.jar. In the case of using JAX-
RPC and JAXM/SAAJ libraries, ensure that these JAR files are
copied to TOMCAT_HOME\common\lib.

6. To test the Axis Web services environment, start the Tomcat

server.
Then, use your Web browser and open the followings URLs:

■■ To confirm installation: http:localhost:8080/axis/index.html

■■ To validate the Axis environment: http://localhost:8080/axis
/happyaxis.jsp
■■ To list the available Axis services: http://localhost:8080/axis
/servlet/AxisServlet
7. To compile and test applications, create a run script (.bat or .sh)
to ensure that the CLASSPATH in the development environment
includes the following:
AXIS_HOME/lib/axis.jar
AXIS_HOME/lib/jaxrpc.jar
AXIS_HOME/lib/saaj.jar
AXIS_HOME/lib/commons-logging.jar
AXIS_HOME/lib/log4j-1.2.4.jar
AXIS_HOME/lib/xmlsec.jar
AXIS_HOME/lib/tt-bytecode.jar
AXIS_HOME/lib/wsdl4j.jar
AXIS_HOME/xerces.jar
AXIS_HOME/<DATABASE/
OTHER_LIBRARIES.jar> DEVELOPMENT_HOME/
Known Limitations of SOAP

Although the SOAP specifications define a promising communication

model for Web services, the following limitations exist that are not
currently addressed by the SOAP specifications:
1. The specification does not address message reliability, secure message
delivery, transactional support, and its communication requirements
of a SOAP implementation.

2.The specification does not address issues like object activation and
object lifecycle management
3.The specification discusses HTTP as the primary transport
protocol but does not discuss the usage of other transport protocols.

4.The specification does not address how to handle SOAP

messages out of a SOAP implementation.

Note that the limitations of SOAP have been currently well addressed
by the ebXML framework as part of the ebXML messaging service,
which complements SOAP and other Web services standards.
UNIT 3
 Web Services Description Language (WSDL)

WSDL in the World of Web Services

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

Once we develop a Web service, we create its WSDL definition. We can

create this definition either manually or by using a tool. Many tools are
available for generating a WSDL definition from existing Java classes,
J2EE components (such as Servlets/EJBs), or from scratch
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 downloading 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

Language and Platform Independency of WSDL

WSDL is capable of describing Web services that are implemented using any
language and deployed on any platform. Thus, WSDL contributes toward
enabling interoperability in the Web service architecture.

In other words, as long as a WSDL definition can be understood and consumed by

the service user, the service user systems can obtain all of the information
necessary to invoke a Web service potentially developed and deployed using a
completely different set of platform tools and servers.
 Anatomy of a WSDL Definition Document

A WSDL definition document consists of the following seven key

structural 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.
<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.
<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
 <portType>.

This element defines the abstract definition of the operations 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.

<binding>

This element specifies a concrete protocol and data format used for
representing the operations and messages defined by a particular <port Type>,
on the wire

<port>

This element specifies an address for binding to the Web service

<service>.

This element aggregates a set of related <port> elements, 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
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>.
WSDL Binding Extensions

WSDL allows user-defined elements, also known as Extensibility Elements,

under various elements defined by a default WSDL namespace.
These elements are commonly used to specify some technology-specific binding,
although they can be used for other purposes as well.
Extensibility elements, when used to specify a technology-specific binding,
are known as WSDL Binding Extensions.
Extensibility elements provide a powerful mechanism for extending
WSDL because they enable support for network and message protocols to
be revised without having to revise the WSDL specification
The base specification of WSDL defines three WSDL binding extensions,
which are as follows
SOAP binding
HTTP GET & POST binding
MIME binding
WSDL Binding Support for Operations

All four types of operations supported by WSDL—one-way, request response,

solicit-response, and notification—represent an abstract notion only.

Binding describes the concrete correlation to these abstract notions. Binding determines
how the messages are actually sent, for instance, within a single communication (for
example, an HTTP request/response) or as two independent communications (for
example, two HTTP requests).
Thus, binding for a specific operation type must be defined in order to successfully
carry out that type of operation.
Note that although the WSDL structure supports the bindings for these four operations,
the WSDL specification defines bindings for only one-way and request-response
operations.
Hence, in order to use WSDL to describe services that support solicit-response and/or
notification types of operations, the communication protocol of the Web service
must define the WSDL binding extensions, thus enabling the use of these operations
 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 component or from scratch.
WSDL compilation
Atypical WSDL compiler would generate the necessary data structures and a
skeleton for the implementation of the service. The generated
implementation skeleton contains all the methods (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.
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.

WSDL in the World of Web Services
WSDL, as we know, is a description language for
Web services. So what does this exactly
mean? 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
Language and Platform Independency of WSDL
WSDL is capable of describing Web services that
are implemented using any language and
deployed on any platform. Thus, WSDL
contributes toward enabling interoperability
in the Web service architecture. In other
words, as long as a WSDL definition can be
understood and consumed by the service user,
the service user systems can obtain all of the
information necessary to invoke a Web service
potentially developed and deployed using a
completely different set of platform tools and
servers.
Anatomy of a WSDL Definition Document
A WSDL definition document consists of the
following seven key structural
elements:
<definitions> , <types>,<message>,
<portType>, <binding>, <port>, <service>.
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. Let’s begin
with the WSDL binding extensions.
The base specification of WSDL defines three
WSDL binding extensions,
• SOAP binding
• HTTP GET & POST binding
• MIME binding
• We will take a look at the most commonly
used WSDL binding extension, the SOAP
binding, in a later section titled SOAP Binding.
SOAP Binding
WSDL 1.1 defines a binding for SOAP 1.1 end points.
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
• <soap:binding>
The <soap:binding> element is defined in WeatherInfo.wsdl as
follows:
<soap:binding style=”document”
transport=”http://schemas.xmlsoap.org/soap/http”/>
The <soap:binding> element says that the binding is bound to
theSOAP protocol format, that is, envelope, header, and body.
However, this element does not give any information about
the format or encoding of the message. This element must be
present whenever describing services that have a SOAP
binding.
UNIT 4
 UDDI
• This chapter covers such description and
discovery aspects of a Webservice. Detailed
information is provided on two mainstream
technologies that are used today for
describing and discovering Web services: the
Web Services Description Language (WSDL)
and Universal Description, Discovery, and
Integration (UDDI).
 Universal Description, Discovery,
and Integration (UDDI)

As already discussed, UDDI technology is the core and one of the

building blocks of Web services apart from SOAP and WSDL.
UDDI enables the businesses providing services (in electronic
form or in any other medium) to register information to
enable the discovery of their services and business profile by
prospective customers and/or partners. Similarly, it enables
businesses to discover other businesses for expanding potential
business partnerships. Thus, UDDI presents businesses with
an opportunity to step into new markets and services. It
powers all kinds of businesses, large, medium, or small, to
accelerate their business presence in this global market.
• UDDI Registries
An implementation of the UDDI specification is termed as a UDDI
registry. UDDI registry services are a set of software
services that provide access to the UDDI registry. Meanwhile,
registry services can perform a plethora of other activities
such as authenticating and authorizing registry requests,
logging regis
Public and Private UDDI Registries
A UDDI registry can be operated in two modes: public mode and
private mode. A public UDDI registry is available for everyone
to publish/query the business and service information on the
Internet. Such public registries can be a logical single system
built upon multiple UDDI registry nodes that have their data
synchronized through replication.try requests, load-balancing
requests, and so on.
A private UDDI registry is operated by a single organization or a
group of collaborating organizations to share the information
that would be available only to the participating bodies.
Private UDDI registries can impose additional security controls to
protect the integrity of the registry data and to prevent access
by unauthorized users. Note that a private node also can
participate in information replication.
A UDDI registry in itself is a Web service. A Web service
consumer queries the UDDI registry using the SOAP API
defined by UDDI specification publishes a WSDL description of
the UDDI registry service.
UDDI Specifications
All versions of the UDDI specifications can be obtained from the
UDDI organization at their Web site at
http://uddi.org/specification.html. TheUDDI 2.0 specification
set includes the following documents:
UDDI replication. The document describes the data replication
process of the UDDI registries. Also, it describes the
programmatic interfaces supported by UDDI for achieving
replication between UDDI registries operated by different
operators.
UDDI operators. This document provides information on the
operational behavior that should be followed by UDDI node
operators. For example, the document defines guidelines that
node operators can follow in order to manage the data of the
UDDI registry node.
Publishing API
The publishing API consists of functions represented by a UDDI
Schema, which defines XML messages that can be used to create,
update, and delete the information present in a UDDI registry. Note
that in order to publish to a UDDI registry, the registry user needs to
be authenticated.
The following is a list of publishing API functions that can be used for
adding/modifying information to a UDDI registry:
■<save_business>
■ <set_publisherAssertions>
■ <add_publisherAssertions>
■ <save_service>
■ <save_binding>
■ <save_tModel>
• Publishing API
• This section will cover all of the XML messages that perform
the functionality of adding/modifying/deleting information
from a UDDI registry. As mentioned earlier, publishing to a
UDDI registry requires an authenticated access. UDDI
specification does not define authentication mechanisms,
and hence, authentication is dependent upon the
implementations of UDDI. Also, a URL different from an
inquiry URL usually handles publishing-related API calls.
Typically, HTTPS is used for carrying publishing call
request/response information.
Registering as a Systinet UDDI Registry User
Anyone can easily register as a Systinet registry user.
Programming Steps for Publishing
The entire publishing logic is provided by the doSubmit() method of the
jws.ch5.SubmitBusiness class, and hence, its implementation is of most interest to
us. The following are the steps of doSubmit():
1. Construct the UDDIApiPublishing object. This is the object that
we will use to actually publish to the registry.
2. Get hold of the authentication token from the registry with the help
of the get_authToken() API call on the UDDIApiPublishing object. Once we have
the authentication token, we should be able to publish to the registry.
3. Create the BusinessEntity structure and populate it with the name and
description of the business to submit. Note that we do not have to create the
key for this business because the registry, upon submitting the business
information, would generate it.
4. Now, get hold of the SaveBusiness object. This object represents a collection of
businesses that we wish to submit at a time. Hence, we will need to add the
BusinessEntity object that we just created to the SaveBusiness object using the
addBusinessEntity() method.
5. Now, publish the business information through a
save_business() call on UDDIApiPublishing object. This
method call takes the SaveBusiness object as an argument
and returns the BusinessDetail object upon completion.
6. After the publishing operation has been executed, discard the
authentication token. Finally, check whether the publishing
operation was successful or not.
Searching Information in a UDDI Registry
Programming Steps for Searching
The entire querying logic is provided by the doSearch() method of the
jws.ch5.SearchBusiness class, and hence, its implementation is of most
interest to us. The following are the steps to implementing a doSearch():
1.Construct the FindBusiness object. This object represents the
criteria for the search operation. Hence, we will need to add our
criteria, that is, the name pattern that the user supplied, using the
addName() method on this object.
2.Construct the UDDIApiInquiry object that we would use for
placing the inquiry call.
3. Finally, invoke the business inquiry operation through the
find
_business() method on the UDDIApiInquiry object. This
method returns a BusinessList object containing the
BusinessInfo structures.
4.Now, check whether the businesses are found matching the given
criteria. If there are matching businesses, we need to traverse
through their BusinessInfo structures and get hold of the name
Java Architecture for XML Binding (JAXB)
• The XMLbinding technology provides application
developers with a way to generate Java objects based
on XML definitions and XML definitions based on Java
objects. The Java Architecture for XMLBinding (JAXB),
formerly known as JCP project Adelard, is a high-level
specification that defines an abstraction for binding
semantics via classes and interfaces. XML data binding
provides a way for applications to work with objects
rather than complex data trees. Converting XML to Java
can be achieved by using parsing (with JAXP) and then
constructing Java objects.
• The idea behind using a standard such as JAXB is to provide
ease of use and performance enhancement. When
developers are faced with the design and implementation
of such solutions, in many cases they find themselves
locked to their homegrown solutions with unnecessary
complexities. This is potentially a maintenance nightmare
where applications do not scale very well due to poor
design decisions. A binding specification aims at taking all
that away from the developer by implementing the various
techniques in the parser where the classes are generated. It
provides a standardized way to validate documents by
defining the XML schema and data type mapping
definitions to enforce correctness.
• XMLbinding using CASTOR is done with the following steps:
• 1. Create a W3C XMLschema defining the data structure,
data types, and semantics of the XMLdata instance used in
the application. In a Java class, it corresponds to a class
variable or a property using accessor methods.
• 2. Using a CASTOR source code generator, transform
the XMLSchema to bind Java objects.
• 3. Using the CASTOR implementation enables the binding
Java objects to be transformed into XMLinstances
(marshalling), and the XML instances then can be
transformed into binding Java objects (unmarshalling)
dynamically.
• JAX-RPC is quite typical to Java Remote Method
Invocation (RMI),which handles RPC mechanisms by
passing serialized Java objects between Java
applications in a distributed computing environment;
whereas JAXRP uses SOAP-based RPC and WSDL
mechanisms to invokeWeb services
• Building RPC Web Services with JAX-RPC
• running on heterogeneous environments. More
importantly, JAX-RPC hides all of the complexities of
the underlying SOAP packaging and messaging by
providing the required mapping between Java and
XML/WSDL.
 CASTOR provides a full-fledged Java object and XMLattribute mapping, which enables
you to cast the data in the XMLformat to the proper Java type and vice-versa. The
complete list of supported Java object types and XMLSchema attributes are available at
http://castor.exolab.org/xml-mapping.html.
Figure 8.10 XML binding life cycle.
• Currently, the JAX-RPC 1.0 is fully compliant with the
SOAP 1.1 protocol and WSDL specifications and
supports HTTP as its primary transport protocol.
• This helps the Java Web services developers write JAX-
RPC-based Web services applications with minimal
effort and little understanding of SOAP RPC. In a Web
services business context, using JAX-RPC the service
• requestor and service provider can execute SOAP-
based requests and responses and exchange XML as
parameters or return values.
• JAXR is a standard Java API for use in registering/publishing and
discovering/querying Web services from XML-based registries such as
UDDI and ebXML Registry/Repository. JAXR is an integral part of the
J2EE 1.4 platform, which is due to be released in early 2003.
JAXR does not define any new registry standard, rather it defines a
Java API for performing registry operations over a diverse set of
registries.
• JAXR also performs a unification of diverse information models of various
registries, so that regardless of the registry in use, the applications can use
the same code for managing registry information. In the next section, we
will examine the architecture of JAXR as well as its architectural
components.Visit the following site to download the final JAXR draft
specification: http://java.sun.com/xml/downloads/jaxr.html
• JAXM Application Architecture represents a JAXM-based application
architecture and its core elements. Atypical JAXM application
architecture consists of the following elements: JAXM clients. JAXM
clients are JAXM-based application components that send and
receive JAXM messages. The JAXM clients (senders and receivers)
can run using a JAXM provider or without a provider. JAXM clients
using a provider connection can send and receive messages
asynchronously as one-way transmissions. AJAXM client also can
take advantage of the provider-offered features like message
reliability and ensured delivery. In the case of using JAXM without a
provider, the JAXM client can send and receive messages as
requests and responses over a SOAPconnection. In general, a JAXM
receiver client does not require a JAXM provider.
• Introduction to JAXR
• JAXR is a standard Java API for use in registering/publishing and
discovering/querying Web services from XML-based registries such
as UDDI and ebXML Registry/Repository. JAXR is an integral part of
the J2EE 1.4 platform, which is due to be released in early 2003.
JAXR does not define any new registry standard, rather it defines a
Java API for performing registry operations over a diverse set of
registries. JAXR also performs a unification of diverse information
models of various registries, so that regardless of the registry in
use, the applications can use the same code for managing registry
information. In the next section, we will examine the architecture of
JAXR as well as its architectural components. Visit the following site
to download the final JAXR draft specification:
http://java.sun.com/xml/downloads/jaxr.html
JAXR Architecture
JAXR Architectural Components JAXR architecture involves three main components:
registry provider, JAXR provider, and JAXR client. Each of these components are
discussed in the paragraphs that follow.
Registry Provider A registry provider actually implements the registry standard such
as UDDI, ebXML registry/repository, or OASIS registry. A registry provider may or may
not provide implementation for JAXR.
JAXR Provider JAXR provider implements the JAXR specification. A JAXR application/
JAXR client would access the registry through the JAXR provider. There are three
categories of JAXR providers: JAXR pluggable providers, registryspecific providers, and
JAXR bridge providers. Each of these is described in the paragraphs that follow.
XML Signatures
The XML Signature specification, in its very simplest
form, provides a mechanism for applying digital
signatures to XML documents and other Internet
resources and encoding those signatures as XML. The
goal behind using XML in digital signatures is to provide
strong integrity for message authentication, signer
authentication, and non-repudiation services for data of
any type, no matter if this data is located within the
XMLdocument that bears the digital signature or
elsewhere. The XMLSignature specification has been
finalized and was developed at W3C. More information
on XMLSignature and its related specifications can be
found at www.w3.org/Signature. Now, let’s begin by
looking at the different types of XMLSignatures.
Types of XML Signatures There are three types of
signatures supported by the XMLSignature
specification: enveloped
signatures, and signatures,
detached signatures. Eachenveloping
of these
types will be discussed in the following sections.
Enveloped Signatures With enveloped signatures, the
signature is over the XMLcontent that contains the
signature as an element. The root XML document
element provides the content. Obviously, enveloped
signatures must take care not to include their own
value in the calculation of the signature value. Listing
## shows an example of an enveloped signature.
<doc Id=”doc0”> <elem/> <Signature> ... <Reference
URI=”doc0”/> ... </Signature> </doc>
• Detached Signatures With detached signatures, the signature
is over the content external to the <Signature> element, and
this external content is identified via a URI or transform.
Consequently, the signature is “detached” from the content it
signs. This definition typically applies to separate data objects,
but it also includes the instance where the Signature and data
object reside within the same XMLdocument but are sibling
elements. Listing 13.6 is an example of a detached signature.
• <doc>
• <Signature> ... <Reference URI=
“http://www.ach.com/fundstransfer/fundstransferproc.html”
/> ... </Signature> <elem/> </doc>
• detached signature structure.
• XML Signature Syntax Now, let’s take a look at some of
the common elements that comprise the XMLSignature
syntax in this section.
• <Signature> Element The <Signature> element is a
parent element of XML Signature. It identifies a
complete XML Signature within a given context. It
contains the sequence of child elements: <SignedInfo>,
<SignatureValue>, <KeyInfo>, and <Object>. Also, an
optional Id attribute can be applied to the <Signature>
element as an identifier. This is useful in the case of
multiple <Signature> instances within a single context.
• XML Key Management Specification (XKMS)
• XMLKey Management Specification is the next step in
the evolution of the Public Key Infrastructure (PKI). PKI
has long been used to mitigate the risks of automated
electronic business environments. However, PKI has
proven to be quite difficult to implement effectively.
Interoperability is another problem that has almost
always existed in the PKI world. However, these
problems are small enough to stop us from using PKI
when we take into consideration the huge promise of
PKI, that is, the establishment of trust in the electronic
world, which is key to the success of e-commerce and
Web services. XKMS is positioned exactly to solve these
issues of PKI, making it even more easy to deploy and
ubiquitous. XKMS combines the interoperability of
XMLwith the security of PKI to provide an easy method
of securing PKI-based applications
• . XKMS presents a model wherein applications using PKI do
not have to deploy the infrastructure locally. Rather, they
can send XML requests to PKI components hosted by a trust
services provider, who would actually execute those PKI
requests. These requests may be for issuing a certificate or
retrieving/creating a certificate, key, or revocation of a
certificate. Thus, XKMS provides a very good opportunity
for moving the complexity of a PKI to trust processing
centers, such as Verisign, Entrust, and so forth. This means
that applications and Web services relying on XKMS do not
have to deploy any PKI software on their systems, rather
they would issue XMLrequests to the Web services hosted
by trust services providers. In fact, Verisign happens to be
one of the first such trust services providers. They have
hosted Web services that can service XKMS requests. These
XKMS Web services have been hosted at
http://xkms.verisign.com
 XKMS Components
• XMLKey Information Service Specification (X-
KISS). X-KISS defines a protocol that Web
services can use to delegate the processing of
key information associated with an
XMLsignature, XML encryption, or any other
public key, to a trust services provider Web
service. Its functions mainly include locating a
required public key and describing the
information that binds, such as a key to the
owner of its corresponding private key.
• XMLKey Registration Service Specification (X-
KRSS). X-KRSS defines a protocol that a Web
service can use to register a key pair supplying
the proper information pertaining to the
holder of that key pair. That key pair then
would be used in the subsequent requests
made using an X-KISS protocol.