JP2008084328A - Document for commerce in trading partner network and interface definition based on same document - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a framework for promoting interaction between various platforms in a communication network. <P>SOLUTION: An infrastructure is provided for connecting business with customers, suppliers and trading partners. Under this infrastructure, a plurality of companies exchange information and services with one another using self-defined machine-readable documents (e.g., XML type documents). Documents (BID) describing documents to be exchanged are sent on the Internet, or communicated to members of the network. The business interface definitions (BID) notify potential trading partners the services the company offers and the documents to use when communicating with such services. Thus, a typical business interface definition allows a customer to place an order by submitting a purchase order. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a system and protocol for supporting transactions (transactions) between various clients connected to a network, and more particularly, to a system and protocol for supporting commercial transactions between platforms having various architectures. .

  The Internet and other communication networks provide a means for communication between computer platforms and people that are being used for a wide variety of transactions, including commerce in which participants buy and sell goods and services. Many efforts are being made to promote commercial transactions on the Internet. However, because there are many competing standards, in order to execute a transaction, participants in that transaction must agree in advance on the protocol used, and often platform architectures to support such transactions. Requires custom integration (dedicated integration). Commercial processes into certain nodes that are not compatible with the agreed standards may require considerable rework for integration with other nodes. In addition, when one company commits to one standard or another standard, that company is pinned to the standardized group transaction party and the others are excluded.

  An overview of the challenges encountered in the development of Internet commerce is described in "Eco System: An Internet Commerce Architecture" Tenenbaum et al .: Computer, May 1997; pages 48-55.

  It is desirable to standardize the architecture framework in order to open up commerce on the Internet. Platforms developed to support such commercial frameworks are IBM's Commerce Point; Microsoft Internet Commerce Frameworks; NET (Open Network AV); ) Soft EJCF (JAVA Electronic Commerce Framework).

  In addition to these proprietary frameworks, common distributed object model programming techniques based on CORBA IIOP (Common Object Request Broker Architecture Internet ORB Protocol) are being implemented. The use of the common distribution object model is intended to make it easier to migrate an enterprise system to a system that can be interoperated at the business application level for electronic commerce. However, a consumer or business using one framework cannot execute transactions on different networks. This limits the growth of electronic commerce systems.

  A company that implements one framework will have an application programming interface (API), which will be different from APIs that support other frameworks. Therefore, it is very difficult for companies to access each other's business services without having to adopt a common business system interface. Developing such business system interfaces at the API level requires considerable cooperation between the parties, but this is often not practical.

  Accordingly, it is desirable to provide a framework that facilitates interaction between various platforms within a communication network. Such a system would facilitate voluntary business among trading partners without the need for prior consent to custom integration or wide industry standards. In addition, such a system will drive progress towards business automation and eliminate much of the time, cost and risk of traditional system integration.

  In general, it is desirable to provide an electronic commerce system that replaces a closed commercial partner network based on proprietary standards with an open market.

  The present invention provides an infrastructure for connecting businesses to customers, suppliers and commercial partners. Under the infrastructure of the present invention, companies can communicate with each other using self-defining machine-readable documents (eg, XML (Extensible Markup Language) documents that can be easily understood by partners). And exchange services. A document describing a document to be exchanged (referred to herein as a business interface definition or BID) is sent over the Internet or communicated to members of the network. The business interface definition (BTD) tells potential commercial partners the services that the company provides and the documents to use when communicating with those services. Thus, a typical business interface definition allows a customer to place an order by submitting a purchase order (a purchase order that conforms to the document definition issued with the BID of the party receiving the purchase order). The supplier can check its validity by downloading an inventory status report according to the document definition issued with the BID of the business system management inventory data. The use of predefined machine readable business documents provides a more intuitive and flexible way to access enterprise applications.

  A node in a commercial network is an interface for a transaction according to the invention consisting of a machine readable specification of an interface, a machine readable including interpretation information for the machine readable specification of that interface. Establish with data structure. The machine readable specification of an interface includes an input document definition and an output document definition, which are accepted and created by a transaction processor in which the node acts as an interface. The definition of the input document and the definition of the output document include, for example, a description of a set of storage units and a logic structure for the set of storage units, respectively, according to a standard XML-based document. Machine-readable data structures containing interpretation information according to various aspects of the present invention include data type specifications (eg, strings, arrays, etc.), logic structures for logic structures in the definition of input and output documents. Including a data structure that maps a predefined set of storage units for a particular logic structure to each entry in the list of content and / or content models (eg, a list of possible values) and / or logic Provide a semantic definition of the structure (eg, mapping code to generate a name).

  In accordance with another aspect of the invention, the interface includes a repository in memory (which stores a logic structure library and logic structure interpretation information) accessible by at least one node of the network. This repository can be extended to include a library of input and output document definitions, a library of interface specifications, and a library of specification of interface nodes of network participants.

  Accordingly, participants in the transaction framework of the present invention execute transactions between multiple nodes of the network, including multiple node execution processes included in the transaction. The method of the present invention includes storing a machine readable specification of an interface for a transaction, the specification including an input document definition and an output document definition. The input and output document definitions each contain a description of a set of storage units and a set logic structure of storage units. In the preferred system, these definitions are extended and expressed by semantic mapping, content modeling, and some element data typing in a manner that follows the standard XML document type definitions, ie DTD. Transaction participants receive data, including documents, over a communication network. Participants parse the document according to the specifications stored for the transaction and identify the input document for the transaction. After parsing the document, at least a portion of the input document is provided in a machine readable format to a transaction process that provides output. The output document is configured to configure the output of the transaction process based on the stored specification output document definition. The output document is sent over a communications network, typically back to the source of the input document, or sent elsewhere for the specific type of needs of the transaction.

  Thus, the definition of the business interface bridges the gap between, for example, documents specified by XML and programs running on the front end of the transaction processing service at a special node. These front ends are implemented, for example, by JAVA virtual machines or by other common architectures that provide for the interconnection of systems at both ends of the network. Business interface definitions provide the technology by which transaction protocols are programmed using business interface definitions. The program for this transaction protocol is given by a detailed official specification in document format.

  The machine read specification of the transaction interface is made accessible to other platforms in the network. Participant platforms include resources to design input and output documents with transaction interfaces specified at complementary nodes. Thus, the participant's node includes resources that access the input document definition for the complementary interface and the output document definition for the complementary interface. A specification stored for the accessing participant node is established by including at least part of the complementary interface output document definition in the interface input document definition stored in that specification. Is done.

  The process of establishing a stored specification for an interface according to another aspect of the invention includes accessing machine readable specification elements from a repository. This repository stores a logical structure, a content model, a library of schematic maps for the logical structure, and a definition of the document having the logical structure used to build the interface description. A repository accessible in the network facilitates the construction of interface descriptions that can be easily shared. Any differences between the input document formed for the special process and the complementary process expected as a return process agree on a common logical structure that represents the network communication and special information. Easily negotiated by.

  A machine readable specification of a transactional interface according to one aspect of the present invention includes a document that conforms to the definition of an interface document shared among members of a network. The interface document definition has a logical structure for storing a special transaction identifier and a reference to the definition of the input / output document for at least one of the definitions and the special transaction. That is, the interface description for a special service actually contains the definition of the input / output document. Instead, it can include a location in the repository for such a definition, or a pointer to somewhere in the network.

  According to another alternative of the present invention, the machine-readable specification stores a reference to the specification of one or more transaction sets supported by the interface and for storing an identifier of the interface and at least one of the specifications. A business interface definition BID document that conforms to the definition of the interface document that contains the logical structure to store. For each supported transaction, the document contains at least one definition and a reference to the input / output document definition for the special transaction.

  According to another feature of the invention, the storage unit defined in the input / output document definition document identifies the analyzed data including text characters encoding character data, and the set of storage units according to the logical structure of the input / output document. To have markup data. According to another feature of the invention, at least one of the set of storage units encodes a plurality of text characters that provide a natural language. This facilitates the use of input / output document definitions by human readers and developers of these documents.

  According to another feature of the invention, the specification of the input / output document includes translation information for at least one of the set of storage units identified by the logical structure. The translation information in one example encodes a definition for the analyzed character set. In another example, translation information is provided for the content model specification. For example, it requires a particular logical structure to place a large list of mapped codes to create descriptions in a catalog. In some systems, the storage unit in the logical structure of the document contains a set of data that has not been analyzed to meet the special needs of execution.

  According to another feature of the invention, the transaction process in a special platform has a transaction processing architecture that is one of a plurality of variant transaction processing architectures. Thus, the participant node includes a resource for converting at least a portion of the input document into a format that is readable to a modified transaction processing architecture for transactions that utilize the information. Document-defined elements include variables and methods according to a modified transaction processing architecture of the transaction process. For participants who have a JAVA virtual machine that acts as the front end of the transaction process, the special fields in the document are not only translated into JAVA objects containing data, but also get and set functions related to JAVA objects. . Other transaction processing architectures that can be supported by the present invention include the Common Object Request Broker Architecture CORBA, the Component Object Model COM, the On-line Transaction Processing OLTR, and the Electronic Data Interlingual Interface Interpretation in the Electronic Data Interlingual Interface Processing Language Interface DI.

  According to another aspect of the invention, a repository is provided for storing document formats used in multiple transactions. A machine readable specification for a special transaction defines at least one of the input and output documents by referring to the document format in the repository. According to another feature, the document format contained in the repository has a document format for identifying participants in the network. Such a document format provides a structure for identifying participants, identifying services supported by the participants, and identifying input / output documents for each of these services.

  In addition to the method described above, the present invention provides a network interface, a memory for storing a program of data and instructions, including a machine readable specification of an interface for transactions, as described above, and a memory and network interface. An apparatus for managing a transaction between nodes including a data processor connected to a network is provided. The program of instructions stored in the device includes logic to perform the above-described process for the participants in the transaction.

  The present invention further provides an apparatus for establishing a participant interface for transactions executed on a system including a network and data processing resources for performing transaction processing according to a transaction processing architecture. The apparatus is executable by the system and includes a program of instructions stored on a medium accessible by the system that provides a tool for building a participant interface definition for the participant in a particular transaction. Participant interface definitions include input document definitions and output document definitions. The input / output document definition has a machine-readable description of each of the set of storage units in the logical structure for the set of storage units, and it follows the definition of the XML document format as one feature of the present invention. be able to.

  An apparatus for setting a participant interface according to this aspect of the invention also includes a program of instructions stored on a medium accessible by a data processing system, and for converting an input document into a corresponding data structure. Input adapted to the transaction processing architecture to compile instructions executable by the system and to compile instructions executable by the system to translate the output of transaction processing into a set of output document storage and logic structures And responding to the input and output document definitions to compile the logical structure of the output document and a data structure corresponding to the set of storages.

  A tool for building the definition of a participant interface in the preferred system is a definition from a repository that stores the logical structure used to build the interface description and a library of interpretation information for the logical structure and / or from complementary nodes. Instructions executable by the system to access the components of According to various aspects of the invention, the repository includes not only a library of logical structures, but also definitions of documents that have a format for identifying logical structures and participant interfaces. In accordance with this aspect of the invention, a tool is provided for building a business interface specification according to the techniques described above in connection with the description of a participant node. A tool for building an interface according to this aspect of the invention and a tool for compiling the interface into the necessary resources for communication with a transaction processing architecture are implemented at a participant node in a preferred system and input and Used to develop and optimize interface descriptions as the use of the network grows based on the interface descriptions that define the output document.

  Accordingly, another aspect of the present invention includes a memory and a data processor that executes instructions stored in the memory, including a tool for building a participant interface definition and a compiler that performs the functions described above. Providing the device.

  According to yet another aspect of the present invention, the use of the participant interface description enables the operation of the market maker node. In such a node, a method for managing a transaction comprising storing a transaction supported by the interface and a machine readable specification of a plurality of participant interfaces identifying each input and output document of such transaction. Is provided. As described above, the input and output documents comprise a description of each of the storage and the set of logical structures for the storage, as per the XML standard. In addition, the transaction definitions and participant interface definitions all comprise documents specified by techniques that conform to XML or other standardized document representation languages. In such a market maker node, data comprising documents is received over a communication network. The document is parsed by the specification to identify the input document in one or more transactions that accept the identified input document. At least a portion of the input document is provided in a machine readable format for transaction processing associated with one or more identified transactions. A method of providing at least a portion of an input document for transaction processing includes performing routing processing according to a processing architecture at a market maker node. The routing process in one form of the invention is performed by a specific processing architecture, and at least a portion of the input document is converted to the format of the processing architecture of the routing process. The transformation according to the preferred form involves generating programming objects including variables and methods according to the processing architecture of the routing process.

  According to another aspect of the invention, the market maker node also supports a repository structure. Thus, processing is included at the market maker node to allow access by the network participants to the repository stored at the market maker node. As described above, the repository includes instances of business interface definitions that contain logical structure definitions, interpretation information, and participant node document definitions and identify participants to build a transaction interface document, and each Includes transactions executed by participants.

  The routing process can, by various alternatives, convert the input document to a variable processing architecture of the process in which the document is sent, send the input document in its original document format over the network to the remote processing node (routing), or so A combination of different processes. In the alternative, the routing process is also a technique for converting an input document defined by one input document definition into a different document defined by a different document specification for the process registered to wait for the input document. including.

  A market maker node is also provided by the present invention as a device that includes a network interface, a memory for storing program and data of instructions including specifications for participant interfaces, and a data processor. The logic is supplied by the data processor in the form of a program of instructions or the like to perform market maker processing as described above.

  Thus, the present invention provides a basis for electronic commerce based on sharing input and output documentation specifications. The document provides an intuitive and flexible way to access business services that are easier to implement than programming APIs. If a company has already generally agreed, interconnecting such companies with exchanged documents is always easier than a different business system interface. In addition, such documents are identified in a human readable format in the preferred embodiment. In accordance with the present invention, the business interface is specified in a document such as an XML document that can be easily interpreted by humans as well as computers.

  The use of the document-based transaction architecture of the present invention involves the use of a parse that operates in essentially the same manner as any source of the document, and a custom for extracting and integrating information from each participant in the network. • Eliminate many needs for programs. So integrating business information from accounting, purchasing, manufacturing, delivery and other functions first converts each source into a document with the architecture according to the invention and then processes the parsed data stream. Can be achieved. Each node of the system participating in the market only needs to know the format of its internal system as well as the format of the document specified for exchange by the transaction. Thus, there is no need to be able to generate native formats for all other nodes that wish to participate in the e-commerce network.

  For complete business integration, the present invention provides a repository of standardized logical structures, such as XML components, attributes or metadata, between semantic languages for specific commerce communities, and between different metadata descriptions. Set up a means for mapping and a server to process the document and invoke the appropriate applications and services. The basic building block of the network according to the present invention includes interface definitions that inform potential trading business partners what online services the company provides and what documents to use to invoke the services; and trading Includes a server that provides a bridge to combine internal and external business service sets together to create a community. The server operates to parse the input document and invoke the appropriate service. The server according to the invention also handles the conversion task from the format of the received and transmitted documents to and from the format of each host system. Thus, trading partners need to agree only on the structure, content and sequencing of the exchanged business document, not the application programmer interface details. The manner in which the document is processed and the actions that result from the receipt of the document depend entirely on the business providing the service. This improves integration from the system level to the business level. It can allow a business to present a clear and stable interface to its partner despite changes in its internal technology implementation, organization or processing.

  All processes that can build business interface definitions and allow the server to manage commerce with such descriptions are business description primitives such as companies, services and products, catalogs, purchase orders, and invoices. It is facilitated by a common business library or repository of information models for common business concepts including standard measures, including business forms and time and date, location and product classification.

  Other aspects of the invention will be understood by consideration of the drawings, detailed description, and claims set forth below.

  The invention will be described in detail in connection with the drawings. FIG. 1 illustrates a network of market makers and market participants based on the use of business interface definitions, and support for the exchange of input and output documents specified according to the previous description of the interface. The network includes a plurality of nodes 11-18 connected to each other via a communication network such as the Internet 19 or other telecommunications or data communication network. Each of the nodes 11-19 comprises a computer such as a portable computer, desktop personal computer, workstation, system network, or other data processing resource. The node includes a memory for storing business interface definitions, a processor for executing a transaction process that supports commercial transactions with other nodes in the network, and the processor for supporting such services A computer program executed by the program is included. In addition, each node includes a network interface for providing communication across the Internet 19 or other communication network.

