Chapter 8
Chapter 8
Web Service
8.1 Service oriented architecture
Introduction:
Service-Oriented Architecture (SOA) is an architectural approach in which applications make use
of services available in the network. In this architecture, services are provided to form applications,
through a communication call over the internet.
SOA allows users to combine a large number of facilities from existing services to form
applications.
SOA encompasses a set of design principles that structure system development and provide
means for integrating components into a coherent and decentralized system.
SOA based computing packages functionalities into a set of interoperable services, which
can be integrated into different software systems belonging to separate business domains.
Components:
Each SOA building block can play any of the three roles:
1. Service provider
It creates a web service and provides its information to the service registry. Each provider debates
upon a lot of hows and whys like which service to expose, which to give more importance: security
or easy availability, what price to offer the service for and many more. The provider also has to
decide what category the service should be listed in for a given broker service and what sort of
trading partner agreements are required to use the service.
2. Service broker, service registry or service repository
Its main functionality is to make the information regarding the web service available to any
potential requester. Whoever implements the broker decides the scope of the broker. Public brokers
are available anywhere and everywhere but private brokers are only available to a limited amount
of public. UDDI was an early, no longer actively supported attempt to provide Web services
discovery.
3. Service requester/consumer
It locates entries in the broker registry using various find operations and then binds to the service
provider in order to invoke one of its web services. Whichever service the service-consumers need,
they have to take it into the brokers, bind it with respective service and then use it. They can access
multiple services if the service provides multiple services.
The service consumer–provider relationship is governed by a standardized service contract,[17]
which has a business part, a functional part and a technical part.
Properties:
A service has four properties according to one of many definitions of SOA:
1. It logically represents a business activity with a specified outcome.
2. It is self-contained.
3. It is a black box for its consumers, meaning the consumer does not have to be aware of the
service's inner workings.
4. It may consist of other underlying services.
SOA is related to the idea of an application-programming interface (API), an interface or
communication protocol between different parts of a computer program intended to simplify the
implementation and maintenance of software. An API can be thought of as the service, and the
SOA the architecture that allows the service to operate.
An Envelope element that identifies the XML document as a SOAP message – This is the
containing part of the SOAP message and is used to encapsulate all the details in the SOAP
message. This is the root element in the SOAP message.
A Header element that contains header information – The header element can contain
information such as authentication credentials which can be used by the calling application.
It can also contain the definition of complex types which could be used in the SOAP
message. By default, the SOAP message can contain parameters which could be of simple
types such as strings and numbers, but can also be a complex object type.
Characteristics:
SOAP has three major characteristics:
extensibility (security and WS-Addressing are among the extensions under development)
neutrality (SOAP can operate over any protocol such as HTTP, SMTP, TCP, UDP, or JMS)
independence (SOAP allows for any programming model)
Advantages of SOAP
The following are some of the many advantages that SOAP provides.
Language neutrality :SOAP can be developed using any language.
Interoperability and Platform Independence : SOAP can be implemented in any language
and can be executed in any platform.
Simplicity : SOAP messages are in very simple XML format.
Scalability : SOAP uses HTTP protocol for transport due to which it becomes scalable.
Disadvantages of SOAP.
The following are the disadvantages of SOAP.
Slow : SOAP uses the XML format which needs to be parsed and is lengthier too which
makes SOAP slower than CORBA, RMI or IIOP.
WSDL Dependence : It depends on WSDL and does not have any standardized mechanism
for dynamic discovery of the services.
8.2.2 REST
REpresentational State Transfer (REST) is an architectural style that defines a set of constraints to
be used for creating web services. REST API is a way of accessing the web services in a simple
and flexible way without having any processing.
REST technology is generally preferred to the more robust Simple Object Access Protocol (SOAP)
technology because REST uses the less bandwidth, simple and flexible making it more suitable
for internet usage. It’s used to fetch or give some information from a web services. All communication
done via REST API used only HTTP request.
Working:
A request is send from client to server in the form of web URL as HTTP GET or POST or PUT or
DELETE. After that a response is come back from server in the form of resource which can be
anything like HTML, XML, Image or JSON. But now JSON is the most popular format being used
in Web Services.
In HTTP there are five methods which are commonly used in a REST based Architecture i.e.,
POST, GET, PUT, PATCH, and DELETE. These correspond to create, read, update, and delete
(or CRUD) operations respectively. There are other methods which are less frequently used like
OPTIONS and HEAD.
1. GET: The HTTP GET method is used to read (or retrieve) a representation of a resource. In
the safe path, GET returns a representation in XML or JSON and an HTTP response code of
200 (OK). In an error case, it most often returns a 404 (NOT FOUND) or 400 (BAD
REQUEST).
2. POST: The POST verb is most-often utilized to create new resources. In particular, it’s used
to create subordinate resources. That is, subordinate to some other (e.g. parent) resource. On
successful creation, return HTTP status 201, returning a Location header with a link to the
newly-created resource with the 201 HTTP status.
NOTE: POST is neither safe nor idempotent.
3. PUT: It is used for updating the capabilities. However, PUT can also be used to create a
resource in the case where the resource ID is chosen by the client instead of by the server. In
other words, if the PUT is to a URI that contains the value of a non-existent resource ID. On
successful update, return 200 (or 204 if not returning any content in the body) from a PUT.
If using PUT for create, return HTTP status 201 on successful creation. PUT is not safe
operation but it’s idempotent.
4. PATCH: It is used for modify capabilities. The PATCH request only needs to contain the
changes to the resource, not the complete resource. This resembles PUT, but the body
contains a set of instructions describing how a resource currently residing on the server
should be modified to produce a new version. This means that the PATCH body should not
just be a modified part of the resource, but in some kind of patch language like JSON Patch
or XML Patch. PATCH is neither safe nor idempotent.
5. DELETE: It is used to delete a resource identified by a URI. On successful deletion, return
HTTP status 200 (OK) along with a response body.
Best design practice for choosing REST v/s SOAP:
SOAP: Whenever there are external system/applications (third-party applications) to
interact with our system/applications, then it is always preferred to go for SOAP as it has
got in-built ws-security features
REST: And whereas for internal system/applications (or intra-application interaction
within our organization), then it is preferred to go for REST web services as it will be faster
Difference between REST and SOAP:
Short notes:
Representational State Transfer (REST), or RESTful, web services provide
interoperability between computer systems on the Internet. REST-compliant web services
allow the requesting systems to access and manipulate textual representations of web
resources by using a uniform and predefined set of stateless operations. Other kinds of
web services, such as WSDL and SOAP, expose their own arbitrary sets of operations.
"Web resources" were first defined on the World Wide Web as documents or files
identified by their URLs.
In a RESTful web service, requests made to a resource's URI will elicit a response that
may be in XML, HTML, JSON, or some other format.
The response may confirm that some alteration has been made to the stored resource, and
the response may provide hypertext links to other related resources or collections of
resources.
When HTTP is used, as is most common, the operations available are GET, POST, PUT,
DELETE, and other predefined CRUD HTTP methods.
By using a stateless protocol and standard operations, REST systems aim for fast
performance, reliability, and the ability to grow, by re-using components that can be
managed and updated without affecting the system as a whole, even while it is running.
8.2.3 WSDL
WSDL stands for Web Services Description Language
WSDL is used to describe web services
WSDL is written in XML
WSDL is a W3C recommendation from 26. June 2007
WSDL stands for Web Services Description Language. It is the standard format for describing a
web service. WSDL was developed jointly by Microsoft and IBM.
Features of WSDL
WSDL is an XML-based protocol for information exchange in decentralized and
distributed environments.
WSDL definitions describe 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 Universal Description, Discovery, and Integration (UDDI), an
XML-based worldwide business registry.
WSDL is the language that UDDI uses.
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.
History of WSDL
WSDL 1.1 was submitted as a W3C Note by Ariba, IBM, and Microsoft for describing services
for the W3C XML Activity on XML Protocols in March 2001.
WSDL 1.1 has not been endorsed by the World Wide Web Consortium (W3C), however it has just
released a draft for version 2.0 that will be a recommendation (an official standard), and thus
endorsed by the W3C.