Data/Contract Coupling in Messaging
- Posted: Feb 08, 2013 at 8:10AM
- 14 comments
Loading user information from Channel 9
Something went wrong getting user information from Channel 9
Loading user information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
Right click “Save as…”
This whiteboard talk was largely inspired by a series of Twitter conversations around whether and when it's a good idea to share types (i.e. .NET classes compiled into assemblies) as a way to express contracts in a messaging system.
I don't think it is. In fact, it's the exact opposite of loose coupling and negates a lot of the advantages of opting for a messaging middleware system and mostly all advantages of opting into open standard protocols like HTTP and AMQP.
That said, it's difficult to blame the folks in the .NET developer community who've arrived at that practice, ultimately having been led down that path by -- as I am meanwhile convinced -- the late 1990s industry choice of picking XML Schema (XSD) to describe the content of messages. XML Schema, with all of its complexity, is a reasonably good way to describe the syntax of XML-based markup languages of which there are many and where aspects like element order and attribute substitution many other complexities of XSDs might make some sense. XSD's type system, which allows for restrictions that fairly directly map to inheritance on OO languages led developers to think of messages as objects - and serialization frameworks that allow for mapping the XSD type model into class hierarchy helped with that impression.
Messages are not objects. Messages don't care about the version control history. Messages don't care about whether a subset of the data they carry also similarly appears in some other message.
Messages are flat. Maps of keys to values. The values are simple-typed or, again, maps or arrays or values or maps. JSON embodies that model. If you ignore XSD and allow for the same simple constraints as JSON, XML also embodies that model.
If you take a look, you'll start noticing that we and a lot of others in the industry have moved to document messages in simpler ways than schemas.
(BTW, if we could easily do it without breaking backwards compatibility we'd even drop the namespace in the SB API snippet above)
You'll generally see a plain text documentation of properties of which some may have complex context consisting of maps and arrays. The advantage is that these descriptions map nicely into all programming languages and platforms by ways of a skilled developer.
I realize this is controversial, so I'm looking forward to comments.