In the environment of FIG. 1, nodes 11, 12, 13, 14, 16, and 18 are designated market participants. Market participants include resources for consumers or suppliers of goods or services that are traded according to a commercial transaction established in accordance with the present invention.
In this example, nodes 15 and 17 are market maker nodes. The market maker node includes a resource for registering a business interface definition called a BID registry. Participants can send documents to the market maker where they are identified and routed to the appropriate participants registered to receive such documents as input. Market makers also facilitate commerce networks by maintaining a repository of standard forms that constitute a common business library for use in building business interface definitions.

  In this example, the market participant 18 is directly connected to the market maker 17 without going through the Internet 19. This direct connection to the market maker actually uses a public network such as the Internet 19 and a private connection such as a local area network or a point-to-point connection as shown between nodes 17 and 18. The introduction shows that the form of network that supports commerce transactions can be quite diverse. Actual communication networks are quite diverse and suitable for use in establishing a commerce transaction network according to the present invention.

  FIG. 2 is a heuristic diagram of the renormalized structure in a business interface definition (BID) established for market participants in a network according to the present invention. The business interface definition shown in FIG. 2 is a data structure consisting of storage units and logical structures arranged in accordance with a document structure format definition, such as an XML document type definition DTD. The structure of FIG. 2 includes a first logical structure 200 for identifying vertices. Associated with the logical structure 200 is a renormalized logical structure 201 for carrying names, a physical address 202, a network address or location 203, and a transaction 204 for a set of services. For each transaction in the service set, an interface definition is provided that includes transaction BID 205, transaction BID 206, and transaction BID 207. Within each transaction BID, such as transaction BID 205, logic to include a name 208, a network location 209 where the service is executed, an operation 210 performed by the service, and an input document 211 indicated by a set of tags. Structure is provided. The service BID 205 includes an output document 212 indicated by a set of tags. The set of input documents 211 includes a business interface definition for each input document that the service is directed to respond to, including input document business interface definitions 213, 214, and 215. The business interface definition for the input document includes a name 216, a network location 217 where the document description can be found, and a module 218 to be carried in the document as indicated by the field. Similarly, output document set 212 includes interface definitions for output documents, including output document BID 219, output document BID 220, and output document BID 221. For each output document BID, a name 222, a location 223 on the network or elsewhere, and a document module 224 are identified. The business interface definition for the participant shown in FIG. 2 includes an actual definition of the logical structure to be used for each service's input and output documents, or a pointer or other reference to where the definition can be found. Contains.

  In the preferred system, the document of FIG. 2 is specified in the XML document type definition DTD, but other document definition architectures can also be used and translation information about the logical structure used to translate the document request. Is included. Further, each of the transaction BID, the input document BID, and the output document BID is specified according to the XML document type definition. An XML type document is an example of a system based on parsed data including markup data and character data. The markup data identifies the logical structure in the document, and the character data set identifies the contents of the logical structure. In addition, unparsed data can be transported through the document for various purposes. For example, WWW. W3. See Extensible Mark-up Language XML 1.0 REC-XML-19980210 specification published by WC3 XML Working Group at ORG / TR / 1998 / REC-XML-19980210.

  Thus, in the illustrated system, participant nodes in the network establish a virtual enterprise by interconnecting business systems and services with XML encoded documents that are accepted and generated by the business. For example, the business interface definition for a particular service establishes that if a document that matches the BID of the request for catalog entry is received, a document that matches the BTD of the catalog entry is returned. Also, a document that matches the BID of the purchase order is received, and if it is acceptable for the terminal that received the document, the document that matches the BID of the invoice is returned. A node in the network processes the XML document before it enters the local business system established according to the various transaction processing architectures of any given system in the network. Thus, the system decodes a related document set, such as a MIME-encoded XML document set, and parses it to create a stream of “markup messages”. This message is routed to the appropriate application and service using, for example, an event listener model as described below.

  Documents exchanged between business services are encoded using an XML language (common business language) generated from a repository of building blocks where more complex document definitions can be generated. A repository is a business description primitive such as company, service, product, catalog, purchase order, business form like invoice, standard measurements like time, date, location, classification code, and XML document Stores modules of interpretation information focused on functions and information common to the business domain, including those that provide logical structure interpretation information.

  A business interface definition is a higher level document that serves as a schema used to design an interface for exchanging documents according to the present invention. Thus, the business interface bridges the gap between documents written according to XML and programs executed at the front end of the transaction processing service at a particular node. Such a front end is implemented by a JAVA virtual machine or other common architecture that defines the internal connections of the systems in the network. The business interface definition thus provides the techniques used to program the transaction protocol using the business interface definition document. The program for the transaction protocol is defined by a detailed official specification of the document type.

  An example business interface definition BID based on a market participant document according to the XML format is given below. Market participants DTD associates contact and address information with service and financial information descriptions to categorize business information about market participants. This business information consists of a name, code, address, a dedicated taxonomy to indicate the business organization, and a pointer to the business term. In addition, the service identified by the market participant DTD describes the input and output documents that the participant responds and generates. Thus, a document that defines a schema that uses an example common business language for market participants DTD, service DTD, and transaction document DTD described in annotated XML to aid in explanation follows.

サービスＤＴＤスキーマは、共通ビジネス言語リポジトリのサービスタイプエレメントで以下のように拡張されうる。

上記のサービスタイプエレメントは、ビジネスインターフェイス定義によって保有される解釈情報、この例では、有効なサービスタイプのいずれか１つの識別を可能にするコンテントフォームを例示する。別の解釈情報は、例えばコンテントフォーム「ｕｒｌ」を含み、データタイプ「ｓｔｒｉｎｇ」で表されるエレメント＜Ｈ３＞Ｉｎｔｅｒｎｅｔ Ａｄｄｒｅｓｓ＜／Ｈ３＞のような、データタイピングを含む。さらに別の解釈情報は、例えばファイル「ＣＯＵＮＴＲＹ．ＵＳ．ＳＵＢＥＮＴＩＴＹ」中の国に対するコードマッピングを含むエレメント＜Ｈ３＞Ｓｔａｔｅ＜／Ｈ３＞のような、リストのエレメントへのコードのマッピングを含む。
マーケット関係者ＤＴＤによって照会されるサービスディスクリプションは、サービスのコンペティションについてサービスが認めて生成するドキュメントを規定する。ベーシックサービスディスクリプションは、ＸＭＬドキュメントｔｒａｎｓａｃｔ．ｄｔｄとして以下に記載される。
ｔｒａｎｓａｃｔ．ｄｔｄは、インボイスのようなトランザクションディスクリプション、または値の交換のディスクリプションをモデル化する。このドキュメントタイプは、多くの用途を支援し、従って、トランザクションディスクリプションエレメントは、ユーザーがインボイス、業績、売りの申し出、取引価格の要望等を区別するのを可能にする属性を有する。交換は２人以上の関係者間で行われうるが、申し出人と相手の２人のみを登場させる。その各人は、上記に概説したマーケット関係者ＤＴＤに合致するドキュメントへのポインタによって表される。相手のポインタが、売りの申し出を受け入れるのは任意である。交換ディスクリプションは以下に挙げるｔｒａｎｐｒｉｍ．ｍｏｄに記述され、価格および小計を含む。交換ディスクリプションに続いて、全体としてトランザクションに適用される料金が備えられ、全体の料金が与えられなければならない。従って、この例のトランザクションディスクリプションスキーマドキュメントｔｒａｎｓａｃｔ．ｄｔｄは以下に表される。

代表マーケット関係者およびサービスＤＴＤは、上記の定義に従って生成され、以下の通りである。
マーケット関係者ＤＴＤ

サービスＤＴＤ

ｔｒａｎｓａｃｔ．ｄｔｄによって生成されるドキュメントの一例が続く。

The service DTD schema can be extended with the service type elements of the common business language repository as follows.

The service type element above illustrates the interpretation information held by the business interface definition, in this example the content form that allows identification of any one of the valid service types. Another interpretation information includes, for example, data typing, such as the element <H3> Internet Address </ H3>, which includes the content form “url” and is represented by the data type “string”. Yet another interpretation information includes the mapping of codes to elements of the list, for example the element <H3> State </ H3> that contains the code mapping for the country in the file “COUNTRY.US.SUBENTITY”.
The service description queried by the market participant DTD defines the document that the service recognizes and generates for the service competition. The basic service description is the XML document transact. It is described below as dtd.
transact. dtd models a transaction description, such as an invoice, or a value exchange description. This document type supports many uses, so the transaction description element has attributes that allow the user to distinguish between invoices, achievements, offers for sale, transaction price requests, and the like. Exchanges can be made between two or more parties, but only the offerer and the other party appear. Each person is represented by a pointer to a document that matches the market participant DTD outlined above. It is optional for the opponent's pointer to accept the offer for sale. The replacement description is listed below in tranprim. described in mod, including price and subtotal. Following the exchange description, a fee that applies to the transaction as a whole is provided and the entire fee must be given. Therefore, the transaction description schema document transact. dtd is expressed below.

Representative market participants and service DTDs are generated according to the above definitions and are as follows:
Market DTD

Service DTD

transact. An example of a document generated by dtd follows.

  Accordingly, the present invention provides a technique that allows a market participant to identify himself and to identify the type of input document and the type of output document he is trying to trade. The particular manner in which the content carried in this type of document is processed by other parties or local parties in this transaction is not related to establishing a business relationship, nor is it related to conducting the transaction.

  FIG. 3 is a schematic diagram of participant nodes in a network according to the present invention. The node illustrated in FIG. 3 includes a network interface 300 coupled to a communication network at port 301. This network interface is coupled to the document parser 301. The parser 301 supplies the logical structure from the input document to the translator module 302, which converts the input document into a form that can be used by the host trading system and vice versa. Is converted to an output document form in the business interface definition for transmission to the destination. Parser 301 and translator 302 respond to the business interface definition stored in participant module 303.

  The output data structure from the translator 302 is supplied to the trading process front end 304 along with events signaled by the parser 301. The front end 304 in one embodiment comprises a JAVA virtual machine or other similar interface suitable for communicating between various nodes in the network. Trading process front end 304 routes the input data to the appropriate function in the enterprise system and network to which the participant is coupled in response to an event directed by parser 301 and translator 302. Thus, the trading process front end 304 in the example of FIG. 3 is coupled to other enterprise functions such as commercial functions 305, database functions 306, accounting and billing 307, and designed to respond to events directed by the parser. Specific event listeners and processors 308.

  Parser 301 receives a purchase order or other document as in the previous example specified according to the business interface definition and is a set of events recognized by a local transaction processing architecture, such as a set of JAVA events for JAVA virtual machines. Is generated.

  The parser of the present invention is decoupled from the program listening for events based on the received document. Various markup pieces in the received document or a complete document that meets a specific specification serves as an instruction for the listening function that initiates processing. Thus, the listening program implements business logic related to document information. For example, the program associated with the address element can be a code that validates a poster code by checking a database. These listeners join the event by registering with the document router. Document routers direct appropriate events to all subscribers interested in them.

  For example, a purchase order identified as described above may be monitored by a program listening for events generated by a parser that will connect the document or its contents to an order entry program. The inventory is checked using a program upon receipt of the product description in the purchase order. Upon receipt of the address information in the purchase order, a certain program is used to check the availability of the service for delivery. The buyer information field in the document can use various processes to check the order history for credit value or offer similar processing, such as based on knowing promotions or consumer identity.

  A complex listener can be created as a primitive listener configuration. For example, some purchase order listeners may include and use the list listeners described above, and list members may be used with respect to themselves. It should be noted that the application that the listener runs on does not appear to be a native XML process or a native JAVA process. In these cases, the object is converted to the format required by the receiving trans application. When the application completes processing, its output is converted back to XML format for communication to other nodes in the network.

  The market participant document type description and transaction document type description as described above include a schematic mapping for logic elements in the document, and a markup language based on natural language. Natural language markup and other natural language attributes of XML facilitate the use of XML type markup languages for business interface definition, service description and specification of input and output document descriptions.

  In addition to storing business interface definitions, participant module 303 edits objects or other data structures used by trading process front end 304 corresponding to the logical structure in the input document, and edits translator 302. Including the compiler used to Thus, when the business interface definition is changed or updated by the participant as the participant's related transaction changes, the translator 302 and parser 301 are automatically kept in update.

  In the preferred system, the set of JAVA events is generated by the compiler corresponding to the SGML globe model, mainly the standard element structure information set extended by property set for each element (International Standard ISO / IEC 10179: 1996 (E), Information Technology--Processing Language--Document Style Semantic and Specification Language (DSSSL)). Returning an XML document to a set of events for processing is different from the usual parsing model where the parser output is maintained as an internal data structure. By converting XML document elements into JAVA events or other programming structures suitable for use by each node's transaction processing front end, rich functionality can be achieved at nodes that utilize the document being traded. The

  Thus, the trading process front end 304 can operate in a publish and subscribe architecture that allows new listener programs to be added without knowledge or impact of other listening programs in the system. Each listener 305, 306, 307, 308 in FIG. 3 maintains a queue in which the front end 304 directs events. This allows multiple listeners to handle events in parallel at their own pace.

  Furthermore, according to the present invention, the application that the listener will run does not have to be a native XML function or native function that matches the format of the input document. Rather, these listeners can be JAVA functions when the trading process front end 304 is a JAVA interface, or they can be functions that run according to a unique trading processing architecture. In these cases, the object can be converted to the format required by the receiving application. When the listener application finishes, its output is converted back into a document format as specified by the business interface definition in module 303. Thus, the translator 302 is directly coupled to the network interface 300 to provide the combined document as output.

  Listeners coupled to the transaction processing front end may include a listener for the input document, a listener for a particular element of the input document, and a listener for attributes stored in the particular element of the input document. This allows various flexible implementations of the trading process at a particular node for filtering and responding to input documents.

  FIG. 4 illustrates a process for receiving and processing an input document for the system of FIG. Thus, the process begins by receiving a document at the network interface (step 400). The parser identifies the document type (401) in response to the business interface definition. The document is parsed using the business interface definition storing the DTD for the document in XML format (step 402). Next, the document elements and attributes are converted to a host format (step 403). In this example, the XML logic structure is converted to a JAVA object that carries the data of the XML element along with data related methods such as get and set functions. The host object is then transferred to the host transaction processing front end (step 404). These objects are routed to the process in response to events directed by the parser and translator. The process of receiving document elements is executed and generates output (step 405). The output is converted into an output document format as defined by the business interface definition (step 406). In this example, translation proceeds from the JAVA object form to the XML document form. Finally, the output document is sent to the destination through the network interface (step 407).

  FIG. 5 is a detailed diagram of the event generator / event listener mechanism for the system of FIG. In general, the approach shown in FIG. 5 is an improvement of the JAVA JDK1.1 event model. In this model, three types of objects are considered. The first type of object is an event object that includes information regarding the occurrence of an event. There are a number of event object types corresponding to all the different types of events that can occur. The second type of object is an event generator that monitors activity and generates event objects when something happens. The third is an event listener that listens to the event object generated by the event generator. Event listeners generally listen to a specific event generator, such as a mouse click on a specific window. The event listener calls the “add event listener” method on the event generator. This model can be adapted to the environment of FIG. 3, where objects are generated in response to walking and parsing a graph of the object as represented by the XML document.

  The system shown in FIG. 5 has a general XML parser 500. Such a parser can be implemented using a standard recall model. When a parsing event occurs, the parser invokes a specific method in the application object and passes the appropriate information in the parameters. Thus, a single application 501 exists with the parser. The application packages the information provided by the parser into an XML event object and sends it to the number of event listeners identified by itself, as indicated by block 502. The set of events 502 is completely independent of the parser. Event 502 can be delivered to any number of listeners and any number of threads on any number of machines. Events are based on an Element Structure Information Set (ESIS) in one alternative format. These therefore consist of a list of important aspects such as recognition of the document structure or attributes, such as the start and end of an element. XML (and SGML) parsers generally use the ESIS structure as the default set of information for the parser to return to its application.

A specialized ESIS listener 503 is coupled to the set of events 502.
This listener 503 implements the ESIS listener API and listens for all XML events from one or more generators. One element event generator 504 is a specialized ESIS listener and also an XML event generator. The listener is an object that is only interested in events for a particular type of element. For example, in an HTML environment, the listener is interested only in the indicated list, i.e. only the part of the document between the <OL> and </ OL> tags. In another example, the listener listens only to the “party.name” or “service.name” element according to a common business language from the above example document, and the element carries data that matches the schematic mapping for the element To ensure that the element is processed and reacts according to the process required at the receiving node.

  This allows the system to have small objects that only listen to specific parts of the document, such as summing prices. There can also be listeners that only listen to, for example, the <HEAD> portion of an HTML document, since listeners can add or remove themselves from the generator. For this reason and because of the high repeatability of XML documents, it is possible to write highly targeted code and concurrent listeners. For example, the <OL> listener can set the <LI> listener completely separate from the method in which the <UL> (undirected list) listener sets the <LI> listener. As an alternative, you can create a listener that generates a graphic user interface and another listener that searches a database that uses the same input. Thus, the document is treated as a program executed by the listener, as opposed to a complete data structure that the application examines one at a time. If an application is written this way, it is not necessary to have the entire document in memory to run the application.

  The next listener coupled to the set of events 502 is the attribute filter 505. Similar to the element filter 504, the attribute filter 505 is an attribute event generator according to the ESIS listener model. The listener for the attribute filter specifies the attribute that it is interested in and receives events for any element with the specified attribute. For example, the font manager will receive events only for elements with font attributes such as <PFONT = “Times Roman” / P>.

  Element event generator 504 provides such an element object to specialize element listener 504A.

