SOAP

we have alll been staring a form of self-describling data in the face every time we use a web browser. the

protocol is relatively lightweight is based on xml and is designed for the exchange of information in a

distributed computing environment. there is no concept of a central server in soap. all nodes can be

considered equals or even peers. 

the protocol is made up of a number of distict parts. the first is the envelope used to describle the content of a

message and some clues on how to go about processing it. the second part consists of the rules for

encoding instance of custom data types. this is one of the most critical parts of soap: its extensibility. the last

part describle the application of the envelop and data encoding rules for representing rpc calls and responses

including the use of http as the underlying transport.

rpc style distributed computing is the most common java usage of soap today, but it is not the only one. any

transport can be used to carry soap message.

soap differs from rmi corba and com in that it concentrates on the content effectively decoupling itself from

both implementation and underlying transport.

there are dozens of soap implementations and new ones emerge all the time. some are implemented in java

,some are not. some are free some are not. and inevitally some are good and some are not. the apache

software foundation has an ongoing project as apache soap. this is a java implementation of the soap

specification that can be hosted by servers that support java servlets.

glue is an implementation of soap developed by a compant call the mind electric. it relies on the web services

description language and it is free for most user.

all soap messages are packaged in an xml document called an envelope which is a structured container that

holds one soap message. the metaphor is appropriate because you struff everything you need to perform an

operation into an envelope and send it to a recipient who opens the envelope and reconstructs the original

contents so that it can perform the operation you requested. the contents of the soap envelope conform to 

the soap specification allowing the sender and the recipient to exchange messages in a language-neutral way.

the soap specification requires a soap implementation to support the transporting of the soap xml payloads

using http so it is no coincidence that the existing soap implementations all support http. soap can certainly be

used for request /response message exhange like rpc as wellas inherently one-way exchanges like smtp.

an rpc -style request messages usually result in a correspondong http response. the soap specification does

not define a bumbering system for decarling which version of the soap envelope you are using.

the fault is the only body element entry defined by soap. it is used to carry error infromation back to the

originator of a soap message.

it has become common practice to name the rerurn value struct bt appending the word response to the name

of the method that was invoked.

the lifetime of an object is an important part of any distributed system and is sometimes referred  to as service

scope  or service activation. in soap systems based on http, there are generally three service activation

models:

request-level service activation: this kind of service activation is useful for service obects that doesnot

maintain state.

to make the method call, we use the invoke() method of the call object with the url that we set up earlier as the

first parameter. the second parameter is a soap action url which is include as an http hearder entry,the invoke()

method returns an instance of org.apche.soap.rpc.Response; upon succeessful return,this object contains the

response from the server. After invoking the method,we call the getRetrunValue() method of the response

object. This method returns an instance of org.apache.soap.rpc.Parameter which contains the return value.