System and method for XML data binding

CLAIM OF PRIORITY

This application claims priority to U.S. Provisional Patent Application No. 60/359,145, filed Feb. 22, 2002, entitled “SYSTEM AND METHOD FOR XML DATA BINDING”, which is hereby incorporated herein by reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

CROSS-REFERENCED CASES

The following applications are cross-referenced and incorporated herein by reference:

U.S. patent application Ser. No. 10/304,233 entitled “SYSTEM AND METHOD FOR FAST XSL TRANSFORMATION” by Chris Fry, filed Nov. 26, 2002, now U.S. Pat. No. 7,502,996 issued Mar. 10, 2009.

U.S. patent application Ser. No. 10/304,280 entitled “SYSTEM AND METHOD FOR XML PARSING” by Chris Fry, filed Nov. 26, 2002, now U.S. Pat. No. 6,880,125 issued Apr. 12, 2005.

U.S. patent application Ser. No. 10/304,207 entitled “STREAMING PARSER API” by Chris Fry and Sam Pullara, filed Nov. 26, 2002, now U.S. Pat. No. 7,065,561 issued Jun. 20, 2006.

FIELD OF THE INVENTION

The present invention relates to the binding of data, particularly the binding of XML data.

BACKGROUND

The eXtensible Markup Language, otherwise known as XML, has become a standard for inter-application communication. XML messages passing between applications contain tags with self-describing text. This self-describing text allows messages to be understandable not only to the applications, but to humans reading an XML document as well. XML is currently used to define standards for exchanging information in various industries. These document standards are available in various forms.

Several XML-based communication protocols exist, such as the Simple Object Access Protocol (SOAP) and the ebXML protocol. The ebXML protocol is an open XML-based infrastructure that enables the global use of electronic business information. SOAP is a lightweight XML protocol, which can provide both synchronous and asynchronous mechanisms for sending requests between applications. The transport of these XML documents is usually over a lower level network standard, such as TCP/IP.

XML documents need to be valid and well-formed. An XML document is considered to be “well-formed” if it conforms to the particular XML standard. An XML document is considered valid if it complies with a particular schema. At the core of an XML document is an XML parser, which will check to verify that a document is well formed and/or valid.

The processing of XML has become a standard function in many computing environments. When parsing XML, it is necessary to get data from the XML file and transform the data such that the data can be handled by a Java application or other application running the parser. Efficient XML processing is fundamental to the server. As more and more documents become XML based, more and more traffic on the server will be in XML. The latest push into web services (with SOAP as the transport) has also highlighted the fundamental need for fast XML processing. Web services use XML over HTTP as the transport for remote procedure calls. These calls cannot be done in a timely manner if the XML parser is slow. There are primarily two standard approaches for processing XML: (1) SAX, or Simple API for XML, and (2) DOM or Document Object Model. Each protocol has its benefits and drawbacks, although SAX presently has more momentum as an XML processing API.

XML data binding is a process whereby XML documents can be bound to objects that are designed especially for the data in those documents. Data binding allows applications to manipulate data that has been serialized as XML in a way that can be more natural than DOM. Data binding can also have many cross-system dependencies. Web services and XML parsing are examples of clients or applications that can utilize data binding.

One method that is useful for XML data binding is JAXB, or the Java™ Architecture for Data Binding. JAXB compiles an XML schema into Java classes, which handle XML parsing and formatting. These generated classes also ensure that the constraints expressed in the schema are enforced in the resulting methods and Java language data types. Presently, however, there is not a solution that allows not only mapping from XML to Java, but also from Java to XML.

Castor XML is an existing, open source data binding framework for Java to XML binding. Castor enables one to deal with the data defined in an XML document through an object model which represents that data, instead of dealing with the structure of an XML document like DOM and SAX. Castor XML can marshal many Java objects to and from XML. Marshalling, and the inverse operation of unmarshalling, involves converting a stream of data, or sequence of bytes, to and from an object. Marshalling converts an object to a stream, while unmarshalling converts from a stream to an object. Castor, however, is not a complete solution for applications such as web services.

