What is a Web Service?

Web services constitute a distributed computer architecture made up of many different computers trying
to communicate over the network to form one system.
A Web service contains some number of classes, interfaces, enumerations and structures that provide
black box functionality to remote clients. Web services typically define business objects that execute a
unit of work (e.g., perform a calculation, read a data source, etc.) for the consumer and wait for the next
request. Web service consumer does not necessarily need to be a browser-based client. Console-based
and Windows Forms-based clients can consume a Web service. In each case, the client indirectly
interacts with the Web service through an intervening proxy. The proxy looks and feels like the real
remote type and exposes the same set of methods. Under the hood, the proxy code really forwards the
request to the Web service using standard HTTP or optionally SOAP messages.

Why you need to learn web services:

Reuse already developed (old) functionality into new software:
Lets understand with very simple example. Lets say you are developing a finance
software for a company on java and you have old .net software which manages
salary of employees. So rather then developing new software for employee part,
you can use old software and for other parts like infrastructure you can develop
your own functionalities.
Usability:
Web Services allow the business logic of many different systems to be exposed over
the Web. This gives your applications the freedom to chose the Web Services that
they need. Instead of re-inventing the wheel for each client, you need only include
additional application-specific business logic on the client-side. This allows you to
develop services and/or client-side code using the languages and tools that you
want.
Interoperability:
This is the most important benefit of Web Services. Web Services typically work
outside of private networks, offering developers a non-proprietary route to their
solutions.Web Services also let developers use their preferred programming
languages. In addition, thanks to the use of standards-based communications
methods, Web Services are virtually platform-independent.
Loosely Coupled:
Each service exists independently of the other services that make up the
application. Individual pieces of the application to be modified without impacting
unrelated areas.

Ease of Integration:
Data is isolated between applications creating silos. Web Services act as glue
between these and enable easier communications within and across organizations.
Deploy ability:
Web Services are deployed over standard Internet technologies. This makes it
possible to deploy Web Services even over the fire wall to servers running on the
Internet on the other side of the globe. Also thanks to the use of proven community
standards, underlying security (such as SSL) is already built-in.
Simple Object Access Protocol (SOAP)
Simple Object Access Protocol (SOAP) is a standard protocol specification for
message exchange based on XML. Communication between the web service and
client happens using XML messages.
Simple web service architecture has two components

Client

Service provider

So as in above diagram, how client will communicate to service provider. So in order

to communicate client must know some information for e.g.

Location of web services server

Functions available, signature and return types of function.

Communication protocol

Input output formats

Service provider will create a standard XML file which will have all above
information. So If this file is given to client then client will be able to access web
service. This XML file is called WSDL.
What is WSDL?
WSDL stands for Web Service Description Language. It is an XML file that describes
the technical details of how to implement a web service, more specifically the URI,
port, method names, arguments, and data types. Since WSDL is XML, it is both
human-readable and machine-consumable, which aids in the ability to call and bind
to
services dynamically using this WSDL file we can understand things like,

Port / Endpoint URL of the web service

Input message format

Output message format

Security protocol that needs to be followed

Which protocol the web service uses

Elements of WSDL

Description:
It is the root element of a WSDL 2.0 file. It usually contains a set of name space
declarations which are used throughout the WSDL file.
Types:
The WSDL types element describes the data types used by your web service.Data
types are usually specified by XML schema.It can be described in any language as
long as your web services API supports it.
Binding:
The WSDL binding element describes how your web service is bound to a protocol.
In other words, how your web service is accessible. To be accessible, the web
service must be reachable using some network protocol. This is called "binding" the
web service to the protocol.

