XML - A Disruptive Influence on Programming Languages and Methodologies

Influences of change.

application architectureThere are 2 major XML based influences that over the course of the 12 - 18 months are set to change application architecture as it is today.

1. XML at the enterprise boundary

   Today's enterprise boundaries support a wide variety of standards and non-standards based communications protocols and data formats. From the ubiquitous HTTP to EDI to raw sockets enterprises have had to content with a world of non-uniformity in defining interfaces to the outside world. Things however are now changing; first, XML is becoming the data format of choice for inter enterprise transactions. Second, communications protocols such as SOAP that support an XML payload are receiving widespread interest and adoption. These 2 changes constitute a force of reverse entropy that will significantly simplify enterprise boundary APIs.

2. XML inside the enterprise

   XML is becoming more pervasive within an enterprise. For the same reasons that XML makes sense at the enterprise boundary it can also be used to expose services within the enterprise. These services could be provided by legacy systems, new applications or existing products. Providing XML based access to these services decouples them from the type of clients/systems that need to use them. Additionally, standards such a XML Query and DSML will start to provide XML access to core architectural components, XML query for databases and DSML for LDAP directories.

These influences will have the most immediate and significant impact on those developers working on outwards facing enterprise systems that support a companies B2C or B2B initiatives. Many XML standards are still work in progress, for those that are complete there is often little tool support and/or real life practical experience. Application developers however are increasingly going to have to contend with the standards as they mature and thus drive the 2 influences describe above. Applications will become sandwiched between external XML inputs on one side and internal XML data sources and services on the other. They will become surrounded by and embedded in a fabric of XML producers and consumers. The obvious question is what effect this all will have on how these applications are modeled and built? In particular, do current Object oriented modeling techniques and languages provide sufficient support for XML and the architectural possibilities it creates.

Data fights back

Object orientedIn the Object oriented world data is a second class citizen. Objects control access to and provide operations on data. Traditional functional modeling techniques on the other hand are often much more data centric. This data focus however is often cited as a fundamental weakness in these approaches, the separation of data from the functions that manipulate that data is often cited as the principle cause of complexity in non OO development. Objects, through exclusive ownership of their data, reduce complexity by leveraging abstraction and encapsulation to capture a more natural and maintainable model of their problem space. Until recently it looked like data would stay in the shadows, objects seemed to have the advantage.

XML however starts to reverse the clock, it represents a change in course back to a more data centric world, one in which data has a life of it's own. Data has effectively broken free of its object boundaries. This however does not mean a return to data modeling techniques of the past but it does present new challenges to those accustomed to OO development. The natural tendency for some OO practitioners will be to place the XML inside objects, hide it somehow and try and get things back to the familiar world of objects where they have experience, tools, methodologies and comfort. This might make sense if XML was simply a better way to represent data. XML however is much more than just data, it is an extensive and expanding set of standards and technologies. XML and objects will have to co-exist as peer technologies, objects must start to share the spotlight.

Much more than just Data

To many people XML is best described as data. To be pedantic, XML is not data, XML 1.0 ( W3C Recommendation Feb 1998 ) is data. In it's most general sense the term XML refers to a extensive set of XML based standards that encompass everything from the core W3C standards ( e.g. XML schema, XSLT etc. ) to standards defined by various industrial verticals ( e.g. Rosettanet ) and numerous other bodies ( e.g. ebXML, SOAP ). XML is huge, expanding along many dimensions at a pace that is difficult to comprehend. Many of the XML based standards add a computational/process dimension to XML that extends it way beyond the myopic notion of XML as data. At one end of the spectrum core standards such as XSLT and XML schema provide powerful specialized capabilities to process and manipulate XML, at the other end are enterprise class standards such as ebXML. The idea of webservices that is poised to revolutionize inter enterprise exchanges is only possible through XML based technologies.

Developer will need to start to leverage the expanding set of XML technologies, this will mean that the processing responsibilities within systems will have to change. Today, many systems are built solely using object technologies, as XML becomes more pervasive objects will no longer be the exclusive providers of functionality within a system. A division of labor must occur, there will now be a choice between realizing functionality through objects or alternatively through the new capabilities provided by XML. Developers will not be faced with an either/or decision, individual business requirements may be realized by combining both approaches, the balance tipping in either direction depending on the nature of the problem to be solved.

Modeling support

