Marshalling RPC With a Proxy

Since there is no tool to produce proxy classes for invoking methods over message queues we have to write our proxy class by hand. Our proxy will call an InsertNewUser() method on the user management server. The methods accepts a parameter of the User type we already used in listing 13.2 in the previous chapter to encapsulate user data.

The proxy also implements an InsertNewUser() method with the same signature to create the illusion of a local method call. The implementation sets up a SoapMessage object to create an RPC SOAP message to send to the RPC server. First, the proxy sets the SoapMessage’s MethodName property to “InsertNewUser” to identify the method to invoke. If the publisher of the RPC service defined an XML namespace for the exposed method we also have to set the XmlNamespace property to the namespace name or the RPC server will not recognize the method name. Next the proxy sets up arrays with the name and the value of the newUser parameter to assign them to the properties ParamNames and ParamValues. Finally, the proxy has to create a SOAP message from the SoapMessage object and transmit it to the server. The SoapRPCMessageSender class from listing 14.2 does exactly that. It calls the SoapFormatter to create the message and sends the message to a specified message queue.

Listing A proxy class for a user management service

public class UserMgmtProxy

{

  protected SoapRPCMessageSender _Sender

  public UserMgmtProxy( string queueName )

  {

    _Sender =

          new SoapRPCMessageSender( queueName );

  }

  public void InsertNewUser( User newUser )

  {

    SoapMessage msg = new SoapMessage();

    msg.MethodName = "InsertNewUser";

    msg.XmlNameSpace = "urn:com-manning-xmlbook-users";

    msg.ParamNames = new string [] { "newUser" };

    msg.ParamValues = new object [] { newUser };

    _Sender.Send( msg );

  }

}

We always have to be careful that the ParamNames and ParamValues arrays match up and contain the same number of elements. The SoapFormatter’s Serialize() method will only throw an exception if the number of elements in the ParamValues array is greater than then number of elements in the ParamNames array. The formatter does not view other size mismatch conditions as errors and does not report them.

Examing the RPC Request Message

When our proxy calls Send(), the SoapRPCMessageSender produces a SOAP RPC message like the one in listing 14.3.

Listing An InsertUser RPC message

<SOAP-ENV:Envelope

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xmlns:xsd="http://www.w3.org/2001/XMLSchema"

  xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"

  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

  xmlns:clr="http://schemas.microsoft.com/soap/encoding/clr/1.0"

  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

  <SOAP-ENV:Body>

    <i2:InsertNewUser id="ref-1"                         |#1

      xmlns:i2="urn:com-manning-xmlbook-users">          |

      <newUser href="#ref-4"/>                           |

    </i2:InsertNewUser>                                  |

    <a1:User id="ref-4"                                        |#2

      xmlns:a1="http://schemas.microsoft.com/clr/nsassem/      |

      Christoph.SoapMQ.Shared/Objects%2C%20Version%3D1.0.0.1   |

      %2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull">     |

      <_Id>1500</_Id>                                          |

      <_Name id="ref-5">Joe</_Name>                            |

    </a1:User>                                                 |

  </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

(annotation) <#1 The first element in the Body of an RPC message represents with method to call. Child elements represent the method parameters. No type information is required here.>

(annotation) <#2 Referenced objects are serialized according to section 5 of the SOAP standard. >

 This RPC message looks almost like the document-style message in listing 13.4, except the first body entry’s name is InsertNewUser and its namespace is set to the name our proxy object specified. It does not contain any encoded type information, like it did for serialized objects. The first body entry does not need any type information because it identifies an interface method, not an object type. The interface itself is implicitly identified by the URL of the message.

As required by the SOAP spec, the newUser parameter of the method is represented by a child element of the InsertNewUser element. Since the newUser points to a struct-like type, the SoapFormatter chooses to create the referenced object separately parameter outside the InsertNewUser element. The serialized User object itself looks identical to the serialized User object in listing 13.4. The element’s namespace declaration encodes the full type information about the User type to enable the message receiver to recreate the object from the correct type. The field elements of the serialized User object do not need to declare their types because the formatter can infer them from the declaration of the User type.

Transmitting fully qualified type information to deserialize types works great if the receiver of the message also processes SOAP RPC messages with the SoapFormatter. The receiver can dynamically load the types referenced in the message from the type information embedded into the message. However, other platforms or SOAP implementations do not know how to interpret the namespaces or load the specified assemblies automatically. We have to keep this limitation in mind when we use the SoapFormatter to build interoperable systems. We need to restrict method signatures to the types defined by SOAP and the XSD type system in order to fully interoperate with other SOAP implementations.