Advantages of Message based services


A large portion of my development career has been devoted to interprocess communication; from building Java based SOAP web services to using JMS and Websphere MQ for reliable messaging. I recently started working with ServiceStack which introduced me to the idea of Message Based web services. But before I start talking about the advantages, let me provide a little context.

The SOAP protocol is a protocol for performing Remote Procedure Calls (RPC). It allows clients call methods on a server via service boundaries (network, processes, etc) as if they were calling local methods. This method of interprocess communication has dominated the web services and RPC space for years due to its solid tooling and low learning curve. However, the SOAP protocol is complex and heavyweight. While this has its advantages such as; being able to accommodate advanced security and reliability requirements often found within enterprises, and being able to model complex / application-specific objects, SOAP's complexity and addressing scheme does not work well in the world of the world wide web.

There is another option however. Starting from the mid to late 2000's, REST-ful web services emerged and have now dethroned SOAP on the web in part due to its simplicity and its seamless integration with HTTP. And now REST-ful web services provide the foundation for Message based web services. Please note the subtle but vital difference in the two terms I'm using; "Message based services" and "Message based web services". Interprocess communication using Messaging does not have to occur over the web or over HTTP. There are several other message based architectures such as Message Queues, JMS, Erlang processes, F# Mailboxes, etc that have little to do with the web.

Some of the advantages of Message based services over their counterparts

  • Message based architectures tend to have coarse grained interfaces, therefore they encourage less back and forth compared to Remote Method Invocation (RMI) style interfaces. This helps further decouple components.
  • Messages can be versioned and evolved easily without breaking method signature. This makes refactoring less stressful.
  • Messaging is naturally "batch-ful". This is important in high volume scenarios where batching requests together can result in a significantly more performant architecture / system.
  • Messages can be cached, routed, chained and decorated. These qualities are especially important in web systems. Messages can also easily be logged and replayed at a later time.
  • Messages are ideal for concurrency as they are thread-safe and can be easily multi-plexed with their handlers over multiple threads

These advantages point to message based services as being the better choice for distributed systems. And therefore they should be considered for your next integration project. The one caveat to my recommendation is that message based services, in particular, implementations using REST over HTTP do not have as strong of vendor / tools support as SOAP services. This sometimes leads to having to write a lot of serialization and service protocol code by hand.

To get started with implementing message based web services on C# .Net you can take a look at ServiceStack which provides an entire framework around message based web services but comes with a one-time perpetual licensing fee or you can use Microsoft Web API 2 and follow messaging principles. In Java, you can use a combination of a suitable JAX-RS implementation with JAXB to provide the message serialization and deserialization. For MQ and service buses there are several options out there that can be found with a simple google/bing search. ActiveMQ is a popular open source option.

Thanks for reading

You Might Also Like