BRIEF SUMMARY

It is therefore desirable to provide a framework that can map from both XML to Java and from Java to XML.

It is also desirable to provide data binding support to web services.

It is also desirable to develop a parsing system that has increased speed and ease of use.

It is also desirable to develop a parsing system with broad support of XML specifications.

It is also desirable to develop a parsing system that has interoperability across platform versions and releases.

A system and method for data binding in accordance with one embodiment of the present invention uses a schema parser to create a schema object model when given an XML schema. Java classes can be generated using the schema object model, with the Java classes corresponding to elements and types in the schema. Mapping can be done in each direction between the schema and Java classes. This mapping is written to a type mapping directory. The schema object model can also contain mappings between each Java class and an XSD type. The mappings in the type mapping directory can then be used to generate XML when given a Java object tree, and can be used to create and populate a Java class when given an XML instance matching the schema object model.

Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

BRIEF DESCRIPTION OF THE DRAWING

<figref idrefs="DRAWINGS">FIG. 1</figref> is an overview of an exemplary XML data binding system in accordance with one embodiment of the present invention.

<figref idrefs="DRAWINGS">FIG. 2</figref> is an illustration of different components in an exemplary XML data binding system in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION

A data binding framework, or a data binding system, in accordance with one embodiment of the present invention can provide a mapping from XML to Java and from Java to XML. Such a framework can be based, at least in part, on Castor and JAXB. XML schema can be used as a syntax definition for the framework. Multiple modes can be supported, such as may include ‘fully code generated’ mode and ‘fully interpreted’ mode. The framework can bind to provided classes and can make use of a generic API. The framework can also provide validation of XML content, and can support a subset of an application runtime. There may be no inheritance required in the user code. This approach can provide acceptable performance, such as being able to work within a Java Remote Method Invocation (RMI) type timeframe to allow Remote Procedure Call (RPC) style invocations, such as under 10 ms. The system can utilize a configuration with a binding schema file, and can offer interoperability with systems such as .NET and IBM.

For web services, XML binding requirements at runtime can include the creation of Web Service Definition Language (WSDL) code from an existing remote Java interface. A schema can be generated for complex Java data types. Primitive types can also be mapped to XML Schema Definition language (XSD) types. XSD is an XML-based grammar that can be used to describe the structure of an XML document. A schema-aware validating parser can validate an XML document against an XSD schema and can report any discrepancies. The system can handle arrays and collection classes. The schema should be generated using some default rules. The user can have some control over the schema generation. The Java interface and data classes can be generated from WSDL. The system can convert XSD data types to Java and can generate Java classes for complex XML types. A user can choose a package for generated Java classes. A user can also recreate a schema from the generated classes.

For an XML to Java case, a given namespace and element name user can get the appropriate Java classes at runtime in a mode such as generated mode. Given the stream and class, a user can get the populated java instance. The user can also have control over the deserialization. For a Java to XML case, the primitives can be mapped to XSD types. The user can also specify the XSD type. The system can convert the java instance to an XML stream or to a tree, such as a DOM tree.

At runtime in dynamic mode, a system can read schema specified in WSDL. The system can also validate incoming XML documents using this schema. The system can create and manipulate XML using an API such as a DOM API or streaming parser API.

According to the JAXB specification, an XML data binding facility can contain a schema compiler able to bind an input schema to a Java class. The binding facility can also provide a binding framework that can utilize a runtime API supporting certain primary operations, such as unmarshalling, marshalling, and validation. An unmarshalling operation can map an XML document into a tree of existing and schema-derived classes. A marshalling operation can map content trees back to XML documents. A validation operation can validate content trees against schemas.

A system utilizing these operations is shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. In this system, an input XML schema <b>100</b> can be compiled into at least one Java class <b>104</b>. Marshalling can be used to map an XML document <b>102</b> to a class tree or Java object <b>106</b>, and unmarshalling can be used to map the Java object <b>106</b> to an XML document <b>102</b>. When unmarshalling, binding can be used by feeding an XML stream for an instance of an XML document to generated classes <b>104</b>, which can create and fill Java objects <b>106</b>. When marshalling, an instance of a Java object <b>106</b> can be fed to generated classes <b>104</b>.

