Web Services can convert your applications into Web-applications.

Web Services are published, found, and used through the Web.

What You Should Already Know

Before you continue, you should have a basic understanding of the following:

 HTML
 XML

If you want to study these subjects first, find the tutorials on our Home page.

What are Web Services?

 Web services are application components

 Web services communicate using open protocols
 Web services are self-contained and self-describing
 Web services can be discovered using UDDI
 Web services can be used by other applications
 XML is the basis for Web services

How Does it Work?

The basic Web services platform is XML + HTTP.

XML provides a language which can be used between different platforms and
programming languages and still express complex messages and functions.

The HTTP protocol is the most used Internet protocol.

Web services platform elements:

 SOAP (Simple Object Access Protocol)

 UDDI (Universal Description, Discovery and Integration)
 WSDL (Web Services Description Language)
 Interoperability has Highest Priority
 When all major platforms could access the Web using Web browsers, different
platforms could interact. For these platforms to work together, Web-applications
were developed.
 Web-applications are simple applications that run on the web. These are built
around the Web browser standards and can be used by any browser on any
platform.


 Web Services take Web-applications to the Next Level

 By using Web services, your application can publish its function or message to
the rest of the world.
 Web services use XML to code and to decode data, and SOAP to transport it
(using open protocols).
 With Web services, your accounting department's Win 2k server's billing system
can connect with your IT supplier's UNIX server.


 Web Services have Two Types of Uses

 Reusable application-components.
 There are things applications need very often. So why make these over and over
again?
 Web services can offer application-components like: currency conversion,
weather reports, or even language translation as services.
 Connect existing software.
 Web services can help to solve the interoperability problem by giving different
applications a way to link their data.
 With Web services you can exchange data between different applications and
different platforms

SOAP

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

2. SOAP is XML. That is, SOAP is an application of the XML specification.

3. Although SOAP can be used in a variety of messaging systems and can be

delivered via a variety of transport protocols, the initial focus of SOAP is remote
procedure calls transported via HTTP.

4. SOAP enables client applications to easily connect to remote services and invoke
remote methods.

5. Other frameworks, including CORBA, DCOM, and Java RMI, provide similar
functionality to SOAP, but SOAP messages are written entirely in XML and are
therefore uniquely platform- and language-independent.
SOAP Message Structure

SOAP message is an ordinary XML document containing the following elements.

 Envelope: ( Mandatory )
Defines the start and the end of the message.

 Header: ( Optional )
Contains any optional attributes of the message used in processing the message,
either at an intermediary point or at the ultimate end point.

 Body: ( Mandatory )
Contains the XML data comprising the message being sent.

 Fault: ( Optional )
An optional Fault element that provides information about errors that occurred
while processing the message

A SOAP Message Structure

<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<SOAP-ENV:Header>
...
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>

...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP_ENV:Envelope>

SOAP envelope element:

The SOAP envelope indicates the start and the end of the message so that the receiver
knows when an entire message has been received. The SOAP envelope solves the
problem of knowing when you're done receiving a message and are ready to process it.
The SOAP envelope is therefore basic ally a packaging mechanism

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<soap:Header>
<m:Trans

xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234</m:Trans>
</soap:Header>

<soap:Body>
<m:GetPrice
<m:Quotation>This is Qutation</m:Quotation>
After <m:GetPrice>
xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
SOAP Header Element
The optional</m:GetPrice>
Header element offers a flexible framework for specifying additional
</soap:Body>
application-level requirements. For example, the Header element can be used to specify
a digital signature for password-protected services; likewise, it can be used to specify
</soap:Envelope>
an account number for pay-per-use SOAP services.

SOAP Header element can have following two attributes

 Actor attribute:
The SOAP protocol defines a message path as a list of SOAP service nodes. Each
of these intermediate nodes can perform some processing and then forward the
message to the next node in the chain. By setting the Actor attribute, the client
can specify the recipient of the SOAP header.

 MustUnderstand attribute
Indicates whether a Header element is optional or mandatory. If set to true ie. 1
 the recipient must understand and process the Header attribute according to its
defined semantics, or return a fault.

SOAP Body Element

