Along with WSDL and UDDI, SOAP is another element in the distributed arm of .NET and the Web services it hosts. Besides being a mechanism for invoking RPCs, it can also be used as a wrapper around entire XML documents or binary data, as is the case with the DIME protocol from Microsoft. This greatly expands what can be done with this protocol and will continue to expand as XML Web services evolve.

As mentioned, when using Web services, SOAP is not the only protocol that can be used to call Web services. For example, a simple HTTP GET request can be made as long as it is passing and receiving simple data types, such as strings. However, when you begin to work with more complex types, such as ADO Datasets, it becomes necessary to use a protocol such as SOAP and more specifically, XML schemas to describe such data as referenced in the SOAP message. SOAP was designed for simplicity and elegance, and it does not do some of things you might expect. Some of the elements not covered (at this time) are:

1. Message batching - You must create your means of batching messages/functions calls.
2. Distributed garbage collection - There are no means of telling the server that the client has suddenly disappeared.
3. Object references - Holding state from the client and server is an implementation-specific issue.
4. Reliability protocols - This really lies at the application protocol level and can be designed into your application, especially if HTTP is being used as the communication protocol.

SOAP currently does not outline these specific elements like other remote protocols, such as DCOM and CORBA. But it does what it was intended to do - provide us with a simple, standard specification to drive the description of the data types and methods for using and producing Web services. It is important to note, however, that a SOAP "message" only specifies the XML format for the package sent across the wire. As long as you have a well-formed XML document encapsulated in the necessary SOAP tags, you have a valid SOAP message. Any compliant SOAP implementation on the server should understand the request and should service it. In fact, although the default application protocol for SOAP is HTTP, it does not require it. That's the simplicity of it. Other protocols, such as SMTP, FTP, and even asynchronous messaging protocols, will soon be supported. Because HTTP is the Internet protocol, it is also the default for SOAP. This is why when you hear about XML Web services, it is usually assumed that there will be a one-to-one correspondence with both SOAP and HTTP.

To truly understand SOAP, you first have to understand a few basic elements of the language that makes up a SOAP message. Once again, that language is XML. Most interaction with SOAP usually takes place through a toolkit or service of some kind. For example, the Microsoft SOAP Toolkit (Java has its own) hides the exact format of a SOAP message by providing high-level programmatic client objects to use. These clients provide the code to serialize, de-serialize, send, and receive SOAP messages to and from a corresponding SOAP server, such as a .NET Web service. This simplifies developers' lives but it also shelters them from understanding the format in which their messages are bundled. Knowing such details will help your debugging and designing efforts in the future and it is recommended that you become at least slightly acquainted with such details.

About the Author
Spec-India is a Custom Application Development Company that offers cost effective Software development, Mobile Software Application development, Custom Software development, ASP.Net development, Legacy system migration, Onsite Software development and Application support and maintenance.

Submitted by spec-india