Components of a system that can be useful for XSD/Java databinding are shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. A data binding subsystem <b>200</b> is shown, which includes a SOM instance <b>210</b>, a schema compiler <b>212</b>, an instance of the binding language <b>214</b>, and a binding framework <b>202</b>. The binding framework <b>202</b> itself can include a marshaller <b>204</b>, an unmarshaller <b>206</b>, and a validator <b>208</b>. The system also utilizes a parsing subsystem <b>222</b>, which includes a base parser <b>224</b>, a non-validating parser <b>226</b>, and a validating parser <b>228</b>. A parsing subsystem can be similar to that described in U.S. patent application Ser. No. 10/304,280, now U.S. Pat. No. 6,880,125 issued Apr. 12, 2005 entitled “SYSTEM AND METHOD FOR XML PARSING” to Chris Fry et al. The data binding subsystem can communicate with the parsing subsystem through a stream interface <b>216</b> and a schema interface <b>218</b>. The system can also include a web services subsystem <b>230</b>, which can communicate with the data binding subsystem <b>200</b> through a data binding interface <b>220</b>.

The schema object model, or SOM, is a java object model that can read or write any valid XML schema document, verify its validity, and allow easy programmatic manipulation of schema documents. A schema parser can parse an XML schema and create a schema object model. A schema writer can take a SOM and output an XML schema representation.

For each construct in SOM, there can be a corresponding interface. All generated classes can implement these interfaces. It is possible to write general parsing and XML output routines in terms of these interfaces, thereby leaving all such code out of the generated classes. There can be generic implementations of these interfaces that can be used in the dynamic case, where users of the data binding will not have enough information about the schema to write to a Java interface that is a direct mapping of the schema. These generic classes can implement enough of the DOM interfaces to allow processing through XSLT or other appropriate tools.

Given a SOM and an optional binding specification, a schema compiler can output a collection of java classes or interfaces that map the complex types and elements described in the schema into Java classes.

The binding process can be configurable. This can allow an XML Path language (XPath) expression or other similar expression on the schema to specify bindings at specific nodes in the schema. A marshaller can take a tree of java objects and output valid XML. An unmarshaller can parse an XML instance of a schema document and generate or fill in an object tree.

Generally speaking, data binding can happen at compile time or at runtime. At runtme, an arbitrary schema can be received, such as from WSDL, and the system can access the XML data from an instance document in a generic fashion. Generating java classes may not be feasible in this case, as the user of the generated classes may not know which methods to call.

In a dynamic situation, a schema parser can be used to create a SOM and set up data binding if the parser is given an XML schema. Using generic XSD objects, one or more object trees can be created that are based on the SOM. To use binding with unmarshalling, an empty object tree can be obtained or cloned, the XML instance can be parsed using general classes, and the object tree can be filled in. If marshalling, an XSD instance XML writer can be used for output, and can do some validation in the process.

For a code-generation situation, binding can be set up by first using a schema parser to create a SOM when given an XML schema. Using this SOM, Java classes can be generated that correspond to elements and complex types in the schema. The mapping in both directions can be entered into a type mapping directory, from complex types to Java classes. The generated classes can implement the DOM interfaces and generic XSD object interfaces, and may not contain any parsing code. An XSD instance parser can be initiated with the generated SOM, which can prefill various hashes. A pool of empty object trees can be created that are ready to be filled. An XSD instance XML writer can be instantiated with prefilled data structures that are ready to output XML when given an object tree. For unmarshalling, an empty object instance tree can be cloned, created, or obtained from a pool of objects for use in binding. The instantiated XSD instance parser can be used to parse the code and fill in the empty object tree.

For a code generation case where Java classes are given, binding can be set up by reflecting on Java classes, building a SOM that contains mappings of each class into an XSD complex type or simple type.

The same basic procedure can be used as when starting with an XML schema. Each generated class can contain a static method that can take an XML instance of that schema type, and can create and populate the given Java class. There may be no need to create an intermediate tree of code-generated objects.