The SOAP body is a mandatory element which contains the application-defined XML
data being exchanged in the SOAP message. The body must be contained within the
envelope and must follow any headers that might be defined for the message. The
body is defined as a child element of the envelope, and the semantics for the body are
defined in the associated SOAP schema.

The example above requests the quotation of computer sets. Note that the m:GetPrice
and the Item elements above are application-specific elements. They are not a part of
the SOAP standard.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<soap:Body>
<m:GetPriceResponse
xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
The Price service might be implemented using an EJB running in an application server;
</m:GetPriceResponse>
if so, the SOAP processor would be responsible for mapping the body information as
</soap:Body>
parameters into and out of the EJB implementation of the GetPriceResponse service.
The SOAP processor could also be mapping the body information to a .NET object, a
</soap:Envelope>
CORBA object, a COBOL program, and so on.

WSDL

Web Services Description Language is the standard format for describing a web service
in XML format.

WSDL is very easy to learn and very important for Web Services.

WSDL Abstract:
  WSDL stands for Web Services Description Language
 WSDL is an XML based protocol for information exchange in decentralized and
distributed environments.
 WSDL is the standard format for describing a web service.
 WSDL definition describes how to access a web service and what operations it
will perform.
 WSDL is a language for describing how to interface with XML-based services.
 WSDL is an integral part of UDDI, an XML-based worldwide business registry.
 WSDL is the language that UDDI uses.
 WSDL was developed jointly by Microsoft and IBM.
 WSDL is pronounced as 'wiz-dull' and spelled out as 'W-S-D-L'

WSDL Usage:

WSDL is often used in combination with SOAP and XML Schema to provide web services
over the Internet. A client program connecting to a web service can read the WSDL to
determine what functions are available on the server. Any special datatypes used are
embedded in the WSDL file in the form of XML Schema. The client can then use SOAP
to actually call one of the functions listed in the WSDL.

The WSDL Document Structure

  Definition: element must be the root element of all WSDL documents. It
defines the name of the web service, declares multiple namespaces used
throughout the remainder of the document, and contains all the service elements
described here.

 Data types: the data types - in the form of XML schemas or possibly some
other mechanism - to be used in the messages

 Message: an abstract definition of the data, in the form of a message presented

either as an entire document or as arguments to be mapped to a method
invocation.

 Operation: the abstract definition of the operation for a message, such as

naming a method, message queue, or business process, that will accept and
process the message

 Port type : an abstract set of operations mapped to one or more end points,
defining the collection of operations for a binding; the collection of operations,
because it is abstract, can be mapped to multiple transports through various
bindings.

 Binding: the concrete protocol and data formats for the operations and
messages defined for a particular port type.

 Port: a combination of a binding and a network address, providing the target

address of the service communication.

 Service: a collection of related end points encompassing the service definitions

in the file; the services map the binding to the port and include any extensibility
definitions.

In addition to these major elements, the WSDL specification also defines the following
utility elements:

 Documentation: element is used to provide human-readable documentation

and can be included inside any other WSDL element.

 Import: element is used to import other WSDL documents or XML Schemas.

NOTE: WSDL parts usually are generated automatically using Web services-aware
tools.
Analysis of the Example

 Definition : DefinitionsName

 Type : Using built-in data types and they are defined in XMLSchema.

 Message :
1. getSummary : firstName parameter
2. getSummaryResponse: greeting return value

 Port Type: getSummary operation that consists of a request and response

service.

 Binding: Direction to use the SOAP HTTP transport protocol.

 Service: Service available at http://www.examples.com/SayHello/.

 Port: Associates the binding with the URI

http://localhost:8090/weather/WeatherSummary/ where the running service can
be accessed.

WSDL Definition Element

The <definition> element must be the root element of all WSDL documents. It defines
the name of the web service.

The definitions element specifies that this document is the DefinitionsName

 The definitions element specifies a targetNamespace attribute. The

targetNamespace is a convention of XML Schema that enables the WSDL
document to refer to itself. In this example we have specified a targetNamespace
of NamespaceURI.
 The definition element specifies a default namespace:
