Runtime Object Serialization

The second prerequisite for this chapter is an understanding of the .NET Framework’s runtime serialization functionality found in the namespaces System and System.Runtime.Serialization. With runtime serialization we can transform objects into a different format that is better suited for storage or transmission. The previous chapter explained serializable classes in great detail. Please take some time to read it before you continue this one if you are not already familiar with at least the SerializableAttribute.

Serializing Objects to SOAP messages

In the previous chapter we learned how to develop serializable classes with the .NET Framework. In this chapter we will see what they are good for. The focus will be on serializing objects with the SoapFormatter. You probably already guessed from the name what the SoapFormatter does: It transforms an object’s state into a representation based on the SOAP standard. Of course, it also works the other way: It re-creates an object from a SOAP message. That in itself is interesting functionality, but it is already available through ASP.NET WebServices, what do we need the SoapFormatter for? Well, for one WebServices internally rely on the XmlSerializer to do the object-to-SOAP transformations. This serializer has quite a few weak spots when it comes to serializing the majority of objects out there. The SoapFormatter on the other hand works well with all serializable objects.

Second, WebServices are tied to the Web. We do not have a good solution available when we want to move objects over a different transport. The SOAP protocol was designed to send messages over all sorts of different protocols and transports. SOAP over HTTP is probably the most prevalent today because it allows nicely for tunneling through corporate firewalls, but it also has some weaknesses. For example, communication over HTTP is based on a synchronous request-response model and it is very much hit-or-miss. We are out of luck when the WebService’s server is not running and we have to code complicated logic to retry sending a message if the first attempt fails because the recipient of the message does not respond. If we need an asynchronous communication model or if we are looking for a more reliable delivery mechanism .NET Web Services do not provide an adequate solution right out of the box. Microsoft is currently working on an initiative called Global XML Architecture (GXA) to address these issues, but that project just entered the “Technology Preview” phase. It may take a while until the results of this initiative are integrated into the .NET Framework. There are, however, alternatives available today to provide asynchronous, reliable, SOAP-based solutions if we can get away from using HTTP as the message transport. Message queues, for example, are a transport mechanism which addresses both of these issues. SOAP is actually very much suited to message queues since it is inherently message based and does not require an immediate response.

Sending SOAP Messages over Message Queues

To get an idea how SOAP over message queues would work, we will build pieces of a system to send and receive objects over message queues throughout this chapter. We will show how we can send objects in a user management system. The activity we focus on in the example is inserting new users into the system. We imagine a client application queues a message representing the insert operation each time it needs to insert a new user into the system. Through the use of message queues it is completely transparent whether the queued request is executed on the same computer or on a different computer half-way across the world. The message queuing infrastructure takes care of the routing for us. Another application takes the message off the queue and acts on the information stored in the message. The example in this chapter this example will focus on one-way message exchange.