A typical web service is a piece of software that uses a standardized XML messaging system to make it available over the Internet. Specifically, a web service typically comprises a collection of functions that are packaged as a single entity and published to a network for use by other programs through XML based messages, wherein the XML based messages are exchanged via Internet based protocols. According to the Object Oriented (OO) architecture, applications exchange messages using Remote Procedure Calls (RPC) between various objects such as, for example, Distributed Component Object Model (DCOM) and Common Object Request-Broker Architecture (CORBA); however this architecture is not suitable for the Internet which uses HyperText Transfer Protocol (HTTP) to transport data. For example, RPC often presents compatibility and security issues, while most firewalls and proxy servers block RPC transactions.
As an alternative to RPC, a consortium of technology corporations developed and proposed to W3C, the Simple Object Access Protocol (SOAP) Internet protocol. The SOAP protocol simplifies application development by connecting graphic user interface desktop applications to powerful Internet servers using the standards of the Internet, namely HTTP and XML. SOAP is generally known as the preferred protocol for exchanging web services. Specifically, SOAP defines an envelope format and various rules for describing its contents. A SOAP message is an ordinary XML document which contains four primary elements, the envelope that identifies the XML document as a SOAP message; an optional Header element containing application specific information; a Body element containing call and response information; and, an optional Fault element providing information about errors that occur during message processing.
SOAP, in its current form, only defines one internal block which is the Fault block that can appear in the Body element. Without a standard structure to leverage, developers of components are forced to create their own message structure and create individual solutions to bridge multiple technologies and provide linkages to enterprise messaging infrastructure (EMI) infrastructure capabilities. Additionally, the time to deploy and maintenance costs within the EMI are driven up as each of these solutions includes unique handling logic.
Therefore, a need exists for a system and method for defining an expanded message envelope incorporating a number of standard header blocks, wherein each block is defined to store the data needed for a specific common infrastructure capability found within an entity's EMI.