InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

June 28, 1999

XML Makes Object Models More Useful

Extensible Markup Language can be used for many aspects of a system's architecture, from the early stages of modeling through development

By Bruce Klein

ML is a World Wide Web Consortium recommendation that, among other things, defines how related data can be transmitted across the Web in a structured manner. One reason for all the hype surrounding the Extensible Markup Language is the extensibility factor, which lets people come up with new and creative uses for XML almost daily. Be it document indexing or data standards, XML is relevant to the discussion.

KPMG's consulting arm has found that XML can be applied to multiple aspects of a system's architecture as well, beginning at the earliest stages of business and object modeling and continuing through the various stages of development. A business domain can actually be represented in XML, and that representation can drive key components of a system's architecture, from defining messages being passed between system components to actually generating large portions of the code at each layer of the classic three-tiered architecture.

From a business standpoint, an application architecture that incorporates XML is better positioned to support that same application quickly via an additional delivery channel. For example, an application that's available to users via the Web and a call center can be extended to a kiosk environment without writing an entirely new user interface from scratch.

XML also adds value to the customer experience by allowing a delivery channel to be easily personalized in a way that customizes and enhances the customer interaction. From a technology standpoint, defining XML vocabularies between various system components lets developers work independently while greatly reducing the debug cycle time needed to integrate those components.

Enterprise Architectures
Enterprise applications are typically built by first having a business analyst construct a model of the business domain using the techniques of object-oriented analysis and design. This model is then graphically expressed via Unified Modeling Language diagrams, and these diagrams are handed off to the development team to crank out the code that implements the model.

UML is both a methodology and a notation for performing object analysis and design. UML has gained widespread acceptance among system architects in addition to being adopted by the Object Management Group as a standard. But UML remains a complicated technology that requires an understanding of object technology and a steep learning curve.

Typically, a development team takes the UML model and proceeds to implement it across three tiers: user interface, business logic, and database.

This architectural approach has led to many significant advances in software engineering, including component-based architectures, design patterns, and standards such as Microsoft's Component Object Model and the Object Management Group's Corba object models.

One difficulty often encountered in a three-tiered architecture is integrating the components across all the tiers. During development, programmers working at each of the three tiers often have to write entire applications just to test the specific functionality they are developing. The developer of the business-logic tier, for example, needs to write an application that simulates all the calls that the user interface will possibly make. This application is a mini user-interface tier in itself and is pure throwaway. Even after such unit testing is done, there's no guarantee that when the user interface is complete it will actually communicate with the business tier as expected, resulting in the rarely envied task of having to debug across all the tiers.