Rechercher SOAP Vs.

REST: Difference between Web API Services

The earlier tutorials have given a lot of details on 2 key types of web service designs. One
is SOAP protocol (Simple Object Access Protocol) and the other being REST for
Representational State Transfer.

Each technique has its own advantages and disadvantages. Hence, it's always good to
understand in which situations each design should be used. This tutorial will go into some of
the key differences between these techniques as well as what challenges you might encounter
while using them.

In this tutorial, you will learn-

 SOAP vs REST
 When to use REST and when to use SOAP
 SOAP vs REST API challenges
 Difference between SOAP Vs. CORBA Vs. DCOM Vs. Java RMI

SOAP vs. REST

Let' have a quick overview of SOAP and REST before we do a deep dive into the key
differences between them.

SOAP – SOAP is a protocol which was designed before REST and came into the picture.
The main idea behind designing SOAP was to ensure that programs built on different
platforms and programming languages could exchange data in an easy manner.

REST – This was designed specifically for working with components such as media
components, files, or even objects on a particular hardware device. Any web service that is
defined on the principles of REST can be called a RestFul web service. A Restful service
would use the normal HTTP verbs of GET, POST, PUT and DELETE for working with the
required components.

Below are the main differences between SOAP and REST

SOAP REST

 SOAP stands for Simple Object  REST stands for Representational State Transfer
Access Protocol

 SOAP is a protocol. SOAP was  REST is an Architectural style in which a web service can only be
designed with a specification. It treated as a RESTful service if it follows the constraints of being
includes a WSDL file which has 1. Client Server
the required information on 2. Stateless
what the web service does in 3. Cacheable
 addition to the location of the 4. Layered System
web service. 5. Uniform Interface

 SOAP cannot make use of REST  REST can make use of SOAP as the underlying protocol for web
since SOAP is a protocol and services, because in the end it is just an architectural pattern.
REST is an architectural
pattern.

 SOAP uses service interfaces to
expose its functionality to
client applications. In SOAP, the
WSDL file provides the client
with the necessary information
which can be used to
understand what services the
web service can offer.
 REST use Uniform Service locators to access to the components on
the hardware device. For example, if there is an object which
represents the data of an employee hosted on a URL as
http://demo.guru99 , the below are some of URI that can exist to
access them
http://demo.guru99.com/Employee
http://demo.guru99.com/Employee/1

 SOAP requires more bandwidth  REST does not need much bandwidth when requests are sent to
for its usage. Since SOAP the server. REST messages mostly just consist of JSON messages.
Messages contain a lot of Below is an example of a JSON message passed to a web server.
information inside of it, the You can see that the size of the message is comparatively smaller
amount of data transfer using to SOAP.
SOAP is generally a lot.
{"city":"Mumbai","state":"Maharastra"}
<?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/soa
p-encoding">
<soap:Body>
<Demo.guru99WebService
xmlns="http://tempuri.org/">
<EmployeeID>int</EmployeeID>
</Demo.guru99WebService>
</soap:Body>
</SOAP-ENV:Envelope>

 SOAP can only work with XML  REST permits different data format such as Plain text, HTML, XML,
format. As seen from SOAP JSON, etc. But the most preferred format for transferring data is
messages, all data passed is in
 XML format. JSON.

When to use REST and when to use SOAP

One of the most highly debatable topics is when REST should be used or when to use SOAP
while designing web services.

Below are some of the key factors that determine when each technology should be used for
web services REST services should be used in the following instances

 Limited resources and bandwidth – Since SOAP messages are heavier in content
and consume a far greater bandwidth, REST should be used in instances where
network bandwidth is a constraint.
 Statelessness – If there is no need to maintain a state of information from one request
to another then REST should be used. If you need a proper information flow wherein
some information from one request needs to flow into another then SOAP is more
suited for that purpose. We can take the example of any online purchasing site. These
sites normally need the user first to add items which need to be purchased to a cart.
All of the cart items are then transferred to the payment page in order to complete the
purchase. This is an example of an application which needs the state feature. The state
of the cart items needs to be transferred to the payment page for further processing.
 Caching – If there is a need to cache a lot of requests then REST is the perfect
solution. At times, clients could request for the same resource multiple times. This can
increase the number of requests which are sent to the server. By implementing a
cache, the most frequent queries results can be stored in an intermediate location. So
whenever the client requests for a resource, it will first check the cache. If the
resources exist then, it will not proceed to the server. So caching can help in
minimizing the amount of trips which are made to the web server.
 Ease of coding – Coding REST Services and subsequent implementation is far easier
than SOAP. So if a quick win solution is required for web services, then REST is the
way to go.

SOAP should be used in the following instances

1. Asynchronous processing and subsequent invocation – if there is a requirement

