Distributed Service Oriented Architecture (SOA)

Service-oriented architecture (SOA) is a software architecture based on discrete pieces of software providing
application functionality as services to other applications. This is known as Service-orientation. It is
independent of any vendor, product or technology.

A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be
combined by other software applications to provide the complete functionality of a large software application.
SOA makes it easy for computers connected over a network to cooperate. Every computer can run an arbitrary
number of services, and each service is built in a way that ensures that the service can exchange information
with any other service in the network without human interaction and without the need to make changes to the
underlying program itself.

Services are unassociated, loosely coupled units of functionality that are self-contained. Each service
implements one action, such as submitting an online application for an account, retrieving an online bank
statement, or modifying an online booking or airline ticket order. Within a SOA, services use defined protocols
that describe how services pass and parse messages using description metadata.

Underlying and enabling all of this requires metadata in sufficient detail to describe not only the characteristics
of these services, but also the data that drives them. Programmers have made extensive use of XML in SOA
to structure data that they wrap in a nearly exhaustive description-container. Analogously, the Web Services
Description Language (WSDL) typically describes the services themselves, while the SOAP protocol describes
the communications protocols

The purpose of SOA is to allow users to combine together fairly large chunks of functionality to form ad hoc
applications built almost entirely from existing software services. The larger the chunks, the fewer the
interfaces required to implement any given set of functionality; however, very large chunks of functionality
may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing
overhead, so there is a performance consideration in choosing the granularity of services.

Web Services

A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described
using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web
service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.

 a web service is a distributed web application that allows maximum interoperability between reusable
software components written in different languages and running on different platforms
 common data representation: XML
 common communication protocol: to call the service, book the appointment, order the part, ...
 service discovery: a way for programs to find services on the web

1|Page
  classic (futuristic) example is software agent booking and paying for a holiday which includes flight,
hotel and rental car reservations from multiple suppliers
 organization can expose any business function to other functions, organizations or users
 web service can be invoked on-the-fly, in response to other web services

Web Services Architecture

Service Provider

 A service provider is the primary engine underlying the Web services.

 service provider describes services using Web Services Description Language (WSDL)
 actually provides or implements the business functionality of various types
 The WSDL definition is published to a service broker.

Server Broker

 directory service (broker) stores WSDL definitions in a Universal Description, Discovery and
Integration (UDDI) registry
 A service broker describes the service's location and contract.
 It is responsible for ensuring the service information is available to any potential service requestor,
consumer, or called Web service client.


Service Consumer

 A service consumer or Web service client issues one or more queries to the service broker to locate a
service and determine how to communicate with that service.
 client (service requestor) interacts with the service using Simple Object Access Protocol (SOAP)

WSDL and SOAP are the communication vehicles facilitating the services. Part of the WSDL provided
by a service provider is passed to the service consumer in specifying what the requests and responses are
for the service provider. The service consumer sends SOAP messages as service requests to the service
provider. The service provider then provides the expected SOAP responses back to the service consumer
to complete the requests.

2|Page
Web Services Description Language (WSDL)

WSDL is a format for describing a Web Services interface. It is a way to describe services and how they
should be bound to specific network addresses.

 uses XML syntax to describe services. There is a particular structure followed

Ex:
 names a <service>, specifies a <port> (URI) at which it is available and refers to a binding for the port
 a <binding> specifies the
style of interaction (e.g. RPC)
the transport protocol used (e.g. HTTP)
the <operation>s defined along with encodingStyle for their <input> and <output>

 provides information about

 interfaces to all publicly available functions

 data types for all message requests and message responses
 binding to the transport protocol to be used
 addresses for locating the specified services

Universal Description, Discovery and Integration (UDDI)

 how to find a web service (cf. yellow pages)

 based on SOAP and WSDL
 UDDI has not been submitted to any standards body
 UDDI business registry is a web service itself

Simple Object Access Protocol (SOAP)

Simple Object Access Protocol (SOAP) is a protocol for exchanging XML-based messages over networks,
normally using HTTP/HTTPS.

In Web service environment, SOAP provides a standard way of structuring these XML documents and acts
as a building block for Web service communication. For example, Web service provider receives SOAP
requests from Web service clients to invoke Web services and also sends the corresponding SOAP responses
out to the clients.

 SOAP Version 1.2 is a W3C Recommendation

 toolkits exist to deploy applications as web services which use SOAP, generating WSDL automatically
 a SOAP message is an XML document
 root element is Envelope
 Envelope has optional Header and mandatory Body elements as children
 Body contains elements corresponding to web service requests or responses (application specific)

3|Page
REST – Representational State Transfer

REST stands for Representational State Transfer, which is an architectural style for networked hypermedia
applications. It is primarily used to build Web services that are lightweight, maintainable, and scalable. A service based
on REST is called a RESTful service.

REST is web standards based architecture and uses HTTP Protocol for data communication. It revolves around resource
where every component is a resource and a resource is accessed by a common interface using HTTP standard methods.

Here each resource is identified by URIs/ global IDs. REST uses various representations to represent a resource like
text, JSON and XML. Now a days JSON is the most popular format being used in web services.

Web services based on REST Architecture are known as RESTful web services. These web services use HTTP methods
to implement the concept of REST architecture. A RESTful web service usually defines a URI, Uniform Resource
Identifier a service, provides resource representation such as JSON and set of HTTP Methods(such as GET, PUT, DELETE
…)

SOAP or REST

SOAP is a standards-based Web services access protocol which has been in using for a long time and REST is the newly
introduce to fix the problems with SOAP. REST provides a simple method of accessing Web services. Both SOAP and
REST share similarities over the HTTP protocol. But SOAP is a more rigid set of messaging patterns than REST. The rules
in SOAP are important because without these rules, you can’t achieve any level of standardization. REST as an
architecture style does not require processing and is naturally more flexible.

SOAP relies entirely on XML to provide messaging services. The XML used to make requests and receive responses in
SOAP can become extremely complex. Many developers found SOAP cumbersome and hard to use. For example,
working with SOAP in JavaScript means writing a lot of code to perform extremely simple tasks because you must create
the required XML structure every time.

REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many
cases. Web services even obtain additional information needed using the URL approach. REST can use four different
HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.

Unlike SOAP, REST doesn’t have to use XML to provide the response. REST-based Web services provide the output in
Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The output
form is easy to parse within the language. REST is closer to other Web technologies in design philosophy

4|Page