Sunday, December 2, 2012

The Choices for Intra-System Data Communication

In the .NET world, WCF has been the de facto data communication standard for quite some time. When designing a distributed multi-tier software system, most software designers would choose to use WCF to connect the various subsystems. For example, in Figure 2 of my previous post, the communication between the website ("Website") and the backend service ("Service") is usually handled by WCF.

WCF client is very easy to setup. C# code can be generated with a few mouse clicks from WSDL provided by the WCF server. But it has several problems when used for this task:

  1. Maximum WCF message size is pre-determined. When handling data of unpredictable sizes, it may hit a message size ceiling and stop working. The standard solution is not pretty: once you have determined that the maximum message size is the problem, you will need to re-configure it and the system will restart. If you go to a streaming solution, you will lose some very important WCF security features.
  2. WCF messages are transmitted in XML over HTTP, so HTTP load balancers cannot easily perform some of its basic tasks such as retrying WCF operations. For example, if the XML contents of the WCF message command the service tier to create a new object, a retry without interrogating the service tier would end up creating redundant objects. In contrast, a RESTful communication layer can be easily understood by HTTP load balancers. The balancers would know which operations they can safely retry without interrogating the service tier.
  3. The data objects that are transmitted to the recipients are "raw". Consuming these data objects will require a lot of work.
  4. When running under IIS, it has all of the limitations of the HTTP server in addition to those of its own. For example, the maximum download limit that exists for other services still applies.

Software designers are moving to RESTful services for some very good reasons:

  1. Its message sizes are only limited by the HTTP server that it runs on.
  2. By staying with HTTP verbs that the HTTP load balancers can understand, load balancing is quite straightforward.
  3. The payload is smaller for the same data objects.
  4. When RIA service is configured as a RESTful service, the recipient can handle data objects as if they are local. Although one can use RIA service as a WCF service as well, but the RESTful approach is much more appealing.

There are other reasons RIA RESTful service should be the best choice for Intra-System Data Communication, but these should be compelling enough.

No comments:

Post a Comment