that the client needs a guaranteed level of reliability and security then the new SOAP
standard of SOAP 1.2 provides a lot of additional features, especially when it comes
to security.
2. A Formal means of communication – if both the client and server have an
agreement on the exchange format then SOAP 1.2 gives the rigid specifications for
this type of interaction. An example is an online purchasing site in which users add
items to a cart before the payment is made. Let's assume we have a web service that
does the final payment. There can be a firm agreement that the web service will only
accept the cart item name, unit price, and quantity. If such a scenario exists then, it's
always better to use the SOAP protocol.
 3. Stateful operations – if the application has a requirement that state needs to be
maintained from one request to another, then the SOAP 1.2 standard provides the
WS* structure to support such requirements.

SOAP vs. REST API challenges

API is known as the Application Programming Interface and is offered by both the client
and the server. In the client world, this is offered by the browser whereas in the server world
it's what is provided by the web service which can either be SOAP or REST.

Challenges with the SOAP API

1. WSDL file - One of the key challenges of the SOAP API is the WSDL document itself. The
WSDL document is what tells the client of all the operations that can be performed by the
web service. The WSDL document will contain all information such as the data types being
used in the SOAP messages and what all operations are available via the web service. The
below code snippet is just part of a sample WSDL file.

<?xml version="1.0"?>
<definitions name="Tutorial"
targetNamespace=http://demo.guru99.com/Tutorial.wsdl
xmlns:tns=http://demo.guru99.com/Tutorial.wsdl
xmlns:xsd1=http://demo.guru99.com/Tutorial.xsd
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>
<schema targetNamespace=http://Demo.guru99.com/Tutorial.xsd
xmlns="http://www.w3.org/2000/10/XMLSchema">

<element name="TutorialNameRequest">
<complexType>
<all>
<element name="TutorialName" type="strin
g"/>
</all>
</complexType>
</element>
<element name="TutorialIDRequest">
<complexType>
<all>
<element name="TutorialID" type="number"/>
</all>
</complexType>
</element>
</schema>
</types>
As per the above WSDL file, we have an element called "TutorialName" which is of the type
String which is part of the element TutorialNameRequest.

Now, suppose if the WSDL file were to change as per the business requirements and the
TutorialName has to become TutorialDescription. This would mean that all the clients who
are currently connecting to this web service would then need to make this corresponding
change in their code to accommodate the change in the WSDL file.

This shows the biggest challenge of the WSDL file which is the tight contract between the
client and the server and that one change could cause a large impact, on the whole, client
applications.

2. Document size – The other key challenge is the size of the SOAP messages which get
transferred from the client to the server. Because of the large messages, using SOAP in
places where bandwidth is a constraint can be a big issue.

Challenges with the REST API

1. Lack of Security – REST does not impose any sort of security like SOAP. This is why REST is
very appropriate for public available URL's, but when it comes down to confidential data
being passed between the client and the server, REST is the worst mechanism to be used for
web services.
2. Lack of state – Most web applications require a stateful mechanism. For example, if you had
a purchasing site which had the mechanism of having a shopping cart, it is required to know
the number of items in the shopping cart before the actual purchase is made. Unfortunately,
the burden of maintaining this state lies with the client, which just makes the client
application heavier and difficult to maintain.

REST

In the REST architectural style, the implementation of the client and the implementation of
the server can be done independently without each knowing about the other. This means
that the code on the client side can be changed at any time without affecting the operation
of the server, and the code on the server side can be changed without affecting the
operation of the client

WHAT IS THE PURPOSE OF SERVICE REGISTERY IN WEB

SERVICE ARCHITECTURE? HOW CAN IT HELP IN SERVICE
DISCOVERY PROCESS

What are Web Services? Architecture,

Types, Example
Modern day business applications use variety of programming platforms to develop web-
based applications. Some applications may be developed in Java, others in .Net, while some
other in Angular JS, Node.js, etc.

Most often than not, these heterogeneous applications need some sort of communication to
happen between them. Since they are built using different development languages, it becomes
really difficult to ensure accurate communication between applications.

Here is where web services come in. Web services provide a common platform that allows
multiple applications built on various programming languages to have the ability to
communicate with each other.

In this introductory tutorial, we will explain more about what web services are about, the
different elements which constitute web services, and a little bit about SOA (Service Oriented
Architecture) principles.

In this tutorial, you will learn-

 What is Web Service?

 Type of Web Service
 Web Services Advantages
 Web Service Architecture
 Web Service Characteristics

What is Web Service?

Web service is a standardized medium to propagate communication between the
client and server applications on the World Wide Web.

A web service is a software module which is designed to perform a certain set of

tasks.

o The web services can be searched for over the network and can also be
invoked accordingly.
o When invoked the web service would be able to provide functionality to the
client which invokes that web service.
Web Service Architecture Diagram

