Archive for June, 2007

Questionable XML Messaging Practices

Having recently looked at Event Driven Architecture in comparison with SOA, I was struck that many of the proponents arguments as to why EDA was better than SOA were based on comparisons with bad SOA design. And that got me thinking about the way we critique software patterns and practices.

For example; XML is a good thing. Not perfect, but definitely a large step forward from previous ways of representing data, particularly for transitory messaging. However even the best of ideas can be ruined through bad or inappropriate design. Often the inappropriate issue arises when we slavishly follow a pattern that whilst suitable for the original intent does not apply to our individual problems.

So here is the start of a list of personal grievances/issues with XML and messaging. Not at all exhaustive, but it will grow;

  1. Runtime validation of messages – if the messages are being produced by a stable consistent process they should not alter and therefore should not "become" invalid at a random time. Therefore the process of validation, which is expensive for large messages, should not occur at run-time, rather at a validation stage of the project.
  1. Deserilisation of large messages – this is highly expensive and of questionable value. Often the messages, particularly in vertical specific specification such as GJXDM and HL7 version 3.0, carry large amounts of non-business value data used to qualify the message or wrapper it. These values are typically not used in a daily processing way, and can often be safely ignored. The expense in representing them in class structures is therefore a unnecessary practice. A more suitable way may be through the use of XPath or even string manipulation. Removal of non-business value wrappers prior to processing a message through string manipulation would greatly reduce the processing time per message.
  1. Representing relational data structures in messages – messages are intended to communicate business values or occurrence of events. They do not, and regularly should not, represent the underlying data source. The use of automated tools to generate xml messages from relational models has resulted in massive XML Schemas to represent often simple events or business data.
  1. Excessive attempts at human readability – XML is not read by end users. Ever. Unless they are IT professionals. Which they usually are not. Although human readability was an intent of XML its value is questionable. Although the naming practices of XML should not be obscure or obtuse, excessive attempts to make the data human readable usually translate into large messages. This is highly questionable as messages are a) transmitted and b) transitory. The larger the message, the longer the transmission. Although we have fat bandwidth in many cases, this is not universal true. And we should not forget the impact of large messages on processing time. Conservation of processing resources and reduction of message size should be high on the design requirements of all solutions.

Tags: , ,

Powered by Qumana