Interface:
The WSDL interface element describes the operations supported by your web
service.It is similar to methods in programming language.Client can only call one
opertion per request.
Service:
It describes the endpoint of your web service. In other words, the address where the
web service can be reached.
Endpoint:
The endpoint element describes the address of the web service. The endpoint
binding attribute describes what binding element this endpoint uses.i.e. protocol
with which you will access web service. The address attribute describes the URI
at which you can access the service.
Message:
The message element describes the data being exchanged between the Web
service providers and consumers.
Sample WSDL file:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://DefaultNamespace"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://DefaultNamespace" xmlns:intf="http://DefaultNamespace"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.4
Built on Apr 22, 2006 (06:55:48 PDT)-->
<wsdl:types>
<schema elementFormDefault="qualified" targetNamespace="http://DefaultNamespace"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="details">
<complexType>
<sequence>
<element name="name" type="xsd:string"/>
<element name="age" type="xsd:string"/>
<element name="Address" type="xsd:string"/>
<element name="DOB" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="detailsResponse">
<complexType>
<sequence>
<element name="detailsReturn" type="xsd:string"/>
</sequence>
</complexType>
</element>

</schema>
</wsdl:types>
<wsdl:message name="detailsRequest">
<wsdl:part element="impl:details" name="parameters">
</wsdl:part>
</wsdl:message>
<wsdl:message name="detailsResponse">
<wsdl:part element="impl:detailsResponse" name="parameters">
</wsdl:part>
</wsdl:message>
<wsdl:portType name="MyDetails">
<wsdl:operation name="details">
<wsdl:input message="impl:detailsRequest" name="detailsRequest">
</wsdl:input>
<wsdl:output message="impl:detailsResponse" name="detailsResponse">
</wsdl:output>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="MyDetailsSoapBinding" type="impl:MyDetails">
<wsdlsoap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="details">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="detailsRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="detailsResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>

</wsdl:operation>
</wsdl:binding>
<wsdl:service name="MyDetailsService">
<wsdl:port binding="impl:MyDetailsSoapBinding" name="MyDetails">
<wsdlsoap:address
location="http://localhost:8001/PankajSOAPServices/services/MyDetails"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Universal Description, Discovery and Integration (UDDI):

UDDI stands for Universal Description, Discovery and Integration.It is a directory
service. Web services can register with a UDDI and make themselves available
through it for discovery

Web service design approaches:

Contract last or Bottom up approach:
When using contract last approach,you first write your java code then you create
web service contract(WSDL) .There are various kinds of tools which can generate
WSDL on the basis of java code.
Contract first or Top Down Approach :
It is reverse of contract first Here you first define web service contract. You define all
the elements of WSDL first then after that you create your java logic.

Ways to access web service:

There are two ways to access web service.

If Service provider knows client: If service provider knows its client then it
will provide its wsdl to client and client will be able to access web service.

Service providers register its WSDL to UDDI and client can access it
from UDDI: UDDI stands for Universal Description, Discovery and
Integration. It is a directory service. Web services can register with a UDDI
and make themselves available through it for discovery. So following steps
are involved.
o

Service provider registers with UDDI.

Client searches for service in UDDI.

UDDI returns all service providers offering that service.

Client chooses service provider

o

UDDI returns WSDL of chosen service provider.

Using WSDL of service provider, client accesses web service.

Web Services Technologies and Tools

2. Apache Axis is an implementation of the SOAP submission to W3C.
3. From the draft W3C specification:SOAP is a lightweight protocol for exchanging structured information in a decentralized,
distributed environment. It is an XML based protocol that consists of three parts: an envelope that
defines a framework for describing what is in a message and how to process it, a set of encoding
rules for expressing instances of application-defined data types, and a convention for
representing remote procedure calls and responses.
4. Apache Axis is an Open Source SOAP server and client. SOAP is a mechanism for interapplication communication between systems written in arbitrary languages, across the Internet.
SOAP usually exchanges messages over HTTP: the client POSTs a SOAP request, and receives
either an HTTP success code and a SOAP response or an HTTP error code.

Commands
(1). How to check the connection/AdminClient on given port
java org.apache.axis.client.AdminClient -p 8001 deploy.wsdd
Above command try to connect to your tomcat on 8001 port configuration

(2). WSDL2Java
java org.apache.axis.wsdl.WSDL2Java CustomObject.wsdl.xml -v -o src -p
pankaj_file

Understanding SOAP
An example SOAP message
Example 1)

