SOAP in Enterprise Applications

XML has been the focus of many a debate and discussion among the application developers community. In 1998 itself there were moves to transport XMLdata. The last seven months has seriously turned to addressing this issue.Today,around 15 XML communication protocols exist. Among them SOAP (Simple Object Access Protocol) seems to be in the limelight. Developers specifically are beginning to explore its feasibility in enterprise applications.

Soap is a lightweight protocol for exchange of information in a decentralised, distributed environment. Which means the provision of standard methods of sending communication from one web server to another, regardless of platform or web server software use. This simple, non-intrusive wire protocol has been deviced to facilitate server communications via XML formatted messages through an HTTP protocol.

Where is the need for XML transport when we already have HTTP? This can be elucidated with an example.Suppose suppliers have to convey a price change information to a number of retailers. Naturally the retailers would want to place orders with the changed price. Each sender, retailer or a supplier,should write this communication in a way that is comprehensible at the receiving end.All these suppliers should also have their retailer's addresses, make sure that the retailer have received all the documents and the contact should be kept up even if the Internet routing to its server fails. The retailer is also expected to do the same thing.

HTTP has no solution for any of these problems. On many occasions it takes upon itself the task of supporting the required coordination, security and reliability. On many others it does without it. No doubt HTTP is a very useful protocol. However originally created to execute simple tasks such as transferring files, today accessing applications is also being delegated as its responsibility.

Internet protocols like the DCOM (Distributed Component Object Model) and IILOP (Internet Interorb Protocol)encounter various kinds of trouble on the Net. Firewalls pose the most danger for them. They are devised to obstruct Internet Protocols. Firewalls are however ineffective against HTTP. Distributed object protocol should be used to access remote application servers than to force fit HTTP into this role. Firewall administrators refuse to open more than absolutely necessary. The distributed object access available with HTTP is Microsoft's SOAP. The server receives a comprehensive client request which is then posted as a regular HTTP operation that gives normal HTTP responses. The XML format is used for requests and results. Firewall cannot impede SOAP as it cannot block HTTP. What is more SOAP is not bound to any specific distributed technology object.

Lucidity and extensibility of usage is the high point of SOAP.It is not dependent on any object model. Object functions (such as instantiating code and garbage collection) are left to the infrastructure on which client and servers work. Irrespective of object models, applications are bound together by SOAP.

Any language may be used to implement a valid SOAP request. Formerly Java, Perl, and Windows version were used. Every usage should suit the exact parameters and responses cognisable to a SOAP entity.This will effect its interpolation with others of its kind.

SOAP can be used sans an operating system, programming language or object models. All it needs is an interface between systems by determining the kind of data that comes into the server and the kind of data that needs to come out of the system such as response and request. A support infrastructure, subject to the complexity or the simplicity of the application, is required to enable everyone to send, receive and comprehend relevant soap messages.

The SOAP-enabled thermostat would be an example of a simple application and an extranet application linking a large aerospace firm's engineering, marketing and inventory system with all its suppliers is a classic example of a complex one. SOAP can be advantageously executed in specific purpose enterprise applications. Example of a tailor made SOAP solution is the credit card payment which is executed securely, reliably and accurately. This is also known as face less building blocks provided by service providers.

A SOAP envelope, optional SOAP header and a SOAP body comprise a SOAP message which is an XML document. The envelope is the top element of an XML document containing the message. The header, a generic mechanism, adds features to a SOAP message in a decentralised manner. The mandatory information meant for the ultimate recipient is encoded in the body.

Although devised for only one-way transmissions SOAP messages can be combined to take upon request and response messages.Usually what happens is optimisation of SOAP applications where characteristics associated with a particular network are made full use of. HTTP bindings are used to deliver messages in HTTP response. When SOAP uses HTTP bindings the messages are delivered in HTTP response. A fixed path-the message path- is always taken, regardless of the protocol SOAP may be bound to. This facilitates processing not only at one or more intermediate nodes but also at the ultimate destination.

A SOAP message that comes in goes about detecting the different parts of a SOAP application. Then it checks the parts relating to the message and then goes on to processing it.In case it so happens that the destination of the SOAP application is not the same as that of the message, it deletes the verified parts and forwards the message.

Inaccuracies may creep into a SOAP message. Complete status information on the error may be obtained from the SOAP fault, which will appear just once in a body entry. The sub elements specified in the SOAP fault element are: an algorithm mechanism to detect faults is provided in a fault code element. Human comprehension of the error is dealt with by the fault string element.Detection of what caused an error to come up in a message path is done by the fault factor.We are given exact details on the location of the fault.

SOAP has not yet divulged much about its two-way communication. Layering these semantics is not an issue; however it is not empowered to operate beyond HTTP. Advanced issues such as object activation or lifetime managementhave not been addressed so far.