The above diagram shows a very simplistic view of how a web service would actually
work. The client would invoke a series of web service calls via requests to a server
which would host the actual web service.

These requests are made through what is known as remote procedure calls. Remote
Procedure Calls(RPC) are calls made to methods which are hosted by the relevant
web service.

As an example, Amazon provides a web service that provides prices for products sold
online via amazon.com. The front end or presentation layer can be in .Net or Java but
either programming language would have the ability to communicate with the web
service.

The main component of a web service is the data which is transferred between the
client and the server, and that is XML. XML (Extensible markup language) is a
counterpart to HTML and easy to understand the intermediate language that is
understood by many programming languages.

So when applications talk to each other, they actually talk in XML. This provides a
common platform for application developed in various programming languages to talk
to each other.

Web services use something known as SOAP (Simple Object Access Protocol) for
sending the XML data between applications. The data is sent over normal HTTP. The
data which is sent from the web service to the application is called a SOAP message.
The SOAP message is nothing but an XML document. Since the document is written
in XML, the client application calling the web service can be written in any
programming language.

Type of Web Service

There are mainly two types of web services.

3. SOAP web services.

4. RESTful web services.

In order for a web service to be fully functional, there are certain components that
need to be in place. These components need to be present irrespective of whatever
development language is used for programming the web service.

Let's look at these components in more detail.

SOAP (Simple Object Access Protocol)

SOAP is known as a transport-independent messaging protocol. SOAP is based on

transferring XML data as SOAP Messages. Each message has something which is
known as an XML document. Only the structure of the XML document follows a
specific pattern, but not the content. The best part of Web services and SOAP is that
its all sent via HTTP, which is the standard web protocol.

Here is what a SOAP message consists of

o Each SOAP document needs to have a root element known as the <Envelope>
element. The root element is the first element in an XML document.
o The "envelope" is in turn divided into 2 parts. The first is the header, and the
next is the body.
o The header contains the routing data which is basically the information which
tells the XML document to which client it needs to be sent to.
o The body will contain the actual message.

The diagram below shows a simple example of the communication via SOAP.
We will discuss SOAP in detail in this tutorial.

WSDL (Web services description language)

A web service cannot be used if it cannot be found. The client invoking the web
service should know where the web service actually resides.

Secondly, the client application needs to know what the web service actually does, so
that it can invoke the right web service. This is done with the help of the WSDL,
known as the Web services description language. The WSDL file is again an XML-
based file which basically tells the client application what the web service does. By
using the WSDL document, the client application would be able to understand where
the web service is located and how it can be utilized.

Web Service Example

An example of a WSDL file is given below.

<definitions>
<message name="TutorialRequest">
<part name="TutorialID" type="xsd:string"/>
</message>

<message name="TutorialResponse">
<part name="TutorialName" type="xsd:string"/>
 </message>

<portType name="Tutorial_PortType">
<operation name="Tutorial">
<input message="tns:TutorialRequest"/>
<output message="tns:TutorialResponse"/>
</operation>
</portType>

<binding name="Tutorial_Binding" type="tns:Tutorial_PortType">

<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="Tutorial">
<soap:operation soapAction="Tutorial"/>
<input>
<soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:Tutorialservice"
use="encoded"/>
</input>

<output>
<soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:Tutorialservice"
use="encoded"/>
</output>
</operation>
</binding>
</definitions>

The important aspects to note about the above WSDL declaration are as follows;

9. <message> - The message parameter in the WSDL definition is used to define