xmlns=http://schemas.xmlsoap.org/wsdl/. All elements without a
namespace prefix, such as message or portType, are therefore assumed to be
part of the default WSDL namespace.
WSDL Types Element
 Web service needs to define its inputs and outputs and how they are mapped
into and out of services. WSDL <types> element take care of defining the data
types that are used by the web service. Types are XML documents, or document
parts.
 The types element describes all the data types used between the client and
server

Data types address the problem of how to identify the data types and format you intend
to use with your Web services. Type information is shared between sender and
receiver. The recipients of messages therefore need access to the information you used
to encode your data and must understand how to decode the data.

WSDL Message Element

 The <message> element describes the data being exchanged between the Web
service providers and consumers.
 Each Web Service has two messages: input and output.
 The input describes the parameters for the Web Service and the output describes
the return data from the Web Service.
 Each message contains zero or more <part> parameters, one for each
parameter of the Web Service's function.
 Each <part> parameter associates with a concrete type defined in the <types>
container element.

Here, two message elements are defined. The first represents a request message
getSummary, and the second represents a response message
getSummaryResponse.

Each of these messages contains a single part element. For the request, the part
specifies the function parameters; in this case, we specify a single zipcode parameter.
For the response, the part specifies the function return values; in this case, we specify a
single return return value.
WSDL portType Element
The <portType> element combines multiple message elements to form a complete
oneway or round-trip operation.

For example, a <portType> can combine one request and one response message into a
single request/response operation. This is most commonly used in SOAP services. A
portType can define multiple operations.

The portType element defines a single operation, called WeatherSummary.

The operation itself consists of a single input message getSummary

The operation itself consists of a single output message getSummary Response

Patterns of Operation

WSDL supports four basic patterns of operation:

One-way :
The service receives a message. The operation therefore has a single input element. The grammar
for a one-way operation is:
<wsdl:definitions .... > <wsdl:portType .... > *
<wsdl:operation name="nmtoken">
<wsdl:input name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

Request-response:
The service receives a message and sends a response. The operation therefore has one input
element, followed by one output element. To encapsulate errors, an optional fault element can
also be specified. The grammar for a request-response operation is:
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
</wsdl:portType >
 </wsdl:definitions>

Solicit-response:
The service sends a message and receives a response. The operation therefore has one output
element, followed by one input element. To encapsulate errors, an optional fault element can also
be specified. The grammar for a solicit-response operation is:
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

Notification :
The service sends a message. The operation therefore has a single output element. Following is
the grammer for a notification operation:
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken">
<wsdl:output name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

WSDL Binding Element

 The <binding> element provides specific details on how a portType operation
will actually be transmitted over the wire.
 The bindings can be made available via multiple transports, including HTTP GET,
HTTP POST, or SOAP.
 The bindings provide concrete information on what protocol is being used to
transfer portType operations.
 The bindings provide information where the service is located.
 For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP
messages on top of HTTP protocol.
 You can specify multiple bindings for a single portType.
The binding element has two attributes - the name attribute and the type attribute.

<binding name="Hello_Binding" type="tns:Hello_PortType">

<binding type=“dictionaryWords"
name="b1">
<soap:binding style="document“
transport=

"http://schemas.xmlsoap.org/soap/ht
tp" />
<operation>
<soap:operation

soapAction="http://example.com/getT
SOAP Binding
erm"/>
WSDL 1.1 includes built-in extensions for SOAP 1.1. This enables you to specify
SOAPspecific details,<input> <soap:body
including SOAP headers, SOAP encoding styles, and the
SOAPAction HTTP header. The SOAP extension elements include:
use="literal"/> </input>
soap:binding <output> <soap:body
This element use="literal"/> </output>
indicates that the binding will be made available via SOAP. The style
</operation>
attribute indicates the overall style of the SOAP message format. A style value of rpc
specifies an RPC format.
</binding>
The transport attribute indicates the transport of the SOAP messages. The value
http://schemas.xmlsoap.org/soap/http indicates the SOAP HTTP transport, whereas
http://schemas.xmlsoap.org/soap/smtp indicates the SOAP SMTP transport.
soap:operation
This element indicates the binding of a specific operation to a specific SOAP
implementation. The soapAction attribute specifies that the SOAPAction HTTP header
be used for identifying the service.

