Autonomous Services

Comments on ServerSide article by Stuart Charlton 

"XML Web Services are actually a specific case of the larger trend of leveraging extensible metadata as a means to make software more flexible and re-usable." 

This is only a partial characterization. Web services exemplify several interesting trends apart from this one, and have a range of other beneficial outcomes besides software flexibility and reuse. 

But Charlton's focus on leveraging extensible metadata is useful, and raises some important questions about process and order. The value of extensibility depends on who does the extending, and how. Uncontrolled and ungoverned extensibility leads to XML chaos, and does not contribute to the reuse agenda. 

 "[Do not assume] that the developer of one service has any authority to change the implementation another service. [Assume] that in any distributed system, each participating service is autonomous, allowing each to evolve independently of the other." 

This injunction is valid, but doesn't go far enough. With installed software components, the developer may have no right to change the code, but usually has the right to stick with the code she's got – for example, to decline or defer version upgrades. With services, she may have no authority to prevent changes in implementation, and may not even have the right to be notified of such changes, since the service providers may assume (not always correctly) that internal changes will not affect the external characteristics of the service. 

"XML represents a new data model that differs significantly from the traditional programming models of relations and objects."

XML is a notation that allows relational, object and other styles of data model to be expressed. However, XML's preferred style of data model is a tree structure: the traditional hierarchical data model, on which DL/1 and IMS/DB were based. Older developers may like to think of XML as DL/1 on acid. 

Charlton ends his article by recommending different styles of data model for different categories of data. This is useful practical advice for developers, but leaves open the architectural question of joined-up data: how to manage business adaptability and data integrity across these different styles.