Editorials

Sharing Data With a Web Service

When working with WCF web services you have a few options for transporting data to the client. Each method has its own benefits, and complications. Four mainstream techniques I am aware of are:

  • Pass data as XML documents
  • Pass data as JSON objects
  • Pass data as POCO objects through shared library definition
  • Pass data as Server side POCO objects. The definition is shared to the client through the web service, so the client and the server are always in sync.
  • Pass data as POCO objects through JSON serialization

Using XML and an XML Schema, you can pass your xml data nicely between the web service and the client. The contents of the document can be validated as well formed using the XSD. This allows you to share some rather complex objects with a clear contract in mind regarding how the XML data may be used.

JSON is more free form in implementation. Most people don’t use JSON directly themselves anyway.

Passing data as POCO objects is popular. If both the server and the client have a shared library, then the objects may be passed back and forth using binary serialization, or any other serialization technique.

Passing data using a Server Side managed POCO, exposed to the client as an object, allows the server code to maintain the POCO, and the server and client to consume it. This way the data can be passed through any form of serialization.

Passing the data through a POCO using JSON serialization allows the server and the client to have it’s own definition of a POCO class. As long as both definitions are synchronized, then serializing or de-serializing to or from JSON works effortlessly. In this fashion, the client and the server share nothing. The biggest issue here is that you must maintain the POCO in both sets of code.

In reality, using a shared POCO through the server interface still requires modification to both sets of code. First you have to modify the Server definition of the POCO. Second, you have to update the contract between the client and the server, thus receiving the new definition of the POCO. Then, you have to modify the client code to utilize any changes to the POCO properties. To me, this isn’t any less work than simply maintaining a separate POCO definition in both the client and the server, in those cases where a shared POCO library is not available

At the end of the day it comes down to, how closely linked do you want your client application and your web service application to be. There are great arguments for any answer to this question. No answer is without some negative result. Where do your preferences stand? Share your comment to add to the conversation.

Cheers,

Ben