Web service

A Web service is a method of communication between two electronic devices over a

network. It is a software function provided at a network address over the Web with the
service always on as in the concept of utility computing

The software system that requests data is called a service requester, whereas the software
system that would process the request and provide the data is called a service provider.

Different software might be built using different programming languages, and hence there is
a need for a method of data exchange that doesn't depend upon a particular programming
language. Most types of software can, however, interpret XML tags.

Hence, Web services can use XML files for data exchange.

Purpose

Used primarily as a means for businesses to communicate with each other and with
clients, Web services allow organizations to communicate data without intimate
knowledge of each other's IT systems behind the firewall.

Unlike traditional client/server models, such as a Web server/Web page system, Web
services do not provide the user with a GUI. Web services instead share business
logic, data and processes through a programmatic interface across a network

Rules for communication between different systems need to be defined, such as:

 How one system can request data from another system

 Which specific parameters are needed in the data request
 What would be the structure of the data produced. Normally, data is exchanged in
XML files, and the structure of the XML file is validated against an .xsd file.
 What error messages to display when a certain rule for communication is not
observed, to make troubleshooting easier

Web services components

 Web services are web application components.

 Web services can be published, found, and used on the Web.
 The term Web services describes a standardized way of integrating Web-based
applications using the XML, SOAP, WSDL and UDDI open standards over an
Internet protocol backbone.
 XML is used to tag the data,
 SOAP is used to transfer the data,
 WSDL is used for describing the services available and
 UDDI is used for listing what services are available.
WSDL

 WSDL stands for Web Services Description Language

 WSDL is an XML-based language for describing Web services.
 WSDL is a W3C recommendation
 WSDL stands for Web Services Description Language.
 WSDL was developed jointly by Microsoft and IBM.
 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.

SOAP

 SOAP stands for Simple Object Access Protocol

 SOAP is an XML based protocol for accessing Web Services.
 SOAP is based on XML
 SOAP is a W3C recommendation

UDDI

 UDDI stands for Universal Description, Discovery and Integration

 UDDI is a directory service where companies can search for Web services.
 UDDI is described in WSDL
 UDDI communicates via SOAP

 UDDI is a specification for a distributed registry of web services.

 UDDI is platform independent, open framework.
 UDDI can communicate via SOAP, CORBA, and Java RMI Protocol.
 UDDI uses WSDL to describe interfaces to web services.
 UDDI is seen with SOAP and WSDL as one of the three foundation standards of web
services.
 UDDI is an open industry initiative enabling businesses to discover each other and
define how they interact over the Internet.
 UDDI is an XML-based standard for describing, publishing, and finding web services
 Why web services

Exposing the Existing Function on the network

A web service is a unit of managed code that can be remotely invoked using HTTP, that is, it
can be activated using HTTP requests. Web services allows you to expose the functionality of
existing code over the network. Once it is exposed on the network, other application can use
the functionality of your program.

Interoperability
Web services allow various applications to talk to each other and share data and services
among themselves. Other applications can also use the web services. For example, a VB
or .NET application can talk to Java web services and vice versa. Web services are used to
make the application platform and technology independent.

Standardized Protocol
Web services use standardized industry standard protocol for the communication. This
standardization of protocol stack gives the business many advantages such as a wide range of
choices, reduction in the cost due to competition, and increase in the quality.

Low Cost of Communication

Web services use SOAP over HTTP protocol, so you can use your existing low-cost internet
for implementing web services. This solution is much less costly compared to proprietary
solutions like EDI/B2B. Besides SOAP over HTTP, web services can also be implemented
on other reliable transport mechanisms like FTP.

Characteristics of web services

XML-Based
Web Services uses XML at data representation and data transportation layers. Using XML
eliminates any networking, operating system, or platform binding. Web Services based
applications are highly interoperable application at their core level.