The attribute event generator 505 supplies an attribute event object to the attribute listener 505A. Similarly, attribute objects are provided to the “architecture” in the sense of transforming SGML / XML using attributes from one document format to another. Thus, the 505B architecture allows a specific attribute with a specific name to be identified. Only elements with that defined attribute become part of the output document, and the name of the element in the output document is the value of the attribute in the input document. For example, if architecture 505B is HTML,
<PURCHASES HTML = “OL”><ITEM HTML = “LI”><NAME HTML = “B”> STUFF </ NAME><PRICE HTML = “B”> 123 </ PRICE></ITEM></PURCHASE>
When translated,
<OL><LI> STUFF </ B><B> 123 </ B></LI></OL>
It is correct HTML.

  The next module coupled to the set of events 502 is a tree builder 506. The tree builder takes a stream of XML events and generates a tree representation of the underlying document. One preferred form of tree builder 506 generates a document object model DOM object 507 according to the specification of W3C (http://www.w3.org/TR/1998/WD-DOM-199980720/introduction.html). Listeners in the event stream can be used to handle most requests, but the tree format helps with questions around the document, creating new documents, eg parsing documents many times, to reorder nodes It helps to support in-memory data structures from which the same event stream can be generated multiple times. Specialized builder 508 can be coupled to tree builder 506 to create a special subtree of the portion of the document that fits a particular implementation.

  In addition to responding to incoming documents, other sources of XML events 502 can also be provided. Thus, the event stream 510 is generated by walking over the tree of DOM objects and by regenerating the original event stream that was created when the document was parsed. This allows the system to give the appearance that the document has been parsed several times.

  The notion of an object that walks the tree and generates a stream of events can be generalized to any tree of objects that can be queried beyond the tree of DOM objects. Accordingly, JAVA walker 512 may be an application that walks the tree of JAVA bean components 513. Walker walks on all public fields and methods. The walker remembers the trajectories of objects that have already been visited to ensure that it never enters an endless cycle. JAVA event 514 is a type of event generated by JAVA walker 512. This currently includes most of the types of information that can be extracted from an object. This is the JAVA equivalent of ESIS, and allows the same programming techniques applied to XML to be applied to JAVA objects in general, but especially to JAVA beans.

  The JAVA to XML event generator 515 includes a JAVA listener and a JAVA event generator. It receives a stream of events 514 from a JAVA walker 512 and translates the one selected to supply a JAVA object as an XML document. In the preferred embodiment, event generator 515 utilizes the JAVA beans API. Each object seen becomes an element, and the element name is the same as the class name. Within that element, each embedded method also becomes an element whose contents are the values returned by invoking the method. If it is an object or an array of objects, these are walked alternately.

  FIG. 6 is a schematic diagram of a particular application built on the framework of FIG. This application takes an XML document 600 and applies it to a parser / generator (parser routine generation system) 601. An ESIS event 602 is generated and provided to the attribute generator 603 and the tree builder 604. The attribute generator corresponds to the generator of FIG. The generator 505 sends the event to, for example, an “architecture” 505B for translating from XML input to HTML output. These events are processed in parallel as indicated by block 605 and processed by the listener. The listener's output is supplied to the document writer 606 and translated back into XML format for output. Thus, for example, the application shown in FIG. 6 takes an XML document and outputs an HTML document having a form. This form is then sent to the browser and the result is converted back to XML. For this operation, the architectural concept provides a mapping from XML to HTML. The three architectures included in FIG. 6 are intended to give the structure of an HTML document, such as a table and a list, a second specifying the document to be displayed, such as a label for an input field on the browser document. And a third describing the input field itself. The elements of the XML document that are required to maintain the XML document structure are invisible fields in the HTML form. This is useful for use in reconstructing an XML document from information that the client puts in an HTTP post message sent back to the server. A listener who listens to these events outputs events for the HTML document. This document goes to the document writer object. The document writer object listens for XML events and returns them to the XML document. The document writer object is a listener for all element generators listening to the architecture in this example.

  The configuration of the processing modules illustrated in FIGS. 5 and 6 represents one embodiment of the parser and transaction process front end for the system of FIG. As can be appreciated, a very flexible interface is provided so that a diversified transaction process can be performed in response to an incoming XML document or other structured document format.

  FIG. 7 illustrates a node similar to FIG. 3 except that it includes a business interface definition builder module 700. Accordingly, the system of FIG. 7 includes a network interface 701, a document parser 702, and a document translator 703. The translator 703 outputs the output to the transaction processing front end 704. This front end is coupled to listening functions such as commercial functions 705, databases 706, enterprise functions 707, and other general listeners and processors 708. As illustrated in FIG. 7, the business interface builder 700 includes a user interface, a common business library CBL repository, a process for reading complementary business interface definitions, and a compiler. User interfaces are used to assist in the construction of business interface definitions, depending on the ability to retrieve common business library repositories and complementary business interface definitions. Thus, the complementary business interface definition input document can be identified as an output document for a particular transaction, and the complementary business interface definition output document can be identified as an input such as a transaction process. In a similar manner, the transaction business interface definition can be constructed using components selected from the CBL repository. Logical structure and interpretation in the use of CBL repositories in the construction of standardized document formats, such as the above-mentioned example (bid1) document, and business interface definitions that can be readily adopted by other people in the network Promote the use of information.

  The business interface definition builder 700 also includes a translator 703, a compiler used to generate objects to be processed by the translator according to the host transaction processing architecture and to manage the parsing function 702.

  FIG. 8 is a heuristic diagram showing the logical structure stored in the repository within the business interface definition builder 700. Accordingly, repository storage representing party business interface definition 800 includes, for example, consumer BID 801, catalog house BID 802, warehouse BID 803, and action house BID 804. Thus, a new participant in the online market selects one of the standardized BIDs that best matches the business as the basic interface definition. In addition, the repository stores a set of service business interface definitions 805. For example, an order entry BTD 806, an order tracking BID 807, an order fulfillment BID 808, and a catalog service BID 809 can be stored. As new participants in the market build the business interface definition, they can select the standardized service business interface definition stored in the repository.

  In addition to the party and service BID, the input and output document BIDs are stored in the repository indicated by field 810. Accordingly, the purchase order BID 811, invoice BID 812, quotation request BID 813, product availability report BID 814, and order status BID 815 can be stored in the repository.

  In the preferred system, the repository stores interpretation information in the form of a semantic map as indicated by field 816, in addition to the business interface definition specified as a document form definition according to XML. Thus, a semantic map used to identify weight 817, currency 818, size 819, product identification 820, and product feature 821 can be stored in the repository. Furthermore, the interpretation information provides for classifying the data structure within the logical structure of the document.

  Further, the logical structure used in composing the business interface definition is stored in the repository pointed to by block 822. Therefore, a form for giving address information 823, a form for giving price information 824, and a form for giving a contract-related period 825 can be provided. As the network expands, the CBL repository expands as well, and standardization makes it easier to add new participants and define business interfaces.

  FIG. 9 illustrates the process of building a business interface definition using the system of FIG. The process begins by displaying a BID Builder graphical interface to the user (step 900). The system accepts user input identifying participant, service and document information generated by the graphical interface (step 901).

  Next, any reference logical structures, interpretation information, document definitions, and / or service definitions are retrieved from the repository via a graphical user interface in response to user input (step 902). In the next step, the complementary business interface definition or components of the business interface definition are selected by a customized search engine, web browser, or other method through other user inputs in the network (Step 903). A document definition for the participant is generated using the collected information (step 904). A translator for each mapper from document to host and from host to document is generated by the compiler (step 905). A host architecture data structure corresponding to the definition is generated by the compiler (step 906). The generated business interface definition is then posted on the network by posting it to a website or other location, making it accessible to other nodes in the network. (Step 907).

The definition of a business interface tells potential commercial partners about the online services offered by the company and the documents used to implement these services. Thus, a service is defined in the business interface definition by the documents that the service receives and generates. This is illustrated in the following fragment of the XML service definition.

  This XML fragment defines a service consisting of two processes: one that obtains an order and one that follows it. Each definition represents a contract or promise to perform a service if a legitimate request is presented to a particular web address. Here, the order service is a standard “po.dtd” DTD (Document Type Definition) located in a repository which can be local or stored in an industry-wide registry on the network. ) Is required to be input document. If one node can execute the order, it will return a document that conforms to the customized “invoice.dtd” whose definition is local. In practice, a company promises to do business with anyone who can submit a purchase order that conforms to the XML specification it declares. Prior adjustment is not required.

  DTD is an official specification or grammar for a given type of document that describes the elements, their attributes, and the state in which they must be displayed. For example, a purchase order typically includes buyer and seller names and addresses, a set of product descriptions, and associated terms and conditions such as price and delivery date. In the Electronic Data Interchange (EDI), for example, the X12 850 specification is a commonly used model for purchase orders.

  Repositories facilitate the development of XML document models from reusable semantic components common to many business areas. Such documents can be understood from their common message elements, even if they look quite different. This is the role of the Common Business Library repository.

The common business library repository consists of an information model for general business concepts, including:
-Business description primitives, such as companies, services, and products;
・ Business forms such as catalogs, purchase orders, and invoices,
Standard measurement values, date and time, position, and classification code.

  This information is expressed as an extensible and public XML building block that can be customized and assembled by a company to rapidly develop XML applications. The atomic CBL element implements industry messaging standards and conventions, such as standard ISO codes for country, currency, address, and time. Low level CBL semantics can also be derived from analysis of presented metadata frameworks for Internet resources, such as Dublin Core.

  The next level of elements uses these building blocks to provide X12 as well as business forms used in emerging Internet standards such as OTP (Open Trading Protocol) and OBI (Open Buying on the Internet). It also performs basic business forms such as those used in EDI processing.

  CBL focuses on all business areas (business description primitives, such as companies, services, and products; business forms such as catalogs, purchase orders, and invoices; standard measurements, dates, locations, classification codes) Common functions and information. CBL relies on standards for possible semantics or industry conventions (eg, “month / day / year” in the United States versus “day / month / year” in Europe). The rules you specify are coded in a separate CBL module).

  CBL is a language used to design applications. It is designed to bridge the gap between the XML “document world” and the JAVA “programming world” or other processing process architecture. A schema embodies the idea of “programming by document”, where a detailed official specification of a document type is a master source from which various related forms are generated. These forms include CBL, JAVA objects, conversion programs between XML instances and corresponding JAVA objects, and XML DTD for supporting documents.

  CBL creates a single source from which almost every part of the system is automatically generated by the compiler. CBL works by extending SGML / XML that is commonly used to formally define the structure of a particular document type to include semantic specifications associated with each information element and attribute. The (most) limited set of character types in SGML / XML can be extended to declare any kind of data type.

This is a fragment from the CBL definition for the “datetime” module.

  In this fragment, ELEMENT “year” is defined as the character data and the associated “schema” attribute, and the character data also defines the schema for “year” to be section 3.8 of the ISO8601 standard.

  This “datetime” CBL module is actually defined as an instance of the schema DTD. First, the module name is defined. Next, the “date” element “YEAR” is combined with the ISO 8601 standard semantics.

  Example market participants and the above service modules are also stored in the CBL repository.

  In FIG. 10, an air freight receipt (Airbill) 1000 is defined by customizing a general purchase order DTD 1001 and adding more specific information about the shipping weight 1002. A typical purchase order 1001 was first assembled extensively from address, date and time, currency, and CBL module for seller and product description. Thus, the use of CBL greatly facilitates the implementation of XML commercial applications. More importantly, CBL makes it easy to interconnect commercial applications.

In CBL, XML is extended by a schema. The extension adds strong-typing to the XML element so that the contents can be easily confirmed. For example, <CPU clock An element called speed> can be defined as an integer with a set of valid values: {100, 133, 166, 200, 233, 266 Mhz}. The schema also adds a class-subclass hierarchy so that information can be easily instantiated from class definitions. For example, a laptop can be described as a computer with additional tags for features such as display type and battery life. These and other extensions facilitate data entry as well as automatic translation between XML and traditional object-oriented and relational data models.

  In this way, the completed BTD is converted from the participant and the actual instance of the service outlined above, the JAVA beans corresponding to the logical structure of the DTD instance, and from XML to JAVA and from JAVA to XML. It is executed through a compiler that creates a DTD for the conversion code to do. In other systems, documents are also generated for display on the user interface or for printing by the user to make the object easier to use.

上記したＪＡＶＡビーンに加えて、変換コードは以下に示されているように、ＪＡＶＡからＸＭＬへ、及びＸＭＬからＪＡＶＡへ翻訳するため作られる。

For example, JAVA beans generated by market participants and the aforementioned service DTD, compiler, are shown as follows (with some modifications for brevity):

In addition to the JAVA beans described above, conversion codes are created for translation from JAVA to XML and from XML to JAVA as shown below.

  Using tools along with a BID composer application that provides a user interface to edit drags, drops and shapes, developers can create business interface definitions and are well-formed Effective business interface definitions can be produced in the form of XML documents. Thus, the example runtime instance is the definition of a business interface for ordering services for IBM, used by Ingram Micro to order a laptop computer from IBM. . (There is no relationship between the applicant and IBM or Ingram Micro.) With these processes, users can build systems that can program business interfaces using documents defined according to the present invention. can do.

  The role of the CBL and BID processors of the present invention in an XML / JAVA environment will be further understood from the following description of purchase order processing.

  Company A defines its purchase order document using a visual programming environment that includes a library of CBL DTDs and modules, all defined using common business language elements, which contain data types and other translation information It is like that. Company A's PO may include minor customizations to the more general transaction document specification that comes with the CBL library, or the ground from the CBL module for address, data and time, current, etc. May be made from.

  General transaction document specification documents (such as transact.dtd described above) typify how CBL specifications are created from modules and concatenated with other CBL DTDs.

The compiler takes purchase order definitions and generates several different target formats. All of these target types can be obtained via a “tree to tree” variant of the original specification. The most important for this example is
(A) XML DTD for purchase order
(B) JAVA bean containing data structure for purchase order (JAVA classes, arguments, data types, methods, and exception structures are created corresponding to information in the purchase order schema definition)
(C) an alignment program that converts purchase orders according to the purchase order DTD into purchase order JAVA beans, or loads them into a database or creates HTML (or XSL style collections) to display the purchase order in a browser (d ) Unaligned program that pulls data values from purchase order JAVA beans and converts them to XML documents according to purchase order DTD Now, returning to the scenario, the purchase application generates a purchase order and the purchase order accepts the purchase order Follow DTD specified as service interface for suppliers.

  The parser uses the purchase order DTD to decompose the purchase order instance into an information stream about the element and the attribute values it contains. These property sets are then converted into corresponding JAVA event objects by overlaying them with JAVA code. In effect, this transformation processes the portion of the XML document whose grammar is marked as a customer programming language instruction defined by DTD. These JAVA events can be processed by the aligned application generated by the compiler to load the JAVA bean data structure.

  Converting and processing an XML document into a set of events for a JAVA application, unlike the normal model that does the analysis, does not start the internal data structure and processing until the analysis is complete, so the parser output is maintained Is done. Event-based processing according to the BID definition is the key to enabling a very good functioning of the processor, as soon as the first event is fired, it starts the document application processing that occurs at the same time.

  A JAVA program that listens to various types of events is formed from the schema definitions of those events. These listeners are programs created to perform the business logic associated with the CBL XML definition, for example code associated with the address element and checking the zip code by checking the database. . These listeners apply for events by registering at the document router and assign events related to all applicants who have shown interest in them.

  This published and applied architectural means programmed by new listeners can be added without knowledge of existing ones or without affecting them. Each listener has a queue to which the router assigns its events, and multiple listeners can handle events in parallel at their own pace.

For the example purchase order here,
A purchase order that will link it to an order entry program, a product description that will check inventory, an address information that will allow you to check Fed Ex or other services for the validity of delivery For buyer information that would be able to check the history of the order (for credit worth or for providing a public notice or for a similar process based on knowing who the customer is) Maybe a listener.

  A composite listener can be created as an initial shape. (For example, purchase order listeners may include these listeners here and quote them, or they may quote themselves.)

FIG. 11 shows market marker nodes in the network of FIG. The market marker node includes the basic structure of the system of FIG. 3 and includes a network interface 1101, a document parser 1102, a host to document and document translator host 1103, and a front end 1104, in this example called a router. ing. The market marker module 1105 in this example provides a set of business interface definitions, or other identifiers sufficient to support the market marker functionality for market participants, CBL repositories, and market participant requests. Has a satisfying compiler. The router 1104 comprises a participant registry and document filter, responds to events generated by the parser at the output of the translator, by the participant registry, and by element and attribute filters between listeners to the XML event generator, Define the path of the input document. Thus, certain participants in the market may register and receive documents that meet pre-specified parameters.
For example, an input document with a specific DTD may include attributes such as the number of purchased products above a threshold, or the maximum price of a document request to be purchased, and may be used by the router 1104 for a filter document. Thereafter, a document that matches the information registered in the participant's registry by the router 1104 is sent to the registered participant.

  The router 1104 also satisfies the requirements of the local host services 1105 and 1106 and operates like a market participant, for example, as well as a market marker. Typically, documents received by the router 1104 are traversed to determine destinations and such documents are sent where they are sent again via the translator 1103, if necessary, from the network interface 1101 to the respective destination. It is done.

A market marker is a server that links together with a set of internal and external business services, creating a virtual planning or trading community.
The server parses the input document and references the appropriate service, for example, by passing a request for product data to the catalog server or by sending a purchase order to the ERP system. The server also handles translation tasks and maps information from the company's XML document to the document format used by the trading partner and the data format required by its legacy system.

With respect to the above service definition, when the company submits a purchase order, the server's XML parser uses the purchase order DTD to convert the purchase order instance into a stream of information events. These events are then sent to an application programmed to handle a given type of event, and in some cases the information is sent completely to different businesses over the Internet. In the purchase order example, some applications may operate with information coming from a parser.
• The order entry program processes the purchase as a complete message.
• The ERP system checks inventory for the product described in the purchase order.
The customer database verifies or updates the customer's address.
・ The shipping company uses the address information and schedules the transportation.
・ Banks use credit cards and allow transactions.

  Trading partners need only agree on the structure, content and order of the business documents they exchange, not the API details. How the document is processed and what action results will occur is strictly up to the business providing the service. This enhances integration from the system level to the business level. It allows a business to provide its business partner with a clear and stable interface despite changes in its internal technology implementation, organization, or process.

  12, 13 and 14 illustrate the processes performed at the market maker node of the system of FIG. In FIG. 12, an input document is received at a network interface from an originating participant node (step 1200). The document is parsed (step 1201). The document is converted to a host format, eg, XML to JAVA (step 1202). Host formatted events and objects are then sent to the router service (step 1203). Services stored to accept the document according to the document type and document content are identified (step 1204). The document and part of the document are sent to the identified service (step 1205). A service is executed according to the contents of the document (step 1206). Service output data is generated (step 1207). The output is converted to a document format, for example, from a JAVA format to an XML format (step 1208). Finally, the output document is sent to the participant node (step 1209).

  The registration service is one such function managed by the router. Accordingly, a market participant document is accepted at the network interface shown in FIG. 13 (step 1300). The market participant document is stored in the business interface definition repository for the market maker node (step 1301). In addition, the document is parsed (step 1302). The parsed document is converted to the host format (step 1303). Next, the document is sent to the router service (step 1304). The router service includes a listener that identifies the registration service as a document destination according to the document type and document content (step 1305). The document and document elements are sent to a registration service (step 1306). In the registration service, the required service specifications are retrieved according to the business interface definition (step 1307). If service specifications are collected in step 1308, a router service filter is set according to the business interface definition and service specifications (step 1309). Registration acknowledgment data is generated (step 1310). Registration acknowledgment data is converted into a document format (step 1311). Finally, an acknowledgment document is sent to the participant node to notify the participant successfully registered with the market maker (step 1312).

  The process in step 1307 for collecting required service specifications is shown for one example in FIG. The process begins by locating service business interface definitions supported by market participants (step 1400). The service definition is retrieved, for example, by email transaction or web access to the repository node (step 1401). The service specification is stored in the BID repository (step 1402). The service business interface definition document is parsed (step 1403). The parsed document is converted to the host format (step 1404). Next, the host object is sent to the router service (step 1405). A registration service is identified according to the document type and content (step 1406). Finally, the service business interface definition document information is sent to the registration service (step 1407) and used according to the process of FIG.

  FIG. 15 illustrates a processor, component and sequence for processing data input to a market maker node in accordance with the present invention. The market maker node has a communication agent 1500 at the network interface. The communication agent is connected to the XML parser 1501, and the XML parser 1501 supplies an event to the XML processor 1502. The XML processor 1502 supplies the event to the document router. The document router feeds to the document service 1504, and the document service 1504 serves as an interface for supplying the received document to the enterprise solution software 1505 of the host system. Communication agent 1500 is an Internet interface with a suitable protocol stack that supports protocols such as HTTP, SMTP, FTP, or other protocols. Thus, the data to be entered may be entered in XML syntax, ASCII data syntax, or other syntax to suit a particular communication channel. All documents received in non-XML syntax are converted to XML and sent to an XML parser. A conversion table 1506 is used to support conversion from non-XML format to XML format.

  The converted document is supplied to the parser 1501. The XML parser parses the received XML document according to the matching document type definition. If an error is found, the parser sends the document back to the communication agent 1500. The business interface definition compiler BIDC 1507 serves as a compiler for business interface definition data. Conversion rules for converting DTD files for XML parsers, JAVA beans corresponding to DTD files, and DTD files into JAVA beans are created by compiling BID data. By referring to these tools, an XML instance is converted into a JAVA instance. Therefore, the BID compiler 1507 stores the DTD document 1508 and generates a JAVA document corresponding to 1509. The XML document is sent to the processor 1502, and the processor 1502 converts the document into a JAVA format. In a preferred system, a JAVA document is generated that has the same status as the document type definition received in XML format. JAVA beans are sent to the document router 1503. Document router 1503 receives the JAVA beans and sends the received classes to the appropriate document service using a registry program, for example using the event listener architecture described above. The document service 1504 that receives the document in the form of JAVA beans from the router 1503 works as enterprise solution software. It has a registry service 1510 that couples to the data stream that enters the listener for XML events, and a service manager 1511 that manages the routing of incoming documents to the appropriate service. The document service manager 1511 performs management of the registry service and maintenance of document consistency.

  The document service communicates with the backend system using any proprietary API or using a more common form such as a CORBA / COM interface or other architecture.

  FIG. 16 is a heuristic diagram of the market maker and market participant structure according to the present invention. Accordingly, the e-commerce transaction market according to the present invention can be logically organized as shown in FIG. A market maker node 1600 is set at the top of the organization. The market maker node includes resources for setting the market place 1601. Such resources include market registry services and the like. Business 1602 registers with the marketplace by publishing the business interface definition. The business interface definition defines a service 1603 for commercial transactions in which the business participates. Transaction 1604 and service 1603 use document 1605 to define inputs and outputs and outline commercial relationships between participants in the transaction. The document has a content 1606 that contains details of each transaction. The way content is processed by market participants and by market makers depends entirely on documents based on an e-commerce transaction network established in accordance with the present invention. Overall, a robust, scalable, and intuitive structure is provided to enable e-commerce transactions over a communications network.

