Summary: 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. Service Bus Queue: http://msdn.microsoft.com/en-us/library/windowsazure/hh780773.aspx Twitter Tweet: h
