Limitations of the SoapFormatter

Despite the limitation of passing intelligent types, there is more opportunity for interoperability in RPC messages than there is in messages with serialized objects. We can build RPC systems with the SoapFormatter to interoperate with other SOAP implementations as long as we stay away from struct-like types in the method signatures. Well, almost. There are a few more limitations we need to know about if we are trying to design interoperable services with the SoapFormatter. The SOAP standard defines specialized arrays, i.e. multidimensional arrays, sparse arrays and partially transmitted arrays to optimize array representation on the wire. None of these special types are deserialized correctly by the SoapFormatter. Unfortunately they do not cause an exception either. The formatter simply ignores the additional information in the message and attempts to deserialize regular arrays. Fortunately this limitation only comes into play if we have to interoperate with different SOAP implementations. The formatter itself never produces messages containing any of these specialized arrays.

Summary

In this chapter we learned how easy it is to generate and parse SOAP RPC messages with the SoapFormatter and the SoapMessage classes. With these two classes we can quickly build an RPC infrastructure based on the SOAP protocol over an arbitrary transport.

While it is very easy to develop the infrastructure, we need to design the RPC interfaces exposed by the infrastructure very carefully. Interoperability with other SOAP implementations is only guaranteed if the method signatures are limited to the primitive types defined by the SOAP standard. Other types always require that both client and server know how to bind to the custom type. Binding to custom types is fairly easy when sender and receiver both are built on top of the SoapFormatter. The sending formatter embeds detailed type information into the message to enable the receiver to locate the type’s assembly. Furthermore, the SoapFormatter provides hooks to customize type binding if necessary. SerializationBinders for example can substitute types that are not available or resolve type information in a format that does not conform to SoapFormatter’s default scheme. Other SOAP implementations, even ASP.NET WebServices, can not resolve the type information generated by the SoapFormatter and are not able to bind custom types.