CN100388292C - Business document in trading partner network and interface definition based on the document - Google Patents

Abstract

Machine-readable documents connect businesses with customers, suppliers, and trading partners. Custom electronic documents, such as XML-based documents, are easily understood between trading partners. The definitions for these e-commerce documents are referred to as business interface definitions, which are published on the internet, or elsewhere in communication with the network members. The business interface definition tells potential trading partners the services that the company offers and the documents that are used when communicating with those services. Thus, a generic business interface definition allows a customer to order by placing a purchase order or a supplier to check the available amount by downloading an inventory status report. In addition, input and output documents are compiled coupled with interpretive information in a common business repository, programming transactions in a manner that is near parallel to the operation of paper enterprises.

Description

Business documents in the trading partner network and interface definitions based on the documents

Background of the invention

field of invention

The present invention relates to systems and protocols that support transactions between different clients connected to a network, and more particularly to systems and protocols that support commerce between platforms with different architectures.

Description of related technologies

The Internet and other communication networks provide means of communication between humans and various computer platforms that are being used in a wide variety of transactions, including commerce in which participants buy and sell goods and services. Efforts are being made to facilitate commerce on the Internet. However, in the face of many competing standards, in order to execute a transaction, the parties must agree in advance on the protocol to be used, and often require custom integration of the platform architecture to support these transactions. Business processes internal to a particular site that are not compatible with agreed standards may require substantial rework to integrate with other sites. In addition, when a company submits one standard or another, the company falls into a given group of standards with respect to the parties to the transaction, to the exclusion of others.

Tenenbaum et al. provide a good overview of the challenges encountered in the development of Internet commerce in "Eco Systems: Internet Commerce Architecture," published in the May 1997 issue of Computers, pp. 48-55.

In order to conduct business activities on the Internet, the architectural framework needs to be standardized. Platforms developed to support such commerce frameworks include IBM Commerce Point, Microsoft Internet Commerce Framework, Netscape ONE (Open Network Environment), Oracle NCA (Network Computing Architecture), and Sun/JAVASoft JECF (JAVA Electronic Commerce Framework).

In addition to these patent frameworks, programming techniques such as the Common Distributed Object Model based on CORBA IIOP (Common Object Request Broker Architecture Internet ORB Protocol) are being researched. The intent of using a common distributed object model is to simplify the migration of systems from enterprise systems to systems that can work together at the business application level of e-business. However, a user or business using one framework cannot transact on another framework. This limits the growth of e-commerce systems.

A company that implements a certain framework will have an application programming interface API that is distinct from the APIs that support other frameworks. Therefore, it is difficult for a company to access other transaction processing services without requiring a common business system interface. Developing such business system interfaces at the API level requires significant cooperation between the parties involved, which is often unrealistic.

Therefore, it is desirable to provide a framework that facilitates the interaction between different platforms in a communication network. Such a system should facilitate spontaneous trade between trading partners, without the need for custom integration or prior agreement on industry-wide standards. In addition, such systems should encourage ways to increase business automation to avoid the time-consuming, high-cost and high-risk shortcomings of traditional system integration.

In general, it is desirable to provide an e-commerce system that replaces a closed network of trading partners based on proprietary standards with an open marketplace.

Contents of the invention

The present invention provides an infrastructure that connects businesses with customers, suppliers and trading partners. Under the infrastructure of the present invention, companies exchange information and services in custom, machine-readable documents, such as documents based on Extensible Markup Language XML, that are easily understood among trading partners. In this paper, the document used to describe the document being exchanged is called the business interface definition BID, such document is published on the Internet, or communicates with network members elsewhere. The business interface definition tells potential trading partners the services the company provides, and the documents to use when communicating with such services. Thus, a generic business interface definition allows a customer to place an order by issuing a purchase order conforming to a document definition published in a party's BID in order to receive the purchase order. Allows suppliers to check availability by downloading inventory status reports that comply with document definitions published in the BID of a business system used to manage inventory data. Using predetermined, machine-readable business documents provides a more intuitive and flexible method of accessing enterprise applications.

According to the present invention, a network point in a business network establishes a transaction interface, which includes a machine-readable interface specification and a machine-readable data structure, wherein the machine-readable interface specification includes a machine-readable interface specification explanation information. The machine-readable interface specification includes the definition of the input document and the definition of the output document, which are accepted and generated by the transaction process that the network node acts as the interface. For example, according to standard XML-based documents, the definition of input and output documents includes a description of each set of storage units and the logical structure of each set of storage units. According to various aspects of the invention, machine-readable data structures including interpretation information include data type specifications (e.g., strings, arrays, etc.) for logical structures in input and output document definitions, content models for logical structures (e.g., list of values), and/or a data structure that maps predetermined groups of storage units of a particular logical structure to individual entries of a list to provide a semantic definition of the logical structure (e.g., mapping code to a product name).

According to other aspects of the invention, the interface includes a memory repository accessible by at least one node in the network, which stores a repository of logical structures and interpretation information of the logical structures. The 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 sites in the network.

Thus, the participants in the transaction framework of the invention carry out transactions between nodes of a network comprising a plurality of nodes which carry out the processes contained in the transactions. A method is to store a machine-readable interface specification for a transaction, the specification including a definition of an input document and a definition of an output document. The definition of input and output documents includes a description of each set of storage units and the logical structure of each set of storage units. In a preferred system, the expression of the definition complies with the standard XML document type definition DTD, and can be extended by performing semantic mapping, content modeling and data classification on some elements. Transaction participants receive data, including documents, over a communication network. A participant parses a document against the specification stored for a transaction in order to identify the input document for that transaction. Following parsing of the document, at least a portion of the input document is provided in a machine-readable format to a transaction process to produce an output. An output document is formed according to the definition of the output document in the stored specification, and the output document includes the output of the transaction process. Typically, output documents are sent back to the source of the input documents over a communications network, or elsewhere as appropriate for a particular type of transaction.

Thus, the business interface definition bridges the gap between documents specified, for example, in terms of XML, and programs executed on the front end of a transaction service at a particular site. Such front ends may be implemented, for example, by a JAVA virtual machine or by other common architectures that provide system interconnection over a network. The business interface definition provides a technique by which transaction protocols can be designed using a business interface definition document. A transaction protocol program can be established with a detailed formal specification of the document type.

The machine-readable transaction interface specification can be accessed by other platforms in the network. The participant platform includes resources for designing input documents and output documents according to transaction interfaces specified on a complementary web site. Thus, a participant node includes resources for accessing input document definitions of complementary interfaces as well as output document definitions of complementary interfaces. A stored specification for an access participant site is built by including at least a portion of an output document definition for a complementary interface in an input document definition for an interface stored in the specification.

According to another aspect of the invention, the process for building a stored specification of an interface includes accessing elements of the machine-readable specification to a repository. The resource library stores a library consisting of logical structures, content models, schematic diagrams of logical structures, and definitions of documents, wherein the documents include logical structures used to build interface descriptions. A resource library accessible on the network makes it easy to create interface descriptions, and interface descriptions are easily shared. Any differences between input documents built for a particular process and output documents expected to be returned by complementary processes are easily negotiated through network communication and agreement on a common logical structure in order to express particular information.

According to one aspect of the invention, a machine-readable transaction interface specification includes a document conforming to the definition of an interface document shared among members of the network. The interface document definition includes logical structures for storing an identifier for a particular transaction and at least one of a definition and a reference to a definition of input and output documents pertaining to the particular transaction. That is, the interface description for a particular service can actually include the definition of input and output documents. Alternatively, include a pointer to a location in the repository or elsewhere in the network for such a definition.

According to another aspect of the invention, the machine-readable specification includes a business interface definition BID document conforming to the interface document definition, and the interface document definition includes logical structures for storing identifiers of interfaces and storing information about At least one of a specification and a reference to a specification of one or more transaction groups of transactions supported by the interface. For each supported transaction, the document includes at least one of a definition and a reference to the definition of the input and output documents for the particular transaction.

According to another aspect of the present invention, according to the logical structure of the input and output documents, the storage units defined in the input and output document definitions include data for parsing, which in turn includes character data encoding text characters, and Tag data used to identify groups of memory cells. According to another aspect of the invention, at least one set of memory cells encodes a plurality of text characters providing natural language words. This facilitates the use of input and output document definitions by human readers and developers of such documents.

According to another aspect of the invention, the input and output specifications include interpretation information for at least one of the plurality of sets of memory cells identified by the logical structure. In one example, the interpretation information encodes the definition of each set of analyzed characters. In another example, the interpretation information provides a conceptual model specification, such as requiring a specific logical structure to carry a member in a manifest of code mapped to a product description of a catalog. In some systems, storage units within the logical structure of a document include as many sets of unanalyzed data as are required by a particular implementation.

According to another aspect of the invention, a transaction process in a particular platform has a transaction architecture that is one of a plurality of different transaction architectures. Thus, depending on the transaction architecture of the transaction process using the information, the participant site includes resources for translating at least a portion of the input document into a readable format. According to the different transaction processing architectures of the transaction processing process, the elements defined by the document are translated into programming objects including many variables and methods. For participants with a JAVA virtual machine acting as the front end of the transaction process, specific fields in the document are translated into JAVA objects, including data and get and set functions related to the JAVA objects. Other transaction processing architectures supportable by the present invention include procedures conforming to an interface description language in the sense of Common Object Request Broker Architecture CORBA, Component Object Model COM, Online Transaction Processing OLTP and Electronic Data Interchange EDI.

According to other aspects of the present invention, a repository is provided that stores document types used in transactions. A machine-readable specification of a particular transaction defines at least one of an input document and an output document by reference to a document type of a repository. According to another aspect, the document types contained in the repository include document types for identifying network participants. This type of document provides structures for identifying actors, for specifying the services that actors support, and for specifying the input and output documents for each service.

In addition to the above method, the present invention provides a device for managing transactions between network points, which device includes a network interface; a memory for storing data and instruction programs, including the above-mentioned machine-readable transaction interface specification; and data Processor, which is connected to memory and network interface. The program of instructions stored in the device includes logic circuits to perform the above-described processes for the transaction participants.

The present invention also provides a device for establishing a participant interface for transactions executed on the system, wherein the participant interface includes network interfaces and data processing resources, and executes transaction processing processes according to the transaction processing architecture. The apparatus includes a program of instructions executable by the system and stored on a medium accessible to the system, the program of instructions providing the means to establish a participant interface definition for a particular transaction participant. Actor interface definitions include input document definitions and output document definitions. The input and output document definitions include a machine-readable description of each set of storage units and the logical structure of each set of storage units. According to one aspect of the present invention, each set of storage units and the logical structure of each set of storage units conform to the XML document type definition .

In accordance with this aspect of the invention, the apparatus for establishing a participant interface further includes a program of instructions stored on a medium accessible to the data processing system and responsive to input and output document definitions for compiling and storing sets of units and A data structure corresponding to the logical structure of the input and output documents, where the group of storage units and the logical structure of the input and output documents follow the transaction processing architecture; used to compile system-executable instructions to translate the input documents into the corresponding data structures ; and compile system-executable instructions for translating the output of the transaction process into logical structures of groups of storage units and output documents.

In a preferred embodiment, the means for establishing the participant interface definition includes system-executable instructions for accessing elements of the definition from a supplemental network site and/or a repository storing elements defined by the logical structure As well as a library of logical structure interpretation information used to create interface descriptions. According to various aspects of the invention, the resource repository includes not only a repository of logical structures, but also document definitions containing logical structures, and formats for specifying participant interfaces. According to this aspect of the invention, tools are provided for building business interface specifications based on the techniques described above, combined with descriptions of participant sites. The tools for building the interface and the tools for compiling the interface into the repository required to communicate with the transaction processing architecture according to this aspect of the invention are implemented in the participant node of the preferred embodiment. Also, these tools can be used to develop and optimize interface descriptions as the usage of the network grows according to the interface descriptions that define the input and output documents.

Accordingly, another aspect of the invention provides an apparatus comprising a memory and a data processor, wherein the data processor is operable to execute instructions stored in the memory, the instructions including means for establishing a participant interface definition and for A compiler that performs the above functions.

In accordance with another aspect of the invention, market maker sites are enabled using participant interface descriptions. At such a site, there is provided a method for managing transactions, the method comprising storing a machine-readable specification of a multi-participant interface, the specification identifying the transactions supported by the interface, and the Input and output documents. As mentioned above, the definition of input and output documents includes a description of each set of storage units and the logical structure of each set of storage units, such as according to the XML standard. In addition, both the transaction definition and the participant interface definition include documents specified according to a technology that follows XML or other standardized document expression language. On such a market maker site, the data of the document is contained via a communication network interface. The document is parsed according to the specification to identify input documents for one or more transactions that accept the identified input documents. At least a portion of the input document is provided to a transaction processing process associated with the one or more identified transactions in a machine-readable format. The step of providing at least a portion of the input document to the transaction process includes performing a routing process at the market maker site according to the processing architecture. According to a particular processing architecture, the routing process of one aspect of the present invention is executed and at least a portion of the input document is translated into the format of the processing architecture of the routing process. The translating step according to the preferred embodiment includes generating a programming object containing a method of a number of variables according to the processing architecture of the routing process.

According to another aspect of the present invention, the market maker site also supports a repository structure. Accordingly, a process is provided on the market maker site for allowing participants in the network to access the repository stored on the market maker site. As mentioned above, the repository includes definitions of logical structures, interpretation information, and document definitions used by participant sites to build transaction interface documents, and the repository includes instances of business interface definitions used to identify participants, and each participant implements affairs.

Depending on the circumstances, the routing process includes translating the input document into a different processing architecture for the process to which the document is to be sent, or sending the input document over the network in the original document format to a remote processing site, or to the A combination of class handling. In another case, the routing process may also include the technique of translating an input document defined according to one input document definition into a different document defined according to a different process document specification, wherein the process document specification Indicates that it has already checked in to wait for this input document.

Furthermore, according to the present invention a market maker site is provided as a device comprising a network interface, a memory and a data processor. The memory is used to store data and instruction programs, and the instruction programs include specification descriptions of participant interfaces. The logic circuit is provided with a data processor in the form of a program of instructions, or executes the market maker process as described above.

Thus, the present invention provides the basis for electronic transactions based on the principle of sharing input and output document specifications. Documentation provides an intuitive and flexible approach to accessing transactional services that is easier to implement than a programmatic API. It is easier to interconnect companies through exchanged documents on which the companies have largely agreed, rather than through always different business system interfaces. Additionally, in the preferred embodiment, such documents are specified in a human-readable format. According to the invention, the business interface is specified in a document, such as an XML document, which is easily interpreted by a human or computer.

Using the document-based transaction architecture of the present invention, including the use of a parser, the parser works in essentially the same way for any document source. Doing so greatly reduces the need for custom programs for extracting and integrating information from each participant in the network. Therefore, enterprise information generated by accounting, purchasing, manufacturing, shipping, and other functions can be integrated through the following steps. The steps are first to convert each source according to the invention into a document with an architecture, and then to process the data stream for parsing. Each outlet in the system that participates in the market needs only to know the format of its internal system, and the format of the documents specified for the exchange according to the transaction. Thus, there is no need to generate a local format for every other site wishing to participate in the e-commerce network.

For complete business integration, the present invention provides a resource library with standardized logical structure (similar to XML elements), attributes or metadata, and establishes a semantic language for specific business groups. The invention also provides a means for mapping between different metadata descriptions, and a server for processing documents and invoking appropriate applications and services. In accordance with the present invention, the basic building blocks of a network include business interface definitions, which tell potential trading partners what online services a company provides, and which documents to use to invoke the services; servers, which provide a bridge between internal and external transaction services; Groups are bound together, thus creating a trade group. The role of the server is to parse the input document and invoke the appropriate service. In addition, the server of the present invention undertakes the task of translating the received and sent document formats into the formats of each host system. Therefore, trading partners only need to agree on the structure, content and sequence of the business documents to be exchanged, and do not need to agree on the details of the application programming interface. How documents are handled and the actions that result from receipt of documents are strictly at the discretion of the business providing the services. This elevates integration from the system level to the enterprise level. This allows a business to present a clear and stable interface to its adversaries regardless of changes in its internal technical implementation, organization or processes.

The overall process of establishing business interface definitions and enabling servers to manage business activities based on these descriptions is facilitated by the use of a common business library or resource library that includes information models of general business concepts, such as companies, services, Business description primitives such as and products, business forms such as catalogs, purchase orders, and invoices, and standard metrics including time and date, location, and item classification.

Other aspects of the invention will become apparent from the drawings, detailed description, and claims that follow.

Figure overview

Fig. 1 is a simplified diagram showing an electronic commerce network including a business interface definition BID according to the present invention.

Figure 2 is a simplified diagram illustrating a business interface definition document in accordance with the present invention.

Figure 3 is a conceptual block diagram illustrating a server at a participant site in the network of the present invention.

FIG. 4 is a flowchart illustrating the processing of received documents at a participant site in accordance with the present invention.

Figure 5 is a block diagram showing a parser and transaction processing front end for an XML-based system.

Fig. 6 is a conceptual diagram showing the flow of an analysis function.

Figure 7 is a simplified diagram showing the server resources used to build the business interface definitions of the present invention.

Figure 8 is a simplified diagram illustrating the resource library used to create business interface definitions in accordance with the present invention.

Fig. 9 is a flowchart illustrating the process of creating a business interface definition in accordance with the present invention.

Figure 10 provides a heuristic look at the repository of the present invention.

Figure 11 is a simplified diagram showing the resources of the server providing the market maker functionality for the network of the present invention according to the business interface definition.

Fig. 12 is a flowchart showing the market maker site processing of receiving documents.

FIG. 13 is a flowchart illustrating the process of enrolling participants at a market maker site in accordance with the present invention.

FIG. 14 is a flowchart of the process of providing service specification at a market maker site in accordance with the process of FIG. 9. FIG.

Figure 15 is a schematic diagram showing the sequence of operations at a participant or market maker site in accordance with the present invention.

Fig. 16 is a conceptual diagram showing BID-based business network elements according to the present invention.

A detailed description

