Enterprise Service Bus (ESB) technology has arguably become the latest and greatest approach to enterprise integration and SOA. An ESB provides a standards based solution for building a service oriented platform. Systems and applications targeted for integration (either as consumers, producers, or both) only need to worry about "getting on the bus".

David Chappell's book stresses the importance of a canonical XML format. An ESB domain, or instance of a bus implementation within a specific environment/organization, must speak a common language between all systems on the bus. This common language can be some existing XML vocabulary or standard, or modeled from scratch using sound document engineering (this is the approach I took for various reasons).

One of the most prevalent and common problems that large organizations could face is data redundancy or inefficient data sharing. New systems and applications can become information silos over time; the quickest and cheapest solution often forgoes proper research and analysis to avoid creating redundant data.

The canonical XML format or vocabulary defining message content within an ESB IS the solution to the simple yet potentially severe data sharing problem. The vocabulary is a representation of the universal set of data items across the enterprise, agnostic of any specific system or application (i.e. the XML encoded model need not worry from which applications the elements were pulled). Commonalities across systems must be identified and defined only once, or else data redundancy or ambiguity could be exacerbated by the very solution trying to solve it.

This application agnostic, lowest level XML model is referred to as the core. The core model documents (I use XML Schema) should be 1) in the same namespace and 2) split up by functional or business area. Number one also implies to in fact use a namespace for your ESB domain's XML vocabulary. Why? Because of the most basic reason namespaces exist - to avoid element collision (if and when inter-domain ESB integration occurs) and to associate some sort of an identity to the vocabulary. Number two just avoids creating an unwieldy and huge document - simple modularization. For the set of common data items that span functional areas (and thus your set of core schemas), a separate document should be created. An example of a data item that would be placed in this common schema are globally unique identifiers shared by two or more applications.

The next level of ESB vocabulary modeling above the core is the context in which elements from the core are referenced to interface with a specific system or application. The context can be further segmented into external and internal documents. External refers to ESB request & response message documents (and could be included in WSDL). Internal directly corresponds to a specific system or application's XML encoded data flowing through the bus.

The next write up on this will include a specific, real world example on how this approach was actually implemented.