Web Services and SOAP
by: Spec-India
Total views: 188
Word Count: 701
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.
Article Source: http://www.ArticleStreet.com/profile/spec-india-10675.html
About the Author
Spec India is a Custom Software Application Development and Custom Software Solutions Company based in Ahmedabad, India. Our Services includes Legacy Application Migration and Interfaces, Java Application Development, ORACLE, .Net, and Mobile Computing Application.
Rating: Not yet rated