<soap:Envelope>
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>Client</faultstring>
<detail>
<ErrorCode>ABC-01001</ErrorCode>
<ErrorMessage>An invalid command was specified</ErrorMessage>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Example 2)
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
</env:Header>
<env:Body>
<cms:getNumberOfArticles xmlns:cms="http://www.daily-moon.com/cms">

<cms:category>classifieds</cms:category>
<cms:subcategory>forsale</cms:subcategory>
</cms:getNumberOfArticles>
</env:Body>
</env:Envelope>

In example 2 there are two different "prefixes", each of which corresponds to a particular namespace. In this
case, we are distinguishing the SOAP "envelope" from the actual payload.

The SOAP envelope

The basic unit of a web service message is the actual SOAP envelope. This is an XML document that includes all of
the information necessary to process the message.

An example SOAP envelope

<?xml
version='1.0' ?>
<env:Envelope
xmlns:env="htt
p://www.w3.org/
2003/05/SOAPenvelope">
<env:Header>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope
>

In this case, you have a simple Envelope, with the namespace specified as SOAP version 1.2. It includes two sub
elements, aHeader and a Body. Let's look at what each of those pieces do.

The SOAP header

The Header in a SOAP message is meant to provide information about the message itself, as opposed to
information meant for the application. For example, the Header might include routing information, as it does in this
example .

Routing information in the Header

<?xml
version='1.0' ?>
<env:Envelope
xmlns:env="htt
p://www.w3.org/
2003/05/SOAPenvelope">
<env:Header>
<wsa:ReplyTo
xmlns:wsa=
"http://schema
s.xmlSOAP.org
/ws/2004/08/a
ddressing">

<wsa:Address
>
http://schemas
.xmlSOAP.org/
ws/2004/08/ad
dressing/role/a
nonymous
</wsa:Address
>
</wsa:ReplyTo
>
<wsa:From>
<wsa:Address
>
http://localhos
t:8080/axis2/s
ervices/MySer
vice</wsa:Add
ress>
</wsa:From>
<wsa:Message
ID>ECE5B3F18
7F29D28BC11
433905662036
</wsa:Messag
eID>
</env:Header
>
<env:Body>
</env:Body>
</env:Envelope
>

In this case you see a WS-Addressing element, which includes information on where the message is going and to
where replies should go. The Header and can include all kinds of information about the message itself. In fact, the
SOAP specification spends a great deal of time on elements that can go in the Header, and how they should be
treated by "SOAP intermediaries". In other words, the SOAP specification makes no assumption that the message is
going straight from one point to another, from client to server. It allows for the idea that a SOAP message might
actually be processed by several intermediaries, on its way to its final destination, and the specification is very clear
on how those intermediaries should treat information they find in theHeader. That discussion is beyond the scope of
this tutorial, however. So for now, just understand that the Header can provide you much more functionality if you
need it.
Now let's look at the actual payload.

The SOAP body

When you're sending a SOAP message, you're doing it with a reason in mind. You are trying to tell the receiver to do
something, or you're trying to impart information to the server. This information is called the "payload". The payload
goes in the Body of theEnvelope. It also has its own namespace, in this case corresponding to the content
management system. The choice of namespace, in this case, is completely arbitrary. It just needs to be different from
the SOAP namespace.

A payload example

<?xml
version='1.0' ?>
<env:Envelope
xmlns:env="htt
p://www.w3.org/
2003/05/SOAPenvelope">
<env:Header>
...
</env:Header>
<env:Body>
<cms:addArtic
le
xmlns:cms="h
ttp://www.dail
ymoon.com/cms
">
<cms:category
>classifieds</
category>
<cms:subcate
gory>forsale<
/cms:subcateg
ory>
<cms:articleH
eadline></cms
:articleHeadlin
e>
<cms:articleTe
xt>Vintage
1963 T-Bird.
Less than 300
miles.
Driven by my
daughter until
I took it away.
Serious
inquires only.
555-3264 after
7
PM.</cms:arti
cleText>
</cms:addArti
cle>
</env:Body>
</env:Envelope
>

In this case, you have a simple payload that includes instructions for adding an article to the content management
system for theDaily Moon.

References.
1. https://www.ibm.com/developerworks/webservices/tutorials/ws-understand-webservices1/