The invention is described in detail with reference to the accompanying drawings, in which Figure 1 shows a network of market participants and market makers based on the use of business interface definitions and support for input and output documents specified in accordance with such interface descriptions Trading. The network comprises a plurality of sites 11-18 interconnected by a communications network such as the Internet 19 or other telecommunications or data communications network. Each site 11-19 includes a computer, such as a laptop computer, desktop personal computer, workstation, system network, or other data processing resource. A network node includes a memory for storing business interface definitions; a processor for executing transaction processing procedures for conducting business transactions with other network nodes in the network; and computer programs executed by the processors that support these services. In addition, each site includes a network interface for providing communication with the Internet 19 or other communication networks.

In the context of Figure 1, the nodes 11, 12, 14, 16 and 18 represent market participants. Market participants include consumers or suppliers of goods or services that are to be established in accordance with the business process transactions of the present invention.

In this example, sites 15 and 17 are market maker sites. The Market Maker Site includes a resource for registering business interface definitions, called the BID Registry. Participants are able to send documents to the market maker site where they are identified and communicated to the appropriate participants registered to receive these documents as input. The market maker also maintains a repository of standard forms to facilitate the business network, where the repository of standard forms constitutes a common business repository for building business interface definitions.

In this example, the market participants 18 are directly connected to the market maker 17 and not via the Internet 19 . This direct connection to market makers means that the network structures supporting commercial transactions can be varied, including public networks such as the Internet 19, and private connections such as local area networks, or as shown between network points 17 and 18. Point-to-point connection. Actual communication networks vary widely and are applicable to the business transaction network of the present invention.

Fig. 2 is a heuristic diagram showing the nested structure in the Business Interface Definition BID established for market participants in the network of the present invention. The business interface definition shown in FIG. 2 is a data structure including logical structures and storage units arranged in the form definition of a document structure (such as XML document type definition DTD). The structure of Figure 2 includes a first logical structure 200 for identifying a party. Associated with the logical structure 200 are nested logical structures for carrying a name 201 , a physical address 202 , a network address or unit 203 , and a set of service transactions 204 . For each transaction in the service group, provide an interface definition, including transaction BID 205, transaction BID 206 and transaction BID 207. Within each transaction BID, such as transaction BID 205, a logical structure is provided for containing a name 208, a location on the network for the service 209, an operation to be performed by the service 210, and a set of inputs represented by labels 211 document. Additionally, service BID 205 includes a set of output documents represented by tags 212. Input document set 211 includes a business interface definition for each input document to which the service responds, including input document business interface definitions 213 , 214 and 215 . Each input document business interface definition includes a name 216, a location on the network where the document description can be found 217, and the modules carried in the document as indicated by field 218. Similarly, output document group 212 includes interface definitions of 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 on the network or elsewhere 223, and a document module 224 are specified. The business interface definitions of the actors shown in Figure 2 include the actual definitions of the logical structures that will be used for the input and output documents of the various services, or pointers or other references where these definitions can be found.

In a preferred system, the documents of Figure 2 are listed in an XML Document Type Definition DTD, although other document definition structures may be used. In addition, the transaction BID, the input document BID and the output document BID are all specified according to the XML document type definition. An XML-type document is an example of a system based on analyzing data including markup data and character data. Markup data identifies logical structure within a document, and character data sets identify logically structured content. In addition, the documents carry unanalyzed data and are used for various purposes. See, for example, the Extensible Markup Language XML 1.0 REC-XML-19980210 specification published by the WC3 XML Working Group at WWW.W3.ORG/TR/1998/REC-XML-19980210.

Thus, in an exemplary system, participant sites in the network create virtual corporations by interconnecting business systems and services with XML-encoded documents received and generated by business activities. For example a business interface definition for a particular service establishes the following: If a document is received that matches the BID of the requested catalog entry, then a document matching the BID of the catalog entry will be returned. Additionally, if a document is received that matches the order BID and is acceptable to the receiving terminal, then the document that matches the invoice will be returned. Sites in the network process the XML documents before they are imported into the local business systems that are built upon the various transaction structures of any given system in the network. Thus, the system unpacks related sets of documents (such as MIMI-encoded sets of XML documents), analyzes them, and produces a stream of "marked messages". Messages are delivered to suitable applications and services, for example using the event listener model described below.

Documents exchanged between business services are encoded in XML language, where XML language is established by a resource library of building blocks. It is a common business language, and more complex document definitions can be established in this language. The repository stores interpretive information modules, focusing on functions and information common to the business world, including business description primitives such as companies, services, and products; business forms such as catalogs, orders, and invoices; and standard metrics such as addresses such as time and date ; classification codes; and other things that provide interpretation information for the logical structure in an XML document.

A business interface definition is a high-level document that acts as a pattern for designing the interface of a transaction document according to the present invention. Thus, the business interface definition bridges the gap between XML-specified documents and programs executed on the front end of a transaction processing service at a particular site. These front ends can be implemented using JAVA virtual machines or other common structures that interconnect systems over a network. Thus, the business interface definition provides a technique by which a transaction processing protocol can be programmed using a business interface definition document. Procedures for establishing transaction protocols are specified in a documented, detailed form.

The following describes an example of a business interface definition BID based on a market participant document, wherein the market participant document conforms to the XML format. The Market Participant DTD groups the business information of a Market Participant, associating contact and address information with a description of a service and amount information. This business information includes names, codes, addresses, sub-categories to describe business establishments, and pointers to business terms. Additionally, the service identified by the Market Participant DTD will specify the input and output documents to which the Participant is expected to respond and generate. Accordingly, the following are documents that formulate schemas for Market Participant DTDs, Services DTDs, and Transaction Document DTDs (specified in XML) in an exemplary common business language, including illustrative comments.

Examples of Market Participants

<! DOCTYPE SCHEMA SYSTEM ″bidl. dtd″>

<SCHEMA>

  <H1>Market Participant Sample BID</H1>

<META

WHO.OWNS="Veo Systems" WHO.COPYRIGHT="Veo Systems"

WHEN.COPYRIGHT="1998" DESCRIPTION="Sample BID"

WHO.CREATED="*" WHEN.CREATED="*"

WHAT.VERSION="*" WHO.MODIFIED="*"

WHEN.MODIFIED="*" WHEN.EFFECTIVE="*"

WHEN.EXPIRES="*" WHO.EFFECTIVE="*"

WHO.EXPIRES="*">

</META>

<PROLOG>

<XMLDECL STANDALONE=″no″></XMLDECL>

<DOCTYPE NAME="market.participant">

<SYSTEM>markpart.dtd</SYSTEM></DOCTYPE>

</PROLOG>

DTD NAME="markpart.dtd">

  <H2>Market Participant</H2>

  <H3>Market Participant</H3>

<ELEMENTTYPE NAME="market. participant">

<EXPLAIN><TITLE>A Market Participant</TITLE>

<SYNOPSIS>A business or person and its service interfaces.</SYNOPSIS>

<P>A market participant is a document definition that is created to describe a business

and at least one person with an email address, and it presents a set of pointers to service

interfaces located on the network. In this example, the pointers have been resolved and the

complete BID is presented here.</P></EXPLAIN>

<MODEL><CHOICE>

<ELEMENT NAME="business"></ELEMENT>

<ELEMENT NAME="person"></ELEMENT>

</CHOICE></MODEL></ELEMENTTYPE>

  <H3>Party Prototype</H3>

<PROTOTYPE NAME="party">

<EXPLAIN><TITLE>The Party Prototype</TITLE></EXPLAIN>

<MODEL><SEQUENCE>

<ELEMENT NAME="party.name" OCCURS="+"></ELEMENT>

<ELEMENT NAME="address.set"></ELEMENT>

</SEQUENCE></MODEL>

</PROTOTYPE>

  <H3>Party Types</H3>

<ELEMENTTYPE NAME="business">

<EXPLAIN><TITLE>A Business</TITLE>

<SYNOPSIS>A business(party)with a business number attribute.</SYNOPSIS>

<P>This element inherits the content model of the party prototype and adds a business

number attribute, which serves as a key for database lookup. The business number may be used

as a cross-reference to/from customer id, credit limits, contacts lists, etc.</P></EXPLAIN>

<EXTENDS HREF="party">

<ATTDEF NAME="business. number"><REQUIRED></REQUIRED></ATTDEF>

</EXTENDS>

</ELEMENTTYPE>

  <H3>Person Name</H3>

<ELEMENTTYPE NAME="person">

<EXPLAIN><TITLE>A Person</TITLE></EXPLAIN>

<EXTENDS HREF="party">

<ATTDEF NAME="SSN"><IMPLIED></IMPLIED></ATTDEF>

</EXTENDS>

</ELEMENTTYPE>

  <H3>Party Name</H3>

<ELEMENTTYPE NAME="party.name">

<EXPLAIN><TITLE>A Party’s Name</TITLE>

<SYNOPSIS>A party’s name in a string of character.</SYNOPSIS></EXPLAIN>

<MODEL><STRING></STRING></MODEL>

</ELEMENTTYPE>

<H3>Address Set</H3>

<ELEMENTTYPE NAME="address.set">

<MODEL><SEQUENCE>

<ELEMENT NAME="address.physical"></ELEMENT>

<ELEMENT NAME="telephone" OCCURS="*"></ELEMENT>

<ELEMENT NAME="fax" OCCURS="*"></ELEMENT>

<ELEMENT NAME="email" OCCURS="*"></ELEMENT>

<ELEMENT NAME="internet" OCCURS="*"></ELEMENT>

</SEQUENCE></MODEL>

</ELEMENTTYPE>

<H3>Physical Address</H3>

<ELEMENTTYPE NAME="address.physical">

<EXPLAIN><TITLE>Physical Address</TITLE>

<SYNOPSIS>The street address, city, state, and zip code.</SYNOPSIS></EXPLAIN>

<MODEL><SEQUENCE>

<ELEMENT NAME="street"></ELEMENT>

<ELEMENT NAME="city"></ELEMENT>

<ELEMENT NAME="state"></ELEMENT>

<ELEMENT NAME="postcode" OCCURS="?"></ELEMENT>

<ELEMENT NAME="country"></ELEMENT>

</SEQUENCE></MODEL>

</ELEMENTTYPE>

<H3>Street</H3>

<ELEMENTTYPE NAME="street">

<EXPLAIN><TITLE>Street Address</TITLE>

<SYNOPSIS>Street or postal address.</SYNOPSIS></EXPLAIN>

<MODEL><STRING></STRING></MODEL>

</ELEMENTTYPE>

<H3>City</H3>

<ELEMENTTYPE NAME="city">

<EXPLAIN><TITLE>City Name or Code</TITLE>

<P>The city name or code is a string that contains sufficient information to identify

a city within a designated state.</P>

</EXPLAIN>

<MODEL><STRING></STRING></MODEL>

</ELEMENTTYPE>

<H3>State</H3>

<ELEMENTTYPE NAME="state">

<EXPLAIN><TITLE>State, Province or Prefecture Name or Code</TITLE>

<P>The state name or code contains sufficient information to identify a state within

a designated country.</P></EXPLAIN>

<MODEL><STRING DATATYPE="COUNTRY.US.SUBENTITY"></STRING></MODEL>

</ELEMENTTYPE>

<H3>Postal Code</H3>

<ELEMENTTYPE NAME="postcode">

<EXPLAIN><TITLE>Postal Code</TITLE>

<P>A postal code is an alphanumeric code, designated by an appropriate postal authority,

that is used to identify a location or region within the jurisdiction of that postal authority.

Postal authorities include designated national postal authorities.</P></EXPLAIN>

<MODEL><STRING DATATYPE=″string″></STRING></MODEL>

</ELEMENTTYPE>

<H3>Country</H3>

<ELEMENTTYPE NAME="country">

<EXPLAIN><TITLE>Country Code</TITLE>

<P>A country code is a two-letter code, designated by ISO, that is used to uniquely

identify a country.</P></EXPLAIN>

<MODEL><STRING DATATYPE="country"></STRING></MODEL>

</ELEMENTTYPE>

<H3>Network Addresses</H3>

<ELEMENTTYPE NAME="telephone">

<EXPLAIN><TITLE>Telephone Number</TITLE>

<P>A telephone number is a string of alphanumerics and punctuation that uniquely

identifies a telephone service terminal, including extension number.</P></EXPLAIN>

<MODEL><STRING></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Fax</H3>

<ELEMENTTYPE NAME="fax">

<EXPLAIN><TITLE>Fax Number</TITLE>

<P>A fax number is a string of alphanumerics and punctuation that uniquely identifies

a fax service terminal.</P>

</EXPLAIN>

<MODEL><STRING></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Email</H3>

<ELEMENTTYPE NAME="email">

<EXPLAIN><TITLE>Email Address</TITLE>

<P>An email address is a datatype-constrained string that uniquely identifies a mailbox

on a server.</P></EXPLAIN>

<MODEL><STRING DATATYPE="email"></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Internet Address</H3>

<ELEMENTTYPE NAME="internet">

<EXPLAIN><TITLE>Internet Address</TITLE>

<P>An Internet address is a datatype-constrained string that uniquely identifies a

resource on the Internet by means of a URL.</P></EXPLAIN>

<MODEL><STRING DATATYPE=″url″></STRING></MODEL>

</ELEMENTTYPE>

</DTD>

</SCHEMA>

Service Description Example

<! DOCTYPE schema SYSTEM ″bidl.dtd″>

<SCHEMA>

<H1>Service Description Sample BID</H1>

<META

WHO.OWNS="Veo Systems" WHO.COPYRIGHT="Veo Systems"

WHEN.COPYRIGHT="1998" DESCRIPTION="Sample BID"

WHO.CREATED="*" WHEN.CREATED="*"

WHAT.VERSION="*" WHO.MODIFIED="*"

WHEN.MODIFIED="*" WHEN.EFFECTIVE="*"

WHEN.EXPIRES="*" WHO.EFFECTIVE="*"

WHO.EXPIRES="*">

</META>

<PROLOG>

<XMLDECL STANDALONE="no"></XMLDECL>

<DOCTYPE NAME="service">

<SYSTEM>service.dtd</SYSTEM></DOCTYPE>

</PROLOG>

<DTD NAME="service.dtd">

<H2>Services</H2>

<H3>Includes</H3>

<! -- INCLUDE><SYSTEM>comments.bim</SYSTEM></INCLUDE -->

<H3>Service Set</H3>

<ELEMENTTYPE NAME="service.set">

<EXPLAIN><TITLE>Service Set</TITLE>

<SYNOPSIS>A set of services.</SYNOPSIS></EXPLAIN>

<MODEL>

<ELEMENT NAME="service" OCCURS="+"></ELEMENT>

</MODEL></ELEMENTTYPE>

<H3>Services Prototype</H3>

<PROTOTYPE NAME="prototype.service">

<EXPLAIN><TITLE>Service</TITLE></EXPLAIN>

<MODEL><SEQUENCE>

<ELEMENT NAME="service.name"></ELEMENT>

<ELEMENT NAME="service.terms" OCCURS="+"></ELEMENT>

<ELEMENT NAME="service.location" OCCURS="+"></ELEMENT>

<ELEMENT NAME="service.operation" OCCURS="+"></ELEMENT>

</SEQUENCE></MODEL>

<! -- ATTGROUP><IMPLEMENTS

HREF="common.attrib"></IMPLEMENTS></ATTGROUP -->

</PROTOTYPE>

  <H3>Service</H3>

<INTRO><P>A service is an addressable network resource that provides interfaces to

specific operations by way of input and output documents.</P></INTRO>

<ELEMENTTYPE NAME="service">

<EXPLAIN><TITLE>Service</TITLE>

<P>A service is defined in terms of its name, the location(s) at which the service is

available, and the operation(s) that the service performs.</P></EXPLAIN>

<MODEL><SEQUENCE>

<ELEMENT NAME="service.name"></ELEMENT>

<ELEMENT NAME="service.location"></ELEMENT>

<ELEMENT NAME="service.operation" OCCURS="+"></ELEMENT>

<ELEMENT NAME="service.terms"></ELEMENT>

</SEQUENCE></MODEL>

</ELEMENTTYPE>

  <H3>Service Name</H3>

<ELEMENTTYPE NAME="service.name">

<EXPLAIN><TITLE>Service Name</TITLE>

<P>The service name is a human-readable string that ascribes a moniker for a service.

It may be employed is user interfaces and documentation, or for other purposes.</P></EXPLAIN>

<MODEL><STRING></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Service Location</H3>

<ELEMENTTYPE NAME="service.location">

<EXPLAIN><TITLE>Service Location</TITLE>

<SYNOPSIS>A URI of a service.</SYNOPSIS>

<P>A service location is a datatype-constrained string that locates a service on the

Internet by means of a URI.</P></EXPLAIN>

<MODEL><STRING DATATYPE=″url″></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Service Operations</H3>

<INTRO><P>A service operation consists of a name, location and its interface, as

identified by the type of input document that the service operation accepts and by the type

of document that it will return as a result.</P></INTRO>

<ELEMENTTYPE NAME="service.operation">

<EXPLAIN><TITLE>Service Operations</TITLE>

<P>A service operation must have a name, a location, and at least one document type as

an input, with one or more possible document types returned as a result of the operation.</P>

</EXPLAIN>

<MODEL><SEQUENCE>

<ELEMENT NAME="service.operation.name"></ELEMENT>

<ELEMENT NAME="service.operation.location"></ELEMENT>

<ELEMENT NAME="service.operation.input"></ELEMENT>

<ELEMENT NAME="service.operation.output"></ELEMENT>

</SEQUENCE></MODEL>

</ELEMENTTYPE>

  <H3>Service Operation Name</H3>

<ELEMENTTYPE NAME="service.operation.name">

<EXPLAIN><TITLE>Service Operation Name</TITLE>

<P>The service operation name is a human-readable string that ascribes a moniker to a

service operation.It may be employed in user interfaces and documentation, or for other

purposes.</P></EXPLAIN>

<MODEL><STRING></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Service Operation Location</H3>

<INTRO><P>The service location is a network resource. That is to say, a URI.</P></INTRO>

<ELEMENTTYPE NAME="service.operation.location">

<EXPLAIN><TITLE>Service Operation Location</TITLE>

<SYNOPSIS>A URI of a service operation.</SYNOPSIS>

<P>A service operation location is a datatype-constrained string that locates a service

operation on the Internet by means of a URL.</P></EXPLAIN>

<MODEL><STRING DATATYPE=″url″></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Service Operation Input Document</H3>

<INTRO><P>The input to a service operation is defined by its input document type.That

is, the service operation is invoked when the service operation location receives an input