Loosely Coupled
. The web service interface can change over time without compromising the client's ability to
interact with the service. A tightly coupled system implies that the client and server logic are
closely tied to one another, implying that if one interface changes, the other must be updated.
Adopting a loosely coupled architecture tends to make software systems more manageable
and allows simpler integration between different systems.
Coarse-Grained
Object-oriented technologies such as Java expose their services through individual methods.
An individual method is too fine an operation to provide any useful capability at a corporate
level. Building a Java program from scratch requires the creation of several fine-grained
methods that are then composed into a coarse-grained service that is consumed by either a
client or another service.

Businesses and the interfaces that they expose should be coarse-grained. Web services
technology provides a natural way of defining coarse-grained services that access the right
amount of business logic.

Ability to be Synchronous or Asynchronous

Synchronicity refers to the binding of the client to the execution of the service. In
synchronous invocations, the client blocks and waits for the service to complete its operation
before continuing. Asynchronous operations allow a client to invoke a service and then
execute other functions.

Asynchronous clients retrieve their result at a later point in time, while synchronous clients
receive their result when the service has completed. Asynchronous capability is a key factor
in enabling loosely coupled systems.

Supports Remote Procedure Calls(RPCs)

Web services allow clients to invoke procedures, functions, and methods on remote objects
using an XML-based protocol. Remote procedures expose input and output parameters that a
web service must support.

Component development through Enterprise JavaBeans (EJBs) and .NET Components has
increasingly become a part of architectures and enterprise deployments over the past couple
of years. Both technologies are distributed and accessible through a variety of RPC
mechanisms.

A web service supports RPC by providing services of its own, equivalent to those of a
traditional component, or by translating incoming invocations into an invocation of an EJB or
a .NET component.

Supports Document Exchange

One of the key advantages of XML is its generic way of representing not only data, but also
complex documents. These documents can be as simple as representing a current address, or
they can be as complex as representing an entire book or Request for Quotation (RFQ). Web
services support the transparent exchange of documents to facilitate business integration.
Soap(SOAP stands for Simple Object Access Protocol.)

 SOAP stands for Simple Object Access Protocol

 SOAP is a communication protocol
 SOAP is for communication between applications
 SOAP is a format for sending messages
 SOAP communicates via Internet
 SOAP is platform independent
 SOAP is language independent
 SOAP is based on XML
 SOAP is simple and extensible
 SOAP allows you to get around firewalls

SOAP Building Blocks

A SOAP message is an ordinary XML document containing the following elements:

 An Envelope element that identifies the XML document as a SOAP message

 A Header element that contains header information
 A Body element that contains call and response information
 A Fault element containing errors and status information

All the elements above are declared in the default namespace for the SOAP envelope:

URL/soap-envelope

and the default namespace for SOAP encoding and data types is:

URL/soap-encoding

Skeleton SOAP Message

<?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>
...
</soap:Header>
<soap:Body>
...
  <soap:Fault>
  ...
  </soap:Fault>
</soap:Body>

</soap:Envelope>

The SOAP Envelope element is the root element of a SOAP message.

The xmlns:soap Namespace

Notice the xmlns:soap namespace in the example above. It should always have the value of:
"http://www.w3.org/2001/12/soap-envelope".

The namespace defines the Envelope as a SOAP Envelope.

If a different namespace is used, the application generates an error and discards the message.

The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This
attribute may appear on any SOAP element, and applies to the element's contents and all
child elements.

A SOAP message has no default encoding.

Syntax
soap:encodingStyle="URI"

Example

<?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">
  ...
  Message information goes here
  ...
</soap:Envelope>
The SOAP Header element contains header information.

The optional SOAP Header element contains application-specific information (like

authentication, payment, etc) about the SOAP message.

If the Header element is present, it must be the first child element of the Envelope element.

<?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:Envelope>
These attributes are: mustUnderstand, actor, and encodingStyle.

The mustUnderstand Attribute

The SOAP mustUnderstand attribute can be used to indicate whether a header entry is
mandatory or optional for the recipient to process.

soap:mustUnderstand="0|1"

The actor Attribute

A SOAP message may travel from a sender to a receiver by passing different endpoints along
the message path. However, not all parts of a SOAP message may be intended for the
ultimate endpoint, instead, it may be intended for one or more of the endpoints on the
message path.

The SOAP actor attribute is used to address the Header element to a specific endpoint.

