WCF: Individual methods or a generic ProcessMessage method accepting xml.

Question

My company is developing an application that receives data from another company via TCP sockets and xml messages. This is delivered to a single gateway application which then broadcasts it to multiple copies of the same internal application on various machines in our organisation.

WCF was chosen as the technology to handle the internal communications (internally bi-directional). The developers considered two methods.

1. Individual methods exposed by the WCF service for each different message received by the gateway application. The gateway application would parse the incoming external message and call the appropriate WCF service method. The incoming XML would be translated into DataContract DTO’s and supplied as argument to the appropriate WCF method.

2. The internal application exposed a WCF service with one method “ProcessMessage” which accepted an Xml string message as argument. The internal app would parse then deserialize the received xml and process it accordingly.

The lead developer thought option two was the better option as it was “easier” to serialized/deserialize the xml. I thought the argument didn’t make sense because DataContracts are serialized and deserialized by WCF and by using WCF we had better typing of our data. In option 2 someone could call the WCF service and pass in any string. I believe option 1 presents a neater interface and makes the application more maintainable and useable.

Both options would still require parsing and validation of the original xml string at some point, so it may also be a question where is the recommended place to perform this validation.

I was wondering what the current thoughts are for passing this kind of information and what people’s opinions on both alternatives are.

Answer 1

I hope I understood this right. I think it might make sense to have your gateway app handle all the deserialization and have your internal app expose WCF services that take actual DataContract objects.

This way, your deserialization of the TCP-based XML is more centralized at the gateway, and your internal apps don't need to worry about it, they just need to expose whatever WCF services make sense, and can deal with actual objects.

If you force the internal apps to do the deserialization, you might end up with more maintenance if the format changes or whatever.

So I think I would say option 1 (unless I misunderstood).

Answer 2

Option 1 is suited if you can ensure that the client always sends serialized representations of data contracts to the server.

However if you need some flexibility in the serialization/deserialization logic and not get tightly coupled with DataContracts, then option 2 looks good. Particularly useful when you want to support alternate forms of xml (say Atom representations, raw xml in custom format etc)

Also in option 2 inside the ProcessMessage() method, you have the option of deciding whether or not to deserialize the incoming xml payload (based on request headers or something that is specific to your application).

In option 1, the WCF runtime will always deserialize the payload.

Answer 3

I recently asked a couple of questions around this area: XML vs Objects and XML vs Objects #2. You'll find the answers to those questions interesting.

For our particular problem we've decided on a hybrod approach, with the interface looking something like this:

// Just using fields for simplicity and no attributes shown.
interface WCFDataContract
{
    // Header details
    public int id;
    public int version;
    public DateTime writeDateTime;

    public string xmlBlob;

    // Footer details
    public int anotherBitOfInformation;
    public string andSoemMoreInfo;
    public book andABooleanJustInCase;

}

The reason we use an xmlBlob is because we own the header and footer schema but not the blob in the middle. Also, we don't really have to process that blob, rather we just pass it to another library (created by another department). The other library returns us more strongly typed data.

Good luck - I know from experience that your option 2 can be quite seductive and can sometimes be hard to argue against without being accused of being overly pure and not pragmatic enough ;)