Accordingly, the present invention provides a platform based on an XML processor and uses XML documents as an interface between loosely coupled business systems in the exemplary system. Documents are transferred between businesses and processed by specific nodes before entering the company's business system.
Thus, the platform enables cross-business e-commerce applications by identifying a common set of business documents and formats where each business system uses a different internal commerce platform, processing and semantics.

According to the present invention, a virtual enterprise is formed by interconnecting business systems and services, mainly defined as follows for documents (XML coded) that are accepted and generated by the business. .
“If you ask us for a catalog, we will send you a catalog.” “If you have ordered your purchase and we can accept it, we will send you an invoice.”
The foregoing description of the preferred embodiment of the invention has been made for the purpose of illustrating the invention. This is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. The scope of the present invention is defined by the following claims and their equivalents.

1 is a schematic diagram of an electronic commerce network including a business interface definition (BID) according to the present invention. FIG. FIG. 4 is a schematic diagram of a business interface definition document according to the present invention. 2 is a conceptual block diagram of a server for a participant node in a network according to the present invention. 4 is a flowchart illustrating processing of a document received at a participant node according to the present invention. FIG. 3 is a block diagram of a parser and transaction process front end for an XML based system. It is a conceptual diagram of the flow of a parser program function. It is the schematic of the resource in the server used for the business interface definition by this invention. FIG. 2 is a schematic diagram of a repository according to the present invention used for building a business interface definition. 6 is a flowchart illustrating a process for building a business interface definition according to the present invention. 1 provides a heuristic overview of a repository according to the present invention. FIG. 6 is a schematic diagram of resources in a server providing market maker functions for the network of the present invention based on business interface definitions. FIG. 5 is a flowchart of market maker node processing of received documents. FIG. 4 is a flowchart illustrating a process for registering a participant in a market maker node according to the present invention. 10 is a flowchart illustrating a process for providing a service specification in a market maker node according to the process of FIG. It is a diagram explaining the sequence of operation in the market maker or participant by this invention. 2 is a conceptual diagram of elements of a BID-based commerce network according to the present invention.

  The present invention relates to a system and protocol that supports transactions between various clients connected to a network, and more particularly, to a system and protocol that supports commerce between platforms having different architectures. .

  The Internet and other communication networks provide a means for communication between computer systems and people, which is used for a wide variety of transactions, such as commerce where goods and services are bought and sold by participants. ing. Many efforts have been made to promote business transactions on the Internet. However, because there are many competing standards for conducting transactions, the parties involved in the transaction must agree in advance to the protocol used, and the system architecture must be used to support such transactions. Each time there was a frequent demand for reorganization. Commercial processes that do not comply with agreed standards and are inherent in a particular node may require considerable rework for integrated reorganization with other nodes. Furthermore, when one company is involved in one standard or another standard, the company is fixed to the trading group of the existing standard group, and the other is excluded.

  An overview of challenges related to the development of Internet commerce is described in “Eco System: An Internet Commerce Architecture” by Tenenbaum et al .: Computer, May 1997; pages 48-55.

  It is desirable to standardize the architectural framework to make commerce on the Internet open. Platforms developed to support such commercial frameworks include IBM's Commerce Point; Microsoft® Internet Commerce Frameworks; Netscape's ONE (Open Network Environment); Oracle's NCA (it There is Sun / JAVA (R) software JECF (JAVA Electronic Commerce Framework).

  In addition to these proprietary frameworks, programming techniques such as a common distributed object model based on CORBA IIOP (Common Object Request Broker Architecture Internet ORB Protocol) are being promoted. The use of a uniform distributed object model is intended to simplify the migration of enterprise systems to systems that allow electronic commerce to be interoperable at the business application level. However, a consumer or business that uses only one framework cannot execute transactions that are on different frameworks. This is an impediment to the growth of the electronic commerce system.

  An enterprise running one framework will have a different application programming interface (API) than the API supporting the other framework. Thus, it is very difficult for companies to access business services to each other without requiring a common business system interface to be adopted. Developing a business system interface at the API level may require significant cooperation between the parties that is not practically feasible.

  Accordingly, it is desirable to provide a framework that facilitates interaction (interaction) between various platforms in a communication network. Such a system should facilitate the voluntary transactions between trading partners without prior consent of individual integration restructurings or a wide range of industry standards. In addition, such systems must pave the way for business automation and eliminate the tremendous time, cost, and risk required by traditional system integration.

  Overall, it is desirable to provide an electronic commerce system that replaces a network with closed commercial partners based on proprietary standards with an open market.

  The present invention provides an infrastructure for having business connections with consumers, suppliers (suppliers), and trading partners. Under the infrastructure of the present invention, using self-defining, machine-readable documents such as XML (Extensible Markup Language) based documents that are easily understandable with trading partners, Exchange information and services between companies. A document describing the items to be exchanged (hereinafter referred to as a business interface definition, or “BID”) is sent over the Internet or communicated to members of the network. The business interface definition (BID) informs potential business partners of services provided by companies and documents used when the services are exchanged. Thus, a typical business interface definition is one that allows a consumer to place an order by submitting a purchase order, which is the BID of the counterparty receiving the purchase order. It follows the document definition that appears in The supplier can confirm the possibility of ordering by downloading an inventory status report according to the document definition that appears in the BID of the business system that manages the inventory data. The use of predefined, machine-readable business documents provides a more intuitive and flexible way to access enterprise applications.

  A node in a commercial network establishes an interface for transactions according to the present invention. In this case, the present invention includes not only the specification of the interface, but also a machine readable data structure with the information necessary to interpret the interface. This interface specification includes an input document definition and an output document definition. The transaction processor accepts and generates the specification, and the node acts as an interface. Both definitions of the input document and the output document include, for example, a description of a storage device and a description of a logical structure of the storage device according to a standard XML document. In accordance with various aspects of the present invention, a machine readable data structure containing interpretation information is provided for each entry in the list to provide a semantic definition of the logical structure (eg, a mapping code for a product name). Data type specifications for logical structures in the definition of input and output documents (eg, strings, arrays, etc.), content models for logical structures (eg, a list of possible values), and / or for specific logical structures It contains a data structure that maps the storage device.

  In accordance with another aspect of the present invention, the interface includes a repository (which stores a library of logical structures and interpretation information of logical structures) in memory accessible by at least one node of the network. This repository can be extended to include a library of input and output document definitions, a library of interface specifications, and a library of specifications for participant interface nodes in the network.

  Accordingly, the participants of the transaction framework of the present invention execute transactions between nodes in a network including a plurality of node execution processes related to the transaction. The method of the present invention includes storing a machine readable specification of the interface for the transaction. The specification has an input document definition and an output document definition. The input and output document definitions each include a storage device description and a logical structure for the storage device. In the preferred system, these definitions are expressed in a manner compliant with the standard XML document type definition, DTD, and are extended by semantic mapping, content modeling, and data typing of some elements. A transaction participant receives data including a document over a communication network. Participants parse the document according to the specifications stored for the transaction and identify the input document for the transaction. After parsing the document, at least a portion of the input document in a machine readable format is provided to the transaction process that produces the output. The output document is formed to include the output of the transaction process based on the definition of the output document of the stored specification. The output document is sent over a communications network and is usually returned to the source of the input document, or otherwise tailored to the needs of a particular type of transaction.

  Thus, the definition of the business interface bridges the gap between, for example, a document specified by XML and a program executed at the front end of the transaction processing service at a special node. Such a front end is implemented, for example, by a JAVA virtual machine or other common architecture provided for interconnection between systems that exist across a network. The business interface definition provides a technique by which the transaction protocol is programmed with a document that defines the business interface. The program for the transaction protocol is established by a detailed formal form of the document format.

  The machine readable specification of the transaction interface makes it accessible to other platforms of the network. The participant's platform includes resources for designing input and output documents according to the transaction interface specified by complementary nodes. Thus, the participant's node includes resources that access the input document definition for the complementary interface and the output document definition for the complementary interface. The stored specification for the accessing participant node is established by including at least a portion of the complementary document's output document definition in the input document definition stored in that specification.

  According to another aspect of the invention, the process of establishing the interface specification includes accessing a machine-readable specification element from the repository. The repository stores a logical structure, a content model, and a library of schematic maps for the logical structure, as well as a document definition that includes the logical structure used to build the interface description. A network accessible repository simplifies the construction of interface descriptions that can be easily shared. The difference between the input document generated for a special process and the output document expected as a return by a complementary process agrees with the communication over the network and a common logical structure for representing special information You can get over it.

  According to one aspect of the invention, the machine readable specification of a transactional interface comprises a document that conforms to the definition of an interface document that is shared among members of the network. The interface document definition has a logical structure for storing a special transaction identifier, at least one definition, and references to the input and output document definitions for the special transaction. That is, in practice, the interface description for a special service covers the definition of input and output documents. Alternatively, it can include a pointer to a repository location for such a document definition, or a pointer to somewhere in the network.

  According to another alternative of the invention, the machine readable specification includes a business interface definition BID document that conforms to the definition of the interface document, the interface document storing an interface identifier, and It has a plurality of logical structures for storing references to at least one specification and one or more transaction set specifications supported by the interface. For each supported transaction, the document contains at least one definition and a reference to the input and output document definitions for the particular transaction.

  According to another aspect of the invention, the storage device defined in the input / output document definition identifies the storage device according to parsing data including character data encoding text characters and the logical structure of the input / output document. Includes markup data. According to another aspect of the invention, at least one of the set of storage devices encodes a plurality of text characters that result in a natural language. This makes it easy for document developers and readers to use input and output document definitions.

  According to another aspect of the invention, the input / output document specification includes interpretation information for at least one of the set of storage devices identified by the logical structure. This interpretation information, for example, encodes a definition for a parsed character. In another example, interpretation information is provided for content model specifications. For example, a particular logical structure may be required to handle multiple lists of mapped codes to create a catalog description. For some systems, the storage device in the logical structure of the document includes a set of data parsed to the needs of a particular implementation.

  According to another aspect of the invention, the transaction process on a particular platform has one of a number of variant transaction processing architectures. Accordingly, the participant node includes resources for using the information to convert at least a portion of the input document into a readable format according to a modified transaction processing architecture. Document-defined elements are converted into programming objects that contain variables and methods according to a modified transaction processing architecture. For participants who have a JAVA virtual machine that acts as a front end for the transaction process, certain fields of the document are converted to JAVA objects. It includes setting functions associated with JAVA objects as well as data. Other transaction processing architectures that can be supported in accordance with the present invention are Common Object Request Broker Architecture CORBA, Component Object Model COM, On-line Transaction Processing OLTR, and Electronic Data Interchange Interface, which includes the Electronic Data Interchange Processing Language.

  According to another aspect of the invention, a repository is provided for storing document formats used in multiple transactions. A machine readable specification for a special transaction defines at least one of the input and output documents by referring to the document format of the repository. According to another aspect, the document format of the repository includes a document format for identifying network participants. Such a document format provides a structure for identifying participants, identifying services supported by the participants, and identifying input / output documents for each such service.

  In addition to the above-described method, the present invention provides an apparatus for managing transactions between nodes, which stores instruction programs and data including machine-readable specifications for network interfaces and transaction interfaces. And a data processor connected to the memory and the network interface. A program of instructions stored in the device includes logic to perform the above-described process for a transaction participant.

  The present invention further provides an apparatus for establishing a participant interface for transactions executed on a system having a data processing resource and a network interface for performing transaction processing according to a transaction processing architecture. The apparatus includes program instructions executable by the system. The program instructions are stored on a medium that is accessible to a system that provides a tool for building interface definitions for participants of special transactions. Participant interface definitions include input document definitions and output document definitions. This input / output document definition has a machine-readable description of each storage device within the logical structure for the storage device, and in one aspect of the invention it conforms to the XML document format definition.

  Also according to this aspect of the present invention, an apparatus for establishing a participant interface includes a program of instructions stored on a medium accessible by a data processing system, and in response to a definition of an input / output document, the storage apparatus Compile the data structure corresponding to the logical structure of the input / output document according to the set and transaction architecture. It also compiles instructions executable by the system to convert the input document into a corresponding data structure. The system then compiles instructions executable by the system to convert the output of the transaction processing into a set of output document storage and logical structures.

  In a preferred system, tools for building participant interface definitions include instructions executable by the system, from a repository storing a library of interpretation information used to build logical structures and interface descriptions, and Access definition elements from complementary nodes. In accordance with various aspects of the present invention, the repository has a format that identifies not only a library of logical structures, but also document definitions and participant interfaces that contain the logical structures. This feature of the present invention provides a tool for building business interface specifications based on the above-described techniques relating to the description of participant nodes. Tools for building the interface, and tools for compiling this interface into the resources needed for communication with the transaction processing architecture, are implemented at the participant nodes of the preferred system of the present invention. And when the use of the network increases based on the interface description that defines the input / output document, it is used for the development and optimization of the interface description.

  Accordingly, another aspect of the present invention accomplishes the functions described above with a memory and a data processor that executes instructions that are stored in the memory and that include tools for building a participant interface definition. A device including a compiler is provided.

  According to yet another aspect of the present invention, the use of the participant interface description results in the market maker node operating. At such a node, a transaction management method is provided that includes storing a transaction supported by the interface and a machine readable specification of a plurality of participant interfaces identifying each input / output document of such transaction. . As described above, the definition of the input / output document includes, for example, each description of the storage device and the logical structure for the storage device in accordance with the XML standard. In addition, all of the transaction definitions and participant interface definitions include documents specified according to XML-compliant technology or other standardized document expression language. At such a market maker node, data including documents is received via a communication network. The document is parsed according to the specification to identify the input document in one or more transactions that accept the input document. For transaction processing associated with one or more identified transactions, at least a portion of the input document is provided in a machine readable format. Providing at least a portion of the input document for transaction processing includes performing routing processing at the market maker node according to the processing architecture. In one aspect of the invention, this routing process is performed by a specific processing architecture and converts at least a portion of the incoming document into a format for the processing architecture of the routing process. According to a preferred aspect, the transformation includes generating a programming object having variables and schemes based on the processing architecture of the routing process.

  According to another aspect of the invention, the market maker node supports a repository structure. As a result, it includes a process that allows network participants to access the repository stored at the market maker node. As described above, the repository includes a logical structure definition, interpretation information, and document definitions used by each participant node to build a transaction interface document, and a business interface that identifies the participant. Includes instances of definitions and transactions executed by each participant.

  Based on various alternatives, the routing process converts the input document to the various processing architectures to which the document is sent, or converts the input document in the original document format over the network to a remote processing node. Or both of the conversion process and the transmission process. Alternatively, the routing process includes a technique for converting an input document defined according to one input document definition into another document defined according to a different document specification for the process of looking at the input document.

  A market maker node is also provided in accordance with the present invention as a device that includes a network interface, a memory storing instruction programs and data including participant interface specifications, and a data processor. The logic is provided by the data processor in the form of an instruction program, otherwise it performs market maker processing as described above.

  Accordingly, the present invention provides a basis for electronic commerce based on sharing the specifications of input / output documents. Documents provide an intuitive and flexible way to access business services and are easier to implement than programming APIs. If companies have already agreed broadly, it is much easier for companies that are trying to exchange documents by exchanging documents than companies that always implement different business system interfaces. Is possible. In addition, in the preferred embodiment, such documents are specified in a human readable format. In accordance with the present invention, the business interface is specified in documents such as XML documents that can be easily interpreted by humans as well as computers.

  The use of a document-based transaction architecture in accordance with the present invention for any source of a document while eliminating the demands of custom programs for extracting, integrating and editing information from each participant in the network. Basically involves the use of parsing that works in a similar way. Thus, integrating and editing business information from accounting, purchasing, manufacturing, delivery and other functions first converts each source into a document having the architecture of the present invention, and then parsed data This can be achieved by processing the stream. Each node of the system participating in the market is only required to know the format of its internal system, as well as the specific document format that is specified for document conversion for the transaction. Thus, there is no need to be able to generate a format that is unique to all other nodes that wish to participate in the e-commerce network.

  For complete business integration, the present invention provides a repository of standard logical structures such as XML elements, attributes or metadata, and a semantic language for a particular commerce community, mapping between different metadata descriptions And a server for processing documents and calling appropriate applications and services. The basic building block of the network according to the present invention includes a business interface definition that informs potential trading business partners what online services the company provides and what documents to use to invoke the service; It includes a server that provides a bridge that connects internal / external business service pairs together to create a trading community. This server operates to parse the input document and invoke the appropriate service. The server according to the present invention also handles the conversion task of the format of documents received and transmitted to and from each host system format. Thus, the trading partner need only agree on the structure, content, and order of the business documents being exchanged, and not the details of the application's program interface. Depending on the business providing the service, how the document is processed is determined, and the actions that result from the receipt of the document are also severe. This improves integration and editing from the system level to the business level. It can present a clear and stable interface to partners despite its internal technology implementation, organization or processing changes.

  All the processing of building a business interface definition and the server doing some transactions according to the above description is easily realized by a common business library, i.e. a repository, for example, companies, services and products, catalogs -Stores information models for general business concepts including basic business descriptions, such as business forms such as purchase orders and invoices, and standard indicators including date, place, and product classification.

  Other features of the invention will be understood by consideration of the drawings, detailed description, and claims set forth below.

  The invention will be described in detail in connection with the drawings. FIG. 1 shows a network of market makers and market participants based on the use of business interface definitions and supports the exchange of input and output documents specified according to the interface. The network includes a plurality of nodes 11-18 interconnected via a communication network such as the Internet 19 or other communication means or data communication network. Each of the nodes 11 to 19 is composed of a computer such as a portable computer, desktop personal computer, workstation, system network, or other data processing resource. The node includes a memory for storing business interface definitions, a processor for executing transaction processes that support commercial transactions with other nodes in the network, and the processor for supporting such services. Contains computer programs to be executed. In addition, each node includes a network interface for providing communication over the Internet 19 or other communication network.

