EDN Admin
Well-known member
This whiteboard talk was largely inspired by a series of Twitter conversations around whether and when its a good idea to share types (i.e. .NET classes compiled into assemblies) as a way to express contracts in a messaging system.
I dont think it is. In fact, its 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, its difficult to blame the folks in the .NET developer community whove 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. XSDs 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 dont care about the version control history. Messages dont 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, youll start noticing that we and a lot of others in the industry have moved to document messages in simpler ways than schemas.
Youll 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 Im looking forward to comments.
View the full article
I dont think it is. In fact, its 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, its difficult to blame the folks in the .NET developer community whove 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. XSDs 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 dont care about the version control history. Messages dont 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, youll 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: https://dev.twitter.com/docs/platform-objects/tweets
- Facebook Post https://developers.facebook.com/docs/reference/api/post/
Youll 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 Im looking forward to comments.
View the full article