the different data elements for each operation performed by the web service.
So in the example above, we have 2 messages which can be exchanged
between the web service and the client application, one is the
"TutorialRequest", and the other is the "TutorialResponse" operation. The
TutorialRequest contains an element called "TutorialID" which is of the type
string. Similarly, the TutorialResponse operation contains an element called
"TutorialName" which is also a type string.
10. <portType> - This actually describes the operation which can be performed
by the web service, which in our case is called Tutorial. This operation can
take 2 messages; one is an input message, and the other is the output message.
11. <binding> - This element contains the protocol which is used. So in our case,
we are defining it to use http (http://schemas.xmlsoap.org/soap/http). We
also specify other details for the body of the operation, like the namespace and
whether the message should be encoded.

We will discuss "WDSL" in detail in this tutorial.

Universal Description, Discovery, and Integration (UDDI)

UDDI is a standard for describing, publishing, and discovering the web services that
are provided by a particular service provider. It provides a specification which helps
in hosting the information on web services.

Now we discussed in the previous topic about WSDL and how it contains information
on what the Web service actually does. But how can a client application locate a
WSDL file to understand the various operations offered by a web service? So UDDI
is the answer to this and provides a repository on which WSDL files can be hosted. So
the client application will have complete access to the UDDI, which acts as a database
containing all the WSDL files.

Just as a telephone directory has the name, address and telephone number of a
particular person, the same way the UDDI registry will have the relevant
information for the web service. So that a client application knows, where it can be
found.

Web Services Advantages

We already understand why web services came about in the first place, which was to
provide a platform which could allow different applications to talk to each other.

But let's look at some other advantages of why it is important to use web services.

12. Exposing Business Functionality on the network - A web service is a unit of

managed code that provides some sort of functionality to client applications or
end users. This functionality can be invoked over the HTTP protocol which
means that it can also be invoked over the internet. Nowadays all applications
are on the internet which makes the purpose of Web services more useful.
That means the web service can be anywhere on the internet and provide the
necessary functionality as required.
13. Interoperability amongst applications - Web services allow various
applications to talk to each other and share data and services among
themselves. All types of applications can talk to each other. So instead of
writing specific code which can only be understood by specific applications,
you can now write generic code that can be understood by all applications
14. A Standardized Protocol which everybody understands - Web services use
standardized industry protocol for the communication. All the four layers
(Service Transport, XML Messaging, Service Description, and Service
Discovery layers) uses well-defined protocols in the web services protocol
stack.
15. Reduction in cost of communication - Web services use SOAP over HTTP
protocol, so you can use your existing low-cost internet for implementing web
services.

Web service Architecture

Every framework needs some sort of architecture to make sure the entire framework
works as desired. Similarly, in web services, there is an architecture which consists of
three distinct roles as given below
 16. Provider - The provider creates the web service and makes it available to
client application who want to use it.
17. Requestor - A requestor is nothing but the client application that needs to
contact a web service. The client application can be a .Net, Java, or any other
language based application which looks for some sort of functionality via a
web service.
18. Broker - The broker is nothing but the application which provides access to
the UDDI. The UDDI, as discussed in the earlier topic enables the client
application to locate the web service.

The diagram below showcases how the Service provider, the Service requestor and
Service registry interact with each other.

19. Publish - A provider informs the broker (service registry) about the existence
of the web service by using the broker's publish interface to make the service
accessible to clients
20. Find - The requestor consults the broker to locate a published web service
21. Bind - With the information it gained from the broker(service registry) about
the web service, the requestor is able to bind, or invoke, the web service.

Web service Characteristics

Web services have the following special behavioral characteristics:

22. They are XML-Based - Web Services uses XML to represent the data at the
representation and data transportation layers. Using XML eliminates any
 networking, operating system, or platform sort of dependency since XML is
the common language understood by all.
23. Loosely Coupled – Loosely coupled means that the client and the web service
are not bound to each other, which means that even if the web service changes
over time, it should not change the way the client calls the web service.
Adopting a loosely coupled architecture tends to make software systems more
manageable and allows simpler integration between different systems.
24. Synchronous or Asynchronous functionality- Synchronicity refers to the
binding of the client to the execution of the service. In synchronous
operations, the client will actually wait for the web service to complete an
operation. An example of this is probably a scenario wherein a database read
and write operation are being performed. If data is read from one database and
subsequently written to another, then the operations have to be done in a
sequential manner. Asynchronous operations allow a client to invoke a service
and then execute other functions in parallel. This is one of the common and
probably the most preferred techniques for ensuring that other services are not
stopped when a particular operation is being carried out.
25. Ability to support Remote Procedure Calls (RPCs) - Web services enable
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.
26. Supports Document Exchange - One of the key benefits 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.

--------------------------------------------------------------------------------------------------------------------------------------

Advantages of XML
1) It supports Unicode, allowing almost any information in any written human language to
be communicated.
2) It can represent common computer science data structures: records, lists, and trees.
3) Its self-documenting format describes structure and field names as well as specific values.
4) The strict syntax and parsing requirements make the necessary parsing algorithms
extremely simple, efficient, and consistent.
5) XML is heavily used as a format for document storage and processing, both online and
offline.
6) It is based on international standards.
7) It can be updated incrementally.
8) It allows validation using schema languages such as XSD and Schematron, which makes
effective unit-testing, firewalls, acceptance testing, contractual specification, and software
construction easier.
9) The hierarchical structure is suitable for most (but not all) types of documents.
10) It is platform-independent, thus relatively immune to changes in technology.
11) Forward and backward compatibility is relatively easy to maintain despite changes in
DTD (Document Type Definition) or Schema.
Disadvantages of XML
1) XML syntax is redundant or large relative to binary representations of similar data,
especially with tabular data.
2) The redundancy may affect application efficiency through higher storage, transmission
and processing costs
3) XML syntax is verbose, especially for human readers, relative to other alternatives ‘text-
based’ data transmission formats.
4) The hierarchical model for representation is limited in comparison to an object-oriented
graph
5) Expressing overlapping (non-hierarchical) node relationships requires extra effort.
6) XML namespaces are problematic to use and namespace support can be difficult to
correctly implement in an XML parser.
7) XML is commonly depicted as “self-documenting” but this depiction ignores critical
ambiguities.
8) The distinction between content and attributes in XML seems unnatural to some and
makes designing XML data structures harder.
9) Transformations, even identity transforms, result in changes to format (whitespace,
attribute ordering, attribute quoting, whitespace around attributes, newlines). These problems
can make diff-ing the XML source very difficult.
10) Encourages non-relational data structures (data non-normalized)
11)XML is very concrete and highly non-canonical. It introduces a very strong coupling
between the actual representation chosen and the processing program (unlike relational
storage and SQL

--------------------------------------------------------------------------------------------------------------------------------------

What is SOAP?
SOAP is an XML-based protocol for accessing web services over HTTP. It has some
specification which could be used across all applications.

SOAP is known as the Simple Object Access Protocol, but in later times was just shortened
to SOAP v1.2. SOAP is a protocol or in other words is a definition of how web services talk
to each other or talk to client applications that invoke them.

SOAP was developed as an intermediate language so that applications built on various

programming languages could talk easily to each other and avoid the extreme development
effort.

In this tutorial, you will learn-

 SOAP Introduction
 Advantages of SOAP
 SOAP Building blocks
  SOAP Message Structure
 SOAP Envelope Element
 SOAP Communication Model
 Practical SOAP Example

SOAP Introduction
In today's world, there is huge number of applications which are built on different
programming languages. For example, there could be a web application designed in Java,
another in .Net and another in PHP.

Exchanging data between applications is crucial in today's networked world. But data
exchange between these heterogeneous applications would be complex. So will be the
complexity of the code to accomplish this data exchange.

One of the methods used to combat this complexity is to use XML (Extensible Markup
Language) as the intermediate language for exchanging data between applications.

Every programming language can understand the XML markup language. Hence, XML was
used as the underlying medium for data exchange.

But there are no standard specifications on use of XML across all programming languages for
data exchange. That is where SOAP comes in.

SOAP was designed to work with XML over HTTP and have some sort of specification
which could be used across all applications. We will look into further details on the SOAP
protocol in the subsequent chapters.

Advantages of SOAP
SOAP is the protocol used for data interchange between applications. Below are some of the
reasons as to why SOAP is used.

 When developing Web services, you need to have some of language which can be used for
web services to talk with client applications. SOAP is the perfect medium which was
developed in order to achieve this purpose. This protocol is also recommended by the W3C
consortium which is the governing body for all web standards.
 SOAP is a light-weight protocol that is used for data interchange between applications. Note
the keyword 'light.' Since SOAP is based on the XML language, which itself is a light weight
data interchange language, hence SOAP as a protocol that also falls in the same category.
 SOAP is designed to be platform independent and is also designed to be operating system
independent. So the SOAP protocol can work any programming language based applications
on both Windows and Linux platform.
 It works on the HTTP protocol –SOAP works on the HTTP protocol, which is the default
protocol used by all web applications. Hence, there is no sort of customization which is
required to run the web services built on the SOAP protocol to work on the World Wide
Web.

SOAP Building blocks

The SOAP specification defines something known as a "SOAP message" which is what is
sent to the web service and the client application.

The diagram below shows the various building blocks of a SOAP Message.

The SOAP message is nothing but a mere XML document which has the below components.

 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.

A simple example of a complex type is shown below.

Suppose we wanted to send a structured data type which had a combination of a "Tutorial
Name" and a "Tutorial Description," then we would define the complex type as shown below.

The complex type is defined by the element tag <xsd:complexType>. All of the required
elements of the structure along with their respective data types are then defined in the
complex type collection.

<xsd:complexType>
<xsd:sequence>
<xsd:element name="Tutorial Name" type="string"/>
<xsd:element name="Tutorial Description" type="string"/>
</xsd:sequence>
</xsd:complexType>

 A Body element that contains call and response information – This element is what contains
the actual data which needs to be sent between the web service and the calling application.
Below is an example of the SOAP body which actually works on the complex type defined in
the header section. Here is the response of the Tutorial Name and Tutorial Description that
is sent to the calling application which calls this web service.

<soap:Body>
<GetTutorialInfo>
<TutorialName>Web Services</TutorialName>
<TutorialDescription>All about web
services</TutorialDescription>
</GetTutorialInfo>
</soap:Body>

SOAP Message Structure

One thing to note is that SOAP messages are normally auto-generated by the web service
when it is called.

Whenever a client application calls a method in the web service, the web service will
automatically generate a SOAP message which will have the necessary details of the data
which will be sent from the web service to the client application.

As discussed in the previous topic, a simple SOAP Message has the following elements –

 The Envelope element

 The header element and
 The body element
 The Fault element (Optional)

Let's look at an example below of a simple SOAP message and see what element actually
does.
 1. As seen from the above SOAP message, the first part of the SOAP message is the envelope
element which is used to encapsulate the entire SOAP message.
2. The next element is the SOAP body which contains the details of the actual message.
3. Our message contains a web service which has the name of "Guru99WebService".
4. The "Guru99Webservice" accepts a parameter of the type 'int' and has the name of
TutorialID.

Now, the above SOAP message will be passed between the web service and the client
application.

You can see how useful the above information is to the client application. The SOAP
message tells the client application what is the name of the Web service, and also what
parameters it expects and also what is the type of each parameter which is taken by the web
service.

SOAP Envelope Element

The first bit of the building block is the SOAP Envelope.
The SOAP Envelope is used to encapsulate all of the necessary details of the SOAP
messages, which are exchanged between the web service and the client application.

The SOAP envelope element is used to indicate the beginning and end of a SOAP message.
This enables the client application which calls the web service to know when the SOAP
message ends.

The following points can be noted on the SOAP envelope element.

 Every SOAP message needs to have a root Envelope element. It is absolutely mandatory for
SOAP message to have an envelope element.
 Every Envelope element needs to have at least one soap body element.
 If an Envelope element contains a header element, it must contain no more than one, and it
must appear as the first child of the Envelope, before the body element.
 The envelope changes when SOAP versions change.
 A v1.1-compliant SOAP processor generates a fault upon receiving a message containing the
v1.2 envelope namespace.
 A v1.2-compliant SOAP processor generates a Version Mismatch fault if it receives a
message that does not include the v1.2 envelope namespace.

Below is an example of version 1.2 of the SOAP envelope element.

<?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:Body>
<Guru99WebService xmlns="http://tempuri.org/">
<TutorialID>int</TutorialID>
</Guru99WebService>
</soap:Body>
</SOAP-ENV:Envelope>

The Fault message

When a request is made to a SOAP web service, the response returned can be of either 2
forms which are a successful response or an error response. When a success is generated, the
response from the server will always be a SOAP message. But if SOAP faults are generated,
they are returned as "HTTP 500" errors.

The SOAP Fault message consists of the following elements.

1. <faultCode>- This is the code that designates the code of the error. The fault code can be
either of any below values
1. SOAP-ENV:VersionMismatch – This is when an invalid namespace for the SOAP
Envelope element is encountered.
2. SOAP-ENV:MustUnderstand - An immediate child element of the Header element,
with the mustUnderstand attribute set to "1", was not understood.
3. SOAP-ENV:Client - The message was incorrectly formed or contained incorrect
information.
4. SOAP-ENV:Server - There was a problem with the server, so the message could not
proceed.
2. <faultString> - This is the text message which gives a detailed description of the error.
 3. <faultActor> (Optional)- This is a text string which indicates who caused the fault.
4. <detail>(Optional) - This is the element for application-specific error messages. So the
application could have a specific error message for different business logic scenarios.

Example for Fault Message

An example of a fault message is given below. The error is generated if the scenario wherein
the client tries to use a method called TutorialID in the class GetTutorial.

The below fault message gets generated in the event that the method does not exist in the
defined class.

<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
<faultstring xsi:type="xsd:string">
Failed to locate method (GetTutorialID) in class (GetTutorial)
</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Output:

When you execute the above code, it will show the error like "Failed to locate method
(GetTutorialID) in class (GetTutorial)"

SOAP Communication Model.

All communication by SOAP is done via the HTTP protocol. Prior to SOAP, a lot of web
services used the standard RPC (Remote Procedure Call) style for communication. This was
the simplest type of communication, but it had a lot of limitations.

Let's consider the below diagram to see how this communication works. In this example, let's
assume the server hosts a web service which provided 2 methods as

 GetEmployee - This would get all Employee details

 SetEmployee – This would set the value of the details like employees dept, salary, etc.
accordingly.

In the normal RPC style communication, the client would just call the methods in its request
and send the required parameters to the server, and the server would then send the desired
response.
The above communication model has the below serious limitations

1. Not Language Independent – The server hosting the methods would be in a particular
programming language and normally the calls to the server would be in that programming
language only.
2. Not the standard protocol – When a call is made to the remote procedure, the call is not
carried out via the standard protocol. This was an issue since mostly all communication over
the web had to be done via the HTTP protocol.
3. Firewalls – Since RPC calls do not go via the normal protocol, separate ports need to be
open on the server to allow the client to communicate with the server. Normally all firewalls
would block this sort of traffic, and a lot of configuration was generally required to ensure
that this sort of communication between the client and the server would work.

To overcome all of the limitations cited above, SOAP would then use the below
communication model

1. The client would format the information regarding the procedure call and any arguments
into a SOAP message and sends it to the server as part of an HTTP request. This process of
encapsulating the data into a SOAP message was known as Marshalling.
2. The server would then unwrap the message sent by the client, see what the client requested
for and then send the appropriate response back to the client as a SOAP message. The
practice of unwrapping a request sent by the client is known as Demarshalling.
What is an XML Schema?
An XML Schema describes the structure of an XML document.

The XML Schema language is also referred to as XML Schema Definition (XSD).

XSD Example
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

</xs:schema>

The purpose of an XML Schema is to define the legal building blocks of an XML document:

 the elements and attributes that can appear in a document

 the number of (and order of) child elements
 data types for elements and attributes
 default and fixed values for elements and attributes

Why Learn XML Schema?

In the XML world, hundreds of standardized XML formats are in daily use.

Many of these XML standards are defined by XML Schemas.

XML Schema is an XML-based (and more powerful) alternative to DTD.

XML Schemas Support Data Types

One of the greatest strength of XML Schemas is the support for data types.
  It is easier to describe allowable document content
 It is easier to validate the correctness of data
 It is easier to define data facets (restrictions on data)
 It is easier to define data patterns (data formats)
 It is easier to convert data between different data types

XML Schemas use XML Syntax

Another great strength about XML Schemas is that they are written in XML.

 You don't have to learn a new language

 You can use your XML editor to edit your Schema files
 You can use your XML parser to parse your Schema files
 You can manipulate your Schema with the XML DOM
 You can transform your Schema with XSLT

XML Schemas are extensible, because they are written in XML.

With an extensible Schema definition you can:

 Reuse your Schema in other Schemas

 Create your own data types derived from the standard types
 Reference multiple schemas in the same document

XML Schemas Secure Data Communication

When sending data from a sender to a receiver, it is essential that both parts have the same
"expectations" about the content.

With XML Schemas, the sender can describe the data in a way that the receiver will
understand.

A date like: "03-11-2004" will, in some countries, be interpreted as 3.November and in other
countries as 11.March.

However, an XML element with a data type like this:

<date type="date">2004-03-11</date>

ensures a mutual understanding of the content, because the XML data type "date" requires the
format "YYYY-MM-DD".
Well-Formed is Not Enough
A well-formed XML document is a document that conforms to the XML syntax rules, like:

 it must begin with the XML declaration

 it must have one unique root element
 start-tags must have matching end-tags
 elements are case sensitive
 all elements must be closed
 all elements must be properly nested
 all attribute values must be quoted
 entities must be used for special characters

Even if documents are well-formed they can still contain errors, and those errors can have
serious consequences.

Think of the following situation: you order 5 gross of laser printers, instead of 5 laser
printers. With XML Schemas, most of these errors can be caught by your validating software.

XML Schemas Support Data Types

One of the greatest strength of XML Schemas is the support for data types.

 It is easier to describe allowable document content

 It is easier to validate the correctness of data
 It is easier to define data facets (restrictions on data)
 It is easier to define data patterns (data formats)
 It is easier to convert data between different data types

XML Schemas use XML Syntax

Another great strength about XML Schemas is that they are written in XML.

 You don't have to learn a new language

 You can use your XML editor to edit your Schema files
 You can use your XML parser to parse your Schema files
 You can manipulate your Schema with the XML DOM
 You can transform your Schema with XSLT

XML Schemas are extensible, because they are written in XML.

With an extensible Schema definition you can:

 Reuse your Schema in other Schemas

 Create your own data types derived from the standard types
 Reference multiple schemas in the same document
What is an XML transformation?
0

By admin

July 11th, 2013

XML has strong methods to use or reuse data. The mechanism of reusing data is called
transformation in extensible language (Extensible Stylesheet Language). The transformations
are making the XML language really interesting. For example, after validating a data file, you
will have the possibility to make a transformation to use the data in MS Office 2003, or you
could make a marketing brochure to create a sales report.

You can use the transformations to exchange data between the backend systems, such as
databases. For the moment, let’s suppose A stores sales data in a chart that works well for the
sales department. B database stores data from incomes and expenses in a table structure
adapted for the accounting department. The B database can use a transformation to accept
data from A and to write the correct data.

The combination between the file and the transformation scheme is called an elementary
XML system. The data file is validated according with the scheme, than it is reproduced. In
this case, the transformation distributes data from a chart to a Web page.

A structure with an XML file and a transformation scheme

The next code example shows one of the methods to write a transformation. The code loads
data <DOG> in a chart from a web page. The purpose of the example is not to show you how
you could write in a transformation; it has to show you one of the forms that the
transformation can take.

<?xml version=”2.1″?>

<xsl:style sheet version=”2.1″>

<TABLE>

<TR>

<TH>Nameofdog</TH>

<TH>Breedofdog</TH>
<TH>Ageofdog</TH>

<TH>OwnerLicense</TH>

<TH>Ownerdof</TH>

</TR>

<xsl:for-each select=”DOG”>

<TR ALIGN=”RIGHT” VALIGN=”BOTTOM”>

<TD>

<xsl:value-of select=”NAMEOFDOG”/>

</TD>

<TD>

<xsl:value-of select=”BREEDOFDOG”/>

</TD>

<TD>

<xsl:value-of select=”AGEOFDOG”/>

</TD>

<TD>

<xsl:value-of select=”LICENSEOFDOG”/>

</TD>

<TD>

<xsl:value-of select=”OWNEROFDOG”/>

</TD>

</TR>

</xsl:for-each>

</TABLE>
This example shows a type of transformation when it is coded. However, remember that you
have the possibility to describe exactly what you want from the data in the English language.
As an example, go to the IT department and say you want to print the sales charts for some
regions in the next two years. “And it must look like this.” The IT department can write (or
modify) a transformation so it could have the expected result.

What makes it even more convenient is the fact that Microsoft and other companies create
transformations for any kinds of activities. I the future, you will be able to download a
transformation that will meet all your necessities and it can also comply with any purpose.
This means that XML will cost less in the future.

However, it will pass some time before the perfect transformation would be invented. For the
moment, the software developers are trying to develop universal transformation. For
example, they are trying to find a marketing transformation that will be able to extract the
charts from any sales report.

If the developers would manage to create this perfect transformation code, the usage of XML
will be extended. Practically, anyone would be able to use the XML language directly,
without a complicated interface or IT support

Components of .Net Framework

There are many articles are available in the web on this topic; I just want to add one more article
over the web by explaining Components of .Net Framework.

Components of .Net Framework

Net Framework is a platform that provides tools and technologies to develop Windows, Web and
Enterprise applications. It mainly contains two components,

1. Common Language Runtime (CLR)

2. .Net Framework Class Library.

1. Common Language Runtime (CLR)

.Net Framework provides runtime environment called Common Language Runtime (CLR).It
provides an environment to run all the .Net Programs. The code which runs under the CLR is called
as Managed Code. Programmers need not to worry on managing the memory if the programs are
running under the CLR as it provides memory management and thread management.

Programmatically, when our program needs memory, CLR allocates the memory for scope and de-
allocates the memory if the scope is completed.

Language Compilers (e.g. C#, VB.Net, J#) will convert the Code/Program to Microsoft Intermediate
Language (MSIL) intern this will be converted to Native Code by CLR. See the below Fig.
There are currently over 15 language compilers being built by Microsoft and other companies also
producing the code that will execute under CLR.

2. .Net Framework Class Library (FCL)

This is also called as Base Class Library and it is common for all types of applications i.e. the way
you access the Library Classes and Methods in VB.NET will be the same in C#, and it is common for
all other languages in .NET.

The following are different types of applications that can make use of .net class library.

1. Windows Application.
2. Console Application
3. Web Application.
4. XML Web Services.
5. Windows Services.

In short, developers just need to import the BCL in their language code and use its predefined
methods and properties to implement common and complex functions like reading and writing to
file, graphic rendering, database interaction, and XML document manipulation.

Below are the few more concepts that we need to know and understand as part of this .Net
framework.

3. Common Type System (CTS)

It describes set of data types that can be used in different .Net languages in common. (i.e), CTS
ensures that objects written in different .Net languages can interact with each other.

For Communicating between programs written in any .NET complaint language, the types have to
be compatible on the basic level.

The common type system supports two general categories of types:

Value types:

Value types directly contain their data, and instances of value types are either allocated on the
stack or allocated inline in a structure. Value types can be built-in (implemented by the runtime),
user-defined, or enumerations.

Reference types:

Reference types store a reference to the value's memory address, and are allocated on the heap.
Reference types can be self-describing types, pointer types, or interface types. The type of a
reference type can be determined from values of self-describing types. Self-describing types are
further split into arrays and class types. The class types are user-defined classes, boxed value
types, and delegates.

4. Common Language Specification (CLS)

It is a sub set of CTS and it specifies a set of rules that needs to be adhered or satisfied by all
language compilers targeting CLR. It helps in cross language inheritance and cross language
debugging.

Common language specification Rules:

It describes the minimal and complete set of features to produce code that can be hosted by CLR.
It ensures that products of compilers will work properly in .NET environment.

Sample Rules:

1. Representation of text strings

2. Internal representation of enumerations

3. Definition of static members and this is a subset of the CTS which all
.NET languages are expected to support.

4. Microsoft has defined CLS which are nothing but guidelines that
language to follow so that it can communicate with other .NET
languages in a seamless manner.

Below mentioned the .Net Architecture stack for easy understanding.