In the case of the environment shown in FIG. 1, nodes 11, 12, 13, 14, 16 and 18 are designated market participants. Market participants include resources for consumers or suppliers of goods or services to be traded in accordance with a commercial transaction established in accordance with the present invention.
In this example, nodes 15 and 17 are market maker nodes. The market maker node includes a resource for registering a business interface definition called a BID registry. The participant can send the document to the market maker where the document is identified and forwarded to the appropriate participant registered to receive such document as input. Market makers help the commerce network by having a standard format repository for constructing a common business library used to build business interface definitions.

  In this example, the market participant 18 is directly connected to the market maker 17 rather than via the Internet 19. This direct connection to the market maker incorporates a public network such as the Internet 19 and a private connection such as a local area network or a point-to-point connection as shown between nodes 17 and 18. This indicates that the network configuration that supports commerce transactions can be very diverse. Since actual communication networks are quite diverse, it can be said that they are suitable for use in establishing a commercial transaction network according to the present invention.

  FIG. 2 shows a heuristic diagram of a nested structure in a business interface definition (BID) established for a market participant in a network according to the present invention. The business interface definition shown in FIG. 2 is a data structure composed of a logical structure and a storage device arranged in accordance with a document structure format definition such as an XML document type definition (DTD). The structure of FIG. 2 includes a first logical structure 200 for identifying a party. Associated with the logical structure 200 is a nested logical structure 201 for sending names, a physical address 202, a network address or location 203, and a set of service transactions 204. For each transaction in the service set, an interface definition including transaction BIDs 205, 206, 207 is provided. Each transaction BID, such as transaction BID 205, includes a name 208, a network location 209 where the service is executed, an operation 210 executed by the service, and a set of input documents 211 indicated by the tag. A logical structure is provided for inclusion. The service BID 205 also includes a set of output documents 212 indicated by tags. The set of input documents 211 includes a business interface definition for each input document that the service is designated to respond to, such as input document business interface definitions 213, 214, 215. Each business interface definition for an input document includes a name 216, a network location 217 where the description of the document can be found, and a module 218 to be sent in the document as indicated by the field. In a similar manner, the output document set 212 includes interface definitions for output documents that include output document BIDs 219, 220, 221. For each output document BID, a name 222, a location 223 on the network or elsewhere, and a document module 224 are identified. The business interface definition for the participant shown in FIG. 2 can be the actual definition of the logical structure used for each service's input / output document, or a pointer or other location where the definition can be found. Contains a reference.

  In the preferred system, the document of FIG. 2 is specified in an XML document type definition (DTD), but other document definition architectures can also be used, as well as the logical structure used to interpret the document instance. Contains interpretation information. Further, each of the transaction BID, the input document BID, and the output document BID is specified according to the XML document type definition. An XML type document is an example of a system based on parsing data including markup data and character data. The markup data identifies the logical structure in the document, and the character data set identifies the contents of the logical structure. In addition, non-parsed data can be transmitted in the document for various purposes. For example, WWW. W3. In ORG / TR / 1998 / REC-XML-19980210, the specification of Extensible Mark-up Language XML 1.0 REC-XML-19980210 issued by the WC3 XML working group can be referred to.

  Thus, in the illustrated system, participant nodes in the network establish a virtual enterprise by interconnecting business systems and services with business-understood and generated XML coded documents. For example, the business interface definition for a particular service establishes that if a document is received that matches a requested BID for catalog entry, a document that matches the catalog entry BID is returned. Also, if a document that matches the BID of the purchase order is received and it is acceptable to the receiving terminal, a document that matches the BID of the invoice will be returned. Nodes in the network process the XML document before entering the local business system established according to the various transaction processing architectures of any given system in the network. As a result, the system decodes a related set of documents, such as a MIME-encoded set of XML documents, and parses it to generate a stream of “markup messages”. This message is transmitted to an appropriate application and service using, for example, an event listener model described later.

  Documents exchanged between business services are encoded using an XML language built from a repository of building blocks (a common business language) from which more complex document definitions are generated. This repository stores modules of interpretation information focused on functions and information common to business areas. In the business area, for example, business format such as company / service / product, catalog / purchase order / invoice, etc. Includes a basic business description that gives

  A business interface definition is a higher level document that serves as a schema used to design an interface for trading documents according to the present invention. Thus, the business interface definition bridges the gap between the document specified according to XML and the program executed at the front end of the transaction processing service at the specific node. Such a front end is implemented by a JAVA virtual machine or other common architecture that provides internal connectivity of the system across a network. Thus, the business interface definition provides the technology by which the transaction protocol is programmed using the business interface definition document. The program for the transaction protocol is established by a detailed formal specification of the document type.

  An example of a business interface definition BID based on a market participation document that conforms to the XML format is given below. The market participant DTD groups contact and address information into business information about the market participant while associating with service and financial information descriptions. This business information consists of a name, code, address, a dedicated classification mechanism to indicate the business organization, and pointers to business terms. In addition, the service identified by the market participant DTD identifies the input / output documents that the participant is expected to respond to and generate. As a result, the document that defines the schema using a typical common business language for market participants DTD, service DTD, and transaction document DTD identified in XML with annotated comments is: It is.

サービスＤＴＤスキーマは、共通ビジネス言語リポジトリのサービスタイプ要素によって、以下のように拡張される。

The service DTD schema is extended by the service type elements of the common business language repository as follows:

The service type element above represents the interpretation information provided by the business interface definition, and in this case represents a content format that allows the identification of any one of the valid service types. Another interpretation information includes a data type definition. For example, an element including a content format “url” (<H3> Internet Address </ H3>) is represented by a data type “string”. Yet another interpretation information includes code mapping to list elements, for example, <H3> State </ H3>, an element containing code mapping for states present in the file “COUNTRY.US.SUBENTITY”. .
The service description queried by the market participant DTD is to define a document for which the competition is accepted and generated as a service. The basic service description is the XML document transact. This will be described in detail below as dtd.
transact. dtd models a transaction description such as a bill or a description for exchanging values. This document type supports many uses, so the transaction description element has attributes that the user is likely to distinguish from others in the presence of invoices, performance, sales offers, quote requests, and the like. Exchanges are made between two or more parties, but only two are eligible as applicants and their counterparts, each represented by a pointer to a document that matches the market participant DTD described above. The pointer of the other party for accepting the offer for sale is arbitrary. The description for the exchange is given below in transprim. Includes price and subtotal as shown in mod. Following the description for the exchange, a charge that applies to the entire transaction may be provided and the total charge must be given. Accordingly, the transaction description schema document transact. dtd is expressed as follows.

上記の定義に従って生成される典型的なマーケット参加者およびサービスＤＴＤは、以下の通りである。

＜マーケット参加者ＤＴＤ＞

＜サービスＤＴＤ＞

ｔｒａｎｓａｃｔ．ｄｔｄに従って生成されたドキュメントの一例は次のように示される。

A typical market participant and service DTD generated according to the above definition is as follows.

<Market participant DTD>

<Service DTD>

transact. An example of a document generated according to dtd is shown as follows.

  Thus, the present invention provides a technique that allows market participants to identify themselves and the type of input / output document they wish to trade with. The particular manner in which the content brought to the document by other parties to this transaction or by some parties is processed does not affect the establishment of the business relationship nor the transaction.

  FIG. 3 shows a schematic diagram of a participant node of a network according to the present invention. The node illustrated in FIG. 3 includes a network interface 300 that is coupled to a communication network at port 301. This network interface is coupled to a document parser 301. The parser 301 provides the logical structure from the input document to a conversion module (translator) 302, which converts the input document into a form that can be used by the host trading system and vice versa. Convert to a document format that matches the output document form specified in the business interface definition for transmission to the destination. Parser 301 and translator 302 respond to the business interface definition stored in participant module 303.

  The output data structure from the translator 302 is supplied to the trading process front end 304 along with the event signaled by the parser 301. The front end 304 in one embodiment is comprised of a JAVA virtual machine or other similar interface suitable for communicating between various nodes of the network. The transaction processing front end 304 is responsive to events indicated by the parser 301 and translator 302 and forwards input data to the appropriate functions of the network coupling the enterprise system and participants. As a result, the transaction processing front end 304 shown in FIG. 3 is combined with commercial functions 305, database functions 306, and other corporate functions 307 such as accounting / invoicing to respond to events indicated by the parser. Combine with a specific event listener / processor 308 designed.

  Parser 301 receives purchase orders as described above, or other documents identified in accordance with business interface definitions, and generates events that are recognized by local transaction processing architecture, such as JAVA events for JAVA virtual machines.

  The parser of the present invention is uncoupled from a listening program that attempts to know events based on received documents. Each markup language construct present in a received document or a complete document conforming to a specification acts as an instruction for a listening function that initiates processing. Thus, the listening program executes business logic associated with document information. For example, the program associated with the address element is a code that authenticates a postal code by checking a database. These listeners subscribe to the event by registering with the document router, and the document router directs the relevant event to all interested subscribers.

  For example, the purchase order described above is monitored by a program that listens for events generated by the parser, which connects the document or its contents to the order entry program. Receiving the product description of the purchase order is related to a program for checking inventory. Receiving purchase order address information relates to a program for checking the possibility of delivery service. The buyer information field in the document can invoke a process of advertising and similar processing based on whether the credit is worthless by checking the order history and knowing the consumer's ID. .

  Complex listeners are created as basic listener configurations. For example, a purchase order listener may include or call the list listeners described in the previous paragraph, or list members may call themselves. It should be noted that the application executed by the listener is unlikely to be an original XML process or an original JAVA process. In these cases, the object will be converted to the format required by the receiving trading application. When the application completes processing, the output is converted back to XML format for communication to other nodes in the network.

  The market participant document type description and the transaction document type description, as described above, include a rough mapping for the logical elements of the document and a markup language based on natural language. Natural language markup, and other natural language attributes of XML, facilitate the use of XML type markup languages for business interface definition, service description, input / output document description specifications.

  In addition to storing business interface definitions, participant module 303 compiles objects and other data structures used by trading process front end 304 that match the logical structure of the input document, and compiles translator 302. Includes a compiler used to do that. As a result, the translator 302 and parser 301 are automatically kept updated when the business interface definition is changed or updated by the participant in response to a transaction transition involving the participant.

In the preferred system, JAVA events are generated by the compiler corresponding to the SGML grove model, primarily the standard element structure information set extended by the “property set” of each element. -International Standard ISO / IEC 10179: 1996 (E), Information Technology--Processing Language--Document Style Sequential and Specification Language (DSSSL).
Turning an XML document into an event for a process is different from the usual parsing model where parser output is maintained as an internal data structure. Rich functionality is available on nodes that use documents to be traded by transforming XML document elements into JAVA events or other programming structures suitable for use by each node's transaction processing front end It becomes like this.

  Thus, the trading process front end 304 can operate in a publish and subscriber architecture that allows new listener programs to be added without the knowledge or impact of other listening programs in the system. Each listener 305, 306, 307, 308 in FIG. 3 maintains a queue in which the front end 304 directs events. This allows multiple listeners to handle events in parallel at their own pace.

  Furthermore, according to the present invention, the application executed by the listener does not have to be an original XML function (function) or an original function matching the input document format. Rather, if the transaction process front end 304 is a JAVA interface, these listeners are JAVA functions, or functions that execute according to a specific transaction processing architecture. In these cases, the object will be converted to the format required by the receiving application. When the listener application completes, its output is converted back into a document format as specified by the business interface definition in module 303. As a result, the translator 302 is directly coupled to the network interface 300 to synthesize and provide the document as output.

  The listener coupled to the transaction processing front end includes a listener for the input document, a listener for the specific element of the input document, and a listener for the attribute stored in the specific element of the input document. This makes the execution of the trading process diversified and flexible at specific nodes for filtering and responding to input documents.

  FIG. 4 illustrates a process for receiving and processing an input document for the system of FIG. Thus, the process begins with receiving a document at the network interface (step 400). The parser identifies the document type (401) in response to the business interface definition. The document is parsed using a business interface definition that stores the DTD for the document in XML format (step 402). Next, the document elements and attributes are converted to the host format (step 403). In this example, the XML logical structure is converted to a JAVA object that yields data for the XML element, along with data-related methods such as get and set functions. The host object is then transferred to the host transaction processing front end (step 404). These objects are sent to the process in response to events indicated by the parser and translator. A process of receiving document elements is performed and produces an output (step 405). The output is converted to the format of the output document defined by the business interface definition (step 406). In this example, translation transitions from the JAVA object format to the XML document format. Finally, the output document is transferred to the destination via the network interface (step 407).

  FIG. 5 shows a detailed view of the event generator / event listener mechanism for the system of FIG. In general, the approach shown in FIG. 5 is an improvement of the JAVA JDK1.1 event model. In this model, three types of objects are considered. The first object is an event object including information related to event generation. There are any number of types of event objects corresponding to all the different types of events that can occur. The second object is an event generator that monitors activity when something happens and generates an event object. The third is an event listener that listens to the event object generated by the event generator. Event listeners generally try to know about a specific event occurrence, such as a mouse click, on a specific window. The event listener calls the “add event listener” method on the event generator. This model can be adapted to the environment of FIG. 3 and generates objects in response to tracing and parsing a graph of objects as represented by the XML document.

  The system shown in FIG. 5 has a general XML parser 500. Such a parser can be implemented using a standard call back model. When a parsing event occurs, the parser invokes a specific method in the application object and passes the appropriate information in the parameters. Thus, a single application 501 exists with the parser. The application packages the information provided by the parser in an XML event object and sends it to the number of event listeners identified by itself, as indicated by block 502. The set of events 502 is completely independent of the parser. Event 502 can be delivered to any number of listeners and any number of threads on any number of machines. Events are based on an Element Structure Information Set (ESIS) in one alternative format. These therefore consist of a list of important aspects such as recognition of the document structure or attributes, such as the start and end of an element. XML (and SGML) parsers generally use the ESIS structure as the default set of information for the parser to return to its application.

  A specific ESIS listener 503 is coupled to a set of events 502. This listener 503 implements the ESIS listener API and listens for all XML events from one or more generators. One element event generator 504 is a specific ESIS listener and also an XML event generator. The listener is an object that is only interested in events for a particular type of element. For example, in an HTML environment, the listener is interested only in the indicated list, ie only the part of the document between the <OL> and </ OL> tags. In another example, the listener listens only to the “party.name” or “service.name” element according to a common business language from the above example document, and the element yields data that matches the schematic mapping for the element Process the element to ensure that it reacts according to the process required at the receiving node.

  This allows the system to have small objects that only listen to specific parts of the document, such as summing prices. There can also be listeners that only listen to, for example, the <HEAD> portion of an HTML document, since listeners can add or remove themselves from the generator. For this reason and because of the high repeatability of XML documents, it is possible to write highly targeted code and concurrent listeners. For example, the <OL> listener can set the <LI> listener completely separate from the method in which the <UL> (undirected list) listener sets the <LI> listener. Alternatively, you can create a listener that generates a graphical user interface and another listener that searches a database that uses the same input. Thus, the document is treated as a program executed by the listener, as opposed to a complete data structure that the application examines one at a time. If an application is written this way, it is not necessary to have the entire document in memory to run the application.

  The next listener coupled to the set of events 502 is the attribute filter 505. Similar to the element filter 504, the attribute filter 505 is an attribute event generator according to the ESIS listener model. The listener for the attribute filter specifies the attributes that it is interested in and receives events for every element that has the specified attributes. For example, the font manager will receive events only for elements with font attributes such as <PFONT = “Times Roman” / P>.

  Element event generator 504 provides such an element object to specialize element listener 504A.