Syntax
soap:actor="URI"
The encodingStyle Attribute
The encodingStyle attribute is used to define the data types used in the document. This
attribute may appear on any SOAP element, and it will apply to that element's contents and
all child elements.

The SOAP Body element contains the actual SOAP message. The required SOAP Body element
contains the actual SOAP message intended for the ultimate endpoint of the message.

Soap request

<?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:GetPrice xmlns:m="http://www.w3schools.com/prices">
    <m:Item>Apples</m:Item>
  </m:GetPrice>
</soap:Body>

</soap:Envelope>

Soap response

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

  </m:GetPriceResponse>
</soap:Body>

</soap:Envelope>

The SOAP Fault element holds errors and status information for a SOAP message

SOAP Fault Codes

The fault code values defined below must be used in the fault code element when describing
faults:

Error Description

VersionMismatch Found an invalid namespace for the SOAP Envelope element

An immediate child element of the Header element, with the

MustUnderstand
mustUnderstand attribute set to "1", was not understood

Client The message was incorrectly formed or contained incorrect information

Server There was a problem with the server so the message could not proceed

Document style

While document style indicates that the SOAP body contains a XML document which can be
validated against pre-defined XML schema document

The advantage of using a Document style model is that you can structure the SOAP body
any way you want it as long as the content of the SOAP message body is any arbitrary XML
instance. The Document style is also referred to as Message-Oriented style.

However, with an RPC style model, the structure of the SOAP request body must contain
both the operation name and the set of method parameters. The RPC style model assumes a
specific structure to the XML instance contained in the message body.

RPC Style Document Style

1) RPC style web services use method name 1) Document style web services can be
and parameters to generate XML structure. validated against predefined schema.

2) The generated WSDL is difficult to be 2) In document style, SOAP message is sent

validated against schema. as a single document.

3) In RPC style, SOAP message is sent as 3) Document style message is loosely

many elements. coupled.

4) RPC style message is tightly coupled. 4) In Document style, SOAP message loses
the operation name.
5) In RPC style, SOAP message keeps the
operation name. 5) In Document style, parameters are sent in
XML format.
6) In RPC style, parameters are sent as
discrete values.
package com.sample;

import java.util.ArrayList;

import javax.jws.WebService;

import javax.jws.soap.SOAPBinding;

import javax.jws.soap.SOAPBinding.Style;

@WebService

@SOAPBinding(style=Style.DOCUMENT)