document whose type corresponds to the document type specified by this element.</P>

<P>Rather than define the expected input and output document types in the market

participant document, this example provides pointers to externally-defined BIDs. This allows

reuse of the same BID as the input and/or output document type for multiple operations.In

addition, it encourages parallel design and implementation.</P></INTRO>

<ELEMENTTYPE NAME="service.operation.input">

<EXPLAIN><TITLE>Service Operation Input</TITLE>

<SYNOPSIS>Identifies the type of the service operation input document.</SYNOPSIS>

<P>Service location input is a datatype-constrained string that identifies a BID on the

Internet by means of a URI.</P>

</EXPLAIN>

<MODEL><STRING DATATYPE=″url″></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Service Operation Output Document Type</H3>

<INTRO><P>The output of a service operation is defined by its output document type(s).

That is, the service operation is expected to emit a document whose type corresponds to the

document type specified by this element.</P></INTRO>

<ELEMENTTYPE NAME="service.operation.output">

<EXPLAIN><TITLE>Service Operation Output</TITLE>

<SYNOPSIS>Identifies the type of the service operation output document.</SYNOPSIS>

<P>Service location output is a datatype-constrained string that identifies a BID on

the Internet by means of a URI.</P>

</EXPLAIN>

<MODEL><STRING DATATYPE=″url″></STRING></MODEL>

</ELEMENTTYPE>

  <H3>Service Terms</H3>

  <INTRO><P>This is a simple collection of string elements, describing the terms of an

agreement.</P></INTRO>

<ELEMENTTYPE NAME="service.terms">

<EXPLAIN><TITLE>Service Terms</TITLE>

<SYNOPSIS>Describes the terms of a given agreement.</SYNOPSIS>

</EXPLAIN>

<MODEL><STRING DATATYPE=″string″></STRING></MODEL>

</ELEMENTTYPE>

</DTD>

</SCHEMA>

The Service DTD schema can be extended with service-type elements from the Common Business Language Repository as shown below.

<! ELEMENT service.type EMPTY>

<! ATTLIST service.type

service.type.name(

catalog.operator

| commercial.directory.operator

| eft.services.provider

| escrower

| fulfillment.service

| insurer

| manufacturer

| market.operator

| order. originator

| ordering.service

| personal.services.provider

| retailer

| retail. aggregator

| schema.resolution.service

| service.provider

| shipment.acceptor

| shipper

| van

| wholesale.aggregator

) #REQUIRED

%common.attrib;

>

The service-type element described above specifies the interpretation information carried by the business interface definition, in this case a content form allowing the identification of any one of a list of valid services. Other explanatory information includes data types, such as the element <H3>Internet Address</H3>, which includes the content form "url" and is represented by the data type "string". Still other interpretation information includes the mapping of codes to manifest elements, such as the element <H3>State</H3> which includes codes mapping the states in the file "COUNTRY.US.SUBENTITY".

The Service Description referred to by the Market Participant DTD defines the documents that the service accepts and produces when the service is completed. The basic service description is specified below as the XML document transact.dtd.

Transact.dtd models transaction descriptions such as invoices, or descriptions of exchange of value. This document type supports many uses, so the transaction description element has attributes that allow the user to distinguish between invoices, performance, indication of sale, and request for quotation. The exchange can take place between more than two objects, but only two objects are taken out, the Offeror and the Calculator, both of which are represented by pointers to documents that conform to the Market Participant DTD above. The calculation side pointer is optional in order to accommodate the selling intent. Exchange descriptions are described in the module tranprim.mod listed below, and include pricing and subtotals. After the exchange description, the fee applied to the transaction as a whole can be provided and the total fee must be provided. Therefore, the transaction description profile document for this example is given as follows:

<! --transact.dtd Version: 1.0-->

<! --Copyright 1998 Veo Systems, Inc.-->

...

<! ELEMENT transaction.description(meta?, issuer.pointer,

Counterparty. pointer? , exhange.descrpt ion+, general.charges? ,

net. total? )>

<! ATTLIST transaction.description

Transaction.type(invoice | pro.forma | offer.to.sell | order

| request.for.quote|request.for.bid

| request.for.proposal | response.to.request.for.quote

| response.to.request.for.bid

| response.to.request.for.proposal)"invoice"

%common.attrib;

% altrep.attrib;

%ttl.attrib;

>

The following are representative Market Participant and Service DTDs built from the above definitions: Market Participant DTD

<! ELEMENT business(party.name+, address.set)>

<! ATTLIST business business.number CDATA #REQUIRED

>