The attribute event generator 505 supplies an attribute event object to the attribute listener 505A. Similarly, attribute objects are provided to the “architecture” in the sense of transforming SGML / XML using attributes from one document format to another. Thus, the 505B architecture allows a specific attribute with a specific name to be identified. Only elements with that defined attribute become part of the output document, and the name of the element in the output document is the value of the attribute in the input document. For example, if architecture 505B is HTML,
<PURCHASES HTML = “OL”><ITEM HTML = “LI”><NAME HTML = “B”> STUFF </ NAME><PRICE HTML = “B”> 123 </ PRICE></ITEM></PURCHASE>
When converted (translated),
<OL><LI> STUFF </ B><B> 123 </ B></LI></OL>
It is correct HTML.

  The next module coupled to the set of events 502 is a tree builder 506. The tree builder takes a stream of XML events and generates a tree representation of the underlying document. One preferred form of tree builder 506 generates a document object model DOM object 507 according to the specification of W3C (http://www.w3.org/TR/1998/WD-DOM-199980720/introduction.html). Listeners in the event stream can be used to handle most requests, but the tree format supports questions around the document, so the nodes can be reordered, creating new documents, for example parsing documents many times It helps to support in-memory data structures from which the same event stream can be generated multiple times. The specific builder 508 can be coupled to the tree builder 506 to create a special subtree of the portion of the document that fits the specific implementation.

  In addition to responding to incoming documents, other sources of XML events 502 can also be provided. Thus, the event stream 510 is generated by walking over the tree of DOM objects and by regenerating the original event stream that was created when the document was being parsed. This allows the system to give the appearance that the document has been parsed several times.

  The notion of an object that traverses the tree and generates a stream of events can be generalized to any tree of objects that can be queried beyond the tree of DOM objects. Accordingly, the JAVA walker 512 may be an application that follows the tree of the JAVA bean component 513. Walker follows all open fields and methods. The walker remembers the trajectories of objects that have already been visited to ensure that it does not enter an endless cycle. JAVA event 514 is a type of event generated by JAVA walker 512. This currently includes most of the types of information that can be extracted from an object. This is the equivalent of ESIS's JAVA, and in particular JAVA beans, but allows the same programming techniques applied to XML to be applied to JAVA objects in general.

  The JAVA for the XML event generator 515 is composed of a JAVA listener and a JAVA event generator. It receives a stream of events 514 from a JAVA walker 512 and translates (translates) the selected one to supply a JAVA object as an XML document. In the preferred embodiment, event generator 515 utilizes the JAVA beans API. Each object seen becomes an element, and the element name is the same as the class name. Within that element, each embedded method also becomes an element whose contents are the values returned by invoking the method. If it is an object or an array of objects, these will be traced alternately.

  FIG. 6 is a schematic diagram of a particular application built on the framework of FIG. This application takes an XML document 600 and applies it to a parser / generator (parser routine generation system) 601. ESIS event 602 is generated and provided to attribute generator 603 and tree builder 604. The attribute generator corresponds to the generator of FIG. The generator 505 sends the event to, for example, an “architecture” 505B for converting (translating) the XML input to the HTML output. These events are processed in parallel as indicated by block 605 and processed by the listener. The output of the listener is supplied to the document writer 606 and converted (translated) back to the XML format for output. Thus, for example, the application shown in FIG. 6 takes an XML document and outputs an HTML document having a form. This form is then sent to the browser and the result is converted back to XML. For this operation, the architectural concept provides a mapping from XML to HTML. The three architectures included in FIG. 6 are for providing the structure of an HTML document such as a table and list, a second that specifies the document to be displayed, such as a label for an input field on the browser document, and Includes a third one that describes the input field itself. The elements of the XML document that are required to maintain the XML document structure are invisible fields in the HTML form. This is useful for use in reconstructing an XML document from information that the client puts in an HTTP post message sent back to the server. A listener who listens to these events outputs events for the HTML document. This document goes to the document writer object. The document writer object listens for XML events and returns them to the XML document. The document writer object is a listener for all element generators listening to the architecture in this example.

  The configuration of the processing modules illustrated in FIGS. 5 and 6 represents one embodiment of the parser and transaction process front end for the system of FIG. As can be appreciated, a very flexible interface is provided so that a diversified transaction process can be performed in response to an incoming XML document or other structured document format.

  FIG. 7 illustrates a node similar to FIG. 3 except that it includes a business interface definition builder module 700. Accordingly, the system of FIG. 7 includes a network interface 701, a document parser 702, and a document translator 703. The translator 703 outputs the output to the transaction processing front end 704. This front end is coupled to listening functions such as commercial function 705, database 706, enterprise function 707, and other general listener and processor 708. As illustrated in FIG. 7, the business interface builder 700 includes a user interface, a common business library CBL repository, a process for reading complementary business interface definitions, and a compiler. The user interface is used to assist in planning in building business interface definitions, depending on the ability to retrieve common business library repositories and complementary business interface definitions. Accordingly, the complementary business interface definition input document can be specified as an output document of a specific transaction, and the complementary business interface definition output document can be specified as an input of a transaction process or the like. In a similar manner, the transaction business interface definition can be configured using components selected from the CBL repository. The use of the CBL repository is logical structure and interpretation information in building a standard document format, such as the example schema (bid1) document described above, and business interface definitions that can be easily adopted by other people in the network. Make it easier to use.

  The business interface definition builder 700 also includes a translator 703, a compiler used to generate objects to be processed by the translator and manage the parsing function 702 according to the host transaction processing architecture.

  FIG. 8 is a heuristic diagram showing the logical structure stored in the repository of the business interface definition builder 700. Accordingly, repository storage representing party business interface definition 800 includes, for example, consumer BID 801, catalog house BID 802, warehouse BID 803, and action house BID 804. Thus, a new participant in the online market selects one of the standardized BIDs that best matches the business as the basic interface definition. In addition, the repository stores a set of service business interface definitions 805. For example, an order entry BID 806, an order tracking BID 807, an order fulfillment BID 808, and a catalog service BID 809 can be stored. As new participants in the market build the business interface definition, they can select the standardized service business interface definition stored in the repository.

  In addition to the party and service BID, the input and output document BIDs are stored in the repository indicated by field 810. Accordingly, the purchase order BID 811, invoice BID 812, quotation request BID 813, product availability report BID 814, and order status BID 815 can be stored in the repository.

  The repository stores interpretation information in the form of a semantic map as indicated by field 816, in addition to the business interface definition specified in the preferred system as a document form definition according to XML. . Thus, a semantic map used to identify weight 817, currency 818, size 819, product identification 820, and product feature 821 can be stored in the repository. Furthermore, the interpretation information provides a classification of the data structure within the logical structure of the document.

  Further, the logical structure used in composing the business interface definition is stored in the repository pointed to by block 822. Therefore, a form for giving address information 823, a form for giving price information 824, and a form for giving a contract-related period 825 can be provided. As the network expands, the CBL repository expands as well, and standardization makes it easier to add new participants and define business interfaces.

  FIG. 9 illustrates the process of building a business interface definition using the system of FIG. The process begins by displaying a BID Builder graphical interface to the user (step 900). The system receives user input identifying participant and service / document information generated by the graphical interface (step 901).

  Next, in response to user input, reference logical structures, interpretation information, document definitions, and / or service definitions are retrieved from the repository via the graphical user interface (step 902). In the next step, complementary business interface definitions or components of the business interface definition are placed in a network selected via user input by a customized search engine, web browser, or other method. (Step 903). A document definition for the participant is generated using the collected information (step 904). The compiler generates translators from document to host and from host to document mappers (step 905). The compiler also generates a host architecture data structure corresponding to the definition (step 906). The generated business interface definition is then posted on the network by posting it to a website or other location, making it accessible to other nodes in the network. (Step 907).

  The business interface definition conveys the online services offered by the company to potential commercial partners and the documents used to implement these services. Therefore, the service defined in the business interface definition is defined by the document. This is illustrated in the following part of the XML service definition.

  This XML fragment defines a service consisting of two processes: one that obtains an order and one that follows it. Each definition represents a contract or promise to perform a service if a legitimate request is presented to a particular web address. Here, the order service requires an input document that matches the standard “po.dtd” DTD (Document Type Definition) placed in the repository. It can be local or stored in a wide range of registries related to the industry on the network. If one node can execute the order, that node will return a document whose definition matches the local customized “invoice.dtd”. In practice, companies have promised to do business with anyone who can submit purchase orders that match the declared XML specification. Prior adjustment is not required.

  A DTD is a formal specification or grammar for a given type of document that describes elements, attributes, and states that must be displayed. For example, a purchase order typically includes purchaser and seller names and addresses, a set of product descriptions, and associated trading terms such as price and delivery date. Electronic Data Interchange (EDI) is a commonly used model for purchase orders, for example in the X12 850 specification.

  The repository makes it easy for many business areas to develop XML document models from reusable and common semantic components. Such documents can be understood from common message elements even though they appear to be quite different. It plays the role of a common business library repository.

The common business library repository consists of an information model for general business concepts, including: That is,
Business description primitives, such as companies, services, and products,
Business formats such as catalogs, purchase orders, and invoices,
・ Standard indicators such as date and time, location, classification code,
It is.

  This information is represented as an extensible official XML building block that can be customized and assembled by companies to rapidly develop XML applications. The atomic CBL element implements message standards and agreements such as standard ISO codes for country, currency, address, and time. Low level CBL semantics can also be derived from analyzing the metadata structure of Internet resources such as Dublin Core.

  The next level of elements uses these building blocks to enable X12 EDI transactions as well as business forms used in existing Internet standards such as OTP (Open Trading Protocol) and OBI (Open Buying on the Internet). It also implements basic business forms such as those used in.

  CBL's focus is on functions common to all business areas (basic business descriptions such as companies, services, and products; business formats such as catalogs, purchase orders, and invoices; standard indicators, date / time, location, and classification codes) In the information. CBL is built on standards for semantics or industry agreements (for example, the rules for specifying “month / day / year” in the United States versus “day / month / year” in Europe are: Encoded in a separate CBL module).

  CBL is a language used to design applications. It is designed to bridge the gap between XML's “document world” and JAVA's “programming world” or other transaction processing architecture. Schema embodies the idea of “programming with documents”. In that philosophy, a detailed formal specification of a document type is the main source, and many related formats are generated from that source. These formats include CBL, JAVA objects, programs for converting XML instances to / from corresponding JAVA objects, and XML DTDs for supporting documents.

  CBL generates a single source from which almost all parts of the system are automatically generated by the compiler. CBL works by extending SGML / XML to formally define the structure of specific document types and to include semantic specifications associated with each information element and attribute. Usually used. The (most) restricted character types in SGML / XML can be extended to declare any kind of data type.

The following is a portion from the CBL definition for the “datetime” module.

  In this part, the element “year” is defined as character data and is associated with the “schema” attribute. The character data defines a schema for “year” which is Chapter 3.8 of the ISO8601 standard.

  This “datetime” CBL module is actually defined as an instance of the schema DTD. First, the module name is defined. Next, “YEAR” of the “datetime” element is linked to the meaning of the ISO8601 standard.

  The exemplary market participants and service modules described above are also stored in the CBL repository.

  In FIG. 10, an air freight receipt (Airbill) 1000 is defined by customizing a general purchase order DTD 1001 and adding specific information about the shipping weight 1002. A typical purchase order 1001 was initially assembled from a CBL module for address, date and time, currency, merchant and product description. By using CBL, the implementation of XML commercial applications is significantly speeded up. More importantly, CBL makes it easy to interconnect commercial applications.

In CBL, XML is extended by a schema. This extension adds strong typing to XML elements so that the content can be easily authenticated. For example, <CPU clock An element called speed> can be defined as an integer having a set of valid values {100, 133, 166, 200, 233, 266 Mhz}. The schema also adds class-subclass hierarchies so that information can be easily instantiated from class definitions. For example, a laptop can be described as a computer with additional tags for features such as display type and battery life. These and other extensions facilitate data entry as well as automatic conversion between XML and traditional object-oriented and relational data models.

  As a result, as described above, the completed BID is the actual instance of the participant and service, the JAVA beans that match the logical structure of the DTD instance, and the conversion code that converts from XML to JAVA / JAVA to XML. It is executed through a compiler that creates a DTD for. In other systems, documents are generated for display on the user interface or for printing by the user to make the object easier to use.

上記したＪＡＶＡビーンに加えて、変換コードは以下に示されているように、ＪＡＶＡからＸＭＬへ、及びＸＭＬからＪＡＶＡへ変換するため作られる。

For the example market participant and service DTD described above, the JAVA beans generated by the compiler are shown as follows (with some modifications for brevity):

In addition to the JAVA beans described above, conversion code is created to convert from JAVA to XML and from XML to JAVA as shown below.

  Using the tool together with a BID configuration application that provides a drag, drop, and form editing user interface, developers can create business interface definitions or create and generate valid Business interface definitions can be generated in XML document format. Thus, an exemplary execution instance is a business interface definition for an ordering service for IBM that Ingram Micro and others use to order a laptop computer from IBM. (There is no relationship between the applicant and IBM or Ingram Micro.) Utilizing these processes, users can program business interfaces using documents defined in accordance with the present invention. A system can be constructed.

  The role of the CBL and BID processors of the present invention in an XML / JAVA environment can be further understood by the following description of the processing of purchase orders.

  Company A defines its purchase order document using a visualization program environment that includes a library of CBL DTDs and modules. They are all defined using common business language elements and include data types and other interpretation information. Company A's purchase orders may include slight customization to the general transaction document specifications that come with the CBL library, or be constructed entirely from CBL modules for address, date, currency, etc. You can also.

  A document for a general “transaction document” specification (such as transact.dtd described above) represents a feature of how the CBL specification is created from modules and interconnected with other CBL DTDs.

The compiler receives the purchase order definition and generates several different target types. All of these target types can be obtained via a “tree to tree” transformation of the original specification. The most important for this example is
(A) XML DTD for purchase order,
(B) JAVA beans containing data structures for purchase orders (JAVA classes, arguments, data types, methods, and exception structures created to match information in the purchase order schema definition);
(C) “Marshalling” to convert purchase orders compliant with purchase order DTDs into purchase order JAVA beans, or load them into a database, or create HTML (or XSL stylesheet) to display purchase orders in a browser (marshaling) ”program,
(D) An “unmarshaling” program that extracts data values from a purchase order JAVA bean and converts them into XML documents compliant with the purchase order DTD.
Returning now to the scenario, the purchase application generates a purchase order according to the DTD identified as the service interface for the supplier accepting the purchase order.

  The parser uses the purchase order DTD to break the purchase order instance into an information stream about the element and the attribute values it contains. Next, these “property sets” are converted into corresponding JAVA event objects by overlapping with JAVA code. In fact, this transformation treats a portion of the markup XML document as an instruction in the customer programming language whose grammar is defined by the DTD. These JAVA events can be processed by the marshalling application generated by the compiler and “load” the data structure of the JAVA bean.

  Converting and processing an XML document into a set of events for a JAVA application is the normal parsing of a model where the output of the parser is maintained as an internal data structure and processing does not begin until parsing is complete. Is different. Depending on the BID definition, event-based processing is key to making the processor's very good functionality available. This is because the latest document application process can start as soon as the first event is fired.

  A JAVA program that “listens” for various types of events is formed from a schema definition of those events. These listeners are programs created to execute the business logic associated with the CBL XML definition, for example, code associated with an “address” element and authenticating a postal code by checking a database. May be. These listeners “subscribe” to events by registering with the document router and present relevant events to all subscribers interested in them.

  This publishing and subscription architecture can be added without the new listener program having any knowledge or impact on the existing program. Each listener has a queue in which the router directs the event, allowing multiple listeners to handle the event concurrently at their own pace.

For an exemplary purchase order, there are listeners for:
・ Purchase orders connected to the order entry program,
・ Product manual to check inventory,
・ Address information to check the possibility of courier or other delivery service,
・ Purchaser information that allows you to check the order history (for advertising and similar processing based on knowing whether credit is worthless and who is the consumer) .

  Complex listeners are created as basic listener configurations. For example, certain purchase order listeners may include or call these listeners, or they may call themselves. )

  FIG. 11 shows market marker nodes in the network of FIG. The market marker node includes the basic structure of the system of FIG. 3 and includes a network interface 1101, a document parser 1102, a document-to-host / host-to-document translator 1103, in this example a front end 1104 called a router. Have. The market marker module 1105 in this example is a set of business interface definitions or other identifiers sufficient to support market marker functionality for market participants, CBL repositories, and market participant requests. It has a compiler that meets all the requirements. The router 1104 includes a participant registry and document filter that responds to translator output and parser-generated events, according to the participant registry and according to element and attribute filters between listeners to the XML event generator. Transfer input documents. Thus, a market participant can register to receive a document that conforms to the predetermined parameters. For example, an input document that conforms to a particular DTD includes attributes such as the number of products purchased above a certain threshold, or the maximum price of a document request to be purchased, and is used to filter the document at the router 1104. Next, only documents that match the information registered in the participant registry at the router 1104 are sent to the registered participants.

  The router 1104 satisfies the requests of the local host services 1105 and 1106, and operates as a market participant as well as a market marker, for example. Typically, documents received by the router 1104 are tracked to determine the destination, and such documents to be tracked are sent to that destination. If necessary, it is returned via the translator 1103 and sent from the network interface 1101 to each destination.

  A market marker is a server that connects a set of internal and external business services together, creating a virtual company or trading community. The server parses the input document and invokes the appropriate service, for example, by passing a request for product data to the catalog server or by sending a purchase order to the ERP system. The server also handles the conversion (translation) task and maps information from the company's XML document to the document format used by the trading partner and to the data format required by the legacy system.

