RPC using the NET SoapFormatter

The SoapFormatter can generate two different types of SOAP messages: document-style messages for serialized objects and messages suited for RPC-style communication. While the intention behind the two messages types is very different, the format of the two message types is very similar. Specifically the format for RPC messages is defined in Section 7 of the SOAP standard describes the format for RPC as follows:

• The first child element in the message body is named after the method to invoke.
• Each inbound method parameter ([in] and [in,out] - This syntax is borrowed from the Interface Definition Langauge, which lets users specify in which directions to marshal a method parameter) is modeled as a child element of the method element. They appear in the same order as in the method definition.
• If a parameter references any struct-like values they have to be encoded according to the serialization format in section 5 of the standard.

When you read through the above list you may notice that he only difference between the two formats is the meaning of the first element in the message body. In an RPC message the first body entry identifies the method to invoke, not the root object of a serialized object graph.

Figure The architecture of a SOAP RPC system. A client communicates with a server through SOAP messages to invoke methods on the server. The client sends a SOAP message to the server to request a method invocation. The server executes the method and returns a SOAP message containing the results of the invocation.

In the following we will learn how we can leverage the SoapFormatter’s built-in support for the SOAP RPC-format to build an distributed component infrastructure á la WebServices or DCOM. We will develop the RPC counter parts of the sender and receiver classes we developed in chapter 13. We will also learn how to return the results of a method invocation or return information about errors that occurred while a method request was processed.