Integration and Interpretation of XML Schemas   Table of contents   Indexes   Dimap : Satellite image metadata standard based on XML
 Boulder 
Carlson, Dave
Ontogenics Corp.
 USA 
 		 Dave Carlson
 Chief Technology Officer
Ontogenics Corp.
  5564 North Fork Ct. Suite 100 Boulder (Colorado)  USA (80301)
Email: dcarlson@ontogenics.com Web site:http://www.ontogenics.com
 Biography
 Dave Carlson has an MBA from Cornell and a Ph.D. in Information Systems and Cognitive Science from the University of Arizona. He has been working in Java since the first alpha release in 1995, and has been using XML since 1997. Dave has a passion for uncovering the benefits of new technologies and for applying them to practical business problems.
 

Introduction

 The promise of component-based development (CBD) has captured the attention of many developers - and especially the managers of those developers. Yet, the diversity of component types and the inherent distribution of component archives make the realization of promised benefits difficult to achieve. This paper describes the concepts and prototype implementation of a component broker that helps to integrate a world-wide web of components. A component broker uses a common interlingua for searching and exchanging metadata about components between CBD agents distributed across the Internet. Each CBD agent is responsible for providing information about its set of components, and for communicating with the component broker in the common interlingua.
 We argue that the XML Metadata Interchange (XMI) language is the best choice for representing the content of these exchanges with the component broker. The Object Management Group adopted XMI in March 1999 as the standard for exchanging information models between development tools. XMI is defined as an application of XML for serializing information models. In particular, information models using the Unified Modeling Language (UML) can be completely encoded in XMI for vendor-independent exchange. We focus on the UML as a means to represent component definitions and XMI as the language to exchange those definitions.
 We take a Web-based approach for integrating these components, thus assisting a wide range of programmers and business analysts to assemble component-based applications. We do not promise a silver bullet for solving the problem of rapid component assembly. However, our initial experience with declarative rules-based scripting of components has promising potential. In order to unify UML models of components with rule-based scripting, we have developed a Rule Modeling Language (RML) defined as a formal extension of the UML metamodel. The RML includes an XMI generated RuleMarkup Language DTD, so a user of these models sees only a seamless hyperlinked network of XML documents representing UML and RML models.
 UML 
 Unified Modeling Language 
 		Two views of a prototype design are described in this paper. First, a functional view of the model production and XMI translation provides an integrated end-to-end operational description. Then, an architectural view describes a distributed network of repository agents and component brokers operating in a Web-based environment. This paper emphasizes the role and benefits of XML and only introduces the UML and architectural concepts in enough detail to create a descriptive context.
 

Functional View of the Component Broker

 The benefits of CBD will be achieved only when components can be quickly discovered and assembled into business applications. A business object component is defined by its interfaces and events; its internal behavior, such as database storage and transactional control, are unimportant to application assemblers. A business rule component is defined by its task structure that controls sets of rules, and by the condition patterns of individual rules that constrain selections of business objects [1]. However, there are many different forms for storing component definitions, ranging from Java source code and Java bytecode archives (JAR files), to CORBA interface repositories, UML models saved in the Rational Rose file format, and business rules written in several rule languages. Our component broker supports all of these formats.
 Figure 1 illustrates a functional view of our component broker framework. All inter-system communication is based on HTTP and XML, enabling our goal to build a world-wide web of components. Each component resource, shown on the left, has an associated agent that is able to translate those component definitions into XMI representations. The top group of resources is translated into a Unified Modeling Language (UML) model, and the bottom group is translated into a Rule Modeling Language (RML) model. Each model is then translated into an XMI document and parsed into a Document Object Model (DOM) data structure. In some cases, we directly translate resource metadata into a DOM structure through use of the DOM factory methods.
 
 Figure 1: The Component Broker
Functional Process diagram
 We use the DOM as a standard basis for applying search and transformation tools that process the component definitions into a variety of end user deliverables. The following sections elaborate on our use of two metamodels for UML and RML and their translation into XMI. Additional models, such as the new CORBA Components Model, can be included in the same manner. XPath and XSLT are used to search, filter and transform the XMI into other XML, HTML, or plain text documents. From a user's point of view, the distributed network of component repositories appears as a seamless hyperlinked Web site.
 Consider a use case scenario that weaves together a component broker with several resource agents. Any resource can be used as the entry point into this component hyperspace, and the component broker will insert hyperlinks to all other referenced components. Start with a ruleset written using the Java Expert System Shell (Jess) rule language [2]. Each rule includes references to one or more business objects in its condition, and the rule may create, modify, or delete business objects in its action. The Jess rule is translated into an RML model, then into an XML document. The XML document captures every detail of the rule's condition and action, including references to the business object components. An XSL stylesheet may be applied to the XML document, generating an HTML page with hyperlinks for the references.
 Most rules refer to Java class interfaces, so traversing those hyperlinks generates queries to other resource agents. We have built agents that can translate either Java source code or bytecode. Java bytecode is the result of compiling Java source code into 'class' files, and these class files are often consolidated into a compressed 'jar' archive file. Any 'jar' file can be treated as a kind of repository containing perhaps hundreds of class definitions. The class definitions are reverse-engineered from bytecode into an XMI UML model by using standard Java reflection and Java Bean introspection. Using the HTML pages that are produced by applying an XSL stylesheet to the XMI document, a user can hyperlink between any class definitions within, or even between, 'jar' files -- any Java class in the current CLASSPATH environment is a potential source for translation.
 Metadata 
 XMI 
 