With respect to the above service definition, when a company submits a purchase order, the server's XML parser uses the purchase order DTD to convert the purchase order instance into a stream of information events. These events are then sent to any application programmed to handle the given type of event. In some cases, sending information completely to different businesses over the Internet. In the purchase order example, some applications work with information coming from the parser.
The order entry program processes the purchase order as a complete message.
-The ERP system checks the inventory of the product described in the purchase order.
• The customer database verifies and updates customer addresses.
• The shipping company uses the address information to plan delivery.
• The bank uses the credit card information and authorizes the transaction.

  Trading partners need only agree on the structure, content and order of the business documents they exchange, not the API details. How the document is processed and what actions result will depend entirely on the service providing business. This improves integration and editing from the system level to the business level. It makes it possible to provide a clear and stable interface to the business partner despite business changes in the execution, organization or process of the internal technology.

  12, 13 and 14 illustrate the processes performed at the market maker node of the system of FIG. In FIG. 12, the network interface receives an input document from the originating participant node (step 1200). The document is parsed (step 1201). Convert the document to host format. For example, conversion from XML to JAVA is performed (step 1202). Next, the host's formatted events and objects are sent to the router service (step 1203). The service registered to accept the document according to the document type and content is identified (step 1204). The document and part of the document are sent to the identified service (step 1205). A service is executed according to the contents of the document (step 1206). Output data of the service is created (step 1207). The output data is converted into a document format. For example, conversion from the JAVA format to the XML format is performed (step 1208). Finally, the output document is sent to the participant node (step 1209).

  The registration service is one of the functions managed by the router. Accordingly, as shown in FIG. 13, a market participant document is accepted at the network interface (step 1300). The market participant document is stored in the business interface definition repository for the market maker node (step 1301). In addition, the document is parsed (step 1302). The parsed document is converted to the host format (step 1303). Next, the document is sent to the router service (step 1304). The router service includes a listener that identifies the registration service as the document destination according to the document type and document content (step 1305). The document and the document element are sent to the registration service (step 1306). In the registration service, a required service specification is searched according to the business interface definition (step 1307). If service specifications are collected at step 1308, a router service filter is set according to the business interface definition and service specifications (step 1309). Acknowledgment data for registration is generated (step 1310). This acknowledgment data is converted into a document format (step 1311). Finally, an acknowledgment document is sent to the participant node to notify the participant that registration was successful at the market maker (step 1312).

  The process of gathering the required service specifications at step 1307 is shown as an example in FIG. The process begins by locating service business interface definitions supported by market participants (step 1400). For example, the service definition is retrieved by e-mail transaction or web access to the repository node (step 1401). The service specification is stored in the BID repository (step 1402). The service business interface definition document is parsed (step 1403). The parsed document is converted to the host format (step 1404). Next, the host object is sent to the router service (step 1405). A registration service is identified according to the document type and content (step 1406). Finally, the service business interface definition document information is sent to the registration service for use by the process of FIG. 13 (step 1407).

  FIG. 15 is a diagram illustrating a processor, components, and sequence for processing input data at a market maker node according to the present invention. The market maker node has a communication agent 1500 at the network interface. The communication agent is connected to the XML parser 1501, and the XML parser 1501 supplies an event to the XML processor 1502. The XML processor 1502 supplies the event to the document router. The document router inputs it to the document service 1504. The document service 1504 provides an interface for supplying the received document to the enterprise solution software 1505 of the host system. Communication agent 1500 is an Internet interface with a suitable protocol stack that supports protocols such as HTTP, SMTP, FTP, or other protocols. Thus, incoming data can be accepted in XML syntax, ASCII data syntax, or other syntax to suit a particular communication channel. All documents received in non-XML syntax are converted to XML and forwarded to an XML parser. A conversion table 1506 is used to support conversion from non-XML format to XML format.

  The converted document is supplied to the parser 1501. The XML parser parses the XML document according to the document type definition that matches the received XML document. If an error is found, the parser sends the document back to the communication agent 1500. The business interface definition compiler BIDC 1507 functions as a compiler for business interface definition data. The DTD file for the XML parser, the JAVA beans corresponding to the DTD file, and the conversion rule for converting the DTD file into the JAVA beans are created by compiling the BID data. By referring to these tools, an XML instance is converted into a JAVA instance. Accordingly, the BID compiler 1507 stores the DTD document 1508 and generates 1509 a corresponding JAVA document. The XML document is sent to the processor 1502, and the processor 1502 converts the document into a JAVA format. In the preferred system, a JAVA document is generated that has the same status as the document type definition received in XML format. Send the JAVA beans to the document router 1503. Document router 1503 receives the JAVA beans and sends the received classes to the appropriate document service using a registry program (eg, using the event listener architecture described above). A document service 1504 that receives a document in the form of JAVA beans from the router 1503 functions as enterprise solution software. It has a registry service 1510 that combines listeners for XML events with the input data stream, and a service manager 1511 that manages the transmission of input documents to the appropriate service. The document service manager 1511 provides management of a registry service, maintenance of document consistency, and the like.

  The document service communicates with the backend system using any proprietary API or using a common format such as a CORBA / COM interface or other architecture.

  FIG. 16 is a heuristic diagram of the market maker and market participant structure according to the present invention. Therefore, the electronic commerce market according to the present invention can be logically organized as shown in FIG. A market maker node 1600 is set at the top of the organization. The market maker node includes resources for setting the market place 1601. Such resources include market registration services and the like. Business 1602 registers with the marketplace by publishing the business interface definition. The business interface definition defines a service 1603 for a business transaction in which the business participates. Transaction 1604 and service 1603 use document 1605 to define inputs and outputs and outline commercial relationships between participants in the transaction. The document has content 1606 that includes details of each transaction. The manner in which content is processed by market participants and by market makers is entirely dependent on documents based on electronic commerce networks established in accordance with the present invention. Overall, a robust, scalable and intuitive structure is provided so that electronic commerce is possible over a communications network.

  Thus, the present invention provides a platform based on an XML processor and uses XML documents as an interface between loosely coupled business systems in the exemplary system. Documents are transferred between businesses and processed by specific nodes before entering the enterprise business system. Thus, the platform enables a cross-business e-commerce application by identifying a common set of business documents and formats, where each business system uses a different internal commerce platform, processing and semantics. Make available.

According to the present invention, a virtual enterprise is formed by interconnecting a business system and a service. Mainly, a document that is accepted and generated by a business (XML coded) is defined as follows.
“If you ask us for a catalog, we will send you a catalog.” “If you have ordered your purchase and we can accept it, we will send you an invoice.”
The foregoing description of the preferred embodiment of the invention has been made for the purpose of illustrating the invention. This is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. The scope of the invention is defined by the claims and their equivalents.

1 is a schematic diagram of an electronic commerce network including a business interface definition (BID) according to the present invention. FIG. FIG. 3 is a schematic diagram of a business interface definition document according to the present invention. 2 is a conceptual block diagram of a server for a participant node in a network according to the present invention. 6 is a flowchart illustrating processing of a document received by a participant node according to the present invention. FIG. 2 is a block diagram of a parser and transaction processing front end for an XML based system. It is a conceptual diagram of a functional flow of a parser program. It is the schematic of the resource in a server used for the business interface definition which concerns on this invention. FIG. 2 is a schematic diagram of a repository according to the present invention used for building a business interface definition. It is a flowchart for demonstrating the process which builds the business interface definition based on this invention. It provides a heuristic overview of repositories according to the present invention. FIG. 6 is a schematic diagram of server resources providing market maker functions for the network of the present invention based on business interface definitions. It is a flowchart regarding the process of the market maker node of the received document. 4 is a flowchart for explaining a process for registering participants of a market maker node according to the present invention. FIG. 10 is a flowchart for explaining a process of providing service specifications at a market maker node according to the process of FIG. 9. It is a diagram explaining the operation sequence in the market maker or participant concerning the present invention. 2 is a conceptual diagram of elements of a business transaction network based on BID according to the present invention.

Claims (171)