public interface StockPrice {

public String getStockPrice(String stockName);

public ArrayList getStockPriceList(ArrayList stockNameList);

Benefits of document style

No one can dispute that the ability to invoke a cross-platform remote procedure call using
XML is extremely useful and is a compelling argument for using web services. But if web
services were constrained exclusively to RPC messaging, the reach of the technology would
be limited. Fortunately, developers have a choice of using either RPC or document style
messaging and are able to use the right technology for the tasks they face.

With document style, you can make full use of XML

The XML specification was developed to allow ordinary data that is usually locked up in a
proprietary format to be described in an open format that is human readable, self-describing,
and self-validating. When a web service uses document messaging, it can use the full
capabilities of XML to describe and validate a high-level business document. When a service
uses RPC message formatting, the XML describes the method and the parameters encoded
for the method call and cannot be used to enforce high-level business rules. In order to
enforce these rules, the RPC message must include an XML document as a string parameter
and hide the validation within the method being called. For this reason, some of the benefits
of XML are lost, or at least hidden within the back-end application.

Document style does not require a rigid contract

Another reason to use document messaging is that a remote procedure call is meant to be
relatively static and any changes to the interface would break the contract between the service
and the application. If a service is widely distributed, then it is likely that a large number of
applications have produced stub code from its WSDL document. Changing the WSDL would
cause all of the applications that rely on a specific method signature to break and a lot of
support lines to ring. Good design dictates that the method signature of an RPC message
service should never change. With document messaging, the rules are less rigid and many
enhancements and changes can be made to the XML schema without breaking the calling
application.

Document style is better suited for asynchronous processing

When businesses are using a web-based application to exchange information over the
Internet, the application should be able to use a guaranteed delivery mechanism to improve
its reliability, scalability, and performance. To achieve this, an application will generally use
asynchronous message queues. Since a document message is usually self-contained, it is
better suited for asynchronous processing and can be placed directly into the queue. The
reliability of the application is improved because the message queue guarantees the delivery
of the message even if the target application is not currently active; performance is improved
because the web application simply delivers the document to a queue and is then free to
perform other tasks; and scalability is improved because the document is offloaded to one or
more instances of an application that handles its processing.

Document style makes object exchange more flexible

The design of a business document is often very well suited to object-oriented architectures.
As a result, two applications may be designed to exchange the state of an object by using
XML. In contrast with object serialization, in an object exchange, each end of the exchange is
free to design the object as it sees fit as long as the exchange conforms to the agreed upon
XML document format. One reason for not using object serialization is to support client-side
and server-side implementations of an object. Many current industry-specific XML schemas
are designed as client/server architectures in which the processing that is done at the client is
separate from the processing intended at the server. As is often the case, the client is simply
requesting or saving information in a specific document format that is persisted at the server.
Certainly, this type of exchange could be done using an RPC message, but the encoding
scheme of such a message places constraints on the design of the object at each end. These
constraints are not a problem with document style.
When to use document style
When should you use document style? The short answer: Anytime you are not interfacing to
a preexisting remote procedure call, the benefits of document style may outweigh the extra
effort that is often required to interface to the service. A caveat: The effort to build a service
that uses document messaging is usually greater than the effort required to build an RPC
message service. This extra effort usually involves the design of an XML schema or support
for a preexisting schema, as well as the extraction of relevant information from a document.
The schema design is important because the XML parser uses the schema to validate the
document, supporting the intended business rules. Additional effort is required by the service
to extract relevant information from the document to be used while handling the request. In
contrast, an RPC message only requires the design of the method interface, from which it will
automatically marshal and unmarshal the parameters.

When making your decision to publish a service, you might want to consider the following
questions..

 Is this service interfacing to a preexisting procedure call and is the procedure call stateless?
 Is the service to be used only within your organization, or by outside users as well?
 Is one of the parameters simply an XML document specification?
 Does the service require a request/response architecture?
 Do the parameters represent complex structures that may benefit from an XML document
schema for validation?
 Can all of the information that needs to be exchanged be reasonably contained in memory?

Use document style when maintaining application state

You should consider a document architecture for your service if multiple procedures must be
called in a particular sequence to maintain application state. If multiple procedure calls are
required, then the procedure is not stateless and the service must maintain application state.
Maintaining state within a web service can be difficult; in the case of a remote procedure call,
very few client platforms will generate stub code that is able to support state information.
One possible solution is to use document architecture and pass the contents of an entire
transaction within the document. In this case, the service will perform the calls to ensure that
the proper sequence is maintained inside the service and state information is not maintained
beyond a single transaction. If state information is still required, it can be built in to the
resulting document, or the client application can maintain a token that identifies its state to
the service.

Use document style to publish services for outside partners

If an application is being published outside of the organization, the publisher has very little
control over who is relying on the service and what the consequences will be if any changes
are made. In such cases, it may be more advantageous to use document messaging and
support a common exchange protocol such as ebXML. Common exchange protocols are
evolving to improve the management of external exchanges so that new trading partner
agreements can be rapidly deployed. Also, if your service does not require a request/response
architecture, then common exchange protocols are better designed to handle authentication,
reliable message delivery, and asynchronous request/response.
Use document style to ease validation and use of complex documents

If your service is using a string parameter to pass or return an XML document, or if one of its
parameters is an object with a complex structure that requires custom handling, then
document messaging may be the better alternative. Hiding the true meaning of a parameter
within a string can often lead to valid calls with invalid parameters. If the service publishes
an XML document schema, then it is easier to validate against that schema prior to calling the
service. A complex structure is often used to pass hundreds of pieces of information making
up a complete transaction. When dealing with complex structures, a remote procedure service
may have to deal with custom marshaling code while the application is still responsible for
meticulously validating each element of the structure. If document messaging is used, then
the application programmer can offload validation to the document designer using an XML
schema, and no custom marshaling code is required.

Use document style to minimize in-memory processing

One final consideration when choosing between document and RPC messaging is the amount
of information that may need to be handled. Since most if not all of the implementations that
marshal parameters in RPC messaging perform this operation in-memory, memory
constraints may make RPC messaging unfeasible. Many document-messaging services are
able to choose between DOM and SAX handling of the document and as a result are able to
minimize in-memory processing. This is particularly critical for a web service that may be
required to handle thousands of requests, many simultaneously.

REST

REST stands for Representational State Transfer.

Advantages of RESTful Web Services

Fast: RESTful Web Services are fast because there is no strict specification like SOAP. It
consumes less bandwidth and resource.

Language and Platform independent: RESTful web services can be written in any
programming language and executed in any platform.

Can use SOAP: RESTful web services can use SOAP web services as the implementation.

Permits different data format: RESTful web service permits different data format such as
Plain Text, HTML, XML and JSON.
 o. SOAP REST
1) SOAP is a protocol. REST is an architectural style.
SOAP stands for Simple Object
2) REST stands for Representational State Transfer.
Access Protocol.
SOAP can't use REST because REST can use SOAP web services because it is a
3)
it is a protocol. concept and can use any protocol like HTTP, SOAP.
SOAP uses services interfaces
4) REST uses URI to expose business logic.
to expose the business logic.
JAX-WS is the java API for
5) JAX-RS is the java API for RESTful web services.
SOAP web services.
SOAP defines standards to be
6) REST does not define too much standards like SOAP.
strictly followed.
SOAP requires more
REST requires less bandwidth and resource than
7) bandwidth and resource than
SOAP.
REST.
RESTful web services inherits security measures
8) SOAP defines its own security.
from the underlying transport.
SOAP permits XML data format REST permits different data format such as Plain text,
9)
only. HTML, XML, JSON etc.
SOAP is less preferred than
10) REST more preferred than SOAP
REST.

