In the past communication

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.


In the past communication between any application was very difficult. Rather to say difficult it is expensive and time consuming. And the support for each connection also needs to be looked up. During those days there were technologies which supports the communication. But did have some drawbacks. Technologies like DCOM and CORBA has its own limitation .Due to being a single vendor solution it was difficult to implement. These technologies used non-human readable protocols and were only limited to use within an organisation as they were firewall unfriendly. This has a played a a role in inspiring many technies at Microsoft to develop a new communication protocol whose first version 1.1. was published in 1999. This protocol SOAP was also been embraced by other big companies like IBM and many small companies like userland software and developmentor to submit version 1.1 of SOAP to w3c in 2000.And later this version was published by w3c as a note.

In may 2000 Developmentor,IBM,Lotus,Microsoft and user land suggested SOAP 1.1 in a note to W3C as a protocol for exchanging information in a distributed environment. Soap 1.2 become the w3c recommendation on 24th June 2003.

Soap has been implemented over a 20 platforms in 60 languages.To date there are 50 SOAP toolkits have appeared once after the first introduction of the specification. Even more on its way. The interoperability between these toolkits needs to be perfect to realise the full value of the SOAP.


SOAP stands for Simple Object Access Protocol is a communication protocol is used for communication between applications. It communicate using the World Wide Web's Hypertext Transfer Protocol (HTTP)and its Extensible Mark-up Language (XML).The platform independent Soap is simple and extensible .Soap is not any language dependent it is compatible with any language. Soap allows to get around firewalls. The official definition for SOAP is that it is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment.

In simple language SOAP is a communication protocol used to communicate between two application.If you see todays application use RPC[remote procedure calls] to communicate between objects like CORBA and DCOM [ DCOM (Distributed Component Object Model)andCORBA (Common Object Request Broker Architecture)].Due to the fact that RPC represents a combatibility and security problem ,firewalls and proxy server provides a barrio for this .Another option for this HTTP which is supported by all the internet browsers and servers.SOAP communicates using HTTP.SOAP helps the applications to communicate each other irrespective of there operating systems and the programming languages .As we know SOAP is an ordinary XML document.It contains a envelope which identifies XML documents as a SOAP messages. It carries an optional header element which carries the header information. It has a body element that contains call and response information.and has an optional fault element which provides information about the errors that occurred during the process.

Web service had played an important role in solving this issue .It has develop a set of universally-supported protocols that supports communication in a large scale than the past. SOAP is one such protocol. If we see today there are many problems like many different operating systems, platforms,firewalls and methods of making RPC . To ensure interoperability over internet both the client and server need to know about the security types and trust and implenmentation details.Any remote program can give more power but when it gone beyond the remote it has to face the firewall. SOAP answers all these problems.

Soap workings

Soap messages

Soap example

Recommendation.SOAP can be broadly described as a message and Remote Procedure Telephone (RPC) protocol. The official definition for SOAP is that it is: "a lightweight protocol intended for exchanging structured facts in a decentralized, distributed globe. SOAP uses XML technologies to define an extensible messaging framework, which provides a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming imitation and other implementation specific semantics."

Essentially, this is how SOAP works: when a program invokes a web supply path the request and all other essential data is packaged (i.e. serialised into an XML-based format) in a SOAP request envelope and sent to the web supply. When the web supply receives this envelope it begins by reversing (deserialising) the initial processing that made that envelope which will result in the execution of its method's phone. The web supply then serialises it response in a SOAP envelope and sends it to the client application. The client deserialises the response and retrieves the result of the path telephone SOAP's place in the web services technology stack is as a standardized packaging protocol for the messages shared by applications. The specification defines nothing more than a simple XML-based envelope for the information being transferred, and a set of rules for translating application and platform-specific data types into XML representations. SOAP's design makes it suitable for a wide variety of application messaging and integration patterns. This, for the most part, contributes to its growing popularity. This chapter explains the parts of the SOAP standard. It covers the message format, the exception-reporting mechanism (faults), and the system for encoding values in XML. It discusses using SOAP over transports that aren't HTTP, and concludes with thoughts on the future of SOAP. You'll learn what SOAP does and how it does it, and get a firm understanding of the flexibility of SOAP. Later chapters build on this to show how to program with SOAP using toolkits that abstract details of the XML.

2.4SOAP message

Each SOAP message will have:

  • Outer layer(s) for underlying protocols-Only consider HTTP
  • Envelope (XML root element)
  • Header (optional)-Multiple header blocks/entries,For different purposes - factorisation,For different processing stages .
  • Actors
  • Body (mandatory)-The payload,Zero or more XML elements,May be a Fault element
  • Specific fault reporting standard

2.5An example of SOAP