XML may well be a thorn in the side of some OO developers. It will not simply be a matter of business as normal, XML will present new and unfamiliar challenges to developers, one of the first will be how to capture the influence of XML on the OO modeling process.

Unified Modeling LanguageThe Unified Modeling Language (UML) has widespread acceptance and adoption in the software industry. Although , not necessarily bound to any one problem space UML does lend itself particularly well to OO modeling. The central view of an UML model is a class diagram. In addition, UML defines many other artifacts or views that can be created in the process of modeling a system. All views are closely related to each other and capture different features of the problem space they model. Everything is based on the central idea of an object, an object being characterized as something that has state, behavior and associations to other objects.

As XML moves through a system it may not always be necessary to have objects around that can do something with it. As previously mentioned, XML has an expanding set of standards and technologies that provide some degree of functional processing. In some cases, native XML processing will be sufficient to realize a business function. An example will help to clarify.

A business service API can be defined using an input and output XML document, this is the fundamental underpinning of webservices. Consider a simple example of such a service where the input document undergoes validation, authorization, auditing and formatting before being forwarded to a legacy system. Although , simplistic this type of example is surprisingly common in B2C and B2B systems. In this example authorization may involve applying a transformation to the input document and forwarding the resulting document to an authorization service that supports an XML interface, likewise auditing could be handled in a similar manner, and so on. At no point would it be necessary or advisable to create objects to perform some of the processing. A simple workflow could be defined where the input document is acted on at a number of steps, the basic requirements at each step could be provided by simple transformations, workflow and routing functions.

 Java The challenge modelers will face is how to capture this type of workflow. Without the usual presence of objects it will not be possible to model the behavior in the traditional UML class diagrams, state diagrams, sequence diagrams etc. The situation becomes further complicated in situations where the business function is more involved and requires some complex processing at certain points in the workflow. At these points it is likely that part or all of a document is handed off to a component ( likely developed in Java, C++ etc ) that can provide the necessary function.

A number of new view types will be clearly required to accommodate the new solution alternatives that XML makes available. One possibility is a workflow view that would capture the logical processing of a request as it passed through a series of processing steps. Each step would then be modeled according to how the required functionality was to be realized.

Eventually models should include support for defining documents, schemas, transformations, workflows and other XML processes. These capabilities will need to be integrated into existing modeling tools, methodologies will need to be extended to include new artifacts. OOAD will have an XML centric counterpart, XMLAD ( XML Analysis and Design ).

Language support

Modern languages such as Java, C++ and VB all support the OO model. Many languages have added support for XML, arguably Java has the most complete support. XML is evolving so that it will not be possible for languages to maintain comprehensive support for all the initiatives that are underway. However, support for some of the core standards is widespread. In this regard OO languages face a challenge when processing XML 1.0, there are 2 alternatives

1. Live with the XML

    DOM   SAX  Most OO languages provide support for the DOM and SAX APIs. These APIs support basic manipulation of XML documents through a interface that models the data in a hierarchical manner. Both APIs are difficult to use resulting in code that in most cases will be maintenance nightmare. Java provides a somewhat better solution in JDOM, but again it is far from idea. The basic problem is that a XML document when instantiated does not have a well defined set of typed get/set operations that would typically be available with an object.

   Navigating the document can also be difficult, it can be easier in some languages that support XPATH searches on the document. Overall , processing XML 1.0 is difficult at best.

2. Hide the XML

    SOAP A second choice is to hide the XML. XML-RPC and SAOP use XML as the transport between a client and a server, however both the client and server are largely unaware of that fact and program against their standard model. Other languages provide mechanisms to create objects that consume an XML document and provide a standard accessor model ( get/set ) to access the data. Java provides this through the JAXB extension.

   These techniques greatly simplify basic operations on a document. They do however have a number of disadvantages. First, it is not possible to apply XPATH searches to the objects or apply transformations. Second, if there is a need to interact with external systems that accept XML then the object representations must be converted to XML documents, this can be laborious especially without the ability to apply transformations.

Language support for many of the XML standards is patchy. Microsoft is clearly motivated to support some standards ( WSDL, UUDI ) and not others ( ebXML ). Java is extending support through the Java Community Process with approximately 12 JSRs related to XML. The overall pace of chance and inconsistency of implementation will continue to be serious issues. Most standards are moving targets that progress at their own independent rate, delayed and incomplete language support will continue to impede adoption for the immediate future.