ed and distributed environment using all the capabilities offered by XML technology. It should be understood that SOAP is just a management pro- tocol and does not require development of client or server in a specific programing language, though most open source, SOAP-based, client-server developments are using Java. SOAP is stateless and does not enforce a specific schematic for the management data it has to exchange. SOAP was a recommendation from W3C (World Wide Web Consortium). The SOAP 1.2 recommendation has two parts. The first part defines the SOAP message envelope while the second part defines the data model and protocol binding for SOAP. Following with the XMLP discussion, the SOAP message envelope has a SOAP header and SOAP body. The header is identified using the tag <env:Header> and the body is identified using the tag <env:Body>. The header contains the transac- tion and management information as in most XML protocols. Standardizing bod- ies for Web services are working toward defining standard entries for the header in specific domains. The SOAP header block is not mandatory for message transmission. Specific information that can be used by SOAP intermediaries or destination nodes can be put in the header block. The SOAP body blocks/entries are mandatory for any message envelope to be valid and this block is the key information that is processed at the receiver. It can contain either the application data, the remote procedure call with parameters, or SOAP fault information. Some of the attributes in the SOAP header block are: env:role: The "role" attribute is used to identify the role of the specific target associated with the header block. This role can be standard roles or custom roles, and the absence of a role indicates that the role will be the final destination. env:mustUnderstand: The "mustUnderstand" attribute is used to specify the header block needing to be processed. It is more of a Boolean variable and can have a value of either "true" or "false." If the value of "mustUnder- stand" is tr