As per W3C, web service can be defined as,

a software system designed to support interoperable machine-to-machine interaction over a network.

Web services are:
1. Platform independent
2. Designed to leverage existing technologies
3. Interoperable across disparate programming languages

The Role of Web Services

A web service exposes a remote service or executable procedure to a client application. Web services are designed to be platform independent; however, this platform independence is not without some cost. The cost of a web service’s platform independence is overhead, both in network and CPU usage.

Web Service
Web Service
Key Features :
Platform independent:

As shown in above figure, No CPU, operating system, or programming language-specific data or functionally is required for web services.

Designed to leverage existing technologies:

Web services make extensive use of XML and HTTP technologies. Both of these technologies have large toolset and knowledge bases.

Interoperable across disparate programming languages:

Web services use a client/server model. It is possible to have a client written in one programming language communicating with a server written in a different language.

The Java EE 6 platform enables the easy creation or addition of web services to our appficafions.

Types of Web Services

There are two types of web services.


SOAP stands for Simple Object Access Protocol. SOAP is an XML based industry standard protocol for designing and developing web services. Since it’s XML based, it’s platform and language independent. So our server can be based on JAVA and client can be on .NET, PHP etc. and vice versa.


REST is an architectural style for developing web services. It’s getting popularity recently because it has small learning curve when compared to SOAP. Resources are core concepts of Restful web services and they are uniquely identified by their URIs. For more details please refere.

Overview On SOAP Web Service

SOAP was an acronym for Simple Object Access Protocol. It was later named to just SOAP. But this simple abbreviation represented a huge advance in the world of web services. As We’ve previously described, SOAP is an XML-based language that represents request and response messages between clients and servers. SOAP was developed for Microsoft in the late 1990’s by a group of developers led by Dave Winer. And since 2000, has been managed by the WorldWide Web Consortium or the W3C.

It’s the foundational technology underlying a whole set of specifications known as the WS standards. And is the critical glue binding together web service tool kits for many operating systems and programming languages. SOAP had three major goals in its development.

Extensibility :

Unlike some XML languages, SOAP doesn’t target a specific type of business process. Instead, like a programming language, it’s designed to handle whatever processes and data types are required for the job at hand.

Neutrality :

While SOAP messages are most commonly sent and received over HTTP, it can also be used with other transport protocols, such as SMTP, FTP, JMS, or the Java Message Service, and others.

Independence :

The original SOAP toolkit was built for programming languages that were supported by Microsoft, such as Visual Basic and C++. But tool kits were very quickly created for many other languages and platforms.

There are two versions of SOAP in current use.

SOAP 1.1

The final recommendation for SOAP 1.1 was released in 2000, and it’s still in use. SOAP 1.2 was released in 2007. Most major SOAP toolkits today support both standards. For example, Microsoft’s ASP.NET supports web services that send messages in both 1.1 and 1.2 to maximize the interoperability between servers and available clients.

SOAP 1.2

SOAP 1.2 had many advances, including clearer processing and extensibility models, and better web integration. For most new applications, we should use SOAP 1.2. But again, both are still available. When a developer works with SOAP, they’re freed of any responsibility for serialization or deserialization of XML messages, since that all handled by the SOAP toolkit or the libraries they’re using in their application. As a developer we’ll need a library that is compatible your platform and programming language.

WSDL and SOAP Envelope

You’ll indicate which service you want to use, by providing a document in an XML format, known as web service description language or WSDL. And then you’ll call the remote services objects and methods just as though you were calling local functions. Messages are sent back and forth in a format known as an envelope Think of it as being like a real envelope containing a message. The request envelope tells the server what operation to execute, and the response envelope contains the returned data. Or if a problem occurs, a fault message.

SOAP Communication
SOAP Communication
Advantage of SOAP

It’s supported broadly by many platforms and languages. It frees the developer from having to deal directly with creating or reading web service messages, since the tool kits translate from native data types and back again. And when used with HTTP, it works with existing internet infrastructure.

Disadvantage of SOAP

It’s primary disadvantage is its size. As we’ve previously described, XML is more verbose than competing message formats like JSON, and therefore takes more time and bandwidth. And the translation from native data to XML and back again also takes time. How much depends on the quality of the SOAP toolkit being used, and not all tool kits are equal.

In next articles, we will try to cover SOAP Envelope, WSDL and steps to create SOAP Web Service.

That’s it for now in SOAP Web Service, Keep Learning and Sharing. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *