In XML Modeling for an ESB - Part 1, a simple and modular approach to building a canonical XML vocabulary was described. Core schemas represent a data model across an organization or enterprise without worrying about specific systems or applications; this is essentially a data dictionary encoded in XML Schema, split up by logical and/or functional area. For example, a core schema in the city government case study I will be using is Property.xsd, which captures data items across systems that can be associated with the logical or functional area of "property" (as in physical buildings and houses that are owned by someone or some organization).

Derived from the core are the context schemas which are directly related to specific applications or systems (to be integrated as consumer and/or producer services within the enterprise service bus). The context schemas that define request and response instance documents for ESB clients are referred to as external schemas, and these would be referenced by WSDL (for fans of SOAP and related technologies). Internal schemas define the XML message documents that are pulled or pushed among specific systems on the bus itself. One simple example of this is to consider what represents a single record of interest from a producer system. This internal schema references a core schema to grab elements under the Permit.xsd core model, and in turn is included by its corresponding external schema to define a response document.

By the way, the basic concept of core vs. context is a document engineering fundamental - more information available at Doc or Die.

Despite not being convinced of the practicality of SOAP anymore, SOAP over HTTP and WSDL are used in my current ESB architecture and development project. Reasons for this include the specific ESB product being used does not allow for simple HTTP GET requests (!), the product seems to be geared towards SOAP client calls, and using existing tools such as the Axis WSDL2Java facilitate a direct reliance on the schemas to interact with the ESB.

This excellent write-up by Dennis Sosnoski concerning WSDL2Java, Castor, and Axis was the basis for how I developed client interfaces to the bus directly from the schemas.

The work-flow involved in building Java, SOAP based web service clients to interact with ESB exposed services consists of the following: ESB internal development, core schema modifications, external and internal context schema authoring, WSDL authoring, and client code generation. To avoid numerous schema inclusions in WSDL, a wrapper schema was created to allow the WSDL to include a single document.

Here is the full set of relevant files; (the Ant script for the client stub generation is heavily based on available code from the previously mentioned article at sosnoski.com).

WSDL
External Context Schema wrapper (all schemas can be found from here)
build.xml
ERD

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.