Metamodels and DTDs

 Our current component broker framework uses two different metamodels: the Unified Modeling Language (UML) and the Rule Modeling Language (RML). A metamodel defines a model that is used to represent other models. For example, the UML is a model used to represent other object models. Many people only think about the UML as a graphical notation for documenting object model designs. However, underlying the graphical UML modeling tools is a metamodel that represents those model instances. In addition to our use of the UML, we developed the RML metamodel as a vendor-independent representation of business rule models. Models conforming to either UML or RML can be serialized as XML documents for storage or exchange.
 The XML Metadata Interchange (XMI) [3] standard was developed by the Object Management Group to enable easy interchange of metadata among modeling tools and repositories in a distributed heterogeneous environment. Although a detailed introduction to XMI is beyond the scope of this paper, a brief overview will help explain its value to our component broker. The following three points, and illustration in Figure 2, summarize key concepts in the XMI specification:
 
  •  The XMI specification includes design principles for translating metamodels and models into DTDs and XML streams.
  •  XMI defines a set of production rules for transforming Meta Object Facility (MOF) based metamodels into XML DTDs. Both UML and RML are MOF-compliant metamodels [4].
  •  Production rules are defined for encoding and decoding models into XML document instances.
 
 Figure 2: XML Metadata Interchange (XMI)