The following is the SOAP message of a simple Visual Basic hello world web service:

  1. POST /WebServiceHelloWorld/HelloWorldService.asmx HTTP/1.1
  2. Host: localhost
  3. Content-Type: text/xml; charset=utf-8
  4. Content-Length: xxx
  5. SOAPAction: ""
  6. ?xml version="1.0" encoding="utf-8"?
  7. soap:Envelope xmlns:xsi="" xmlns:xsd="" xmlns:soap="">
  8. soap:Body
  9. HelloWorld xmlns="" /
  10. /soap:Body
  11. /soap:Envelope


Another building block of the web service architecture is the Web Services Description Language (WSDL), pronounced wiz del. Like SOAP, it's a W3C specification note.WSDL-S was developed by IBM and the university of Georgia,and presented to w3c as a member submission in late is a proposal for making up web services descriptions with main advantage of WSDL-S is the reuse of WSDL.Building upon an existing web service standard such as WSDL,which has been a w3c standard since 2001,will make the added semantic layer more pratical and easier to be adopted by application developers.WSDL-S also depends on domain-specific ontologies.its semantic annotations are added to different parts of a WSDL document by using domain ontologiesanother advantage of WSDL-S is that it does not limit the choice of the language in which the domain-specific ontology is constructed .On the other hand,this means that the soft agent responsible for processing the WSDL-S documents has to be smarter;it has to be capable of 'understanding'several different ontology languages.

It is also important to know that WSDL-S mainly focuses on dynamic discovery of the serviceds.In addition to semantically marking up inputs and outputs of an operation,it also adds the concepts of precondition and effect.however it doesnot provide enough semantic information for automatic invocation, composition, and monitoring of a given service.In other words,the WSDL-S proposal focuses on adding semantics to the so-called abstract parts of a WSDL document,leaving the concrete parts untouched.Recall that in a given WSDL document,the abstract parts include porttype,operations,and messages;the rest of the document comprises the concrete parts.

It's a specification whose syntax (vocabulary) is XML-based. Each web service would require a WSDL file associated with it which will contain information that would help a client application consume that service such as:

  • the methods exposed by the web service
  • the arguments accepted by these methods
  • XSD document (or other type system) used to define the types used by the web service
  • the type of (serialization) encoding used

Despite the fact that WSDL files are XML-based, they can be very difficult to create manually. Luckily, most SOAP toolkits will allow you to automatically generate the WSDL file for a particular web service. WSDL to a web service is equivalent to what XSD means to an XML file. Just like an XML parser needs an XML file's XSD to understand it, a web service client also needs the WSDL document of a web service in order to consume it.


UDDI is one of the main components in the structure of SOAP-based web services. However, there is a great deal of discussion and confusion over the future of this standard. Questions as to whether UDDI is still alive are often posed on many websites, blogs and discussion boards that deal with web services. However, no clear answer seems to emerge from these discussions. UDDI is indeed a very interesting set of protocols. While UDDI has been the pioneering work of three main big companies (Microsoft, IBM and Ariba) since 2000 it is now being regulated by OASIS. Like the rest of the other standards of web services, it is XML-based and platform independent and promised more than it was able to deliver. The rationale behind this specification was that once web services have been developed, they have to be published to a depository (i.e. a registry) on the internet and placed under certain categories according to their functions so that they can be accessed (and consumed) by other developers. Publishing and searching for web services can either be accomplished through a web-based interface or dynamically through a set of UDDI APIs (Application Programming Interfaces).

In reality, however, very little serious real world web services have used this complex system. Some analysts see limitations with UDDI and regard it as being focused on the information model that enables the convenient categorization of the published services. They argue that UDDI does not address critical requirements such as defining and enforcing complex authorization policies, reference integrity that would guarantee that the service reference returned to the application (in response to a Get service request for example) is correct, dynamic instantiation of services and references and personalization (e.g. in UDDI the result of a specific query is the same for any requestor). Given these limitations, some authors are proposing the use of search engines as potential candidate for replacing UDDI. IBM, Microsoft and SAP decided to close their UDDI Business Registry (UBR) last year claiming that UBR is a relic of earlier versions for UDDI that provided a proof of concept for early web service business applications and therefore had to be closed . Some analysts argue that, unlike a private UDDI registry, one of the main disadvantages of the UBR is that it suffers from a great deal of "stale data" due to the fact that it allows any public user to register and publish business entities and services that could possibly be "phoney".

  1. W3CSoapActivities. Available at:[Accessed 10 November 2009]. Tom clements.January 2002 (originally posted August 2001).
  2. W3CSoapdefinition. Available at:[Accessed 10 November 2009]. Tom clements.January 2002 (originally posted August 2001).
  3. Overview of SOAP.Available at: .[Accessed 10 November 2009].