|Publication number||US7703008 B2|
|Application number||US 11/369,784|
|Publication date||Apr 20, 2010|
|Filing date||Mar 7, 2006|
|Priority date||Jul 19, 2002|
|Also published as||CN1685312A, CN1685312B, CN100478958C, CN101030229A, EP1552388A1, EP1552388A4, US7047488, US8683321, US20040025117, US20060150095, US20100205522, US20140164898, WO2004010294A1|
|Publication number||11369784, 369784, US 7703008 B2, US 7703008B2, US-B2-7703008, US7703008 B2, US7703008B2|
|Inventors||Christopher Todd Ingersoll, Jayaram Rajan Kasi, Alexander Holmes, Michael Clark, Ashok Aletty, Sathish Babu K. Senathi, Helen S. Yuen|
|Original Assignee||Open Invention Network, Llc|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (13), Non-Patent Citations (4), Referenced by (5), Classifications (16), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates to systems and methods for registry driven semantic transformation of a document exchanged between businesses or applications. More particularly, it relates to systems and protocols for using one or more commonly accessible registries to transform electronic commerce documents among dissimilar interfaces, preferably XML documents.
Business-to-business (B2B) and application-to-application (A2A) electronic commerce are replacing former protocols for electronic data interchange (EDI). As businesses strive to improve their efficiency with B2B and A2A systems, a number of incompatible platforms and competing standards have emerged. One need that has been identified is to convert the documents from one system to another.
XML has become a widely used type of data because the rigid syntactic rules which must be applied to create inline markup make it relatively simple for computer programs to interpret and process. For example, a purchase order written in XML could be processed by an order entry software application that knows how to read the markup annotations that describe what is being purchased, who the purchaser is, and so forth. The growing acceptance of XML as an encoding scheme for documents has led to development of XML-ified application program interfaces for many legacy applications by enterprise adapter implementation (EAI) vendors.
EAI vendors bridge one system to the next, on an application-by-application basis. Interoperability is achieved by design, at design time. Connections between systems or applications are static. Implementation of new versions of applications requires modification of the static connections. Routing among applications is typically within an enterprise. Integration logic is developed on a point-to-point basis. Semantic logic is coded into EAI routines. Semantic logic and syntactic logic are mixed in the coding. The sending party or source of a document is responsible to ensure that what they send is exactly what the target or recipient has advertised to receive. There is no concept of modeling degrees of compatibility for an interface, as opposed to requiring perfect compatibility. This perfect compatibility is difficult to achieve, as it requires that all clients be updated with the latest versions of the services' interfaces and that interfaces be updated contemporaneously. Transformation components are difficult to reuse. No commonly accessible repository is provided to capture individual transformation preferences or to support transformation based on user profiles. The EAI vendor approach makes it difficult and costly to adapt transform routines from one pair of systems or applications to another.
Accordingly, opportunities arise to devise methods and structures that commonly manage transformation of documents between dissimilar interfaces, that provide runtime interoperability and distributed execution of transformations.
The present invention relates to systems and methods for registry driven transformation of a document exchanged between businesses or applications. More particularly, it relates to systems and protocols for using one or more commonly accessible registries to transform electronic commerce documents among dissimilar interfaces, preferably XML documents. Particular aspects of the present invention are described in the claims, specification and drawings.
The following detailed description is made with reference to the figures. Preferred embodiments are described to illustrate the present invention, not to limit its scope, which is defined by the claims. Those of ordinary skill in the art will recognize a variety of equivalent variations on the description that follows.
The web services engine 211 has access to a variety of transforms 213, including transforms using the common syntactic base. These transforms may be reusable. More than one transform may be invoked to convert a document from source semantics to target semantics. It may be desirable to utilize a common semantic base for transformations, for instance, transforming incoming documents to a well-understood document schema, such as the xCBL schema for electronic commerce documents 212. By transforming incoming documents to a common semantic base, the need for point-to-point transforms is minimized. The transforms may be chained and may be reusable. The transforms may be isomorphic or homomorphic. That is, the transforms need not be perfectly reversible. The transforms typically will be rated, either a priori or by comparing source and target semantics before and after transformation, to estimate the degree of loss resulting from the transform. A transform success score can be used to select among alternate sequences of transforms from source to target semantics. Loss resulting from transforms can be compensated for by including in the target document one or more fields that capture imperfectly translated information from the source document. These fields may be user viewable, so that a user associated with the source, the target or an intermediary service provider can respond to imperfections in the computer-implemented transformation service. Alternatively, the source document and target document can be sent to the target, with references to parts of the source document that have been imperfectly transformed or that are suspected of having been imperfectly transformed. These references can be part of the target document or a separate document, such as an error document. They can be a string, a pointer or some other form of reference. References can be provided to one or more sections of the target document where the imperfectly transformed information belongs. The references to the target document may be to an element or subsection of the target document or to a specific location within an element or subsection. In yet another embodiment, the target document and excerpts of the source document can be sent to the target, with references to the excerpts of the source document and, optionally, to the target document.
A commonly accessible registry, partially illustrated in
A commonly accessible registry can provide a so-called semantic hub. The commonly accessible registry may maintain service descriptions for the applications that provide services, such as electronic commerce services. Inbound and outbound document interfaces are registered as part of the service descriptions, preferably in the form of XSD definitions. A service is free to register multiple interfaces, for instance to support multiple versions of an electronic commerce document standard (e.g., xCBL 2.0, xCBL 3.0, or xCBL 3.5) or to support multiple document standards (e.g., xCBL, IDOC, OAG, or BAPI). The introduction of document family concepts provides a way to manage schemas and document types across documents standards and standards versions, as well as custom systems. Document families associate document types that represent the same business events into families. Transformation maps or transforms manage standard and custom logic to convert among document family members. A cost of using a particular transform may reflect imperfect translation of the document. Again, a transform success score can be associated with the transform either a priori, based on prior experience, or by dynamically comparing the semantic content of the document before and after application of the transform.
Maintaining transforms using XML as a common syntactic base is preferred, but not necessary. XML is a rich, self-describing data representation that facilitates declarative mapping logic. Several semantic bases, such as xCBL component model, provide a consistent semantic base to harness XML's powerful semantics. Modeling of XML documents to a semantic registry facilitates reuse and rapid development of new transforms, thereby enhancing the value of existing transforms. Focusing on semantic mapping, with a common syntactic base and even a common semantic base, reduces the complexity of developing new transforms. Business analysts, instead of programmers, may be able to use transform-authoring tools to define XML-to-XML semantic conversions.
A document family, as illustrated in
A registry may subdivide schemas into namespaces, as illustrated in
The namespace is linked to documents and document families, in this embodiment, through the document ID class 812. The document ID 812 may actually have two types of links to a namespace, one of which is the root namespace it belongs to, and the other which is used for extension namespaces. This supports major versions and minor versions. A major version document ID may be a brand new version of a document that does not extend a previous version of a document. A minor version document ID may extend either a major or minor version document ID. A major version doc ID will only have a single namespace relationship, which references the namespace within which the root element is defined. A minor version doc ID references the super parent (major version) doc ID's namespace, along with any other namespaces within which any extensions exist. The document ID 812 may be associated with the document family 804, an external ID 805, document rule 813, a transformation map 823 and an XML document ID 822. Attributes of a document ID may include a name, a URI and a primary alternate URI. A URI is automatically generated for a doc ID using three components: namespace URI, DocID Name, DocId version. This Doc Id URI is used to refer to this Doc ID. If a user desires a custom Doc ID naming scheme, they may enter their own URI, and this is set in the primaryAltId relationship. Users may also have more than one naming scheme; in which case the otherIds relationship models these names. All these names should be unique. Attributes of a document ID may further include a display name, a description and a document version. All of these attributes may be maintained as strings. A specialization of document ID is XML document ID 822, for XML documents. Attributes of the specialization may include an XML element name, a version type, a bean class name and major and minor versions. As characteristic of XML, a relationship loop indicates that XML document IDs may represent nested elements. An external ID 805 may be associated with the document ID 812. The external ID 805 may be a registry key or an alias for a URI. Both a primary, default link and one or more user supplied aliases may link the document ID and external ID.
Document ID rules 813 may be sufficiently generalized to support transforms, validations, and display maps. Transforms 823, sometimes called transformation maps, are a specialization of the document ID rule 813. Logic implementing the transform is linked to a document ID rule 813 through a set of transform components 825. A transform component, in turn, is linked to an external file 827. Attributes of the transformation map 823 may include a cost or transform success score, a transformation URI and a location URI. The transformation URI uniquely identifies a transformation map within a registry. A location URI is an optional identifier that indicates where the transformation should take place. For example, if only one host within a network is capable of performing the transformation, its URI is assigned to the location URI attribute and the transformation/router will send the transformation to this host to be performed. Attributes of the transformation component 825 may include a transformation component URI, a name, description, component type, implementation file, package name and and execution order. Transformation components 825 are linked as a set to the document ID rule 813. The execution order attribute confirms the sequence in which transforms are applied, if more than one transform is required. In this embodiment, transform logic may include one or more of an XSLT map, and XST map, a Java component, or a Contivo map. Transform components are linked to set of configuration elements 826. Attributes of the configuration element may include a name and a value. Document ID rules 813 are also linked to a set of map context strings 814. These strings associate the document ID rule 813 and with a particular trading party, either a sending/source or receiving/target party, or with a particular service or action, as described above in the context of
Logic to retrieve and execute transforms may conveniently be accessed through an XML transformation module (XTM), as illustrated in
The transformation may be identified in the inbound message 901, which may but preferably does not include the details of which transforms should be applied to accomplish the transformation. In
An ICD is contained in the same envelope 901 as the message to be transformed, may use the following schema to identify a transformation required:
<?xml version=“1.0” encoding=“UTF-8”?>
<xs:element name=“Attachment” type=“xs:boolean”
<xs:element name=“Transformation” minOccurs=“0”
An example of transformation instructions, according to schema above, is:
<xs:element name=“Transformation” minOccurs=“0” maxOccurs=“unbounded”> <xs:complexType> <xs:sequence> <xs:element name=“Connector” type=“xs:anyURI”/> <xs:element name=“StartDocTypeName” type=“xs:QName”/> <xs:element name=“StartDocVersionID” type=“xs:string”/> <xs:element name=“EndDocTypeName” type=“xs:QName”/> <xs:element name=“EndDocVersionID” type=“xs:string”/> <xs:element name=“CommunityID” type=“xs:string” minOccurs=“0”/> <xs:element name=“ComponentID” type=“xs:string” maxOccurs=“unbounded”/> </xs:sequence> </xs:complexType> </xs:element>
In this example, the source document type is identified by StartDocTypeName and StartDocVersion. The StartDocTypeName should be a fully qualified document type, a QName in XML terms, including a namespace and local name of the root element for the document type. Alternatively, a unique naming convention could be used, with appropriate administrative provisions to enforce uniqueness within a relevant scope. A version identifier should be supplied to distinguish among variations of the same document. A customer may extend an address element within a purchase order, for instance, and the extensions will have a different minor version ID than the major version. EndDocTypeName and EndDocVersion identify the target document resulting from the transform. Community ID specifies the community where the transform is registered. Component ID is used to look up the transform logic, for instance via the transformation component 825.
One implementation of an ICD specifying the target's preference to receive (or not) the original, source document in addition to the transformed target document is expressed in the following schema excerpt:
<xs:element name=“TransformationContract”> <xs:annotation> <xs:documentation>Transformation Instructions</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name=“Attachment” type=“xs:boolean” minOccurs=“0”/>
The attachment tag will indicate whether the original, source document should be attached or not. A default, in the absence of this element, may either be to attach the document or not to attach it.
More detail regarding computation of transform sequences using both source and target registries of transforms is provided in flowchart
Referring to the flow chart in
The calculation of alternative transform sequences and preferred transform sequences may operate in different environments. The following use cases illustrate some of these environments. In the first use case, no transformation is required. The module for determining a transform sequence is invoked, but the source and target documents are the same type. No transformation is required. In the second use case, no transformation is available between source and target. This may be the case when no transform sequence can be calculated between differing source and target documents, or when transformation policy is “no transforms” and the source and target documents differ, or when only a lossless transformation is accepted but all calculated transform sequences are lossey, as indicated by their transform success scores. An operating exception occurs. In the third use case, the source and target are in the same community, so only one transform registry is queried and a valid path exists. One or more transform sequences are determined. A preferred sequence is determined. In a fourth use case, the source and target are in separate communities and a valid path exists. Two transform registries are queried. As in the third case, one or more transform sequences are determined and a preferred sequence is determined.
Transform success scores, as described above, can be determined a priori, by experience or dynamically, or, more generally, by any metric of a lossey semantic transform. An a priori score is assigned to a transform based on some combination of analysis and tests. The score does not change with experience. An experience based score may begin with an a priori score or a default score, and be adjusted with experience. For instance, methods of dynamically computing success, explained below, can be applied for selected transforms that are used, and the corresponding transform success score updated, for instance as a weighted or moving average, either discarding an oldest historical success score or assigning relative weights to past and present success scores. One approach to dynamically determining success scores is to apply a transform to the candidate document and analyze the transformed document. The transform is applied to the source or intermediate source document, producing a target or intermediate target document. The content of elements (in an XML or similar document) is listed for source and target documents, for instance in a frequency table. Discrepancies between the source and target frequencies reduce the transform success score, regardless of whether the difference is positive or negative. The discrepancies optionally are reported. The success score can depend on exact matches between element contents, or may be weighted by degree. The following example helps illustrate this approach to dynamic scoring. The source document fragment is:
<Address1>125 Henderson Drive</Address1>
</ NameAddress >
The transformed target document fragment is:
A frequency comparison, based on elements of the source document fragment and keyed to exact matches would be:
125 Henderson Drive
A dynamic transform success score corresponding to the fraction of fields in the source document that appear verbatim as fields in the target document can be expressed as a success of 75 percent or a cost of 25 percent could be assigned to this example. A different score would be assigned if partial matches counted, as the house number element of the target document matches one token of the address 1 element of the source document. The success score could correspond to the fraction of the text in fields of the source document that appears verbatim in fields of the target document. Application of a sequence of scores requires calculation, for some purposes, of an aggregate success scores. When individual scores are combined into an aggregate transform success score, the combination may be additive, averaged or multiplicative. The method of constructing an aggregate transform success may take into account the number of transforms in sequence, as in the multiplicative combination of success scores or may accumulate (without compounding) the errors, as in the additive combination of costs. For instance, in the multiplicative combination, if the transforms are T1, T2 and T3, loss percentages can be calculated for each of the three and combined as (1−T1)*(1−T2)*(1−T3). More generally, an aggregate transform success score may be any metric of a sequence of transforms resulting in a lossey transformation from source to target document.
User interfaces for administering document family information and for searching for transforms are illustrated in
While the present invention is disclosed by reference to the preferred embodiments and examples detailed above, it is understood that these examples are intended in an illustrative rather than in a limiting sense. Computer-assisted processing is implicated in the described embodiments. Accordingly, the present invention may be embodied in methods for computer-assisted processing, systems including logic to carry out transform processing, media impressed with logic to carry out transform processing, data streams impressed with logic to carry out transform processing, or computer-accessible transform processing services. It is contemplated that modifications and combinations will readily occur to those skilled in the art, which modifications and combinations will be within the spirit of the invention and the scope of the following claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5784566||Jan 11, 1996||Jul 21, 1998||Oracle Corporation||System and method for negotiating security services and algorithms for communication across a computer network|
|US6125391 *||Oct 16, 1998||Sep 26, 2000||Commerce One, Inc.||Market makers using documents for commerce in trading partner networks|
|US6269380 *||Aug 31, 1998||Jul 31, 2001||Xerox Corporation||Property based mechanism for flexibility supporting front-end and back-end components having different communication protocols|
|US6671695||Jun 18, 2001||Dec 30, 2003||The Procter & Gamble Company||Dynamic group generation and management|
|US6789077||Aug 31, 2000||Sep 7, 2004||Sun Microsystems, Inc.||Mechanism and apparatus for web-based searching of URI-addressable repositories in a distributed computing environment|
|US6868401 *||Oct 19, 2000||Mar 15, 2005||Conocophillips Company||Transaction processing system to facilitate the commercial support activities associated with the buying and selling of commodity products|
|US6961760||Jul 17, 2001||Nov 1, 2005||International Business Machines Corporation||Transforming data automatically between communications parties in a computing network|
|US7219223||Feb 8, 2002||May 15, 2007||Cisco Technology, Inc.||Method and apparatus for providing data from a service to a client based on encryption capabilities of the client|
|US7458018 *||Jun 27, 2002||Nov 25, 2008||Microsoft Corporation||System and method for obtaining and using namespace related information for opening XML documents|
|US20020194227||Apr 18, 2001||Dec 19, 2002||Siemens Corporate Research, Inc.||System for multimedia document and file processing and format conversion|
|US20030079029||Aug 5, 2002||Apr 24, 2003||Sandilya Garimella||Single system user identity|
|US20030208505 *||May 5, 2003||Nov 6, 2003||Ward Mullins||Dynamic class inheritance and distributed caching with object relational mapping and cartesian model support in a database manipulation and mapping system|
|US20050071266 *||Dec 29, 2003||Mar 31, 2005||Eder Jeff Scott||Value and risk management system|
|1||B. Omelayenko, D. Fensel, "Scalable Document Integration for B2B Electronic Commerce", Special Issue of Electronic Commerce Research Journal onn B2B Research, Sep. 12, 2001, pp. 1-31.|
|2||*||Pivotal Intelligence Engine, Technology Overview, 2001 Pivotal Corporation, pp. 1-27.|
|3||Supplementary European Search Report for European Patent Application No. 03765553.7, PCT/US03/21862, dated Dec. 19, 2008.|
|4||*||XEDI.org, 'XML and EDL: Peaceful Co-Existence, by XMLSocutions Corporation, Copyright 1999-2001 XMLSolutions Corporation, pp. 1-15.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8768877||Mar 7, 2006||Jul 1, 2014||Ca, Inc.||System and method for data manipulation|
|US8775654||Dec 19, 2003||Jul 8, 2014||Salesforce.Com, Inc.||Apparatus and methods for mediating messages|
|US8838833||Apr 2, 2010||Sep 16, 2014||Salesforce.Com, Inc.||Providing on-demand access to services in a wide area network|
|US20060200747 *||Mar 7, 2006||Sep 7, 2006||Rishi Bhatia||System and method for providing data manipulation using web services|
|US20080065683 *||Aug 30, 2007||Mar 13, 2008||Alcatel Lucent||Concatenation discovery web service|
|U.S. Classification||715/234, 715/239, 715/236, 715/229|
|International Classification||G06F9/44, G06F17/22, G06F12/00, G06F17/00, G06F17/21, G06Q30/00|
|Cooperative Classification||Y10S707/99934, G06F17/227, G06F17/2288, G06F17/2247|
|European Classification||G06F17/22T2, G06F17/22M|