An interface for a transaction between nodes in a network including a plurality of nodes (nodes) for executing processing related to a transaction (transaction),
A machine readable specification for an interface to transaction processing recorded in memory accessible by at least one node in the network, including translation information that provides the definition of the input document and the definition of the output document. And the input and output document definitions comprise an individual description of a set of recording devices and the specification comprising a logical structure for the set of recording devices. The interface of claim 1, wherein the translation information includes a data type specification for at least one logical structure in the input and output document definitions. The translation information includes at least one data structure that maps a predetermined set of recording devices for a particular logical structure in the definition of the input and output documents to individual entries in a list. The interface of claim 1, comprising:   The interface of claim 1, including a library of logical structures and a repository in memory that is accessible by at least one node in the network that records translation information for the logical structures.   The machine-readable specification includes an interface document definition that includes at least one of a logical structure for recording an identifier of a particular transaction and a definition and a reference to the definition of the input and output documents for the particular transaction. The interface of claim 1, including a compliant document.   The machine readable specification includes a logical structure for recording an identifier of an interface and for recording at least one of a set of one or more transaction specifications supported by the interface and a reference to the specification. The interface of claim 1, including a document in accordance with a definition of an interface document to include.   The machine-readable specification includes a reference to a specific transaction specification, and the specific transaction specification records at least one of the input and output document definitions and definitions for the specific transaction. 7. The interface of claim 6, including a document that includes a logical structure for.   The interface of claim 1, wherein the recording device comprises parsed data. The parsed data in at least one of the input and output documents is:
Character data that encodes text characters in one of the input and output documents; and a mark that identifies a set of recording devices according to one logical structure of the input and output documents 9. The interface according to claim 8, further comprising attachment data.   10. The interface of claim 9, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words.   The translation information for at least one of the set of recording devices identified by at least one specific logical structure of the input and output documents encodes a separate definition for the parsed character set. The interface according to claim 8.   9. The interface of claim 8, wherein the recording device comprises unparsed data.   In a network of document types for use in multiple transactions, includes a repository recorded in memory that is accessible by at least one node, and one definition of the input and output documents is a document document in the repository. The interface of claim 1, including a reference to a type.   The method of claim 13, wherein the repository of document types includes a document type for identifying participant processes in the network.   The interface of claim 1, wherein the input and output document definitions comprise document type definitions according to a standard extensible markup language XML.   The interface of claim 1, wherein the machine-readable data structure containing translation information comprises a document organized according to a document type definition according to a standard extensible markup language XML. An apparatus for configuring a participant interface for a transaction to be executed on a system including a network interface and a data processing resource that performs transaction processing of the transaction according to a transaction processing architecture:
A program of instructions executed by the system, recorded on a medium accessible by the system, and providing a tool for constructing a participant interface definition for a participant in a particular transaction, comprising: The definition includes an input document definition for the participant and an output document definition for the participant, wherein the input and output document definition includes an individual machine-readable description of a set of recording devices, and the recording Said program comprising a logical structure for a set of devices; and a data structure recorded on a medium executable by said system and accessible by said system, and corresponding to said set of recording devices, and said transaction processing Before following the architecture For compiling the input document and the logical structure of the output document, for translating the input document to the corresponding data structure, for compiling instructions executable by the system, and for output of the transaction process And a program responsive to the input and output document definitions to compile instructions executable by the system to translate into a set of recording devices and a logical structure of the output document. A device characterized by.   The tool for constructing a participant interface definition includes instructions that are executable by the system to access elements of the definition from a repository, the repository comprising a library of logical structures; 18. The apparatus of claim 17, further comprising: translation information for the logical structure used to construct the interface description.   The apparatus of claim 18, wherein the repository records a definition of a document having a logical structure. The tool for building participant interface definitions is:
For accessing other participant interface definitions for complementary transactions, the accessed definitions including an input document definition for the complementary transaction and an output document definition for the complementary transaction. Instructions executable by the system to set the participant interface definition by including the output document definition of the complementary transaction, such as the input document definition of the interface being constructed. The apparatus of claim 17, comprising: The tool for building participant interface definitions is:
To include the input document definition of the complementary transaction, such as the output document definition of the interface being constructed,
21. The apparatus of claim 20, comprising instructions that are executable by the system.   The tool for building a participant interface definition includes a document according to a participant interface document definition including a logical structure for recording a particular transaction identifier, and inputs and outputs for the particular transaction. The apparatus of claim 17, comprising instructions executable by the system to construct a document definition and at least one of references to the definition.   The tool for constructing a participant interface definition records the identifier of the participant interface and provides a reference to a set of one or more transaction specifications and specifications supported by the participant interface. 18. The instructions of claim 17 including instructions executable by the system to build a document in accordance with a definition of a participant interface document that includes a logical structure for recording at least one of them. apparatus.   The document in accordance with the definition of the participant interface document includes a reference to a machine readable specification of a particular transaction, and the specification of the particular transaction leads to the definition and definition of input and output documents for the particular transaction. 24. The apparatus of claim 23, comprising a document including a logical structure for recording at least one of the references.   The apparatus of claim 17, wherein the recording device comprises parsed data. The parsed data in at least one of the input and output documents is:
Character data that encodes text characters in one of the input and output documents; and a mark that identifies a set of recording devices according to one logical structure of the input and output documents 26. The apparatus of claim 25, further comprising attachment data.   27. The apparatus of claim 26, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words.   The specification includes translation information for at least one of the set of recording devices identified by the logical structure of at least one of the input and output documents, and encodes a separate definition for the parsed character set 26. The apparatus of claim 25.   26. The apparatus of claim 25, wherein the recording device comprises unparsed data.   The apparatus of claim 17, wherein the data structure corresponding to the set of recording devices and the logical structure of the input and output documents comprise programming objects including variables and methods according to a variable transaction processing architecture. .   The apparatus of claim 17, wherein the variable transaction processing architecture of the transaction processing comprises processing according to an interface description language.   The apparatus of claim 17, wherein the input and output document definitions comprise document type definitions according to a standard extensible markup language XML.   The apparatus of claim 19, wherein the definition of one of the input and output documents includes a reference to a document type in a repository.   The apparatus of claim 18, wherein the repository includes translation information identifying a measurement of a product subject of a transaction.   19. The apparatus of claim 18, wherein the repository includes translation information that identifies a product subject cost of a transaction.   The apparatus of claim 18, wherein the repository includes translation information that identifies characteristics of a product subject of a transaction.   The apparatus of claim 18, wherein the repository includes translation information identifying a financial term of a transaction.   19. The apparatus of claim 18, wherein the repository includes translation information that identifies a shipment term for a product subject of a transaction. A device for setting up a participant interface for transactions executed on a system:
A memory for recording instruction data and programs;
A data processor connected to a memory for executing said program of instructions;
A tool for building a participant interface definition for a participant in a particular transaction, wherein the participant interface definition defines an input document definition for the participant and an output document definition for the participant. And wherein the input and output document definitions are responsive to the input and output document definitions; and the tool comprising a separate machine readable description of the set of recording devices and a logical structure for the set of recording devices; And, in order to compile the data structure corresponding to the set of recording devices and the logical structure of the input and output documents according to the transaction processing architecture, the input document is translated into the corresponding data structure. Instructions that can be executed by the system And a compiler for compiling instructions executable by the system to compile and translate the output of the transaction processing into a set of recording devices and a logical structure of the output document. And a data processor.   The tool for building a participant interface definition, including a repository recorded in memory accessible by the data processor, is executable by the system to access elements of the definition from the repository 40. The apparatus of claim 39, comprising instructions, wherein the repository records a library of logical structures and translation information for the logical structures used to construct an interface description.   41. The apparatus of claim 40, wherein the repository records a definition of a document having a logical structure. The tool for building participant interface definitions is:
For accessing other participant interface definitions for complementary transactions, the accessed definitions including an input document definition for the complementary transaction and an output document definition for the complementary transaction. Instructions executable by the system to set the participant interface definition by including the output document definition of the complementary transaction, such as the input document definition of the interface being constructed. 40. The apparatus of claim 39, comprising: The tool for building participant interface definitions is:
43. The apparatus of claim 42, comprising instructions executable by the system to include an input document definition of the complementary transaction, such as the output document definition of a constructed interface. .   The tool for building a participant interface definition includes a document according to a participant interface document definition including a logical structure for recording a particular transaction identifier, and inputs and outputs for the particular transaction. 40. The apparatus of claim 39, comprising instructions executable by the system to construct a document definition and at least one of references to the definition.   The tool for constructing a participant interface definition records the identifier of the participant interface and provides a reference to a set of one or more transaction specifications and specifications supported by the participant interface. 40. The method of claim 39, comprising instructions executable by the system to construct a document in accordance with the definition of a participant interface document that includes a logical structure for recording at least one of the apparatus.   The document in accordance with the definition of the participant interface document includes a reference to a machine readable specification of a particular transaction, and the specification of the particular transaction leads to the definition and definition of input and output documents for the particular transaction. 46. The apparatus of claim 45, comprising a document including a logical structure for recording at least one of the references.   26. The apparatus of claim 25, wherein the recording device comprises parsed data. The parsed data in at least one of the input and output documents is:
Character data encoding text characters in one of the input and output documents; and marking data identifying a set of recording devices according to one logical structure of the input and output documents. The apparatus of claim 47.   49. The apparatus of claim 48, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words.   The specification includes translation information for at least one of the set of recording devices identified by the logical structure of at least one of the input and output documents, and encodes a separate definition for the parsed character set 48. The apparatus of claim 47, wherein:   48. The apparatus of claim 47, wherein the recording device comprises unparsed data.   40. The apparatus of claim 39, wherein the data structure corresponding to the set of recording devices and the logical structure of the input and output documents include programming objects including variables and methods according to a variable transaction processing architecture. .   40. The apparatus of claim 39, wherein the variable transaction processing architecture of the transaction processing comprises processing according to an interface description language.   40. The apparatus of claim 39, wherein the input and output document definitions comprise document type definitions according to a standard extensible markup language XML.   42. The apparatus of claim 41, wherein the definition of one of the input and output documents includes a reference to a document type in a repository.   41. The apparatus of claim 40, wherein the repository includes translation information that identifies a measurement of a product subject of a transaction.   41. The apparatus of claim 40, wherein the repository includes translation information that identifies a product subject cost of a transaction.   41. The apparatus of claim 40, wherein the repository includes translation information that identifies characteristics of a product subject of a transaction.   41. The apparatus of claim 40, wherein the repository includes translation information that identifies a financial term for a transaction.   41. The apparatus of claim 40, wherein the repository includes translation information identifying a shipping term for a transactional product subject. A method for programming a commercial transaction in a network comprising:
Defining a machine readable definition of an input document for a node in a network including resources for performing processing in the transaction, and a machine readable definition of an output document for the node, wherein the input and output document definitions are: And a step of providing a separate description of a set of recording devices and a logical structure for the set of recording devices; and a step of supplying translation information for the logical structure to the node. Method.   62. The method of claim 61, wherein the translation information includes a data type specification for at least one logical structure in the input and output document definitions.   The translation information includes at least one data structure that maps a predetermined set of recording devices for a particular logical structure in the definition of the input and output documents to individual entries in a list. 62. The method of claim 61, wherein the translation information includes a data type specification for at least one logical structure in the input and output document definitions.   The step of providing translation information includes providing a library of logical structures and a repository in memory that is accessible by at least one node in the network that records translation information for the logical structures. 62. The method of claim 61.   Interface document definition including a logical structure for recording an identifier of a specific transaction and a logical structure for recording at least one of definitions and references to the input and output documents for the specific transaction 62. The method of claim 61, comprising defining a machine readable specification of an interface that includes a document according to.   62. The method of claim 61, wherein the recording device comprises parsed data. The parsed data in at least one of the input and output documents is:
Character data encoding text characters in one of the input and output documents; and marking data identifying a set of recording devices according to one logical structure of the input and output documents. 67. The method of claim 66.   68. The method of claim 67, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words.   The translation information for at least one of the set of recording devices identified by at least one specific logical structure of the input and output documents encodes a separate definition for the parsed character set. 68. The method of claim 67.   The method of claim 66, wherein the recording device comprises unparsed data.   68. The method of claim 67, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words.   The translation information for at least one of the sets of recording devices identified by at least one specific logical structure of the input and output documents encodes individual definitions for the set of parsed characters. 68. The method of claim 67.   The method of claim 66, wherein the recording device comprises unparsed data.   62. The method of claim 61, wherein the input and output document definitions comprise document type definitions according to a standard extensible markup language XML. Providing a parser for generating an event signal in response to a logical structure in the definition of the input document; and an event responsive to the event signal to perform the processing 62. A method according to claim 61, comprising providing an event listener program. A method for performing a transaction between nodes in a network including a plurality of nodes performing processing related to a transaction:
Recording a machine readable specification of an interface to a transaction, the specification including an input document definition and an output document definition, wherein the input and output document definition includes a separate description of a set of recording devices and the Said stage comprising a logical structure for a set of recording devices;
Receiving data comprising a document over a communication network; parsing the document according to the specification for identifying an input document;
Providing at least a portion of the input document in machine-readable form to a transaction process that generates output;
Forming an output document with the output according to the definition of the output document based on the specification; and transferring the output document over the communication network. . Accessing a complementary interface specification supplied to other nodes in the network for the transaction, the accessed specification defining an input document for the complementary interface and an output document for the complementary interface; And at least a part of the definition of the output document of the complementary interface in the definition of the input document of the interface in the recorded specification, and the recorded specification of the interface. 74. The method of claim 73, further comprising the step of:   75. The method of claim 74, comprising finding the complementary interface in a network.   The step of setting the recorded specification is accessing a machine-readable specification element from a repository, the repository comprising a library of logical structures, a schematic map for the logical structure, and 75. The method of claim 74, including the step of recording a document definition comprising a logical structure used to construct an interface description.   Setting the recorded specification of the interface by including at least a portion of the definition of the input document of the complementary interface in the definition of the output document of the interface in the recorded specification. 75. The method of claim 74, wherein:   The method of claim 73, comprising providing access to the specification through a communication network to other nodes in the network.   Transmitting the specification of the interface to another node in the network, wherein access to the specification includes the step of being provided to other nodes in the network. 74. The method according to 73.   The machine-readable specification includes an interface document definition that includes at least one of a logical structure for recording an identifier of a particular transaction and a definition and a reference to the input and output documents for the particular transaction. 74. The method of claim 73, comprising a compliant document.   The machine readable specification includes a logical structure for recording an identifier of an interface and for recording at least one of a set of one or more transaction specifications supported by the interface and a reference to the specification. 74. The method of claim 73, comprising a document according to the definition of the containing interface document.   The machine-readable specification includes a reference to a specific transaction specification, and the specific transaction specification records at least one of the input and output document definitions and definitions for the specific transaction. 82. The method of claim 81, comprising a document that includes a logical structure for.   The method of claim 73, wherein the recording device comprises parsed data. The parsed data in at least one of the input and output documents is:
Character data encoding text characters in one of the input and output documents; and marking data identifying a set of recording devices according to one logical structure of the input and output documents. 84. The method of claim 83, characterized in that   85. The method of claim 84, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words.   The specification includes the translation information for at least one of the set of recording devices identified by at least one logical structure of the input and output documents, and encodes a separate definition for the parsed character set 84. The method of claim 83, wherein:   84. The method of claim 83, wherein the recording device comprises unparsed data.   74. The transaction processing has a variable transaction processing architecture and includes translating at least a portion of the input document into a form readable according to the variable transaction processing architecture of the transaction processing. The method described in 1.   90. The method of claim 88, wherein the step of translating includes generating a programming object that includes variables and methods according to the variable transaction processing architecture of the transaction processing.   90. The method of claim 88, wherein the variable transaction processing architecture of the transaction processing comprises processing according to an interface description language.   The method of claim 73, wherein the input and output document definitions comprise document type definitions according to a standard extensible markup language XML.   Providing a repository of document types for use in a plurality of transactions, and wherein the definition of one of the input and output documents includes a reference to a document type in the repository. Item 74. The method according to Item 73.   94. The method of claim 92, wherein the repository of document types includes a document type for identifying participant processing in a network.   94. The method of claim 92, comprising providing a repository of translation information for the logical structure, the translation information identifying transaction parameters. The transaction processing has a variable transaction processing architecture and:
Accessing a complementary interface specification, wherein the accessed specification includes an input document definition for the complementary interface and an output document definition for the complementary interface;
Setting the recorded specification of the interface by including the definition of the output document of the complementary interface, such as the definition of the input document of the interface in the recorded specification; and the definition of the input and output documents In response to the data structure corresponding to the set of recording devices, the logical structure of the input and output documents according to the transaction processing architecture of the transaction processing, and for translating the input document into the corresponding data structure Compiling instructions executable by the system and instructions executable by the system to translate the output of the transaction processing into a format according to the definition of the output document. When 74. The method of claim 73.   96. Setting a recorded specification of an interface by including a definition of the input document of the complementary interface, such as a definition of the output document of the interface in a recorded specification. The method described in 1. The transaction processing has a variable transaction processing architecture, and setting the recorded specifications includes accessing the machine-readable specification elements from a repository, the repository comprising a library of logical structures; Record the schematic map for the logical structure and the definition of the document with the logical structure used to build the interface description; and
In response to the definition of the input and output documents, the data structure corresponding to a set of recording devices and the logical structure of the input and output documents according to the transaction processing architecture of the transaction processing, and the corresponding input document Compile instructions executable by the system for translation into a data structure and instructions executable by the system to translate the output of the transaction process into a format according to the definition of the output document. 74. The method of claim 73, comprising: steps. An apparatus for managing transactions between nodes in a network including a plurality of nodes that perform processing related to transactions:
A network interface;
A memory for recording instruction data and programs, including a machine readable specification of an interface to a transaction, the specification including an input document definition and an output document definition, wherein the input and output document definitions are recorded Said memory comprising an individual description of a set of devices and a logical structure for said set of recording devices;
A data processor coupled to the memory and the network interface for executing a program of instructions; the instruction program; logic for receiving data comprising a document through the network interface;
Logic to parse the document according to the specification for identifying an input document;
Logic for supplying at least a portion of the input document in machine readable form to a transaction process that generates output;
The data processor comprising: logic for forming an output document with the output according to the definition of the output document based on the specification; and logic for transferring the output document over a network interface The apparatus characterized by comprising. Logic for accessing a complementary interface specification, wherein the accessed specification includes an input document definition for the complementary interface and an output document definition for the complementary interface; and a recorded specification Logic for setting the recorded specification of the interface by including the definition of the output document of the complementary interface, such as the definition of the input document of the interface in. Item 99. The apparatus according to Item 98.   The logic for setting the recorded specification includes logic for accessing elements of the machine-readable specification from a repository, the repository including a library of logical structures, a schematic map for the logical structures, and 100. The apparatus of claim 99, wherein the apparatus records a definition of a document having a logical structure used to construct an interface description.   Including logic for setting the recorded specification of the interface by including a definition of the input document of the complementary interface, such as a definition of the output document of the interface in a recorded specification. 100. The apparatus of claim 99.   99. The apparatus of claim 98, comprising logic to provide access to the specification through a communications network to other nodes in the network.   Including logic for transmitting the specification of the interface to another node in the network, wherein access to the specification includes the logic supplied to other nodes in the network. 99. The apparatus of claim 98.   The machine-readable specification includes an interface document definition that includes at least one of a logical structure for recording an identifier of a particular transaction and a definition and a reference to the input and output documents for the particular transaction. 99. The apparatus of claim 98, comprising a compliant document.   The machine readable specification includes a logical structure for recording an identifier of an interface and for recording at least one of a set of one or more transaction specifications supported by the interface and a reference to the specification. 99. The apparatus of claim 98, comprising a document that conforms to the definition of the containing interface document.   The machine-readable specification includes a reference to a specific transaction specification, and the specific transaction specification records at least one of the input and output document definitions and definitions for the specific transaction. 106. The apparatus of claim 105, comprising a document that includes a logical structure for.   99. The apparatus of claim 98, wherein the recording device comprises parsed data. The parsed data in at least one of the input and output documents is:
Character data encoding text characters in one of the input and output documents; and marking data identifying a set of recording devices according to one logical structure of the input and output documents. 108. The apparatus of claim 107, characterized in that 109. The apparatus of claim 108, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words. The specification includes the translation information for at least one of the set of recording devices identified by at least one logical structure of the input and output documents, and encodes a separate definition for the parsed character set 108. The apparatus of claim 107.   108. The apparatus of claim 107, wherein the recording device comprises unparsed data.   99. The transaction processing has a variable transaction processing architecture and includes logic for translating at least a portion of the input document into a form readable in accordance with the variable transaction processing architecture of the transaction processing. The device described in 1.   113. The apparatus of claim 112, wherein the logic for translating includes logic for generating a programming object that includes variables and methods according to the variable transaction processing architecture of the transaction processing.   113. The apparatus of claim 112, wherein the variable transaction processing architecture of the transaction processing includes processing according to an interface description language.   99. The apparatus of claim 98, wherein the input and output document definitions comprise document type definitions according to a standard extensible markup language XML.   Including a memory accessible by a processor that records a repository of document types for use in multiple transactions, and wherein the definition of one of the input and output documents includes a reference to the document type in the repository 99. The apparatus of claim 98, wherein:   117. The apparatus of claim 116, wherein the repository of document types includes a document type for identifying participant processing in a network.   117. The apparatus of claim 116, comprising providing a repository of translation information for a logical structure, the translation information identifying transaction parameters. The transaction processing has a variable transaction processing architecture and:
Logic for accessing a specification of a complementary interface, the accessed specification including an input document definition for the complementary interface and an output document definition for the complementary interface;
Logic to set the recorded specification of the interface by including the definition of the output document of the complementary interface, such as the definition of the input document of the interface in the recorded specification; and the definition of the input and output documents In response to compiling a data structure corresponding to a set of recording devices and a logical structure of the input and output documents according to the transaction processing architecture of the transaction processing, and converting the input document to the corresponding data structure Instructions executable by the system for compiling instructions executable by the system, and for translating the output of the transaction processing into a format according to the definition of the output document 99. The apparatus of claim 98, comprising logic for compiling.   A logic for setting the recorded specification of the interface by including the definition of the input document of the complementary interface, such as the definition of the output document of the interface in the recorded specification. 120. The apparatus according to item 119. The transaction processing has a variable transaction processing architecture and includes logic for setting the recorded specification by accessing elements of the machine readable specification from a repository, the repository being a library of logical structures And a schematic map for the logical structure, and a definition of the document comprising the logical structure used to construct the interface description; and
In response to the definition of the input and output documents, for compiling a data structure corresponding to a set of recording devices and a logical structure of the input and output documents according to the transaction processing architecture of the transaction processing; and The system for translating a document into the corresponding data structure, for compiling instructions executable by the system, and for translating the output of the transaction processing into a format according to the definition of the output document. 99. The apparatus of claim 98, comprising logic for compiling instructions executable by the system. An apparatus for managing transactions between nodes in a network including a plurality of nodes that perform processing related to transactions:
Recording machine readable specifications of a plurality of participant interfaces, wherein the participant interface identifies a transaction, the individual transactions being identified by an input document definition and an output document definition, the input and output document Said definition comprising a separate description of a set of recording devices and a logical structure for said set of recording devices;
Receiving data comprising the document over a communication network; parsing the document according to the specification for identifying the input document and one or more transactions for receiving the identified input document;
Providing at least a portion of the input document in machine readable form for transaction processing associated with the one or more identified transactions.   Providing a repository that records a library of logical structures, a schematic map to the logical structures, and a definition of a document comprising the logical structures used to construct the participant interface description. The method of claim 122.   124. The method of claim 123, comprising providing access to the repository through a communication network to other nodes in the network.   The machine readable specification includes a logical structure for recording an identifier of a particular transaction, and at least one of a definition and a reference to the definition of the input and output documents for the particular transaction. The method of claim 122, comprising a document according to the definition.   The machine readable specification is for recording an identifier of a participant interface, and for recording at least one of a set of one or more transaction specifications supported by the participant interface and a reference to the specification. 123. The method of claim 122, comprising a document that conforms to the definition of an interface document that includes a logical structure of:   The document according to the definition of the participant interface document includes a reference to a specific transaction specification, and the specific transaction specification includes a reference to the definition and definition of the input and output documents for the specific transaction. 127. The method of claim 126, comprising a document including a logical structure for recording at least one of the following.   The method of claim 122, wherein the recording device comprises parsed data. The parsed data in at least one of the input and output documents is:
Character data encoding text characters in one of the input and output documents; and marking data identifying a set of recording devices according to one logical structure of the input and output documents. 129. The method of claim 128, wherein:   110. The method of claim 109, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words.   The specification includes the translation information for at least one of the set of recording devices identified by at least one logical structure of the input and output documents, and encodes a separate definition for the parsed character set 131. The method of claim 130, wherein:   131. The method of claim 130, wherein the recording device comprises unparsed data. Providing at least a portion of the input document in machine readable form for transaction processing associated with one or more identified transactions includes performing routing processing according to a processing architecture, and:
In response to the definition of the input and output documents in the participant interface, a data structure corresponding to the set of recording devices, a logical structure of the input and output documents according to the transaction processing processing architecture, and the input 123. The method of claim 122, comprising compiling instructions executable by the system to translate a document into the corresponding data structure.   Providing at least a portion of the input document in machine readable form to a transaction process associated with one or more identified transactions includes performing a routing process in accordance with a processing architecture; and at least a portion of the input document. 123. The method of claim 122, comprising translating a file into a form readable according to the processing architecture.   135. The method of claim 134, wherein the step of translating includes generating a programming object that includes variables and methods according to the processing architecture of the routing process.   Providing at least a portion of the input document in machine-readable form for transaction processing associated with one or more identified transactions includes routing the portion of the input document to the identified transactions. The method of claim 122.   The method of claim 136, wherein the routing step includes transmitting the input document on a communication network to a node executing one of the identified transactions.   The method of claim 122, wherein the input and output document definitions comprise document type definitions according to a standard extensible markup language XML.   140. The method of claim 138, wherein the participant interface specification comprises a document definition according to a document type definition according to a standard extensible markup language XML.   The repository includes a standardized document type for use in multiple transactions, and the definition of one of the input and output documents includes a reference to a standardized document type in the repository. The method of claim 122.   141. The method of claim 140, wherein the repository includes a standardized document type for identifying participant processing in a network.   143. The method of claim 140, comprising providing a repository of translation information for a logical structure, the translation information identifying transaction parameters.   The transaction processing each having one of a plurality of variable transaction processing architectures and translating at least a portion of the input document into a form readable according to the variable transaction processing architecture of the individual transaction processing; 123. The method of claim 122, further comprising: routing the translated portion to the individual transaction process.   144. The method of claim 143, wherein the translating step includes generating a programming object that includes variables and methods according to the variable transaction processing architecture of the individual transaction processing.   145. The method of claim 144, wherein the variable transaction processing architecture of the transaction processing comprises processing according to an interface description language. An apparatus for managing transactions between nodes in a network including a plurality of nodes that perform processing related to transactions:
A network interface;
A memory for recording instruction data and programs, including a machine readable specification of a plurality of participant interfaces, wherein the participant interfaces identify transactions, and the individual transactions are input document definitions and output document definitions. And said input and output document definitions are said memory comprising a separate description of a set of recording devices and a logical structure for said set of recording devices;
A data processor coupled to the memory and the network interface for executing a program of instructions; the instruction program; logic for receiving data comprising a document through the network interface;
A logic for parsing the document according to a specification for identifying the input document and one or more transactions for receiving the identified input document; and at least a portion of the input document in machine-readable form, And a data processor including logic for providing transaction processing associated with the one or more identified transactions.   Recorded in a memory accessible by the data processor that records a library of logical structures, a schematic map for the logical structures, and a definition of a document comprising the logical structures used to construct the participant interface description. 147. The apparatus of claim 146, comprising a repository.   Access a repository stored in memory through a network interface that records a library of logical structures, a schematic map to the logical structures, and a definition of a document with the logical structures used to build the participant interface description. 147. The apparatus of claim 146, comprising logic for.   The machine readable specification includes a logical structure for recording an identifier of a particular transaction, and at least one of a definition and a reference to the definition of the input and output documents for the particular transaction. 147. The apparatus of claim 146, comprising a document according to the definition.   The machine readable specification is for recording an identifier of a participant interface, and for recording at least one of a set of one or more transaction specifications supported by the participant interface and a reference to the specification. 147. The apparatus of claim 146, comprising a document according to an interface document definition that includes   The document according to the definition of the participant interface document includes a reference to a specific transaction specification, and the specific transaction specification includes a reference to the definition and definition of the input and output documents for the specific transaction. 161. The apparatus of claim 150, comprising a document that includes a logical structure for recording at least one of the following.   147. The apparatus of claim 146, wherein the recording device comprises parsed data. The parsed data in at least one of the input and output documents is:
Character data encoding text characters in one of the input and output documents; and marking data identifying a set of recording devices according to one logical structure of the input and output documents. 153. Apparatus according to claim 152, characterized in that   154. The apparatus of claim 153, wherein at least one of the set of recording devices encodes a plurality of text characters that provide natural language words.   The specification includes the translation information for at least one of the set of recording devices identified by at least one logical structure of the input and output documents, and encodes a separate definition for the parsed character set 156. The apparatus of claim 154, wherein:   155. The apparatus of claim 154, wherein the recording device comprises unparsed data. Logic for providing at least a portion of the input document in machine readable form to transaction processing associated with one or more identified transactions includes routing processing according to a processing architecture, and:
In response to the definition of the input and output documents in the participant interface, to compile the data structure corresponding to the set of recording devices and the logical structure of the input and output documents according to the transaction processing processing architecture. 147. and an apparatus for compiling said input document with instructions executable by said system for translating said input document into said corresponding data structure.   Logic for providing at least a portion of the input document in machine readable form to transaction processing associated with one or more identified transactions includes a routing process according to a processing architecture, and: 147. The apparatus of claim 146, comprising logic for translating at least a portion into a form readable according to the processing architecture.   159. The apparatus of claim 158, wherein the logic for translating includes generating a programming object that includes variables and methods according to a processing architecture of the routing process.   Logic for supplying at least a portion of the input document in machine readable form to transaction processing associated with one or more identified transactions is for routing the portion of the input document to the identified transactions. 147. The apparatus of claim 146, comprising a plurality of routers.   163. The apparatus of claim 160, wherein the router includes logic to send the input document on a network interface to a node that executes one of the identified transactions.   147. The apparatus of claim 146, wherein the input and output document definitions comprise document type definitions according to a standard extensible markup language XML.   163. The apparatus of claim 162, wherein the participant interface specification comprises a document definition according to a document type definition according to a standard extensible markup language XML.   The repository includes a standardized document type for use in multiple transactions, and the definition of one of the input and output documents includes a reference to a standardized document type in the repository. 148. The apparatus of claim 147.   148. The apparatus of claim 147, wherein the repository includes a standardized document type for identifying participant processing in a network.   The transaction processing each having one of a plurality of variable transaction processing architectures, and for translating at least a portion of the input document into a form readable according to the variable transaction processing architecture of the individual transaction processing; and 147. The apparatus of claim 146, comprising logic for routing the translated portion to the individual transaction process.   171. The apparatus of claim 166, wherein the logic for translating generates a programming object that includes variables and methods according to the variable transaction processing architecture of the individual transaction processing.   166. The apparatus of claim 166, wherein the variable transaction processing architecture of the transaction processing comprises processing according to an interface description language.

Images