SOAP Communication Model

Mainly used SOAP communication models are,

  1. Remote Procedure Call (RPC)
  2. Document (or Message).

1)      RPC-style SOAP Services

RPC- style is a type of Web service which acts as a remote object to a client application. RPC is service specific interface. It is a type of interaction between a client and RPC-style Web service. In this method client gives their request as a method call with a set of arguments, which returns a response containing a return value. RPC is Programming model that application developers use to create distributed computing applications. Examples of existing RPC-based systems are,

b) Java RMI
c) EJB
d) CORBA etc

For deploying distributed applications across the Internet using existing RPC based systems we are using two different roadblocks.

1) The lack of interoperability between heterogeneous RPC-based systems hinders the rapid deployment of and access to web-based services.

2) Traditional RPC-based systems have problems accessing distributed applications through Internet firewalls.   Most firewalls limit the use of random ports because they are configured to accept connections to only a few ports, such as the standard HTTP port 80.  This limits the ability to deploy distributed object protocols, like DCOM, that rely on dynamically assigned ports for remote method invocations.

SOAP is used as the wire format for a remote procedure call (RPC). It helps to transmitted information on the network to and from a remote computer. Here we are using two different communication methods.

1) Marshalling: – The process of an  application invoking a remote procedure call encodes information into the wire format prior to transmission is  known as marshalling.

2) Unmarshalling:- The process of the receiver of the RPC request decodes the information from the wire format into a format supported by the receiver’s local environment, is known as unmarshalling.  The process is reversed to return the result of an RPC to the application.

Eg :- A web-based banking application uses SOAP to complete a remote procedure call to obtain an account balance.  The following are the steps.

1) The client formats information regarding the procedure call and any arguments into a SOAP message and sends it to the server as part of an HTTP request.

Eg: –   POST /getAccountBalance HTTP/1.1
Content – Type: text/xml; charset=“utf-8”
Content – Length: xxx
SOAPAction: “Some-URI”

xmlns: SOAP-ENV= “”
<m:GetBalanceFromAccount xmlns:m=”Some-URI”>
</m: GetBalanceFromAccount xmlns:m=”Some-URI”>

2) Upon receipt of the RPC request, the web server translates the incoming SOAP message into a local method invocation to obtain the account balance for the given account.

3) Third, after the local method call to obtain the account balance returns at the server,

the server marshals the result of the RPC into a SOAP message.

4) The server transmits the SOAP response to the client in an HTTP response.


<m:GetBalanceResponse xmlns:m=”Some-URI”>
</m:GetBalanceResponse xmlns:m=”Some-URI”>

5)  The client extracts the SOAP message from the body of the HTTP response and translates the reply from XML into the format needed in the client’s application program.

The use of SOAP for remote procedure calls

  1. RPC gives a solution to the previously described roadblocks of deploying RPC applications on the web.
  2. SOAP solves all issue of Internet firewalls when embedded in HTTP. Because this permits SOAP messages to penetrate server firewalls that are configured to accept HTTP requests.
  3. SOAP is an open standard for a common wire protocol.  It enables interoperability between heterogeneous RPC systems, provided that they implement support for a SOAP-formatted RPC request and response.