When unmarshalling, binding can be used by feeding an XML stream to generated classes, which can create and fill Java objects. When marshalling, an instance of a Java object can be fed to generated classes.

There can be at least two choices at this point. Generated object instances for DOM type manipulations can be created, or an XML stream can be created directly out of the Java classes, bypassing any intermediate object creation.

For a code generation case where both Java classes and XML schema are given, binding can be set up as described above, except that a smarter binding dictionary can be generated. Implicit in all these cases is the use of a binding specification that can be used to customize the process. All these implementations can use a streaming parser, such as is described in U.S. Provisional Application No. 60/362,773 entitled “STREAMING PARSER API,” by Chris Fry et al.

SOM can be implemented as a set of Java classes that extend from a generic XSD object class. A schema object can contain a catalog of types, both complex and simple, as well as model group definitions and element objects. These classes can somewhat directly model various schema components. A schema parser can contain all the necessary parsing code to take an XML schema and create a SOM. Similarly, a schema writer can take a SOM and output an XML schema. The SOM classes may not contain any parsing logic.

The following example includes code to create a SOM with one element of complexType “someType”:

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Schema schema = new Schema( );</entry></row><row><entry /><entry>schema.setTargetNamespace(“http://www.foo.com”);</entry></row><row><entry /><entry>ComplexType ct = new ComplexType( );</entry></row><row><entry /><entry>ct.setLocalName(“some Type”);</entry></row><row><entry /><entry>ct.setParent(schema);</entry></row><row><entry /><entry>schema.addComplexType(ct);</entry></row><row><entry /><entry>ModelGroup mg = new ModelGroup( );</entry></row><row><entry /><entry>mg.setParent(ct);</entry></row><row><entry /><entry>ct.setContentModel(mg);</entry></row><row><entry /><entry>Element int_el = new Element( );</entry></row><row><entry /><entry>ct.setLocalName(“some_integer”);</entry></row><row><entry /><entry>int_el.setType(new ExpName(SchemaTypes.SCHEMA_NS,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>SchemaTypes.XSD_INT));</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>mg.addParticle(int_el);</entry></row><row><entry /><entry>mg.setMaxOccurs(2);</entry></row><row><entry /><entry>Element el = new Element( );</entry></row><row><entry /><entry>el.setParent(schema);</entry></row><row><entry /><entry>el.setType(ct.getExpName( ));</entry></row><row><entry /><entry>el.setMinOccurs(4); / / particle</entry></row><row><entry /><entry>schema.addElement(el);</entry></row><row><entry /><entry>/ / is this schema valid?</entry></row><row><entry /><entry>schema.validate( );</entry></row><row><entry /><entry>SchemaDumper d = new SchemaDumper(schema);</entry></row><row><entry /><entry>d.walkSchema( );</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

For each class in the SOM, there can be a corresponding Instance class that can hold an instance of a schema component. Each such instance object can hold a reference to the SOM Object that it represents. Given that the most common case can be receipt of many instance documents after initial receipt of a schema, it is possible, using the knowledge of the schema, to precreate much of the object tree in an empty state. The empty trees can then be cloned when a new tree is needed, or possibly pooled, to avoid some of the overhead involved going from an XML instance of a schema to java objects. Given a fully instantiated object tree, it only remains to call the appropriate setters on the leaf nodes to fill in the actual data. Some schema constructs may not be able to be fully allocated in advance. These instance classes can implement the DOM interfaces to allow XSLT and other tools to operate.

Code generation can be limited to the generation of interfaces. These interfaces can be implemented using dynamic proxies that can dispatch calls to the generic XSD object instances. This can allow all the parsing and XML output code to be reused.

Part of the binding process can involve mapping XML names to the more restrictive space of Java names. JAXB outlines an algorithm and approach that can generally be followed. In order to achieve a true round trip from XML to Java and back, the original XML name may need to be stored in the generated or dynamic classes, or perhaps in the mapping directory.

The foregoing description of the preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention, the various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.