XMI diagram
 A UML DTD defined according to these rules is included as an appendix in the UML Semantics specification [5]. We created our RML metamodel using the Rational Rose modeling tool, then used IBM's XMI Toolkit from their AlphaWorks site to generate an RML DTD from that metamodel. We also used the same XMI Toolkit to create a general purpose Rational Rose resource agent that is able to take any Rose UML model and produce an XMI document output, which is then available to our component broker framework.
 A concrete example will help to explain our use of these metamodels and DTDs. When the Java resource agent is used to reverse engineer bytecode from the class com.sun.xml.tree.XmlDocument (part of Sun's XML implementation), a rather long, verbose XML document is generated. A very small subset, with sub-elements removed for brevity, is shown below. This XML fragment defines one parameter of one operation in the class definition. The element tag names, generated by the XMI production rules, use a dotted notation to ensure unique elements for the multi-level package structure in the UML metamodel. In this case, Operation is a class in the Core package, which is contained within the Foundation package.
 A Java method declaration: public void writeXML(XMLWriteContext p1)
 Translates to the following XMI fragment:
 
<Foundation.Core.Operation xmi.id="_146">
     <Foundation.Core.ModelElement.name>
       writeXml
     </Foundation.Core.ModelElement.name>
     <Foundation.Core.ModelElement.visibility xmi.value="public" /> 
     <Foundation.Core.Feature.ownerScope xmi.value="instance" /> 
     <Foundation.Core.BehavioralFeature.parameter>
       <Foundation.Core.Parameter xmi.id="_147">
         <Foundation.Core.ModelElement.name>
           p1
         </Foundation.Core.ModelElement.name>
         <Foundation.Core.Parameter.kind xmi.value="in" />
         <Foundation.Core.Parameter.type>
           <Foundation.Core.Classifier xml:link="simple" 
                href="com.sun.xml.tree.XmlWriteContext" 
                title="XmlWriteContext" />
         </Foundation.Core.Parameter.type>
       </Foundation.Core.Parameter>
     </Foundation.Core.BehavioralFeature.parameter>
</Foundation.Core.Operation>
 One of the elements in this XML fragment, Foundation.Core.Parameter.type, is the representation of a relationship from the Operation class to the Classifier class. In this example, we don't embed the Classifier definition in the type link, but include a XLink reference with an href location for the complete definition. Our component broker uses this link (with a prefixed base URI for the default broker) along with an XSL stylesheet, to present a hyperlink that Web browsers can follow to another resource agent that is able to produce the complete XML document for this Classifier definition.
 Stylesheet 
 XPath 
 XSLT 
 

Search and Transformation

 Using the DOM structure produced by a resource agent, the XML document can be searched using XPath [6] or filtered or transformed using XSLT [7]. XPath is used to specify XSLT template patterns, but also provides a partial solution for simple searches of XML structure. The W3C has recently formed an XML Query working group to prepare a proposed recommendation that will likely use XPath as part of its specification. The term XML Query Language (XQL) is often used to refer to this broader solution, but consensus on its specification is still some months away.
 In a simplistic sense, search is a subset of document transformation because each template rule in an XSLT stylesheet uses a match pattern to search for qualifying elements. The following example is based on the XML fragment described in the last section. The stylesheet processor applies this template to each Parameter element, which in turn applies other specialized templates for transforming the 'type' and 'name' sub-elements. Although it's not shown, the Operation template similarly applied this Parameter template. Notice that this template outputs a ', ' string after the parameter name, but only if this is not the last sibling element contained in the parent element. XSLT provides some very powerful and elegant capabilities!
 
<xsl:template match="Foundation.Core.Parameter">
     <xsl:apply-templates select="Foundation.Core.Parameter.type"/>
     <xsl:text> </xsl:text>
     <xsl:apply-templates select="Foundation.Core.ModelElement.name"/>
     <xsl:if test="not(position()=last())">, </xsl:if>
</xsl:template>
 When the template is applied to a Foundation.Core.Parameter.type element, it applies another generic template that is used to transform all XLink elements. The following template matches all elements having an attribute named 'xml:link'. From the example in the last section, the Classifer element matches this pattern. This template then transforms the Classifier element into an HTML hyperlink element.
 
<xsl:template match="*[@xml:link]">
     <xsl:text> </xsl:text>
     <A href='{$brokerURL}{@href}'>
       <xsl:value-of select="@title"/>
     </A>
     <xsl:text> </xsl:text>
</xsl:template>
 

Distributed Agent Architecture

 The previous section of this paper described a functional view of the component broker framework. This section presents a brief overview of an architecture where that functionality is distributed across the global Internet. The component broker framework is designed as a logical three-tier architecture, consisting of resource agents, component brokers, and clients. Figure 3 shows a typical deployment of this architecture.
 
 Figure 3: Deployment of Agents and Brokers
Architecture diagram
 A component broker is a specialized type of resource agent that maintains a registry of its associated agents/brokers, and always delegates its query processing to one or more of those agents. All inter-agent communication uses standard HTTP protocol with XML response content, thus ensuring maximum interoperability. The primary feature that a broker adds to agent functionality is the ability to transform XMI documents into other XML for HTML document types. Our current broker implementation allows easy configuration for adding XSLT stylesheets that define transformations.
 There are two major categories of clients: development tools and Web browsers. Development tools may be written, or use existing interfaces, to receive standard XMI formats for UML and RML models. A broker also may be designed to transform XMI documents into other XML document types, such as RDF. Web browser clients will most likely request HTML formatted documents from the broker, but may directly receive the XML documents and apply client-side stylesheets.
 

Future Opportunities and Challenges

 The use of XMI for exchanging information models is still a very new and maturing standard. It will undoubtedly be refined based on implementation feedback, but appears to be gaining industry support, at least among UML tool vendors. We have attempted to push the use of XMI beyond typical UML tools into a more mainstream application with wider scope. Our initial prototypes are encouraging and we will continue to improve the implementations described in this paper.
 Particular areas for improvement include a much better catalog of component metadata to facilitate broad searches across all resource agents, and an expansion of our simple XPath queries to a more complete XML query language. Both of these improvements must be kept aligned with industry-wide development of search engines and query languages for XML content. The rapid evolution of XML standards and applications will continue to create fertile ground for growth.
 

References

 
  1.  "Rules and Web-Object Systems," by Dave Carlson, Object Magazine , June 1998 (http://www.ontogenics.com/research/papers/ObjectMag/June98.htm )
  2.  The Java Expert System Shell (Jess) rule language (http://herzberg.ca.sandia.gov/jess/ ) is compatible with a large subset of the widely used CLIPS rule engine, but is written entirely in Java and includes extensions that allow rules to access Java objects.
  3.  XML Metadata Interchange (XMI) specification (http://www.omg.org/cgi-bin/doc?ad/98-10-05 )
  4.  For a good overview of metamodel architectures, see "UML 2001: A Standardization Odyssey," by Cris Kobryn,Communications of the ACM , October 1999.
  5.  UML specification version 1.3 (http://www.omg.org/cgi-bin/doc?ad/99-06-08 )
  6.  XML Path Language (XPath) version 1.0 working draft (http://www.w3.org/TR/xpath )
  7.  XML Transformations (XSLT) Specification version 1.0 working draft (http://www.w3.org/TR/xslt )
Integration and Interpretation of XML Schemas   Table of contents   Indexes   Dimap : Satellite image metadata standard based on XML