Difference between JSON and XML

JSON XML
JSON : “JavaScript Object
 Stands For XML: “Extensible Markup Language”.
Notation”.
XML is extended from SGML :
 Extended
JSON is extended from JavaScript. “Standard Generalized Markup
From
Language“.
 XML is a Markup Language having
 JSON is one type of text-based
format that contains set of rules for the
format or standard for
encoding the documents which is readable
 Purpose interchanging  data i.e. human
for both human & machine. XML is
readable.  JSON is developed by
developed by W3C :“World Wide Web
“Douglas Crockford”.
Consortium “.
 JSON syntax is lighter than XML
 XML is not so lighter as JSON as having
as JSON has serialized format of
start and end tags and it takes more
 Syntax data having  less redundancy.
character than JSON to represent same
JSON does not contain start and
data.
end tags.
JSON is light – weighted in
Speed compare to XML as it has XML is not so light weighted as JSON.
serialized format and so faster also.
Support of JSON supports datatype including XML does not provide any data type so
Data Type & integer and strings, JSON also needs to be parsed into particular
Array supports array. datatype. No direct support for array also.
 Object JSON has support of native XML can get support of objects through
Support objects. mixed use of attributes & elements.
Comments JSON does not support Comments XML supports comments.
JSON does not have support for
Namespace XML supports Namespaces.
Namespaces.
JSON is data oriented and can be XML is document oriented and needs
Mapping
mapped more easily. more effort for mapping.
JSON uses only evel() for parsing
XML needs XML Document Object
i.e. for interpreting the JavaScript
Model (DOM) implementation & with
Parsing code & returns the result. It does
that additional code for mapping text back
not need any additional code for
to the JavaScript objects.
parsing.
Application For Web services, JSON is better. For configuration, XML is better.
In XML, using XSLT you can change
Changing You can not change JSON data to XML data into another format like
Format other format. comma –delimited, plain text, JSON,
etc.
In JSON no such is interface for In XML, Using XPath, it is possible to
Access getting direct access to a part in get the direct access to a particular part of
JSON data-structure. multiple parts of XML data- structure