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.
The invention relates to the transformation of data and data types.
Certain drawbacks exist in the way data is currently transformed, or marshaled, between data types. In existing systems, a user staffs with an existing Java type and asks the system to generate the XML schema that reflects the JAVA® type, and further to marshal the JAVA® data to the XML that was automatically generated. Most products that marshal XML run through a compiler, such as a JAVA® to WSDL compiler, in order to generate an XML schema. One drawback to such an approach is that only the scenario going from JAVA® to XML is addressed. Current tools are not particularly good at taking an existing XML schema and turning that entire schema into a convenient-to-use JAVA® type.
Another problem with current marshaling technologies appears when a user simply wishes to look at a small piece of XML data. That user may prefer to simply pass on the rest of the XML data without processing that data. Current marshaling technologies are not effective at simply passing on the remainder of the data. Typically, going from marshaling to unmarshaling is complicated, as not all semantics in XML can be easily captured in JAVA®. If a user brings in a message, changes a small portion of the message, and tries to resend the message as XML, portions other than that changed by the user will be different, such that a lot of other information may be lost. If the XML contains wildcard attributes or elements, for example, those wildcards will not be retained. Information about element order may also be lost or scrambled, which is a problem if the schema is sensitive to element order.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
Systems and methods in accordance with one embodiment of the present invention overcome many deficiencies in existing marshaling and unmarshaling systems by translating XML schemas, which define XML data in an XML document, into XML types in JAVA® when marshaling data between XML and JAVA®. XML types are actually JAVA® types which, in addition to regular JAVA® bean functions and access to database, can also access and update XML data within JAVA® in an efficient, type-safe, robust, and convenient way. An architecture can be used in at least one embodiment that provides the ability to handle almost 100% of the schema introduced by a user.
The use of XML types can allow the combination of XML- and JAVA®-type systems. This can be done in a way that allows developers to achieve loose coupling. XML schemas realized as XML types can remain fully faithful to the XML. It can be easy for a developer to take control of precise transformations between existing JAVA® types and existing XML types. XML types can address the JAVA®/XML boundary by bringing together several technologies, including for example schema-aware strongly typed access to XML data document from JAVA®, compact and indexed in-memory XML store, speedy and minimal (pull) parsing and (binary) serialization, lightweight document-cursor traversal, XPath and XQuery navigation and transformation, and seamless JAVA® IDE integration.
For an XML-oriented “XML to XML via JAVA® code” example,
At the top of the XSD is a schema definition for an element named ‘purchase order.’ The element is defined as a complex type and contains an element called “line-item.” There is a ‘maxOccurs’ attribute set to ‘unbounded,’ meaning that the line-item can be repeated any number of times. Each of the line items is shown to have four sub-elements: desc, itemid, price, and qty. The ‘desc’ sub-element refers to a description element which is a string, ‘itemid’ refers to an item identifier element which is an integer (type int), ‘price’ refers to a price element which is a floating point number (type float), and ‘qty’ refers to a quantity element which is an integer. These sub-elements are all built-in types of the schema. This schema is basically a description or representation of how a valid purchase order schema should look.
In order to write a program using XML types, an XML schema file can be added to a JAVA® project. An example of a system for XML marshaling and unmarshaling is shown in
A JAVA® source code representation of the XML types compiled from the example schema in
In one embodiment, XML types can implement a common base XML type called “XMLObject”. Such an XML type provides the ability to execute a number of XML-oriented data manipulations and will be referred to herein as an “XBean”. An XBean is not a standard JAVA® bean as an XBean inherits from an XMLObject. An XMLObject is unusual, in that an XMLObject as an XML type provides a way for each XBean to retrieve its original, or corresponding, XML. An XBean can be thought of as a design pattern for JAVA® types representing data, such as business data, that can be serialized and de-serialized to XML, as well as accessed in a type-safe way from JAVA®. XBeans can also be thought of as a small set of natural language idioms, either annotated JAVA® or non-JAVA®, for generating those types. Normally, there is a tradeoff when an application developer or component developer decides how to represent business data. If the data is represented as type-safe JAVA®, then serialization to XML or to databases can be awkward. If the data is represented as XML, then conversion to JAVA® types can also be somewhat awkward. The same holds true for conversion to either of the other types if data is in a result set from a database. It is therefore advantageous to provide a single category of JAVA® types that is convenient for passing, using, and manipulating as both XML and JAVA®. It is further advantageous that the same type is convenient for database access as well as form input and validation.
As Shown in
For example, an application developer could define a file called MyData.schemabean, with the following contents:
This file could compile into a XBean with metadata, such as in
If the data was XML-oriented, for example, a user might have cared whether a name came before a description or a description came before a name. Systems and methods in accordance with the present invention allow a user to get back to the original, ordered XML. There can be any of several methods on a base XMLObject type, such as methods called “getXMLCursor” and “executeXPath.” An XML type can have a number of XML data operations, including methods to query values using XPath, transform values using XQuery, or iterate over the data document using an XMLCursor. This base type can hold several technologies together.
Certain methods can determine what the XML looks like at any point in time. For example, XML types can be used to implement a Web service that executed the requested operation such as shown in
For instance, a user might receive a number of purchase orders with high line items that have erroneously set the line item with quantity 0. That user may wish to manipulate these purchase orders, such that whenever somebody leaves a quantity field set to 0, the system changes that quantity field to 1. A function can take a purchase order XBean as input, and an XPath can be executed on the purchase order which looks for any line item tags underneath the purchase order tag that have quantity equal to 0. This is shown, for example, starting at line 5 in the Figure. A list of nodes can be returned to the user that match the XPath. That list of nodes can be cast back to the XBean type that the user knows it to be. The system selects a set of line items that can be cast to an array. Once the results are obtained from XPath, it is possible to iterate through the results and use an XBean method to manipulate the result nodes.
Strongly typed JAVA® accessors may not be appropriate for all XML usage. In one embodiment, XML types can extend a base XML-oriented XMLObject type that provides, for example, XPath, XQuery, XMLCursor, and XMLReader. On line 5, the XMLObject getAll Values method executes an XPath on the input to locate all line item elements with qty=0. On lines 6 and 7, it can be seen that the LineItem types can be used to update the XML data document. Each instance of the type refers to a specific node in the document, and when methods such as setQty(1) are called, the data of the document are being manipulated in an easy, type-safe way. On line 8, the type is returned directly from the Web service to complete the function and send the response message.
Systems and methods in accordance with embodiments of the present invention can also deal with transformation among different XML types, where a user may need to process an XBean to retrieve data. For example, it may be necessary to clean up the line items by modifying the description and price to match the item ID. This can be done in one example by looking up each catalog item in an existing application database. This work can be done using a JAVA® lookup method that can take an integer item id and return a CatalogItem type. For instance:
This class appears to be similar to a LineItem XML type, but has some relatively minor differences. For instance, CatalogItem has no quantity and the item ID is called a “cataloglD” rather than an “itemID.” In fact, since CatalogItem is so similar to LineItem, it may be desirable in some situations to write code such as that shown in
In systems and methods in accordance with embodiments of the present invention, each XML transformation can be implemented using an XQuery stored in a directory of transformations. Each XQuery can transform from one or more types, each with a known XML schema, into a specific type. A visual XQuery editor can be used that has input and output types pinned to the line-item type, as well as the default type for CatalogItem. An XQuery editor can allow a system or user to connect itemID to catalogID, and to indicate that the quantity should be zero.
An example of a default type declaration for the CatalogItem class is shown in
An example of an XML transformation system is shown in
An alternative way to ensure that the quantity is correct is to define the CatalogItem through a line-item transformation to take two input arguments, such as a CatalogItem and an integer quantity. From this example, it can be seen that there is a global registry of transformations, indicating source types and target types. Sources and targets are allowed to be JAVA types. Whenever an automatic translation between two different types is require, the registry can be consulted. A registry can be used that allows a single JAVA® type to map to any number of different XML types, depending on the situation. A registry can also have the advantage that every mapping between any two given types need only be defined once, and then it is easily reusable.
In certain systems, difficulties may arise such that multiple versions of a schema may need to be dealt with at the same time in a single program. For this reason, there can be a provision for tagging each schema with a version identifier. The relevant JAVA® types and transformations can all be done separately, treating each version as its own type system.
In yet another example, a user may wish to write a Web service that takes a catalog item as input, or to expose an existing JAVA® function such as “findCatalogItem” as a Web service. For example, the following code could be written to expose findCatalogItem as a Web service in existing systems:
Such an approach may be acceptable where a user is defining the proper WSDL type for that user's Web service. Unfortunately, the situation may be such that there is an existing XML schema describing the desired result type. For example, the results may be returned as a standard purchase order line-item element as in the examples above. In such case, the actual WSDL may not conform to the existing XML schema. An attempt can be made to create the proper schema using XML transformation, but other than providing a convenient syntax, existing systems provide no assistance in ensuring that the map conforms to the schema. Using a transformation registry in accordance with various embodiments of the present invention, however, it can be easy to ensure that the return result conforms to the proper type.
For example, the code could be modified as follows:
The code above requires that there be a defined XML transformation that maps the CatalogItem type to the type of the po:line-item element. If there is none, the IDE will signal an error on the return-schema annotation. However, if there is a defined transformation, the return type of the Web service method can conform to the requested schema and the necessary schema can be included in the emitted WSDL.
In the example, such as can be seen in the line including “return-schema type=po:line-item,” the system allows a user to return a catalog item, but have the line item in the XML. The system can go to a registry of XQueries and execute the instructions using an explicit XQuery. This embodiment provides for the association of an XQuery with an XML Map, the support of every schema, and a way to get simultaneous access to both the strongly-typed view and the XML view of the data.
As Shown in
Systems and methods in accordance with some embodiments can keep an XML schema and a corresponding JAVA® type in sync. A user with a strongly-typed JAVA® can begin to add new line items or to change quantities, for example. If that user then wants to run an XPath path on the JAVA® type, the Xpath may need to be run on the XML data document in the current form of the data. In this case, if a user makes a modification to a document, either on the XML side or on the strongly-typed JAVA® side, the appropriate portion of the other side can be invalidated. When a user subsequently looks at that other side, the previously-invalidated information can be faulted in.
In order to compile an XML schema, it can be necessary to parse the schema, or XSD file, which is referred to as “schema for schema”, In other words, an XSD file that represents the appropriate schema for the XSD files themselves. If a system is supposed to be able to handle 100% of the schema passed to the system, and the system generates convenient JAVA® accessibility, it can be expected that the system uses its own generated types for understanding XSD files when the system reads schema. A user should be able to take the schema for schema and compile that into JAVA® such that the system can simply use the JAVA®.
Systems and methods in accordance with some embodiments, as shown in
Systems and methods in accordance with one embodiment of the invention maintain each schema as a JAVA® type, including simple types. If a user has a schema that is a restriction of a simple type, it can be indicated in the schema. For instance, if a user-defined type to be an integer of a legal type, it has to be a five digit number between 10,000-99,000. It is not necessarily desirable to define this to be a simple integer type as in existing systems. Instead, the information can be generated into a JAVA® type. The name of the JAVA® type can then be generated from the schema, such as the name “restricted integer.”
Another invariant that can be maintained by systems and methods in accordance with the present invention arises in cases where there are at least two types in a schema that are base types. If one of the types is a base type of the other, that relationship will connect the two types in JAVA®. A high-fidelity translation of typed systems can allow base types to be preserved.
A validation engine using complied XML type constraints 118 can also be used to allow a user to determine whether any relevant XML type 120 is valid according to the XML. For example, in XML a purchase order line item might have a description quantity, catalog number, and a price. There may also be a restriction in the appropriate XML schema that indicates ‘description’ is optional, but ‘catalogItemNumber’ is not optional. In JAVA® there is no way of indicating that a field is not optional, or cannot be null. As such, most people who do marshaling are not able to validate a bean. Validate methods in accordance with embodiments of the present invention can be used that allow a use to validate any bean against the XML type constraints, and to be informed of any validity problems.
In systems and methods in accordance with some embodiments, an XML type can be shared among multiple JAVA® components. An XBean can be automatically emitted, such as where an automatically generated XML type is defined for a user-defined component works. In such a case, XBeans representing parameters and return values can be auto-generated as inner classes to an XML control interface generated for the component. If the message types are actually shared across many components, it may not make sense to have private XBean types for each instance of the message. In such case, it should be possible to refer to an XBean type explicitly when defining a user-defined component, in order to explicitly control how the XML type of the component is shaped. For example:
By referencing the XBean type “MyData” in the component, such as for parameter-xml, it can be asserted that the bean has getters that correspond to the argument names. For example, getA should return a String, and getI should return an int. If these types do not line up, it may result in a compile-time error. For return-xml, it can be asserted that the bean type is the return value, or that it has a single property whose type matches the return value. By referencing the XML type, the XML schema is being referenced that defines the type of input and output messages to this method. The schemas can be reusable since they have names such as “MyData”. A map is also being referenced between the XML and the JAVA® types. The map can be attached to the MyData type as metadata and, since it is attached to a named type, the map can be reusable.
A generated XML control interface that can be obtained when specifying explicit XBeans on the component can be as follows:
In this example, the named XBean types are used to specify the xml schemas allowed, and there are no generated inner classes.
An XBean type can extend a base XML type, such that wherever XML can be passed, an XBean can be passed as well. In addition, any XBean can be attached to an XML data document, so wherever XML is available, an XBean can be created for convenient access to the data. In systems and methods in accordance with some embodiments, XBeans can be created easily and used in several different ways. For instance, an XBean can be created implicitly via the definition of a JWS (JAVA® Web services) method. An XBean can be created based on a parameter list of the function and the maps associated with the function. Also, an XBean can be created explicitly using a *.xbean file. A *.xbean file can have at least two different implementations, such as JAVA® Bean+Maps or XML+Query, each of which can freely use annotations. An example of implicitly creating a bean over a JWS operation might look like the following:
This would implicitly create an XBean using the default maps for the operation. Applying a specific map to the operation would create the XBean using those maps for input and output. If the beanName is already defined, the existing bean can be used. A separate syntax can be used when creating a bean, instead of using an existing syntax.
A simple JAVA® Bean+Maps *.xbean file might look like the following: public interface xbeanl
This would create a file with public get and set methods, as well as the standard XML that would be defined for this set of properties. A slightly more complex file would have a map attached, such as:
The above examples use individual JAVA® members as native storage. Equally important can be the use of XML as a native storage. On the opposite side, a simple file could use XQuery to return values. This might look as follows:
In systems and methods in accordance with some embodiments, there can be two XML types: movable cursors and immovable values from a developer's point of view. As cursors are moved, the part of the XML data document viewed by it can change, so the types can be designed to operate anywhere within an XML data document. On the other hand, immovable values can be fixed in one place, so they can have strongly-typed methods that match the XML schema of the part of the data document that they reference.
Although a user can use and manipulate a strongly type such as PurchaseOrder as if it were an ordinary JAVA® type, behind the type can be an implementation that directly accesses and manipulates the underlying XML data. For example, immediately after a value is set in a strongly type, the same value can be available from any cursor that uses XPath to search the same set of data.
The model shown in
XML types can add the schema to the JAVA® runtime model. For example, every schema can compile into a JAVA® type at compile time. This can include both complex types and simple types. Precompiled types such as XmlString and XmlDate can be used for the fundamental and simple types built-in to XML Schema. XMLObject itself can correspond to the xsd:anyType. In addition, for each schema, a pointer resource can be generated into the target class hierarchy that provides a map from all schemas with a given name into corresponding JAVA® type names.
Multiple schemas can be allowed to have the same XML name, but different types with the same name may be tagged with different “XML world” names. Only one world may be allowed to be the default world. One way to control type generation is through an .xval file adjacent to the .xsd file at compile time. At runtime, indexed XML can be automatically schema-aware. The visibility of schemas can be tied to the current ClassLoader. A thread-local index of visible schemas can be maintained. When a new schema is requested via fully-qualified XML name, a ClassLoader.getResourceAsStream call can be used to locate a pointer to the corresponding JAVA® type, such as in the default world. Lookups in a specific world can also be done. An implementation of XMLIndex can automatically resolve all XML to types using such a scheme. If no “xml world” is specified, a default world can be used. Other alternate views can also be specified that allow different versions of schemas to be used.
One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and applications.
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. Particularly, while the concept “type” is used for both XML and JAVA® in the embodiments of the systems and methods described above, it will be evident that such concept can be interchangeably used with equivalent concepts such as, interface, shape, class, object, bean, and other suitable concepts. 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.
This application claims priority from the following application, which is hereby incorporated by reference in its entirety: U.S. Provisional Application No. 60/442,673, entitled XML TYPES TN JAVA, by David Bau, filed Jan. 24, 2003. The following related U.S. patent applications and documents are hereby incorporated herein by reference in their entirety: U.S. patent application Ser. No. 09/898,898, filed Jul. 2, 2001, by Terry Lucas, et al., entitled, “Programming Language Extensions for Processing XML Objects and Related Applications”, U.S. Pat. No. 6,754,884, issued Jun. 22, 2004; U.S. patent application Ser. No. 10/150,436, filed May 17, 2002, by Cezar C. Andrei et al., entitled, “Declarative Specification and Engine for Non-Isomorphic Data Mapping”, U.S. Pat. No. 6,859,810, issued Feb. 22, 2005. Beas Systems Weblogic Workshop Online Help Document entitled, “Annotations Reference”, version: 2003.0718.084729, dated Jul. 18,2003.
Number | Name | Date | Kind |
---|---|---|---|
5321841 | East et al. | Jun 1994 | A |
5961593 | Gabber et al. | Oct 1999 | A |
6012083 | Savitzky et al. | Jan 2000 | A |
6067623 | Blakley et al. | May 2000 | A |
6070184 | Blount et al. | May 2000 | A |
6148336 | Thomas et al. | Nov 2000 | A |
6185734 | Saboff et al. | Feb 2001 | B1 |
6212546 | Starkovich et al. | Apr 2001 | B1 |
6230309 | Turner et al. | May 2001 | B1 |
6237135 | Timbol | May 2001 | B1 |
6243737 | Flanagan et al. | Jun 2001 | B1 |
6338064 | Ault et al. | Jan 2002 | B1 |
6367068 | Vaidyanathan et al. | Apr 2002 | B1 |
6480865 | Lee et al. | Nov 2002 | B1 |
6594823 | Corbin et al. | Jul 2003 | B1 |
6604198 | Beckman et al. | Aug 2003 | B1 |
6643652 | Helgeson et al. | Nov 2003 | B2 |
6662357 | Bowman-Amuah | Dec 2003 | B1 |
6721740 | Skinner et al. | Apr 2004 | B1 |
6721779 | Maffeis | Apr 2004 | B1 |
6754884 | Lucas et al. | Jun 2004 | B1 |
6792466 | Saulpaugh et al. | Sep 2004 | B1 |
6795967 | Evans et al. | Sep 2004 | B1 |
6802000 | Greene et al. | Oct 2004 | B1 |
6832238 | Sharma et al. | Dec 2004 | B1 |
6836883 | Abrams et al. | Dec 2004 | B1 |
6850979 | Saulpaugh et al. | Feb 2005 | B1 |
6859180 | Rivera | Feb 2005 | B1 |
6859810 | Andrei et al. | Feb 2005 | B2 |
6918084 | Slaughter et al. | Jul 2005 | B1 |
6918107 | Lucas et al. | Jul 2005 | B2 |
6922827 | Vasilik et al. | Jul 2005 | B2 |
6950875 | Slaughter et al. | Sep 2005 | B1 |
6970869 | Slaughter et al. | Nov 2005 | B1 |
6973493 | Slaughter et al. | Dec 2005 | B1 |
6990654 | Carroll, Jr. | Jan 2006 | B2 |
7043722 | Bau, III | May 2006 | B2 |
7072934 | Helgeson et al. | Jul 2006 | B2 |
7073167 | Iwashita | Jul 2006 | B2 |
7080078 | Slaughter et al. | Jul 2006 | B1 |
7089584 | Sharma | Aug 2006 | B1 |
7149752 | Mangan | Dec 2006 | B2 |
7155705 | Hershberg et al. | Dec 2006 | B1 |
7165041 | Guheen et al. | Jan 2007 | B1 |
7181731 | Pace et al. | Feb 2007 | B2 |
7260599 | Bauch et al. | Aug 2007 | B2 |
7260818 | Iterum et al. | Aug 2007 | B1 |
20010029604 | Dreyband et al. | Oct 2001 | A1 |
20020010781 | Tuatini | Jan 2002 | A1 |
20020049788 | Lipkin et al. | Apr 2002 | A1 |
20020078365 | Burnett et al. | Jun 2002 | A1 |
20020116454 | Dyla et al. | Aug 2002 | A1 |
20020169644 | Greene | Nov 2002 | A1 |
20020188486 | Gil et al. | Dec 2002 | A1 |
20030018832 | Amirisetty et al. | Jan 2003 | A1 |
20030018963 | Ashworth et al. | Jan 2003 | A1 |
20030023957 | Bau et al. | Jan 2003 | A1 |
20030028364 | Chan et al. | Feb 2003 | A1 |
20030041198 | Exton et al. | Feb 2003 | A1 |
20030074217 | Beisiegel et al. | Apr 2003 | A1 |
20030163603 | Fry et al. | Aug 2003 | A1 |
20040015840 | Walker | Jan 2004 | A1 |
20040103406 | Patel | May 2004 | A1 |
Number | Date | Country | |
---|---|---|---|
20040216086 A1 | Oct 2004 | US |
Number | Date | Country | |
---|---|---|---|
60442673 | Jan 2003 | US |