soap:body
This element enables you to specify the details of the input and output messages. In
the case of HelloWorld, the body element specifies the SOAP encoding style and the
namespace URN associated with the specified service.

WSDL Ports Element

A <port> element defines an individual endpoint by specifying a single address for a
binding.

 The port element has two attributes - the name attribute and the binding
attribute.
 The name attribute provides a unique name among all ports defined within in the
enclosing WSDL document.
 The binding attribute refers to the binding using the linking rules defined by
WSDL.
 Binding extensibility elements (1) are used to specify the address information for
the port.
 A port MUST NOT specify more than one address.
 A port MUST NOT specify any binding information other than address
information.

WSDL Service Element

 The <service> element defines the ports supported by the Web service. For each
of the supported protocols, there is one port element. The service element is a
collection of ports.
 Web service clients can learn from the service element where to access the
service, through which port to access the Web service, and how the
communication messages are defined.
  The service element includes a documentation element to provide human-
readable documentation.

The binding attributes of port element associate the address of the service with a
binding element defined in the Web service

UDDI

UDDI is an XML-based standard for describing, publishing, and finding Web services.

UDDI stands for Universal Description, Discovery and Integration

UDDI has two parts:

 A registry of all a web service's metadata including a pointer to the WSDL

description of a service

 A set of WSDL port type definitions for manipulating and searching that registry

 A services registry and directory

o Essential for dynamic usage of web services

 Platform-independent framework for

o describing services,

o discovering services, and

o integrating services by using the Internet.

UDDI roles

• Service Registry

– Provides support for publishing and locating services

• Analogous to yellow pages

• Service Provider

– Provides business services

 – Publishes availability of these services through a registry

• Service Requestor

– Finds required services in the Service Registry

– Binds to services from Service Provider

Consider a company XYZ wants to register its contact information, service description,
and online service access information with UDDI. The following steps are necessary:

1. Choose an operator with which to work. Each operator has different terms and
conditions for authorizing access to its replica of the registry.

2. Build or otherwise obtain a UDDI client, such as those provided by the operators.

3. Obtain an authentication token from the operator.

4. Register information about the business. Include as much information as might

be helpful to those searching for matches.

5. Release the authentication token.

6. Use the inquiry APIs to test the retrieval of the information, including binding
template information, to ensure that someone who obtains it can use it
successfully to interact with your service.

7. Fill in the tModel information in case someone wants to search for a given
service and find your business as one of the service providers.

8. Update the information as necessary to reflect changing business contact

information and new service details, obtaining and releasing a new
authentication token from the operator each time. Whenever you need to update
 or to modify the data you've registered, you have to go back to the operator with
which you entered the data.

The following examples how the XYZ Company would register its information and how a
distributor interested in carrying the XYZ's product line might find information about
how to contact the company and place an order, using the XYZ.com Web services.

Creating Registry:

After obtaining an authentication token from one of the operators-Microsoft, for

example-the XYZ.com developers decide what information to publish to the registry and
use one of the UDDI tools provided by Microsoft. If necessary, the developers can also
write a Java, C#, or VB.NET program to generate the appropriate SOAP messages.
Here is an example.

Retrieving Information:

After XYZ Company has updated its UDDI entry with the relevant information,
companies that want to become XYZ distributors can look up contact information in the
UDDI registry and obtain the service descriptions and the access points for the two Web
services that XYZ.com publishes for online order entry: preseason bulk orders and in-
season restocking orders.

Java APIs for XML Handling

• JAXP

– Java API for XML Processing

– Processes XML documents using various parsers

• JAX-RPC

– Java API for XML-based RPC

– Sends SOAP method calls to remote parties over the internet and receives
the results

• JAXM

– Java API for XML Messaging

– Sends SOAP messages over the Internet

 • JAXR

– Java API for XML Registries

– Provides a standard way to access business registries and share

information

Simplified in JavaEE

• Java API for XML Web Services - JAX-WS

• Java API for XML Schema / DTD – JAXB