<! ELEMENT party.name(#PCDATA)>

<! ELEMENT city(#PCDATA)>

<! ELEMENT internet(#PCDATA)>

<! ELEMENT country(#PCDATA)>

<! ELEMENT state(#PCDATA)>

<! ELEMENT email(#PCDATA)>

<! ELEMENT address. physical(street, city, state, postcode?, country)>

<! ELEMENT telephone(#PCDATA)>

<! ELEMENT person(party.name+, address.set)>

<! ATTLIST person SSN CDATA #IMPLIED

>

<! ELEMENT fax(#PCDATA)>

<! ELEMENT street(#PCDATA)>

<! ELEMENT address.set(address.physical, telephone*, fax*, email*, internet*)>

<! ELEMENT postcode(#PCDATA)>

<! ELEMENT market. participant(business | person)>

Service DTD

<! ELEMENT service. location(#PCDATA)>

<! ELEMENT service.terms(#PCDATA)>

<! ELEMENT service.operation.name(#PCDATA)>

<! ELEMENT service.operation(service.operation.name, service.operation.location,

service.operation.input, service.operation.output)>

<! ELEMENT service(service.name, service.location, service.operation+,

service.terms)>

<! ELEMENT service.operation.input(#PCDATA)>

<! ELEMENT service.operation.location(#PCDATA)>

<! ELEMENT service.name(#PCDATA)>

<! ELEMENT service.set(service+)>

<! ELEMENT service.operation.output(#PCDATA)>

The following is an example document generated according to transact.dtd:

<? xml version="1.0"? >

<! -- rorder.xml Version: 1.0 -->

<! -- Copyright 1998 Veo Systems, Inc. -->

<! DOCTYPE transaction. description SYSTEM ″urn:x-

veosystems:dtd:cbl:transact:1.0:>

<transaction.description transaction.type="order">

<meta>

<urn? urn:x-veosystems:doc:00023

</urn>

<thread.id party.assigned.by="reqorg">FRT876

</thread.id>

</meta>

<issuer.pointer>

<xll.locator urllink="reqorg.xml">Customer

Pointer

</xll.locator>

</issuer.pointer>

<counterparty. pointer>

<xll.locator urllink="compu.xml">Catalog entry owner

pointer

</xll.locator>

</counterparty.pointer>

<exchange.description>

<line. item>

<product.instance>

<product.description.pointer>

<xll.locator urllink="cthink.xml">Catalogue Entry Pointer

</xll.locator>

</product.description.pointer>

<product.specifics>

<info.description.set>

<info.description>

<xml.descriptor>

<doctype>

<dtd system.id=″urn:x-veosystems:dtd:cbl:gprod:1.0″/>

</doctype>

<xml.descriptor.details>

<xll.xptr.frag>DESCENDANT(ALL, os)STRING(″Windows 95″)

</xll.xptr.frag>

<xll.xptr.frag>DECENDANT(ALL，p.speed)STRING(″200″)

</xll.xptr.frag>

<xll.xptr.frag>DESCENDANT(ALL, hard.disk.capacity)

STRING (″4″)

</xll.xptr.frag>

<xll.xptr.frag>DESCENDANT(ALL, d.size)STRING(″14.1″)

</xll.xptr.frag>

</xml.descriptor.details>

</xml.descriptor>

</info.description>

</info.description.set>

</product.specifics>

<quantity>1

</quantity>

</product.instance>

<shipment. coordinates. set>

<shipment. coordinates>

<shipment.destination>

<address.set>

<address.named>SW-1

</address.named>

<address.physical>

<building.sublocation>208C</building.sublocation>

<location.in.street>123

</location.in.street>

<street>Frontage Rd.

</street>

<city>Beltway

</city>

<country.subentity.us

country.subentity.us.name="MD"/>

<postcode>20000

</postcode>

</address.physical>

<telephone>

<telephone.number>617-666-2000

</telephone.number>

<telephone.extension>1201

</telephone.extension>

</telephone>

</address.set>

</shipment.destination>

<shipment.special>No deliveries after 4 PM</shipment.special>

</shipment. coordinates>

</shipment.coordinates.set>

<payment.set>

<credit.card

Issuer.name="VISA"

Instrument.number="3787-812345-67893"

expiry.date="12/97"

Currency.code="USD"/>

<amount.group>

<amount.monetary currency.code=″USD″>3975

</amount.monetary>

</amount.group>

</payment.set>

</line.item>

</exhange.description>

</transaction.description>

Thus, the present invention provides a technique by which a market participant can identify itself and recognize the type of input document and the type of output document with which the market participant will conduct business. The specific manner in which the content contained in these documents is handled by the remaining parties to the transaction or locally is not included in the establishment of commercial relationships and transactions.

Figure 3 provides a simplified diagram showing participant sites in a network according to the invention. The network point shown in FIG. 3 includes a network interface 300 which is connected at port 301 to the communication network. The network interface is connected with the document syntax analyzer 301 . The parser 301 provides the logical structure from the input document to the translator module 302, which translates the input document into a form usable by the host transaction system, and in turn translates the output of the host process into the same output as in the business interface definition The document form matches the document format for delivery to the destination. Parser 301 and translator 302 respond to business interface definitions stored in participant module 303 .

The output data structures from the translator 302 are provided to the transaction process front end 304 together with the signal events emitted by the parser 301 . Front end 304 in one embodiment includes a JAVA virtual machine or other similar interface suitable for communication between different nodes in the network. Transaction processing front end 304 responds to events represented by parser 301 and translator 302 to pass input data to the appropriate functions in the enterprise systems and networks connected to the participants. Thus the transaction processing front end 304 in the example of FIG. Responds to events represented by the parser.

The syntax analyzer 301 obtains an order similar to the above example, or other documents specified according to the business interface definition, and generates a set of events identified by a local transaction processing structure (such as a set of JAVA events of the JAVA virtual machine) .

The parser of the present invention is not linked to a program that listens to events from received documents. Markup segments of a received document or complete document that meet certain specifications serve as listener function instructions to begin processing. Therefore, the listening program completes the business logic related to the document information. For example, a program associated with an address element could be a code that validates a postal code by checking a database. These listeners subscribe to events by registering with the document router, which sends the relevant events to all users interested in them.

For example, the order specified above could be monitored with a program that listens to events generated by the parser, which program would link the document or its contents to the order entry program. Receiving a product description in a purchase order invokes a program to check inventory. Receiving the address information in the purchase order would then invoke a program to check the availability of the delivery service. The buyer information field in the document may invoke procedures to check purchase order history for credit, or to provide promotions or similar processing based on a known customer identity.

Complex listeners can be configured from primitive listeners. For example, an order listener could contain and call the list listener given in the previous paragraph, or it could call a list member on itself. Note that the application run by the listener cannot be a native XML process or a native Java process. In these cases, the object can be converted into the format required by the receiving conversion application. When the application finishes processing, it converts its output back to XML format for transmission to other nodes in the network.

It can be seen that the above-mentioned market participation document type description and transaction document type description include a schematic image for logical units in the document, and include 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 the specification of business interface definitions, service descriptions, and descriptions of input and output documents.

In addition to storing business interface definitions, participant module 303 also includes a compiler for compiling objects or other data structures to be used by transaction process front end 304, which corresponds to the logical structure in the input document, and Translator 302 is also compiled. Thus, translator 302 and parser 301 will automatically be kept up-to-date as participants modify or update business interface definitions as the transactions they are involved in change.

In a preferred embodiment, a compiler corresponding to grove-type SGML is used to generate a set of JAVA events, mainly to add the "capability set" of each element to the standard element structure information set. International Standard ISO/IEC10179:1996(E), Information Technology - Processing Languages - Document Semantics and Specification Language (DSSSL). Turns an XML document into a set of global events, in contrast to the normal parsing model where the output of the parser is kept as an internal data structure. By translating the elements of the XML document into JAVA events or other programming structures suitable for the transaction processing front end of each network point, rich functions can be obtained at the network point using the transaction document.

Thus, the transaction process front end 304 can operate openly, and subscriptions can add listener programs without knowing or affecting the structure of other listening programs in the system. Each listener 305, 306, 307 and 308 in FIG. 3 maintains a queue from which the front end 304 directs events. This enables multiple listeners to process events in parallel at their own pace.

Additionally, in accordance with the present invention, the application run by the listener does not require native XML functionality, or native functionality to match the format of the input document. If the transaction process front end 304 is a JAVA interface, then these listeners may be JAVA functions, or functions that operate according to a unique transaction structure. In these cases, the object can be converted into the format required by the receiving application. When the listener's application ends, its output is converted back to the document format as specified by the business interface definition in block 303 . Therefore, the translator 302 is connected to the network interface 300 and is used directly to provide organized documents as output.

The listeners associated with the transaction processing front end may include listeners for the input document, listeners for specific elements in the input document, and listeners for attributes stored in specific elements of the input document. This allows for different and flexible implementations of transaction processing at participant sites for filtering and responding to input documents.

FIG. 4 illustrates the process of receiving and processing an input document for the system of FIG. 3 . Thus, the process begins by receiving a document at the network interface (step 400). A parser identifies a document type in response to a business interface definition (401). Using the business interface definition (which stores the DTD of the document in XML format), the document is parsed (step 402). Next, the elements and attributes of the document are translated into the master format (step 403). In this example, the XML logical structure is translated into a JAVA object that carries the data of the XML elements and methods related to the data such as getting and setting functions. Next, the master object is passed to the master transaction processing front end (step 404). These objects are provided to certain procedures in response to events represented by the parser and translator. A process is performed for receiving document elements and producing an output (step 405). The output is translated into an output document format as defined by the business interface definition (step 406). In this example, translation is performed from the form of a JAVA object to the form of an XML document. Finally, the output document is delivered to the destination via the network interface.

FIG. 5 describes the event generator/event listener mechanism of the system shown in FIG. 3 in more detail. In general, the method shown in Figure 5 is a refinement of the JAVA JDK 1.1 event model. In this model, three kinds of objects are considered. The first type of object is an event object, which contains information about the occurrence of an event. There can be many kinds of event objects, which correspond to all the different events that can occur. The second type of object is an event generator, which monitors activity and generates event objects when something happens. The third is the event listener, which listens to the event object generated by the event generator. Event listeners typically listen to specific event generators, such as mouse clicks on specific windows. The event listener calls "increase event listener" on the event generator. The model applies to the environment of Figure 3, where objects are generated in response to analysis and walking of object curves such as represented by XML documents.

The system shown in FIG. 5 includes a generic XML parser 500 . Such parsers can be implemented using the standard callback model. When a parse event occurs, the parser calls a specific method in the application object, passing the appropriate information in the parameters. Thus, a single application 501 is together with the parser. As represented by block 502, the application encapsulates the information provided by the parser in an XML event object and sends it to a number of event listeners that recognize itself. Event group 502 is completely independent of the parser. Event 502 may be provided to any number of listeners and any number of threads on any number of machines. In another case, the event is based on the element structure information set ESIS. Thus, they include lists of important aspects of the document's structure, such as the beginning and end of elements, or the identification of attributes. XML (and SGML) parsers typically use the ESIS structure as a default set of information for the parser to return to its application.

A dedicated ESIS listener 503 is connected to a set of events 502 . The listener 503 implements the ESIS listener API and listens to all XML events from one or more producers. Element event generator 504 is a special ESIS listener, which is also an XML event generator. Its listeners are objects that are only interested in events for a particular type of element. For example, in an HTML environment, the listener is only interested in the order, which is just the part of the document between the <OL> and </OL> tags. In another example, the listener listens for a "party.name" element from the above-exemplified document, or a "service.name" element according to the common business language; matched data; and act upon the process required by the receiving outlet.

This allows the system to have smaller objects that listen to specific parts of the document, such as adding only the price part. Since listeners can add and remove themselves from generators, it is possible to have a listener that only listens to <header> sections of HTML documents. Because of this, and the highly recursive nature of XML documents, it is possible to write highly targeted code and write out-of-the-box listeners. For example, an <OL> listener may establish a <LI> listener in a manner completely independent of how a <UL> (Unordered List) listener establishes its <LI> listener. Another approach is to create a listener that produces a GUI, and another listener that uses the same input to search a library of numbers. Thus, treat the document as a program executed by the listener, as opposed to the compact data structure that the application examines one section at a time. If an application is written this way, the entire document does not have to be brought into memory in order to execute the application.

The next listener connected to event group 502 is attribute filter 505 . Attribute filter 505, like element filter 504, is an attribute event generator according to the ESIS listener model. A listener for an attribute filter specifies the attributes it is interested in, and receives events for any element with that specified attribute. So for example the font manager only receives events for elements with font attributes such as <P FONT="Times Roman"/p>.

Element event generator 504 provides this type of element object to specialize element listener 504A.

Property event generator 505 provides a property event object to property listener 505A. Likewise, attribute objects are provided to a "structure" in the sense of an SGML/XML transformation that uses attributes to convert from one document type to another. Therefore, the structure of 505B allows a specific attribute to have a distinguishable specific name. Only elements with the specified attribute become part of the output document, and the element name in the output document is the attribute value in the input document. For example, if structure 505B is HTML, then the string:

<PURCHASES HTML="OL"><ITEM HTML="LI"><NAME

HTML="B">STUFF</NAME><PRICE

HTML="B">123</PRICE></ITEM></PURCHASES>

translate to:

<OL><LI><B>STUFF</B><B>123</B></LI></OL>

This is correct HTML.

The next module connected to event group 502 is the tree builder. A tree builder takes a stream of XML events and produces a tree representing the underlying document. A preferred version of the tree builder 506 generates a Document Object Model DOM object 507 according to the W3C specification (see, http://www.w3.org/TR/1998/WD-DOM-19980720). However, most requirements can be handled with listeners on the event stream, and the tree version is adapted to support querying around documents, reordering of nodes, creation of new documents, and support for in-memory events that can be used to generate the same event stream multiple times The data structure structure, such as multiple analysis documents. A special builder 508 can be connected to the tree builder 506 to build specific subtrees for various parts of the document, to suit a particular implementation.

In addition to responding to input documents, other sources of XML events may be provided. Thus, the event stream 510 is generated by walking the DOM object tree and regenerating the original event stream established when the document was parsed. This allows the system to appear that the document was analyzed several times.

The idea of having objects walk a tree and produce a stream of events can be generalized beyond a tree of DOM objects, to any tree of objects that can be interrogated. Thus, JAVA walker 512 may be an application that walks JAVA bean component tree 513 . The walker walks through all publicly accessible fields and methods. The walker keeps track of the objects it has visited, ensuring that it does not enter an infinite loop. JAVA event 514 is the event type that JAVA walker 512 generates. This generally includes most types of information that can be derived from an object. This is the JAVA equivalent of ESIS, and allows the same programming approach to be applied to XML that would be used for JAVA objects in general, though specifically for JAVA beans.

The JAVA to XML event generator 515 constructs a JAVA listener and a JAVA event generator. It receives the event stream 514 from the JAVA walker 512 and translates selected ones to represent JAVA objects into XML documents. In a preferred embodiment, the event generator 515 develops a JAVA bean API. Each observed object becomes an element with the same element name as the class name. Within the element, each embedded method also becomes an element whose content is the value returned by calling the method. If it's an object or an array of objects, walk through them in turn.

Figure 6 depicts a specific application built on the Figure 5 framework. The application takes an XML document 600 and applies it to a parser/generator 601 . An ESIS event 602 is generated and provided to an attribute generator 603 and a tree builder 604 . The attribute generator corresponds to generator 505 of FIG. 5 . It provides events to the "fabric" 505B to translate XML input into eg HTML output. As represented by block 605, these events are processed in parallel and processed with listeners. The output of the listener is provided to the document writer 506, which is then translated back to XML format for output. So for example, the application shown in Figure 6 takes an XML document, and the output consists of a form of HTML document. This form is then sent to the browser and the result converted back to XML. For this exercise, Structural Concepts provides a mapping from XML to HTML. Figure 6 includes three structures, one provides the structure of the HTML document, such as tables and lists; the second specifies the text to be displayed, such as the input field mark on the browser document; the third describes the input field itself . In the HTML form, elements in the XML document that require maintaining the structure of the XML document become invisible fields. This applies to reconstructing XML documents from information that the client translates into HTTP post messages back to the server. Each architecture takes an input document and transforms it into an architecture based on a subset of HTML. Listeners for these events output the events for the HTML document, which then travel to the document writer object. Document writer objects listen to XML events and convert them back to XML documents. In this example, the Document Writer object is a listener to all element generators that listen to the architecture.

The construction of the processing modules shown in FIGS. 5 and 6 represents an embodiment of the syntax analyzer and transaction processing front end of the system in FIG. 3 . As can be seen from the figure, a very flexible interface is provided through which various transaction processing processes are performed in response to input XML documents or other structured document formats.

FIG. 7 shows a network point similar to FIG. 3 except that it includes a business interface definition composer module 700 . Therefore, the system of FIG. 7 includes a network interface 701 , a document parser 702 and a document translator 703 . Translator 703 provides other output to transaction processing front end 704 which interfaces with listening functions such as business functions 705 , databases 706 , enterprise functions 707 and other general listeners and processors 708 . As shown in FIG. 7, the business interface definition builder 700 includes a user interface, a common business library CBL resource library, a process for reading supplementary business interface definitions, and a compiling program. The user interface is used to help enterprises rely on the public business library resource library to establish business interface definitions, and to read the ability to supplement the business interface definitions. Thus, an input document of a supplemental business interface definition can be designated as an output document of a particular transaction, and an output document of a supplemental business interface definition can be designated as an input of this transaction process. In a similar way, transactional business interface definitions can be composed from components selected from the CBL repository. Use of the CBL repository encourages the use of standardized document formats, such as the above-exemplified schema (bidl) documents, logical structure and interpretation information in forming business interface definitions that are readily adopted by others in the network.

The business interface definition composer module 700 also includes a compiler, which is used to generate a translator 703, which processes objects generated according to the main transaction architecture, and manages the analysis function 702.

FIG. 8 is a heuristic diagram showing the logical structure stored in the repository of the business interface definition composer 700 . Thus, the repository stores the business interface definitions 800 on behalf of the parties, including, for example, the consumer BID 801, the catalog BID 802, the warehouse BID 803, and the auction repository BID 804. Therefore, new players in the online market can choose a standardized BID that best suits their business activities as the basic interface description. Additionally, the repository will store a set of service business interface definitions 805 . For example, Purchase Order Entry BID 806, Purchase Order Tracking BID 807, Purchase Order Fulfillment BID 808, and Catalog Services BID 809 may be stored. When a new participant in the market forms a business interface definition, it can choose the business interface definition of the standardized service stored in the resource library.

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

In addition to business interface definitions specified as document type definitions in accordance with XML in the preferred embodiment, as indicated by field 816, the repository stores interpretation information in the form of semantic maps. Thus, the semantic maps for specifying weight 817, currency 818, dimensions 819, product identifier 820 and product characteristics 821 in this example may be stored in a repository. In addition, interpretation information provides types for data structures within the document's logical structure.

Additionally, as indicated at block 822, the logical structure used in composing the business interface definition may be stored in a resource repository. Accordingly, block 825 may provide a form 823 for providing an address signal, a form for providing an offer signal 824, and a form for providing a contractual relationship. As the network expands, the CBL repository will also be expanded and standardized to facilitate the addition of new participants and the modification of business interface definitions.

FIG. 9 shows the process of forming a business interface definition using the system of FIG. 7 . The process begins by displaying the 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 referenced logical structures, interpretation information, and document definitions and/or service definitions are retrieved from the repository in response to user input through the graphical user interface (step 902). In the next step, any supplementary business interface definitions or components of the business interface definitions are accessed by other participants in the network selected by user input through custom search engines, web browsers or similar means (step 903). A participant's profile definition is built using the collected information (step 904). The compiler is used to build document-to-host and host-to-document translators (step 905). Create the master architecture data structure corresponding to the definition with a compiler (step 906), and post the established business interface definition on the network, such as posting it on a World Wide Web site or elsewhere, to make it accessible to other sites in the network (step 907).

The business interface definition tells potential trading partners which online services the company provides and which documents to use to invoke those services. Therefore, services are defined in business interface definitions with the documents they accept and generate. This is illustrated in the following fragment of the XML service definition.

<service>

<service.name>Order Service</service.name>

<service.location>www.veosystems.com/order</service.location>

<service.op>

<service.op.name>Submit Order</service.op.name>

<service.op.inputdoc>www.commerce.net/po.dtd</service.op.inputdoc>

<service.op.outputdoc>

www.veosystems.com/invoice.dtd</service.op.outputdoc>

</service.op>

<service.op>

<service.op.name>Track Order</service.op.name>

<service.op.inputdoc>www.commerce.net

/request.track.dtd<service.op.inputdoc>

<service.op.outputdoc>

www.veosystems.com/response.track.dtd<service.op.outputdoc>

</service.op>

</service>

This XML fragment defines a service consisting of two transactions, one for getting purchase orders and one for tracking them. Each definition represents a connection or promise to perform a service if a valid request is sent to the specified Weg address. Here the purchase order service requires an input document that conforms to the standard "po.dtd" document type definition in the repository, either locally or stored in an industry-wide registry on the network. If an outlet can fulfill the purchase order, it will return a document conforming to the custom "invoice.dtd", whose definition is local. In effect, the company is promising to do business with anyone who places a purchase order that conforms to its required XML specification. No prior arrangements are required.

A DTD is a formal specification or syntax for a document of a given type; it describes elements, their attributes, and the order in which they must appear. For example, a purchase order typically includes the names and addresses of the buyer and seller, a set of product descriptions, and terms and conditions such as price and ship date. For example, in electronic data interchange EDI, X12 850 is a commonly used purchase order model.

The repository encourages the development of XML document models with reusable semantic components common to many business domains. Such documents can be understood from their common message elements, even though they can appear very difficult. This is the role of the common business library repository.

Common business library resources consist of information models of general business concepts, including:

● business description primitives such as companies, services and products;

●Commercial forms such as catalogs, purchase orders and invoices;

● Standard measure, date and time, location, classification code.

Represent this information as a set of extensible, open XML building blocks that companies can customize and assemble to rapidly develop XML applications. Atomic CBL elements implement industry messaging standards and conventions, such as standard ISO codes for countries, currencies, addresses, and times. Low-level CBL semantics also come from the analysis of recommended metadata frameworks (such as Dublin cores) for Internet resources.

The next level of elements use these building blocks to implement basic business forms such as those used in X12 EDI transaction processing and those used in the formation of Internet standards such as the Open Transaction Protocol OTP and the Open Purchase OBI on the Internet .

The focus of CBL is on functions and information common to all business domains (business description primitives such as companies, services and products; business forms such as catalogs, purchase orders and invoices; standard measures, periods and times, locations, category codes) . CBLs are structured on possible semantic standards or industry conventions (eg, encoding rules in a separate CBL model specifying European "date/month/year" versus US "month/day/year").

CBL is a language for designing applications. It was designed to bridge the gap between the XML "document world" and the JAVA "programming world" or other transaction processing architectures. Schemas embody a "programming with documents" philosophy, where the detailed formal specification of a document type is the primary source from which various related tables can be generated. These tables include XML DTD for CBL, JAVA objects, programs for converting XML instances and corresponding JAVA objects to each other and supporting documents.

CBL establishes a single source from which a compiler can automatically generate almost all pieces of the system. CBL works by extending SGML/XML, which is commonly used to formally define the structure of a particular document type, to include a specification of the semantics associated with each information element and attribute. The limited set of most character types in SGML/XML can be extended to define any kind of data type.

Here is a snippet from the CBL definition for the "datetime" module:

<! --datetime.mod Version: 1.0-->

<! --Copyright 1998 Veo Systems, Inc.-->

...

<! ELEMENT year(#PCDATA)>

<! ATTLIST year

schema CDATA#FIXED″urn:x-veosystems:stds:iso:8601:3.8″

>

<! ELEMENT month(#PCDATA)>

<! ATTLIST month

schema CDATA #FIXED″urn:x-veosystems:stds:iso:8601:3.12″

>

...

In this fragment, the element "year" is defined as character data, and the associated "mode" attribute is also defined as character data, which defines the mode of "year" as section 3.8 of the ISO 8601 standard.

This "datetime" CBL module is in fact defined as an instance of the schema DTD. First, define the module name. Then, constrain the "datetime" element "year" to the semantics of ISO 8601.

<! DOCTYPE SCHEMA SYSTEM″schema.dtd″>

<SCHEMA><H1>Date and Time Module</H1>

...

<ELEMNTTYPE NAME="year" DATATYPE="YEAR"><MODEL>

<STRING

DATATYPE="YEAR"></STRING></MODEL>

<ATTDEF NAME=:schema:iso8601″DATATYPE=″CDATA″>

<FIXED>3.8

Gregorian calendar</FIXED></ATTDEF></ELEMENTTYPE>

...

The market participants and service modules listed above are also stored in the CBL resource library.

In FIG. 10, an airline bill 1000 is defined by customizing the general purchase order DTD 1001 and adding more specific information 1002 about shipping weight. A generic purchase order 1001 is initially assembled entirely with CBL modules for address, date and time, currency, and vendor and product description. Therefore, using CBL significantly speeds up the development and implementation of XML business applications. More importantly, CBL makes it easier for business applications to interconnect.

In CBL, XML is augmented with a schema. The extension adds strong typing to XML elements, making it easy to validate content. For example, the element <CPU_clock_speed> could be defined as an integer with a set of valid values {100, 133, 166, 200, 233, 266 Mhz}. Patterns also increase the class-subclass hierarchy, making it easy to instantiate information by class definitions. For example, a laptop computer may be described as a computer with additional labels regarding such characteristics as display type and battery life. These and other extensions facilitate data entry and automatic translation between XML and traditional object-oriented and relational data models.

Thus, a full BID is run through the compiler, the JAVA beans that correspond to the logical structures in the DTD instance, and the transformation code used to extract the DTD from the XML Conversion to JAVA and from JAVA to XML. In other systems, documentation is also generated, displayed on the user interface, or printed by the user to facilitate the use of the object.

For the market participant and service DTDs exemplified above, the JAVA beans generated by the compiler are described as follows (for brevity, some newer versions are used):

import com.veo.vsp.doclet.meta.Document;

public class AddressPhysical extends Document {

public static final String DOC_TYPE = "address.physical";

String mStreet;

String mCity;

public final static int AK＝0;

public final static int AL=1;

public final static int AR＝2;

public final static int AZ=3;

public final static int CA=4;

...

public final static int WI=48;

public final static int WV＝49;

public final static int WY=50;

int mState;

String mPostcode;

public final static int AD＝51;

public final static int AE＝52;

public final static int AF＝53;

public final static int AG＝54;

public final static int AI＝55;

public final static int AM=56;

...

int mCountry;

public AddressPhysical(){

  super(DOC_TYPE);

mStreet = new String();

mCity = new String();

` this.mState=-1;

mPostcode=null;

  this.mCountry＝-1:

}

public AddressPhysical(String doc_type){

super(doc_type);

mStreet = new String();

mCity = new String();

`` this.mState=-1;

mPostcode=null;

`` this.mCountry=-1;

}

static public AddressPhysical initAddressPhysical(String iStreet, String iCity, int

iState, String iPostcode, int iCountry){

AddressPhysical obj = new AddressPhysical();

     obj.initializeAll(iStreet, iCity, iState, iPostcode, iCountry);

return obj;

}

 public void initializeAll(String iStreet, String iCity, int iState, String iPostcode,

int iCountry){

mStreet=iStreet;

mCity＝iCity;

mState=iState;

mPostcode=iPostcode;

mCountry=iCountry;

}

 public String getStreet(){

return mStreet;

}

public String getStreetToXML() {

If(getStreet()==null) return null;

 char[]c=getStreet().toCharArray();

     StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

       switch(c[x]) {

case'＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″):

break;

case '&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setStreet(String inp){

` this.mStreet=inp;

}

public void streetFromXML(String n){

setStreet(n);

}

public String getCity(){

return mCity;

}

public String getCityToXML(){

If(getCity()==null) return null;

char[]c=getCity().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setCity(String inp){

` this.mCity=inp;

}

public void cityFromXML(String n){

setCity(n);

}

public int getState(){

return mState;

}

public String getStateToXML(){

  switch(mState){

case AK:return "AK";

case AL: return "AL";

case AR:return "AR";

case AZ:return "AZ";

...

}

return null;

}

public void setState(int inp){

` this.mState=inp;

}

public void stateFromXML(String s){

If(s.equals("AK"))mState=AK;

  else if(s.equals("AL"))mState=AL;

else if(s.equals("AR"))mState=AR;

  else if(s.equals("AZ"))mState=AZ;

...

}

public String getPostcode(){

return mPostcode;

}

public String getPostcodeToXML(){

If(getPostcode()==null) return null;

char[]c=getPostcode().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setPostcode(String inp){

` this.mPostcode=inp;

}

public void postcodeFromXML(String n){

setPostcode(n);

}

public int getCountry(){

return mCountry;

}

public String getCountryToXML(){

  switch(mCountry){

case AD: return "AD";

case AE:return "AE";

case AF:return "AF";

...

}

return null;

}

public void setCountry(int inp){

` this.mCountry=inp;

}

public void countryFromXML(String s){

If(s.equals("AD"))mCountry=AD;

      else if(s.equals("AE"))mCountry=AE;

`` else if(s.equals("AF"))mCountry=AF;

      else if(s.equals("AG"))mCountry=AG;

`` else if (s.equals("AI"))mCountry=AI;

..

}

}

package com.veo.xdk.dev.schema.test.blib;

import com.veo.vsp.doclet.meta.Document;

public class AddressSet extends Document {

public static final String DOC_TYPE="address.set";

AddressPhysical mAddressPhysical;

String[]mTelephone;

String[]mFax;

String[]mEmail;

String[]mInternet;

public AddressSet(){

  super(DOC_TYPE);

  this.mAddressPhysical = new AddressPhysical();

mTelephone=null;

mFax=null;

mEmail=null;

mInternet=null;

}

public AddressSet(String doc_type){

super(doc_type);

  this.mAddressPhysical = new AddressPhysical();

mTelephone=null;

mFax=null;

mEmail=null;

mInternet=null;

}

static public AddressSet initAddressSet(AddressPhysical iAddressPhysical, String[]

iTelephone, String[]iFax, String[]iEmail, String[]iInternet){

       AddressSet obj = new AddressSet();

     obj.initializeAll(iAddressPhysical, iTelephone, iFax, iEmail, iInternet);

return obj;

}

 public void initializeAll(AddressPhysical iAddressPhysical, String[]

iTelephone, String[]iFax, String[]iEmail, String[]iInternet){

mAddressPhysical=iAddressPhysical;

mTelephone=iTelephone;

mFax=iFax;

mEmail=iEmail;

mInternet＝iInternet;

}

 public AddressPhysical getAddressPhysical(){

return mAddressPhysical;

}

 public void setAddressPhysical(AddressPhysical inp){

`` this.mAddressPhysical=inp;

}

 public String[]getTelephone(){

return mTelephone;

}

 public String getTelephone(int index){

If(this.mTelephone==null)

return null;

If(index＞＝this.mTelephone.length)

return null;

If(index＜0&&-index＞this.mTelephone.length)

return null;

If(index＞=0) return this.mTelephone[index];

  return this.mTelephone[this.mTelephone.length+index];

}

public String[]getTelephoneToXML(){

String[]valArr=getTelephone();

if(valArr==null) return null;

String[]nvArr=new String[valArr.length];

For(int z=0; z<nvArr.length; z++){

char[]c=valArr[z].toCharArray();

StringBuffer st = new StringBuffer();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

`` switch (c[x]) {

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case"':

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

nvArr[z]=sb.toString();

}

return nvArr;

}

public void setTelephone(int index, String inp){

If(this.mTelephone==null){

         if(index＜0){

  this.mTelephone = new String[1];

`` this.mTelephone[0]=inp;

}else{

  this.mTelephone = new String[index+1];

`` this.mTelephone[index]=inp;

}

}else if(index<0){

        String[]newTelephone＝new String[this.mTelephone.length+1];

java.lang.System.arraycopy((Object)mTelephone, 0,

(Object)newTelephone, 0, this.mTelephone.length);

newTelephone[newTelephone.length-1]=inp;

mTelephone=newTelephone;

}else if(index＞＝this.mTelephone.length){

        String[]newTelephone＝new String[index+1];

java.lang.System.arraycopy((Object)mTelephone, 0,

(Object)newTelephone, 0, this.mTelephone.length);

newTelephone[index]=inp;

mTelephone=newTelephone;

}else{

** this.mTelephone[index]=inp;

}

}

public void setTelephone(String[]inp){

  this.mTelephone = inp;

}

public void telephoneFromXML(String n){

setTelephone(-1, n);

}

public String[]getFax(){

return mFax;

}

public String getFax(int index){

If(this.mFax==null)

return null;

If(index＞＝this.mFax.length)

return null

If(index＜0&&-index＞this.mFax.length)

return null

If(index＞＝0) return this.mFax[index];

  return this.mFax[this.mFax.length+index];

}

public String[]getFaxToXML(){

String[]valArr=getFax();

if(valArr==null) return null;

String[]nvArr=new String[valArr.length];

For(int z=0; z<nvArr.length; z++){

char[]c=valArr[z].toCharArray();

StringBuffer st = new StringBuffer();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case"':

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

       nvArr[z] = sb.toString();

}

return nvArr;

}

 public void setFax(int index, String inp){

If (this.mFax==null){

         if(index＜0){

  this.mFax = new String[1];

`` this.mFax[0]=inp;

        } else {

  this.mFax＝new String[index+1];

`` this.mFax[index]=inp;

}

}else if(index<0){

String[]newFax＝new String[this.mFax.length+1];

java.lang.System.arraycopy((Object)mFax,0,(Object)newFax,0,

this.mFax.length);

newFax[newFax.length-1]=inp;

mFax=newFax;

    }else if(index＞＝this.mFax.length){

        String[]newFax＝new String[index+1];

java.lang.System.arraycopy((Object)mFax,0,(Object)newFax,0,

this.mFax.length);

newFax[index]=inp;

mFax=newFax;

}else{

** this.mFax[index]=inp;

}

}

public void setFax(String[]inp){

  this.mFax = inp;

}

public void faxFromXML(String n){

setFax(-1, n);

}

public String[]getEmail(){

return mEmail;

}

public String getEmail(int index){

If(this.mEmail==null)

return null;

If(index＞＝this.mEmail.length)

return null;

If(index＜0&&-index＞this.mEmail.length)

return null;

If(index＞＝0) return this.mEmail[index];

  return this.mEmail[this.mEmail.length+index];

}

public String[]getEmailToXML(){

String[]valArr=getEmail();

if(valArr==null) return null;

String[]nvArr=new String[valArr.length];

For(int z=0; z<nvArr.length; z++){

char[]c=valArr[z].toCharArray();

StringBuffer st = new StringBuffer();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case'"':

sb.append(″&quot;″);

break;

case"':

sb.append(″&quot;″);

break;

default:

If(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

      nvArr[z] = sb.toString();

}

return nvArr;

}

 public void setEmail(int index, String inp){

If(this.mEmail==null){

        if(index<0){

  this.mEmail = new String[1];

  this.mEmail[0]=inp;

}else{

  this.mEmail = new String[index+1];

  this.mEmail[index]=inp;

}

}else if(index<0){

        String[]newEmail＝new String[this.mEmail.length+1];

         java.lang.System.arraycopy((Object) mEmail, 0, Object) newEmail, 0,

this.mEmail.length);

NewEmail[newEmail.length-1]=inp;

mEmail=newEmail;

    }else if(index＞＝this.mEmail.length){

        String[]newEmail＝new String[index+1];

java.lang.System.arraycopy((Object)mEmail,0,(Object)newEmail,0,

this.mEmail.length);

newEmail[index]=inp;

mEmail=newEmail;

}else{

`` this.mEmail[index]=inp;

}

}

public void setEmail(String[]inp) {

` this.mEmail=inp;

}

public void emailFromXML(String n){

setEmail(-1,n);

}

public String[]getInternet(){

return mInternet;

}

public String getInternet(int index){

If(this.mInternet==null)

return null;

If(index＞＝this.mInternet.length)

return null;

If(index＜0&&-index＞this.mInternet.length)

return null;

If(index＞＝0) return this.mInternet[index];

  return this.mInternet[this.mInternet.length+index];

}

public String[]getInternetToXML(){

String[]valArr=getInternet();

if(valArr==null) return null;

String[]nvArr=new String[valArr.length];

For(int z=0; z<nvArr.length; z++){

char[]c=valArr[z].toCharArray();

StringBuffer st = new StringBuffer();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case"':

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

nvArr[z]=sb.toString();

}

return nvArr;

}

public void setInternet(int index, String inp){

if(this.mInternet==null){

  if (index<0) {

  this.mInternet = new String[1];

` this.mInternet[0]=inp;

}else{

  this.mInternet = new String[index+1];

` this.mInternet[index]=inp;

}

}else if(index<0){

String[]newInternet=new String[this.mInternet.length+1];

java.lang.System.arraycopy((Object)mInternet, 0,

(Object) newInternet, 0, this. mInternet. length);

newInternet[newInternet.length-1]=inp;

mInternet=newInternet;

    }else if(index＞＝this.mInternet.length){

String[]newInternet=new String[index+1];

java.lang.System.arraycopy((Object)mInternet, 0,

(Object)newInternet, 0, this.mInternet.length);

newInternet[index]=inp;

mInternet=newInternet;

}else{

** this.mInternet[index]=inp;

}

}

 public void setInternet(String[]inp){

  this.mInternet=inp;

}

public void internetFromXML(String n){

setInternet(-1, n);

}

}

package com.veo.xdk.dev.schema.test.blib;

import com.veo.vsp.doclet.meta.Document;

public class Business extends Party{

public static final String DOC_TYPE="business";

String aBusinessNumber;

public Business(){

`` super(DOC_TYPE);

aBusinessNumber = new String();

}

public Business(String doc_type){

`` super(doc_type);

aBusinessNumber = new String();

}

static public Business initBusiness(String iBusinessNumber, String[]iPartyName,

AddressSet iAddressSet){

Business obj = new Business();

     obj.initializeAll(iBusinessNumber, iPartyName, iAddressSet);

return obj;

}

public void initializeAll(String iBusinessNumber, String[]iPartyName, AddressSet

iAddressSet){

aBusinessNumber＝iBusinessNumber;

`` super.initializeAll(iPartyName, iAddressSet);

}

public String getBusinessNumber(){

return aBusinessNumber;

}

public String getBusinessNumberToXML(){

If(getBusinessNumber()==null) return null;

 char[]c=getBusinessNumber().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

      switch(c[x]){

case'＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case'"':

sb.append(″&quot;″);

break;

case'\":

sb.append(″&quot;″);

break;

default:

If(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setBusinessNumber(String inp){

`` this.aBusinessNumber=inp;

}

public void businessNumberFromXML(String n){

setBusinessNumber(n);

}

}

import com.veo.vsp.doclet.meta.Document;

public class Party extends Document{

public static final String DOC_TYPE="party";

String[] mPartyName;

AddressSet mAddressSet;

public Party(){

  super(DOC_TYPE);

mPartyName = new String[0];

  this.mAddressSet = new AddressSet();

}

public Party(String doc_type){

super(doc_type);

mPartyName = new String[0];

  this.mAddressSet = new AddressSet();

}

static public Party initParty(String[]iPartyName，AddressSet iAddressSet){

Party obj = new Party();

obj.initializeAll(iPartyName, iAddressSet);

return obj;

}

public void initializeAll(String[]iPartyName，AddressSet iAddressSet){

mPartyName = iPartyName;

mAddressSet = iAddressSet;

}

public String[]getPartyName(){

return mPartyName;

}

public String getPartyName(int index){

If(this.mPartyName==null)

return null;

If(index＞＝this.mPartyName.length)

return null;

If(index＜0&&-index＞this.mPartyName.length)

return null;

If(index＞＝0) return this.mPartyName[index];

  return this.mPartyName[this.mPartyName.length+index];

}

public String[]getPartyNameToXML(){

String[]valArr=getPartyName();

if(valArr==null) return null;

String[]nvArr=new String[valArr.length];

for int z=0; z<nyArr.length; z++){

char[]c=valArr[z].toCharArray();

StringBuffer st = new StringBuffer();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case"':

sb.append(″&quot;″);

break;

default:

If(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

`` nvArr[z]=sb.toString();

}

return nvArr;

}

public void setPartyName(int index, String inp){

If(this.mPartyName==null){

         if(index＜0){

  this.mPartyName = new String[1];

** this.mPartyName[0]=inp;

}else{

  this.mPartyName = new String[index+1];

`` this.mPartyName[index]=inp;

}

}else if(index<0){

      String[]newPartyName＝new String[this.mPartyName.length+1];

java.lang.System.arraycopy((Object) mPartyName, 0,

(Object) newPartyName, 0, this. mPartyName. length);

NewPartyName[newPartyName.length-1]=inp;

mPartyName＝newPartyName;

    }else if(index＞＝this.mPartyName.length){

      String[]newPartyName＝new String[index+1];

java.lang.System.arraycopy((Object) mPartyName, 0,

(Object) newPartyName, 0, this. mPartyName. length);

NewPartyName[index]=inp;

mPartyName＝newPartyName;

}else{

** this.mPartyName[index]=inp;

}

}

public void setPartyName(String[]inp){

`` this.mPartyName=inp;

}

public void partyNameFromXML(String n){

setPartyName(-1, n);

}

public AddressSet getAddressSet(){

return mAddressSet;

}

public void setAddressSet(AddressSet inp){

  this.mAddressSet = inp;

}

}

package com.veo.xdk.dev.schema.test.blib;

import com.veo.vsp.doclet.meta.Document;

public class Person extends Party{

public static final String DOC_TYPE="person";

String aSSN;

public Person(){

`` super(DOC_TYPE);

aSSN=null;

}

public Person(String doc_type){

`` super(doc_type);

aSSN=null;

}

static public Person initPerson(String iSSN, String[]iPartyName, AddressSet

iAddressSet){

Person obj = new Person();

     obj.initializeAll(iSSN, iPartyName, iAddressSet);

return obj;

}

 public void initializeAll(String iSSN, String[]iPartyName, AddressSet iAddressSet){

aSSN=iSSN;

`` super.initializeAll(iPartyName, iAddressSet);

}

 public String getSSN(){

return aSSN;

}

 public String getSSNToXML(){

If(getSSN()==null) return null;

 char[]c=getSSN().toCharArray();

     StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

       switch(c[x]){

case'＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

      break:

case'&':

sb.append(″&″);

break;

case’″’:

sb.append(″&quot;″);

break;

case'\":

sb.append(″&quot;″);

break;

default:

If(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setSSN(String inp){

`` this.aSSN=inp;

}

public void sSNFromXML(String n){

setSSN(n);

}

}

package com.veo.xdk.dev.schema.test.blib;

import com.veo.vsp.doclet.meta.Document;

public class PrototypeService extends Document{

public static final String DOC_TYPE="prototype.service";

String mServiceName;

String[]mServiceTerms;

String[]mServiceLocation;

ServiceOperation[]mServiceOperation;

public PrototypeService(){

  super(DOC_TYPE);

mServiceName = new String();

mServiceTerms = new String[0];

mServiceLocation = new String[0];

  this.mServiceOperation = new ServiceOperation[0];

}

public PrototypeService(String doc_type){

    super(doc_type):

mServiceName = new String();

mServiceTerms = new String[0];

mServiceLocation = new String[0];

     this.mServiceOperation＝new ServiceOperation[0];

}

static public PrototypeService initPrototypeService(String iServiceName, String[]

iServiceTerms, String[]iServiceLocation, ServiceOperation[]iServiceOperation){

  PrototypeService obj = new PrototypeService();

      obj.initializeAll(iServiceName, iServiceTerms, iServiceLocation,

iServiceOperation);

return obj;

}

 public void initializeAll(String iServiceName, String[]iServiceTerms, String[]

iServiceLocation, ServiceOperation[]iServiceOperation){

mServiceName＝iServiceName;

       mServiceTerms = iServiceTerms;

       mServiceLocation = iServiceLocation;

       mServiceOperation = iServiceOperation;

}

 public String getServiceName(){

return mServiceName;

}

 public String getServiceNameToXML(){

If(getServiceName()==null) return null;

    char[]c=getServiceName().toCharArray();

     StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

       switch(c[x]){

case'＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

 break:

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setServiceName(String inp){

  this.mServiceName=inp;

}

public void serviceNameFromXML(String n){

setServiceName(n);

}

public String[]getServiceTerms(){

return mServiceTerms;

}

public String getServiceTerms(int index){

If(this.mServiceTerms==null)

return null;

If(index＞＝this.mServiceTerms.length)

return null;

  if(index＜0&&-index＞this.mServiceTerms.length)

return null;

If(index＞＝0) return this.mServiceTerms[index];

  return this.mServiceTerms[this.mServiceTerms.length+index];

}

public String[]getServiceTermsToXML(){

String[]valArr=getServiceTerms();

if(valArr==null) return null;

String[]nvArr=new String[valArr.length];

For(int z=0; z<nvArr.length; z++){

char[]c=valArr[z].toCharArray();

StringBuffer st = new StringBuffer();

StringBuffer sb = new StringBuffer();

for(int x＝0: x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case"':

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

nvArr[z]=sb.toString();

}

return nvArr;

}

 public void setServiceTerms(int index, String inp){

      if(this.mServiceTerms==null){

          if(index＜0){

      this.mServiceTerms＝new String[1];

** this.mServiceTerms[0]=inp;

      } else {

     this.mServiceTerms＝new String[index+1];

     this.mServiceTerms[index]=inp;

}

}else if(index<0){

      String[]newServiceTerms＝new String[this.mServiceTerms.length+1];

java.lang.System.arraycopy((Object)mServiceTerms, 0,

(Object) newServiceTerms, 0, this.mServiceTerms.length);

newServiceTerms[newServiceTerms.length-1]=inp;

mServiceTerms=newServiceTerms;

    }else if(index＞＝this.mServiceTerms.length){

       String[]newServiceTerms＝new String[index+1];

java.lang.System.arraycopy((Object)mServiceTerms, 0,

(Object) newServiceTerms, 0, this.mServiceTerms.length);

newServiceTerms[index]=inp;

mServiceTerms=newServiceTerms;

}else{

        this.mServiceTerms[index]=inp;

}

}

public void setServiceTerms(String[]inp){

  this.mServiceTerms=inp;

}

public void serviceTermsFromXML(String n){

setServiceTerms(-1, n);

}

public String[]getServiceLocation(){

return mServiceLocation;

}

public String getServiceLocation(int index){

If(this.mServiceLocation==null)

return null;

If(index＞＝this.mServiceLocation.length)

return null;

  if(index＜0&&-index＞this.mServiceLocation.length)

return null;

If(index＞＝0) return this.mServiceLocation[index];

  return this.mServiceLocation[this.mServiceLocation.length+index];

}

public String[]getServiceLocationToXML(){

String[]valArr=getServiceLocation();

if(valArr==null) return null;

String[]nvArr=new String[valArr.length];

For(int z=0; z<nvArr.length; z++){

char[]c=valArr[z].toCharArray();

StringBuffer st = new StringBuffer();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case"':

sb.append(″&quot;″);

break;

default:

If(Character. isDefined(c[x]))

sb.append(c[x]);

            }

            }

** nvArr[z]=sb.toString();

            }

return nvArr;

}

 public void setServiceLocation(int index, String inp){

      if(this.mServiceLocation==null){

           if(index＜0){

      this.mServiceLocation = new String[1];

** this.mServiceLocation[0]=inp;

        } else {

      this.mServiceLocation = new String[index+1];

      this.mServiceLocation[index]=inp;

            }

}else if(index<0){

          String[] newServiceLocation＝new

String[this.mServiceLocation.length+1];

          java.lang.System.arraycopy((Object)mServiceLocation, 0,

(Object) newServiceLocation, 0, this.mServiceLocation.length);

newServiceLocation[newServiceLocation.length-1]=inp;

mServiceLocation＝newServiceLocation;

     }else if(index＞＝this.mServiceLocation.length){

       String[]newServiceLocation＝new String[index+1];

java.lang.System.arraycopy((Object)mServiceLocation, 0,

(Object) newServiceLocation, 0, this.mServiceLocation.length);

newServiceLocation[index]=inp;

mServiceLocation＝newServiceLocation;

}else{

        this.mServiceLocation[index]=inp;

}

}

 public void setServiceLocation(String[]inp){

      this.mServiceLocation=inp;

}

 public void serviceLocationFromXML(String n){

setServiceLocation(-1, n);

}

 public ServiceOperation[]getServiceOperation(){

return mServiceOperation;

}

 public ServiceOperation getServiceOperation(int index){

If (this.mServiceOperation==null)

return null;

If(index＞＝this.mServiceOperation.length)

return null;

If(index＜0&&-index＞this.mServiceOperation.length)

return null;

If (index＞=0) return this.mServiceOperation[index];

       return this.mServiceOperation[this.mServiceOperation.length+index];

}

 public void setServiceOperation(int index, ServiceOperation inp){

     if(this.mServiceOperation==null){

          if(index＜0){

     this.mServiceOperation＝new ServiceOperation[1];

** this.mServiceOperation[0]=inp;

      } else {

     this.mServiceOperation＝new ServiceOperation[index+1];

      this.mServiceOperation[index]=inp;

}

}else if(index<0){

          ServiceOperation[]newServiceOperation＝new

ServiceOperation[this.mServiceOperation.length+1];

         java.lang.System.arraycopy((Object)mServiceOperation, 0,

(Object) newServiceOperation, 0, this.mServiceOperation.length);

newServiceOperation[newServiceOperation.length-1]=inp;

          mServiceOperation = newServiceOperation;

    }else if(index＞＝this.mServiceOperation.length){

         ServiceOperation[]newServiceOperation＝new ServiceOperation[index+1]:

         java.lang.System.arraycopy((Object)mServiceOperation, 0,

(Object) newServiceOperation, 0, this.mServiceOperation.length);

newServiceOperation[index]=inp;

mServiceOperation＝newServiceOperation;

        } else {

        this.mServiceOperation[index]=inp;

}

}

 public void setServiceOperation(ServiceOperation[]inp){

     this.mServiceOperation=inp;

}

}

package com.veo.xdk.dev.schema.test.blib;

import com.veo.vsp.doclet.meta.Document;

public class Service extends Document{

public static final String DOC_TYPE="service";

String mServiceName;

String mServiceLocation;

ServiceOperation[]mServiceOperation;

String mServiceTerms;

public Service(){

`` super(DOC_TYPE);

mServiceName = new String();

mServiceLocation = new String();

     this.mServiceOperation＝new ServiceOperation[0];

mServiceTerms = new String();

}

 public Service(String doc_type){

`` super(doc_type);

mServiceName = new String();

mServiceLocation = new String();

     this.mServiceOperation＝new ServiceOperation[0];

mServiceTerms = new String();

}

static public Service initService(String iServiceName, String

iServiceLocation, ServiceOperation[] iServiceOperation, String iServiceTerms){

  Service obj = new Service();

     obj.initializeAll(iServiceName, iServiceLocation, iServiceOperation,

iServiceTerms);

return obj;

}

public void initializeAll(String iServiceName, String

iServiceLocation, ServiceOperation[] iServiceOperation, String iServiceTerms){

mServiceName＝iServiceName;

      mServiceLocation = iServiceLocation;

      mServiceOperation = iServiceOperation;

      mServiceTerms = iServiceTerms;

}

 public String getServiceName(){

return mServiceName;

}

 public String getServiceNameToXML(){

If(getServiceName()==null) return null;

   char[]c=getServiceName().toCharArray();

     StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

       switch(c[x]){

case'＞':

sb.append(″&gt;″):

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setServiceName(String inp){

  this.mServiceName=inp;

}

public void serviceNameFromXML(String n){

setServiceName(n);

}

public String getServiceLocation(){

return mServiceLocation:

}

public String getServiceLocationToXML(){

If(getServiceLocation()==null) return null;

char[]c=getServiceLocation().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setServiceLocation(String inp){

  this.mServiceLocation = inp;

}

public void serviceLocationFromXML(String n){

setServiceLocation(n);

}

public ServiceOperation[]getServiceOperation(){

return mServiceOperation;

}

public ServiceOperation getServiceOperation(int index){

If(this.mServiceOperation==null)

return null;

If(index＞＝this.mServiceOperation.length)

return null;

     if(index＜0&&-index＞this.mServiceOperation.length)

return null;

If(index＞＝0) return this.mServiceOperation[index];

  return this.mServiceOperation[this.mServiceOperation.length+index];

}

 public void setServiceOperation(int index, ServiceOperation inp){

If(this.mServiceOperation==null){

         if(index＜0){

    this.mServiceOperation＝new ServiceOperation[1];

     this.mServiceOperation[0]=inp;

}else{

  this.mServiceOperation＝new ServiceOperation[index+1];

    this.mServiceOperation[index]=inp;

}

}else if(index<0){

          ServiceOperation[]newServiceOperation＝new

ServiceOperation[this.mServiceOperation.length+1];

         java.lang.System.arraycopy((Object)mServiceOperation, 0,

(Object) newServiceOperation, 0, this.mServiceOperation.length);

newServiceOperation[newServiceOperation.length-1]=inp;

          mServiceOperation = newServiceOperation;

    }else if(index＞＝this.mServiceOperation.length){

       ServiceOperation[]newServiceOperation＝new ServiceOperation[index+1];

         java.lang.System.arraycopy((Object)mServiceOperation, 0,

(Object)newServiceOperation, 0, this.mServiceOperation.length);

newServiceOperation[index]=inp;

          mServiceOperation = newServiceOperation;

}else{

       this.mServiceOperation[index]=inp;

}

}

 public void setServiceOperation(ServiceOperation[]inp){

     this.mServiceOperation=inp;

}

 public String getServiceTerms(){

return mServiceTerms;

}

 public String getServiceTermsToXML(){

If(getServiceTerms()==null) return null;

 char[]c=getServiceTerms().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

     switch(c[x]){

case'＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case'\":

sb.append(″&quot;″);

break;

default:

If(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setServiceTerms(String inp){

  this.mServiceTerms=inp;

}

public void serviceTermsFromXML(String n){

setServiceTerms(n);

}

}

package com.veo.xdk.dev.schema.test.blib;

import com.veo.vsp.doclet.meta.Document;

public class ServiceOperation extends Document{

Public static final String DOC_TYPE="service.operation";

String mServiceOperationName;

String mServiceOperationLocation;

String mServiceOperationlnput;

String mServiceOperationOutput;

public ServiceOperation(){

`` super(DOC_TYPE);

mServiceOperationName = new String();

mServiceOperationLocation = new String();

  mServiceOperationInput = new String();

mServiceOperationOutput = new String();

}

 public ServiceOperation(String doc_type){

`` super(doc_type);

mServiceOperationName = new String();

mServiceOperationLocation = new String();

  mServiceOperationInput = new String();

mServiceOperationOutput = new String();

}

static public ServiceOperation initServiceOperation(String iServiceOperationName,

String iServiceOperationLocation, String iServiceOperationInput, String

iServiceOperationOutput){

     ServiceOperation obj = new ServiceOperation();

      obj.initializeAll(iServiceOperationName, iServiceOperationLocation,

iServiceOperationInput, iServiceOperationOutput);

return obj;

}

 public void initializeAll(String iServiceOperationName, String

iServiceOperationLocation, String iServiceOperationInput, String

iServiceOperationOutput){

      mServiceOperationName＝iServiceOperationName;

mServiceOperationLocation=iServiceOperationLocation;

mServiceOperationInput = iServiceOperationInput;

mServiceOperationOutput＝iServiceOperationOutput;

}

public String getServiceOperationName(){

return mServiceOperationName;

}

public String getServiceOperationNameToXML(){

If(getServiceOperationName()==null) return null;

 char[]c=getServiceOperationName().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setServiceOperationName(String inp){

  this.mServiceOperationName=inp;

}

public void serviceOperationNameFromXML(String n){

setServiceOperationName(n);

}

public String getServiceOperationLocation(){

return mServiceOperationLocation;

}

public String getServiceOperationLocationToXML(){

If(getServiceOperationLocation()==null) return null;

 char[]c=getServiceOperationLocation().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setServiceOperationLocation(String inp){

  this.mServiceOperationLocation = inp;

}

public void serviceOperationLocationFromXML(String n){

setServiceOperationLocation(n);

}

public String getServiceOperationInput(){

return mServiceOperationInput;

}

public String getServiceOperationInputToXML(){

If(getServiceOperationInput()==null) return null;

char[]c=getServiceOperationInput().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setServiceOperationInput(String inp){

  this.mServiceOperationInput=inp;

}

public void serviceOperationInputFromXML(String n){

setServiceOperationInput(n);

}

public String getServiceOperationOutput(){

return mServiceOperationOutput;

}

public String getServiceOperationOutputToXML(){

If(getServiceOperationOutput()==null) return null;

char[]c=getServiceOperationOutput().toCharArray();

StringBuffer sb = new StringBuffer();

for(int x=0; x<c.length; x++){

switch(c[x]){

case '＞':

sb.append(″&gt;″);

break;

case'<':

sb.append(″&lt;″);

break;

case'&':

sb.append(″&″);

break;

case '"':

sb.append(″&quot;″);

break;

case '\":

sb.append(″&quot;″);

break;

default:

if(Character. isDefined(c[x]))

sb.append(c[x]);

}

}

return sb.toString();

}

public void setServiceOperationOutput(String inp){

  this.mServiceOperationOutput=inp;

}

public void serviceOperationOutputFromXML(String n){

setServiceOperationOutput(n);

}

}

package com.veo.xdk.dev.schema.test.blib;

import com.veo.vsp.doclet.meta.Document;

public class ServiceSet extends Document{

public static final String DOC_TYPE="service.set";

Service[]mService;

public ServiceSet(){

  super(DOC_TYPE);

  this.mService = new Service[0];

}

public ServiceSet(String doc_type){

super(doc_type);

  this.mService = new Service[0];

}

static public ServiceSet initServiceSet(Service[]iService){

ServiceSet obj = new ServiceSet();

  obj.initializeAll(iService);

return obj;

}

public void initializeAll(Service[]iService){

mService＝iService;

}

public Service[]getService(){

return mService;

}

public Service getService(int index){

If(this.mService==null)

return null;

If(index＞＝this.mService.length)

return null;

      if(index＜0&&-index＞this.mService.length)

return null;

  if (index＞＝0) return this.mService[index];

  return this.mService[this.mService.length+index];

}

public void setService(int index，Service inp){

If(this.mService==null){

     if(index＜0){

  this.mService = new Service[1];

  this.mService[0]=inp;

}else{

  this.mService = new Service[index+1];

  this.mService[index]=inp;

}

}else if(index<0){

        Service[]newService＝new Service[this.mService.length+1];

java.lang.System.arraycopy((Object)mService, 0,

(Object) newService, 0, this. mService. length);

newService[newService.length-1]=inp;

          mService = newService;

}else if(index＞＝this.mService.length){

         Service[]newService＝new Service[index+1];

java.lang.System.arraycopy((Object)mService, 0,

(Object) newService, 0, this. mService. length);

newService[index]=inp;

      mService = newService;

}else{

      this.mService[index]=inp;

}

}

public void setService(Service[]inp){

  this.mService = inp;

}

}

In addition to the above JAVA beans, conversion code is generated as follows for translation from JAVA to XML and translation from XML to JAVA:

Java to XML

<! DOCTYPE tree SYSTEM″tree.dtd″>

<tree source="null" pass-through="false">

<before>

<vardef name="attribute.def">

<element source="ATTRIBUTE" class="NAME" type="5" position="-2">

<parse>

<data class="java.lang.String" position="-2"/>

</parse>

</element>

</vardef>

<vardef name="pcdata.def">

<element source="PCDATA" class="NAME" type="4" position="-2">

<parse>

<data class="999"type="6"position="-2"/>

</parse>

</element>

</vardef>

<vardef name="content.def">

<element source="PCDATA">

<parse>

<data class="999"type="6"position="-2"/>

</parse>

</element>

</vardef>

<vardef name="ServiceSet.var">

<element source="com.veo.xdk.dev.schema.test.blib.ServiceSet" class="service.set"

type="4"position="-2">

<parse>

<callvar name="Service.var"/>

</parse>

</element>

</vardef>

<vardef name="PrototypeService.var">

<element source = "com.veo.xdk.dev.schema.test.blib.PrototypeService" class =

"prototype.service" type="4" position="-2">

<parse>

<callvar name="pcdata.def" parms="setSource ServiceNameToXML setGenerator

service.name"/>

<callvar name="pcdata.def" parms="setSource ServiceTermsToXML setGenerator

service.terms"/>

<callvar name="pcdata.def" parms="setSource ServiceLocationToXML setGenerator

service.location"/>

<callvar name="ServiceOperation.var"/>

</parse>

</element>

</vardef>

<vardef name="Service.var">

<element source = "com.veo.xdk.dev.schema.test.blib.Service" class = "service" type =

"8"position="0">

<parse>

<callvar name="pcdata.def" parms="setSource ServiceNameToXML setGenerator

service.name"/>

<callvar name="pcdata.def" parms="setSource ServiceLocationToXML setGenerator

service.location"/>

<callvar name="ServiceOperation.var"/>

<callvar name="pcdata.def" parms="setSource ServiceTermsToXML setGenerator

service.terms"/>

</parse>

</element>

</vardef>

<vardef name="ServiceOperation.var">

<element source="com.veo.xdk.dev.schema.test.blib.ServiceOperation"class=

"service.operation"type="4"position="-2">

<parse>

<callvar name="pcdata.def" parms="setSource ServiceOperationNameToXML setGenerator

service.operation.name"/>

<callvar name="pcdata.def" parms="setSource ServiceOperationLocationToXML

setGenerator service.operation.location"/>

<callvar name="pcdata.def" parms="setSource ServiceOperationInputToXML setGenerator

service.operation.input"/>

<callvar name="pcdata.def" parms="setSource ServiceOperationOutputToXML

setGenerator service.operation.output"/>

</parse>

</element>

</vardef>

</before>

<parse>

<callvar name="ServiceSet.var"/>

<callvar name="PrototypeService.var"/>

<callvar name="Service.var"/>

<callvar name="ServiceOperation.var"/>

</parse>

</tree>

XML to Java

<! DOCTYPE tree SYSTEM″tree.dtd″>

<tree source="null" pass-through="false">

<before>

<vardef name="business.var">

<element source="business"

class="com.veo.xdk.dev.schema.test.blib.Business"

type = "7" setter = "setBusiness">

<before>

<onattribute name="business.number">

<actions>

<callmeth name="businessNumberFromXML">

<parms>

<getattr name="business.number"/>

</parms>

</callmeth>

</actions>

</onattribute>

</before>

<parse>

<callvar name="party.name.var"parms="setPosition-1"/>

<callvar name="address.set.var"/>

</parse>

</element>

</vardef>

<vardef name="party.name.var">

<element source = "party.name" setter = "partyNameFromXML" position = "-1" class =

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="city.var">

<element source = "city" setter = "cityFromXML" position = "-1" class =

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="internet.var">

<element source = "internet" setter = "internetFromXML" position = "-1" class =

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="country.var">

<element source = "country" setter = "countryFromXML" position = "-1" class =

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="state.var">

<element source = "state" setter = "stateFromXML" position = "-1" class =

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="email.var">

<element source = "email" setter = "emailFromXML" position = "-1" class =

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="address.physical.var">

<element source="address.physical"

class="com.veo.xdk.dev.schema.test.blib.AddressPhysical"

type = "7" setter = "setAddressPhysical">

<before>

</before>

<parse>

<callvar name="street.var" parms="setPosition -1"/>

<callvar name = "city.var" parms = "setPosition -1"/>

<callvar name="state.var" parms="setPosition -1"/>

<callvar name="postcode.var" parms="setPosition -1"/>

<callvar name="country.var" parms="setPosition -1"/>

</parse>

</element>

</vardef>

<vardef name="telephone.var">

<element source = "telephone" setter = "telephoneFromXML" position = "-1" class =

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="person.var">

<element source="person"

class="com.veo.xdk.dev.schema.test.blib.Person"

type = "7" setter = "setPerson">

<before>

<onattribute name="SSN">

<actions>

<callmeth name="sSNFromXML">

<parms>

<getattr name="SSN"/>

</parms>

</callmeth>

</actions>

</onattribute>

</before>

<parse>

<callvar name="party.name.var"parms="setPosition -1"/>

<callvar name="address.set.var"/>

</parse>

</element>

</vardef>

<vardef name="fax.var">

<element source = "fax" setter = "faxFromXML" position = "-1" class = "java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="street.var">

<element source = "street" setter = "streetFromXML" position = "-1" class =

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="address.set.var">

<element source="address.set"

class="com.veo.xdk.dev.schema.test.blib.AddressSet"

type = "7" setter = "setAddressSet">

<before>

</before>

<parse>

<callvar name="address.physical.var"/>

<callvar name="telephone.var" parms="setPosition -1"/>

<callvar name="fax.var"parms="setPosition -1"/>

<callvar name="email.var" parms="setPosition -1"/>

<callvar name="internet.var" parms="setPosition -1"/>

</parse>

</element>

</vardef>

<vardef name="postcode.var">

<element source = "postcode" setter = "postcodeFromXML" position = "-1" class

"java.lang.String">

<parse>

<data class="java.lang.String" position="0"/>

</parse>

</element>

</vardef>

<vardef name="market.participant.var">

<element source="market.participant"

class="com.veo.xdk.dev.schema.test.blib.MarketParticipant"

type="7"position="0">

<before>

</before>

<parse>

<callvar name="business.var"/>

<callvar name="person.var"/>

</parse>

</element>

</vardef>

</before>

<parse>

<callvar name="business.var"/>

<callvar name="party.name.var"/>

<callvar name="city.var"/>

<callvar name="internet.var"/>

<callvar name="country.var"/>

<callvar name="state.var"/>

<callvar name="email.var"/>

<callvar name="address.physical.var"/>

<callvar name="telephone.var"/>

<callvar name="person.var"/>

<callvar name="fax.var"/>

<callvar name="street.var"/>

<callvar name="address.set.var"/>

<callvar name="postcode.var"/>

<callvar name="market.participant.var"/>

</parse>

</tree>

Makefiles:

#

# this makefile was generated by bic version 0.0. 05/02/1998

#

#

#

#

# get the package name from the package argument passed to SchemaGen

PACKAGE_NAME=com/veo/xdk/dev/schema/test/blib

JAVA_SOURCES += \

MarketParticipant.java\

Business.java\

Person.java\

Party.java\

AddressPhysical.java\

AddressSet.java\

MAKEFILE_MASTER_DIR=xxx

include $(MAKEFILE_MASTER_DIR)/Makefile.master

all::$(JAVA_CLASSES)

#

# this makefile was generated by bic version 0.0. 05/02/1998

#

#

#

#

# get the package name from the package argument passed to SchemaGen

PACKAGE_NAME=com/veo/xdk/dev/schema/test/blib

JAVA_SOURCES += \

ServiceSet.java\

PrototypeService.java\

Service.java\

ServiceOperation.java\

MAKEFILE_MASTER_DIR=xxx

include $(MAKEFILE_MASTER_DIR)/Makefile.master

all::$(JAVA_CLASSES)

Finally, here is an instance of an XML document generated at runtime according to the above model as an example:

<! DOCTYPE market.participant SYSTEM″market.participant.dtd″>

<market. participant>

<business business.number="1234567890">

<party.name>IBM</party.name>

<address.set>

<address.physical>

<street>1 IBM Way</street>

<city>Palo Alto</city>

<state>CA</state>

<postcode>94304</postcode>

<country>USA</country>

</address.physical>

....

<telephone>123 456-7890</telephone>

<fax>123 456 0987</fax>

<email>ibmec@ibm.com</email>

</address.set>

</business>

</market.participant>

<! DOCTYPE service SYSTEM ″service.dtd″>

<service.set>

<service>

<service.name>Order Service</service.name>

<service.location>www.ibm.com/order</service.location>

<service. operation>

<service.operation.name>Submit Order</service.operation.name>

<service.operation.location>www.ibm.com/order/submit</service.location>

<service.operation.input>urn:x-

ibm:services:order:operations:po.dtd</service.operation.input>

<service.operation.output>urn:x-

ibm:services:order:operations:poack.dtd</service.operation.output>

</service.operation>

<service. operation>

<service.operation.name>Track Order</service.operation.name>

<service.operation.location>www.ibm.com/order/track</service.location>

<service.operation.input>urn:x-

ibm:services:order:operations:track.irequest.dtd</service.operation.input>

<service.operation.output>urn:x-

ibm:services:order:operations:track.iresponse.dtd</service.operation.output>

</service.operation>

</service>

</service.set>

Using various tools as well as the BID Composite application (providing a drag, drop and form editing user interface), the developer can create business interface definitions and produce well-formed, valid business interface definitions in the form of XML documents. Thus, the exemplary runtime instance is defined by the business interface used by Ingram Micro for the IBM order service and other order services for ordering laptop computers from IBM. (Applicant has no relationship with IBM or Ingram Micro). Using these procedures, a user can build a system that allows business interfaces to be programmed with documents defined according to the invention.

Through the following description of purchase order processing, the functions of the CBL and BID processors of the present invention in the XML/JAVA environment can be further understood.

Company A defines its purchase order document type with a visible programming environment that includes a library of CBL DTDs and modules defined in common business language elements, so they include Data types and other explanatory information. Company A's PO may contain only minimal customization in terms of providing the more general "transaction document" scope of the CBL library, or it may be constructed entirely from address, period and time, currency, etc. CBL modules.

Documents for general "transaction document" specifications (such as transact.dtd above) represent the way CBL specifications are built by modules and interlinked with other CBL DTDs.

The compiler takes the purchase order definition and generates several different object forms. All of these target forms can be derived by a "tree-to-tree" transformation of the original specification. The most important parts of this example are:

(a) XML DTD for purchase order

(b) JAVA bean, which encapsulates the data structure of the purchase order (establishes the structure of JAVA classes, formal parameters, data types, methods and exceptions, corresponding to the information in the purchase order schema definition).

(c) "Extradition" program, which converts Purchase Orders conforming to the Purchase Order DTD into Purchase Order JAVA beans, or loads them into a database, or creates HTML (or XSL formatted pages) for converting Purchase Orders displayed in the browser.

(d) A "non-extradition" program that extracts data values from the Purchase Order JAVA bean and converts them into an XML document that conforms to the Purchase Order DTD.

Now back to the script. The purchasing application generates a purchase order conforming to the DTD specified as the service interface for the supplier accepting the purchase order.

The purchase order DTD is used by the parser to decompose the purchase order instance into a stream of information about the elements and attribute values it contains. Then, by wrapping these "property groups" with JAVA code, they are converted into corresponding JAVA event objects. In effect, this transformation treats fragments of markup XML documents as instructions in a custom programming language whose syntax is defined by a DTD. These JAVA events can now be handled with the extradition application generated by the compiler to "load" the JAVA bean data structure.

Converting an XML document into a set of JAVA application events for processing is unlike the normal parsing model where parser output is maintained as an internal data structure and processing does not start until after parsing is complete. Responding to the event-based processing defined by the BID is the key to making the processor more functional, as it allows an incoming document application to begin processing as soon as the first event is emitted.

JAVA programs for "listening" to various types of events are generated from the schema definitions for those events. These listeners are programs used to implement business logic associated with the XML definitions in the CBL, for example associated with an "address" element could be a code to validate a postal code by checking a database. These listeners "subscribe" to events by registering with the document router, which directs relevant events to all users interested in them.

This publish and subscribe architecture means that new listener programs can be added without knowing or affecting existing listener programs. Each listener has a queue into which the router feeds its events, and this queue enables multiple listeners to process events in parallel at their own pace.

For the purchase order example exemplified here, there could be listeners with the following purposes:

A purchase order, which can be linked to an order entry program,

● product description, it is possible to check stock availability,

● Address information, which can be checked for Fed Ex or other postal services,

• Buyer information, which can check order history (for credit, or promotion, or similar based on who the customer is known to be).

Complex listeners can be created through configuration of primitive listeners (for example, a purchase order listener can contain and call these listeners here, or they can be called by themselves).

FIG. 11 shows market maker sites in the network of FIG. 1 . The market maker site includes the basic structure of the system in Figure 3, including a network interface 1101, a document parser 1102, a document-to-host and host-to-document translator 1103, and a front end 1104, called a router in this example. The market maker module 1105 in this example includes a set of business interface definitions, or other identifiers sufficient to support market maker functions for participants in the market, CBL resource libraries, and compilers, all of which serve market participants . Router 1104 includes participant registries and document filters that correspond to events generated at the output of the translator and are routed by the parser to input documents based on element and attribute filters between the participant registries and listeners, providing them with to the XML event generator. Thus, certain participants in the marketplace may register to receive documents that satisfy predetermined parameters. For example, documents may be filtered at router 1104 with an input document that is based on a particular DTD and that includes attributes such as the number of product pre-orders greater than a threshold, or the highest price for a pre-order document request. Then, only those documents that are consistent with the information registered in the participant's registration at the router 1104 are transmitted to the registered participants.

Router 1104 may also provide local host services 1105 and 1106, thus acting as a participant in the market as well as a market maker. Generally speaking, the documents received by the router 1104 are traversed to determine the destinations to which these documents should be sent, and here, if necessary, they can be sent back through the translator 1103 again and out of the network interface 1101 to reach their respective destinations.

A market maker is a server that bundles together a set of internal and external business services to create a virtual enterprise or trading community. The server parses the input document and invokes the appropriate service by switching product data requests to a catalog server, or sending a purchase order to an ERP system. The server also handles translation tasks, mapping information from the company's XML documents to the document formats used by the parties to the transaction as well as the data formats required by their legacy systems.

For the above service definition, when the company issues a purchase order, the XML parser in the server converts the purchase order instance into a stream of information events using the purchase order DTD. These events are then passed to applications programmed to handle events of a certain type; in some cases, the information is sent in its entirety to various businesses over the Internet. In the purchase order example, several applications can act on the information from the parser:

●The order entry program processes the purchase order into a complete message;

● The ERP system checks the stock of the product stated in the purchase order;

●Customer database to verify or update the customer's address;

●The shipping company uses the address information to schedule the delivery;

●The bank authorizes the transaction with the credit card information.

Parties to a transaction only need to agree on the structure, content and sequence of the business documents they exchange, not on the details of the API. How documents are processed and what actions are taken is strictly up to the business providing the service. This improves integration from the system level to the enterprise level. This enables the enterprise to present a clear and stable interface with other business partners despite changes in its internal technical implementation, organization or processing.

Figures 12, 13 and 14 illustrate the processes performed at the market maker site in the system of Figure 11 . In FIG. 12, at a network interface, an input document is received from an originating participant site (step 1200). Perform syntax analysis on the document (step 1201). The document is translated into the host's format, eg, from XML to JAVA (step 1202). Host-formatted events and objects are then passed to the router service (step 1203). Services registered to receive documents based on document type and document content are identified (step 1204). The document or a portion of the document is transmitted to the identified service (step 1205). Serving is performed in response to document content (step 1206). Generate output data of the service (step 1207). The output is converted into a document format, such as from JAVA format to XML format (step 1208). Finally, the output document is sent to the participant node (step 1209).

Registry service is a function managed by the router. Accordingly, as shown in FIG. 13, a market participant document is accepted at the web interface (step 1300). Store the market participant documents in the business interface definition resource library of the market maker network (step 1301). In addition, the document is parsed (step 1302). The parsed document is translated into the host's format (step 1303). Next, the document is transmitted to the router service (step 1304). The router service includes a listener that identifies the registry service as the destination of the document based on the document type and content (step 1305). The document or elements of the document are transmitted to the registration service (1306). In the registration service, the required service specification is retrieved according to the business interface definition (step 1307). If the service specification is assembled in step 1308, then router service filter is set according to the business interface definition and service specification (step 1309). Registration confirmation data is generated (step 1310). The registration confirmation data is converted into a document format (step 1311). Finally, a confirmation document is sent to the participant site, indicating to the participant that a successful registration with the market maker has been made (step 1312).

FIG. 14 illustrates the process of assembling required service specifications in step 1307 . The process begins by locating service business interface definitions supported by market participants (step 1400). For example, service definitions are retrieved (step 1401) through email transactions or network access to a repository site. Store the service specification in the BID repository (step 1402). Perform syntax analysis on the service business interface definition document (step 1403). The analyzed document is translated into the master format (step 1404). The master object is passed to the router service (step 1405). Registration services are identified based on document type and content (step 1406). Finally, according to the process in Figure 13, the information in the service business interface definition document is transmitted to the registration service (step 1407) for use.

Figure 15 shows a sequence of processors, components and processing of input data at a market maker site according to the invention. The market maker site includes a communication agent 1500 at the network interface. The communication agent is connected to the XML parser 1501 , and the XML parser provides events to the XML processor 1502 . XML processors feed events to document routers. The document router provides a document service 1504, which in turn provides an interface for providing received documents to enterprise solution software 1505 in the host system. Communication agent 1500 is an Internet interface that includes an appropriate protocol stack supporting protocols such as HTTP, SMTP, FTP, or others. Thus, input data may come in XML syntax, ASCII data syntax, or other syntax appropriate to the particular communication channel. All documents received in non-XML syntax are translated into XML and passed to the XML parser. Translation tables 1506 are used to support translations from non-XML forms to XML forms.

The converted document is provided to the parser 1501 . The XML parser parses the received XML document according to the matching document type definition. The parser sends the document back to the communication agent 1500 if errors are found. The Business Interface Definition Compiler BIDC 1507 acts as a Business Interface Definition Data Compiler. By compiling the BID data, establish the DTD file of the XML parser, the JAVA beans corresponding to the DTD file, and the translation rules for translating the DTD file into JAVA beans. By referring to these tools, the XML instance is translated into a JAVA instance. Therefore, the BID compiler 1507 stores the DTD document 1508 and generates a corresponding JAVA document 1509 . The XML documents are passed to processor 1502 which translates them into JAVA format. In a preferred system, a JAVA document is generated having the same status as the document type definition received in XML format. Transfer the JAVA beans to the document router 1503. The document router 1503 receives the JAVA beans and passes the received classes to the appropriate document service using a registry (eg, using the event listener architecture described above). Document Service 1504, which receives documents in the form of JAVA beans from Router 1503, acts as an interface to the enterprise solution software. This includes a registry service 1510 through which listeners for XML events are coupled to the incoming data stream, and a service manager 1511 for managing delivery of incoming documents to the appropriate service. The document service manager 1511 manages registration services and maintains document consistency.

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

Figure 16 provides a heuristic diagram of the market maker and market participant structure of the present invention. Therefore, as shown in FIG. 16, the electronic commerce market of the present invention can be logically organized. On top of the organization, market maker outlets 1600 are established. The Market Maker site includes resources for building a market 1601. Such resources include market registry services, among others. Enterprises 1602 are registered in marketplace 1601 by publishing business interface definitions. The business interface defines the services 1603 that define the business transactions that the business will participate in. Transactions 1604 and services 1603 define inputs and outputs with documents 1605, and delineate trade relationships between participants in the transaction. The document includes content 1606, which contains the participants in each transaction. The manner in which market participants and market makers process content is completely independent of the document-based e-commerce network established in accordance with the present invention. Overall, a robust, scalable, and intuitive architecture is provided that enables electronic commerce over communication networks.

Accordingly, the present invention provides an XML processor-based platform in an exemplary system and uses XML documents as an interface between loosely coupled business systems. Documents are passed between businesses and processed by participant outlets before entering the company's business systems. Thus, the platform enables e-business applications to work across enterprises, with each business system working with different internal business platforms, processes, and semantics by specifying a common set of business documents and forms.

According to the present invention, a virtual enterprise is established by interconnecting business systems and services, and the virtual enterprise is mainly defined by documents (XML encoded) received and generated by the enterprise:

● "If you send me a catalog request, I will send you a catalog"

● "If you send me a purchase order, and I can accept it, then I will send you an invoice."

The foregoing description of the preferred embodiment of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many variations and modifications will occur to those skilled in the art. The scope of the invention is defined by the following claims and their equivalents.

Claims (118)

1. A device for establishing a participant interface for transactions performed on a system, characterized in that the device comprises: memory for storing data and instruction programs; A data processor, connected to a memory, for executing a program of instructions; wherein the program of instructions includes: Means (700) for establishing a participant interface definition (205) for a participant in a particular transaction, said participant interface definition comprising said participant's input document definition (213) and said participant's output document definition (219), said input and output document definitions comprising a machine-readable description of each set of storage units and the logical structure of each set of storage units; and a compiler (1507), responsive to said input and output document definitions (205), for compiling data structures corresponding to logical structures of storage unit groups and input and output documents, wherein storage unit groups and input and output documents The logical structure complies with the transaction processing architecture; it is used to compile system-executable instructions to translate the input document into corresponding data structures (703); and compile system-executable instructions to translate the output of the transaction processing process into Each group of storage units and the logical structure of the output document (703). 2. The apparatus of claim 1, wherein the resource library is stored in a memory accessible to the data processor, and the means for establishing the actor interface definition includes system-executable instructions to extract from the resource library An element of an access definition, the repository stores a library of logical structures and logical structure interpretation information used to build interface descriptions. 3. The device of claim 2, wherein the repository stores document definitions comprising logical structures. 4. The apparatus of claim 1, wherein the means for establishing an actor interface definition comprises system-executable instructions to: access another participant interface definition of the supplementary transaction, the accessed definitions include the definition of the input document of the supplementary transaction, and the definition of the output document of the supplementary transaction; and A participant interface definition is built by including the output document definition of the supplementary transaction as the definition of the input document of the interface being built. 5. The apparatus of claim 4, wherein the means for establishing a participant interface definition includes system-executable instructions to Include the input document definition of the supplementary transaction as the output document definition of the interface being built. 6. The apparatus of claim 1, wherein the means for establishing an actor interface definition includes system-executable instructions to create a document that conforms to an actor interface document definition, the actor interface document definition Included are logical structures for storing an identifier of a particular transaction and storing at least one of input and output document definitions and references to definitions for the particular transaction. 7. The apparatus of claim 1, wherein the means for establishing an actor interface definition includes system-executable instructions to create a document that conforms to an actor interface document definition, the actor interface document definition includes a logical structure for storing an identifier of a participant interface and storing at least one of a specification and a reference to a specification for one or more transaction groups supported by the participant interface kind. 8. The apparatus of claim 7, wherein the document conforming to the actor interface definition includes a reference to a machine-readable specification of a particular transaction, and the specification of the particular transaction includes a document comprising Logical structures for storing at least one of input and output document definitions and references to definitions for that particular transaction. 9. The apparatus of claim 1, wherein the storage unit includes parsed data. 10. The apparatus of claim 9, wherein the parsed data in at least one of the input and output documents comprises: character data for encoding text characters in one of the input and output documents, and Markup data for identifying groups of storage units based on the logical structure of one of the input and output documents. 11. The apparatus of claim 10, wherein at least one set of memory cells encodes a plurality of text characters providing natural language words. 12. The apparatus of claim 9, wherein the specification includes interpretation information for at least one group of storage units, the interpretation information encoding the definition of each group of parsed characters, and the storage unit is defined by the input and The logical structure of at least one document in the output document is identified. 13. The apparatus of claim 9, wherein the memory location includes unparsed data. 14. The device according to claim 1, characterized in that, according to different transaction processing architectures, data structures corresponding to groups of storage units and logical structures of input and output documents include programming objects containing a number of variables and methods. 15. The apparatus of claim 1, wherein the different transaction processing architecture of the transaction process comprises a process conforming to the interface description language. 16. The apparatus of claim 1, wherein the input and output document definitions comprise document type definitions conforming to the standard Extensible Markup Language XML. 17. The apparatus of claim 3, wherein the definition of one of the input and output documents includes a reference to a document type in the repository. 18. The apparatus of claim 2, wherein the resource repository includes interpretation information for metrics of product subjects specifying transactions. 19. The apparatus of claim 2, wherein the resource repository includes interpretation information for specifying costs of product subjects of a transaction. 20. The apparatus of claim 2, wherein the resource repository includes interpretation information specifying characteristics of product subjects of the transaction. 21. The apparatus of claim 2, wherein the repository includes interpretation information specifying monetary terms of the transaction. 22. The apparatus of claim 2, wherein the resource repository includes explanatory information for shipping items of a product subject of a specified transaction. 23. A method for performing a transaction between nodes in a network, said network comprising a plurality of nodes for performing the processes involved in the transaction, comprising the steps of: Storing a machine-readable transaction interface specification, wherein the specification includes an input document definition and an output document definition, and the input and output document definitions include a description of each group of storage units and the logical structure of each group of storage units; receiving data including a document via a communication network; parsing the document according to the specification to identify an input document; providing at least a portion of the input document to a transaction process in a machine-readable format for generating an output; from said specification, an output document is formed, the output document including the output defined in accordance with the output document; and The output document is transmitted over the communication network. 24. The method of claim 23, comprising the steps of: For said transaction, accessing a supplementary interface specification provided by another site in the network, the accessed specification includes an input document definition of the supplementary interface, and an output document definition of the supplementary interface; and The stored specification of the interface is established by including at least a portion of the output document definition of the complementary interface in the input document definition of the interface in the stored specification. 25. The method of claim 24, comprising the steps of: Look for supplementary interfaces in the network. 26. The method of claim 24, wherein the step of building the stored specification includes the step of accessing elements of the machine-readable specification from a repository storing elements organized by logical structures, A library of schematic diagrams of logical structures and document definitions including logical structures used to build interface descriptions. 27. The method of claim 24, wherein the stored specification of the interface is built by including at least a portion of the input document definition of the supplementary interface in the output document definition of the interface in the stored specification. 28. The method according to claim 23, characterized in that providing access to said specifications to other network points of the network through a communication network. 29. The method according to claim 23, characterized in that the interface specification is sent to another node of the network, where access to the specification is provided for other nodes in the network. 30. The method of claim 23, wherein the machine-readable specification includes a document conforming to an interface document definition including logical structures for storing an identification of a particular transaction character, and store at least one of input and output document definitions and references to definitions for that particular transaction. 31. The method of claim 23, wherein the machine-readable specification includes a document conforming to an interface document definition, said interface document definition including logical structures for storing identifiers of interfaces, And storing at least one of a specification and a reference to the specification for one or more transaction groups supported by the interface. 32. The method of claim 31, wherein the machine-readable specification includes a reference to a specification for a particular transaction, and the specification for a particular transaction includes a document including a logical structure, They are used to store at least one of input and output document definitions and references to definitions for that particular transaction. 33. The method of claim 23, wherein the storage location includes parsed data. 34. The method of claim 33, wherein the parsed data in at least one of the input and output documents includes: character data for encoding text characters in one of the input and output documents, and Markup data for identifying groups of storage units based on the logical structure of one of the input and output documents. 35. The method of claim 34, wherein at least one set of memory cells encodes a plurality of text characters providing natural language words. 36. The method of claim 33, wherein the specification includes interpretation information for at least one group of storage units, the interpretation information encoding the definition of each group of parsed characters, and the storage unit is defined by the input and The logical structure of at least one document in the output document is identified. 37. The method of claim 33, wherein the memory location includes unparsed data. 38. The method of claim 23, wherein the transaction process has a different transaction architecture, and the method includes the step of translating at least a portion of the input document into a different transaction process according to the transaction process Architecture-readable format. 39. The method according to claim 38, wherein the translating step comprises the step of: generating programming objects containing many variables and methods according to different transaction processing architectures of the transaction processing process. 40. The method of claim 38, wherein the different transaction processing architecture of the transaction process comprises a process conforming to the interface description language. 41. The method of claim 23, wherein the input and output document definitions include document type definitions conforming to the standard Extensible Markup Language XML. 42. The method of claim 23, comprising the step of providing a repository of document types for a plurality of transactions, wherein the definition of one of the input and output documents includes a reference to a document in the repository A reference to a document type. 43. The method of claim 42, wherein the document type repository includes document types for identifying participant processes in the network. 44. The method of claim 42, comprising the step of providing a repository of interpretation information about logical structures, the repository including interpretation information for identifying transaction parameters. 45. The method of claim 23, wherein the transaction processes have different transaction architectures, and the method comprises the steps of: Accessing a specification of a supplementary interface, the accessed specification includes an input document definition of the supplementary interface, and an output document definition of the supplementary interface; building the stored specification of the interface by including the output document definition of the supplementary transaction as the input document definition of the interface in the stored specification; compiling data structures corresponding to groups of storage units and logical structures of input and output documents in response to the input and output document definitions, wherein the groups of storage units and logical structure of the input and output documents follow the transaction processing architecture of the transaction processing process; the compilation system instructions executable to translate the input document into corresponding data structures; and instructions executable by the compilation system to translate the output of the transaction process into a form conforming to the definition of the output document. 46. The method of claim 45, wherein the stored specification of the interface is built by including the input document definition of the supplementary transaction as an output document definition of the interface in the stored specification. 47. The method of claim 23, wherein the transaction processing processes have different transaction processing architectures, and said step of establishing a stored specification includes the step of accessing a machine-readable An element of a specification description, the resource library stores a library consisting of a logical structure, a schematic diagram of the logical structure, and a document definition including the logical structure used to create an interface description; compiling data structures corresponding to groups of storage units and logical structures of input and output documents in response to the input and output document definitions, wherein the groups of storage units and logical structure of the input and output documents follow the transaction processing architecture of the transaction processing process; the compilation system instructions executable to translate the input document into corresponding data structures; and instructions executable by the compilation system to translate the output of the transaction process into a form conforming to the definition of the output document. 48. An apparatus for managing transactions between nodes in a network, said network comprising a plurality of nodes performing processes involved in transactions, said apparatus comprising: Network Interface; memory for storing data and instruction programs, including a machine-readable transaction interface specification, the specification including an input document definition and an output document definition, the input and output document definitions including the A description of the logical structure of the unit; a data processor, connected to the memory and the network interface, for executing the program of instructions, and the program of instructions includes: logic for receiving data including a document via a network interface; logic for parsing said document according to said specification to identify an input document; logic for providing at least a portion of said input document to a transaction process in a machine-readable format to generate an output; logic for forming an output document according to the specification, wherein the output document includes output defined in accordance with the output document; Logic for sending said output document over said network interface. 49. The device of claim 48, further comprising: logic for accessing a specification of a supplementary interface, the accessed specification including input document definitions for the supplementary interface, and output document definitions for the supplementary interface; Logic for building a stored specification of an interface by including an output document definition of a supplementary transaction as an input document definition of the interface in the stored specification. 50. The apparatus of claim 49, wherein the logic for creating the stored specification comprises logic for accessing elements of the machine-readable specification from a repository storing A library consisting of logical structures, diagrams of logical structures, and document definitions including logical structures used to build interface descriptions. 51. The apparatus of claim 49, further comprising logic to build the stored specification of the interface by including the input document definition of the supplementary transaction as the output document definition of the interface in the stored specification. 52. The apparatus of claim 48, further comprising logic for providing access to said specification to other nodes of the network via a communication network. 53. The device of claim 48, further comprising a logic circuit for sending the interface specification to another network point in the network, wherein at the other network point, access to the specification description is provided for other network points in the network . 54. The apparatus of claim 48, wherein the machine-readable specification includes a document conforming to an interface document definition including logical structures for storing an identification of a particular transaction character, and store at least one of input and output document definitions and references to definitions for that particular transaction. 55. The apparatus of claim 48, wherein the machine-readable specification includes a document conforming to an interface document definition, said interface document definition including logical structures for storing identifiers of interfaces, And storing at least one of a specification and a reference to the specification for one or more transaction groups supported by the interface. 56. The apparatus of claim 55, wherein the machine-readable specification includes a reference to a specification for a particular transaction, and the specification for a particular transaction includes a document including the logical structure , which are used to store at least one of input and output document definitions and references to definitions for that particular transaction. 57. The apparatus of claim 48, wherein the storage unit includes parsed data. 58. The apparatus of claim 57, wherein the parsed data in at least one of the input and output documents comprises: character data for encoding text characters in one of the input and output documents, and Markup data for identifying groups of storage units based on the logical structure of one of the input and output documents. 59. The apparatus of claim 58, wherein at least one set of memory cells encodes a plurality of text characters providing natural language words. 60. The apparatus of claim 57, wherein the specification includes interpretation information for at least one set of memory locations, the interpretation information encoding the definition of each set of parsed characters, and the storage locations are defined by the input and The logical structure of at least one document in the output document is identified. 61. The device of claim 57, wherein the storage location includes unparsed data. 62. The apparatus of claim 48, wherein the transaction process has a different transaction architecture, and the apparatus further comprises a means for translating at least a portion of the input document into a different transaction architecture according to the transaction process. Structural logic circuits in a readable format. 63. The apparatus of claim 62, wherein the logic for translating further comprises logic for generating a programming object containing a plurality of variables and methods according to different transaction architectures of the transaction process. 64. The apparatus of claim 62, wherein the different transaction processing architecture of the transaction process comprises a process conforming to the interface description language. 65. The apparatus of claim 48, wherein the input and output document definitions comprise document type definitions conforming to the standard Extensible Markup Language XML. 66. The device of claim 48, further comprising processor-accessible memory storing a repository of document types for a plurality of transactions, wherein one of the input and output documents The definition of includes a reference to a document type in the repository. 67. The apparatus of claim 66, wherein the document type repository includes document types for identifying participant processes in the network. 68. The apparatus of claim 66, further comprising a repository providing interpretation information about the logical structure, the repository including interpretation information for identifying transaction parameters. 69. The apparatus of claim 48, wherein transaction processes have different transaction architectures, and wherein the apparatus comprises: logic for accessing a specification of a supplementary interface, wherein the accessed specification includes an input document definition of the supplementary interface, and an output document definition of the supplementary interface; logic for building a stored specification of an interface by including an output document definition of a supplementary transaction as an input document definition of an interface in the stored specification; logic for compiling, responsive to input and output document definitions, compiling data structures corresponding to groups of storage units and logical structures of input and output documents, wherein the groups of storage units and logical structures of input and output documents conform to transactions The transaction processing architecture of the processing procedure; the compilation system executable instructions to translate the input document into corresponding data structures; and the compilation system executable instructions to translate the output of the transaction processing procedure into a form conforming to the definition of the output document. 70. The device of claim 69, further comprising: Logic for building a stored specification of an interface by including an input document definition of a supplementary transaction as an output document definition of an interface in the stored specification. 71. The apparatus of claim 48, wherein the transaction process has a different transaction architecture, and wherein the apparatus further comprises the step of establishing the stored A logical circuit specified by a specification, the resource library stores a library consisting of a logical structure, a schematic diagram of the logical structure, and a document definition including the logical structure used to create an interface description; and includes: logic for compiling, responsive to input and output document definitions, compiling data structures corresponding to groups of storage units and logical structures of input and output documents, wherein the groups of storage units and logical structures of input and output documents conform to transactions The transaction processing architecture of the processing procedure; the compilation system executable instructions to translate the input document into corresponding data structures; and the compilation system executable instructions to translate the output of the transaction processing procedure into a form conforming to the definition of the output document. 72. A method for managing transactions between nodes in a network, said network comprising a plurality of nodes performing the processes involved in the transactions, said method comprising the steps of: storing a machine-readable specification of a plurality of participant interfaces for identifying transactions, each transaction identified by an input document definition and an output document definition, the input and output document definitions including references to sets of storage units And a description of the logical structure of each group of storage units; receiving data comprising a document via a communications network; parsing the document according to the specification to identify an input document and accepting one or more transactions for the identified input document; At least a portion of the input document is provided to a transaction process associated with one or more identified transactions in a machine-readable format. 73. The method of claim 72, further comprising the step of: A repository is provided that stores a library of logical structures, schematic representations of the logical structures, and document definitions including the logical structures used to build participant interface descriptions. 74. The method according to claim 73, further comprising the step of providing access to the resource library to other network points in the network through the communication network. 75. The method of claim 72, wherein the machine-readable specification includes a document conforming to a participant interface document definition that includes logical structures for storing a specified An identifier for a transaction and at least one of input and output document definitions and references to definitions are stored for that particular transaction. 76. The method of claim 72, wherein the machine-readable specification includes a document conforming to an actor interface document definition, the interface document definition including logical structures for storing the An identifier, and storing at least one of a specification and a reference to the specification for one or more transaction groups supported by the interface. 77. The method of claim 76, wherein a document conforming to the participant interface document definition includes a reference to a specification for a particular transaction, and the specification for a particular transaction includes a document that includes Logical structures for storing at least one of input and output document definitions and references to definitions for the particular transaction. 78. The method of claim 72, wherein the storage location includes parsed data. 79. The method of claim 78, wherein the parsed data in at least one of the input and output documents includes: character data for encoding text characters in one of the input and output documents, and Markup data for identifying groups of storage units based on the logical structure of one of the input and output documents. 80. The method of claim 79, wherein at least one set of memory cells encodes a plurality of text characters providing natural language words. 81. The method of claim 80, wherein the specification includes interpretation information for at least one set of storage units, the interpretation information encoding the definition of each set of parsed characters, and the storage units are defined by input and The logical structure of at least one document in the output document is identified. 82. The method of claim 80, wherein the memory location includes unparsed data. 83. The method of claim 72, wherein the step of providing at least a portion of the input document in a machine-readable format to a transaction process associated with one or more identified transactions comprises the step of, according to The processing architecture performs the routing process, and the method further includes the steps of: Compile data structures corresponding to groups of storage units and logical structures of input and output documents in response to the definition of input and output documents in the actor interface, wherein the groups of storage units and logical structure of input and output documents follow the processing architecture of the transaction process structure, and compiles system-executable instructions to translate the input document into the corresponding data structure. 84. The method of claim 72, wherein the step of providing at least a portion of the input document in a machine-readable format to a transaction process associated with one or more identified transactions comprises the step of, according to The processing architecture performs the routing process, and the method further includes translating at least a portion of the input document into a format readable in accordance with the processing architecture. 85. The method of claim 84, wherein said translating step further comprises generating a programming object containing a plurality of variables and methods according to the processing architecture of the routing process. 86. The method of claim 72, wherein the step of providing at least a portion of the input document in a machine-readable format to a transaction processing process associated with one or more identified transactions comprises the step of: The above-mentioned input document part is sent to the identified transaction. 87. The method of claim 86, wherein said sending step includes sending the input document over a communications network to a site performing an identified transaction. 88. The method of claim 72, wherein the input and output document definitions include document type definitions conforming to the standard Extensible Markup Language XML. 89. The method of claim 88, wherein the specification of the participant interface includes a document definition in terms of a document type definition conforming to the standard Extensible Markup Language XML. 90. The method of claim 72, wherein the repository includes standardized document types for multiple transactions, wherein the definition of one of the input and output documents includes a definition of a standardized document type in the repository refer to. 91. The method of claim 90, wherein the resources include standardized document types for identifying participant processes in the network. 92. The method of claim 90, further comprising the step of providing a repository of logical structure interpretation information, the repository including interpretation information for identifying transaction parameters. 93. The method of claim 72, wherein the transaction processing processes each have one of a plurality of different transaction processing architectures, and the method further comprises the step of translating at least a portion of the input document into The different transaction architectures of the transaction process read the format and send the translated part to each transaction process. 94. The method as claimed in claim 93, wherein said translating step comprises the step of generating programming objects containing many variables and methods according to different transaction processing architectures of each transaction processing process. 95. The method of claim 94, wherein the different transaction processing architecture of the transaction processing process comprises a process conforming to the interface description language. 96. An apparatus for managing transactions between nodes in a network, said network comprising a plurality of nodes performing processes involved in transactions, said apparatus comprising: Network Interface; memory for storing data and a program of instructions, including a machine-readable specification of a plurality of participant interfaces identifying transactions, each transaction being identified by an input document definition and an output document definition, the input and output The document definition includes a description of each group of storage units and the logical structure of each group of storage units; a data processor coupled to the memory and network interface for executing a program of instructions comprising: logic for receiving data including a document via a network interface; logic for parsing said document according to said specification to identify an input document and accept one or more transactions for the identified input document; Logic for providing at least a portion of the input document in a machine-readable format to a transaction processing process associated with one or more identified transactions. 97. The apparatus of claim 96, further comprising a resource library stored in a memory accessible to the data processor for storing logical structures, diagrams of logical structures, and To build a library of document definitions including logical structures for actor interface descriptions. 98. The device of claim 96, further comprising logic circuitry for accessing a resource library stored in a memory through a network interface, wherein the resource library stores information about logical structures, pairs of logical structures, A library of schematic diagrams and document definitions including logical structures used to build actor interface descriptions. 99. The apparatus of claim 96, wherein the machine-readable specification includes a document conforming to a participant interface document definition, the participant interface document definition including logical structures for storing a An identifier for a particular transaction and at least one of input and output document definitions and references to definitions are stored for the particular transaction. 100. The apparatus of claim 96, wherein the machine-readable specification includes documents conforming to a participant interface document definition, the interface document definition including logical structures for storing participant interface and store at least one of a specification and a reference to the specification for one or more transaction groups consisting of transactions supported by the participant interface. 101. The apparatus of claim 100, wherein the document conforming to the participant interface document definition includes a reference to a specification of a particular transaction, and the specification of the particular transaction includes a document that includes Logical structures for storing at least one of input and output document definitions and references to definitions for the particular transaction. 102. The device of claim 96, wherein the storage unit includes parsed data. 103. The apparatus of claim 102, wherein the parsed data in at least one of the input and output documents comprises: character data for encoding text characters in one of the input and output documents, and Markup data for identifying groups of storage units based on the logical structure of one of the input and output documents. 104. The apparatus of claim 103, wherein at least one set of memory cells encodes a plurality of text characters providing natural language words. 105. The apparatus of claim 104, wherein the specification includes interpretation information for at least one set of memory locations, the interpretation information encoding the definition of each set of parsed characters, and the storage locations are defined by the input and The logical structure of at least one document in the output document is identified. 106. The device of claim 104, wherein the storage location includes unparsed data. 107. The apparatus of claim 96, wherein said logic for providing at least a portion of an input document in a machine-readable format to a transaction processing process associated with one or more identified transactions comprises a process based on An architectural routing process, and the device further includes: a compiler to, in response to the input and output document definitions in the actor interface, compile data structures corresponding to the logical structure of the storage unit group and input and output documents, wherein the storage unit group and the logical structure of the input and output documents conform to the transaction Processes the processing architecture of the process and compiles system-executable instructions to translate input documents into corresponding data structures. 108. The apparatus of claim 96, wherein said logic for providing at least a portion of an input document in a machine-readable format to a transaction processing process associated with one or more identified transactions comprises a process based on The routing process performed by the architecture, and the apparatus further includes logic for translating at least a portion of the input document into a format readable by the processing architecture. 109. The apparatus of claim 108, wherein the logic for translating further comprises generating a programming object containing a number of variables and methods according to a processing architecture of a routing process. 110. The apparatus of claim 96, wherein said logic for providing at least a portion of an input document in a machine-readable format to a transaction process associated with one or more identified transactions comprises a router, Used to send the input document part to the identified transaction. 111. The device of claim 110, wherein the router includes logic to route the input document over the communications network to a node performing an identified transaction. 112. The apparatus of claim 96, wherein the input and output document definitions comprise document type definitions conforming to the standard Extensible Markup Language XML. 113. The apparatus of claim 112, wherein the specification of the participant interface comprises a document definition in terms of a document type definition conforming to the standard Extensible Markup Language XML. 114. The apparatus of claim 97, wherein the repository includes standardized document types for a plurality of transactions, and the definition of one of the input and output documents includes a definition of a standardized document type in the repository refer to. 115. The device of claim 97, wherein the resourcer includes a standardized document type for identifying participant processes in the network. 116. The apparatus of claim 96, wherein the transaction processes each have one of a plurality of different transaction architectures, and the apparatus further comprises translating at least a portion of the input document into format readable by different transactional architectures and send the translated parts to the logic of each transactional process. 117. The apparatus of claim 116, wherein said logic for translating generates programming objects containing a plurality of variables and methods according to different transaction architectures of respective transaction processes. 118. The apparatus of claim 116, wherein the different transaction processing architecture of the transaction processing process comprises a process conforming to the interface description language.

Images