The present invention relates generally to data communication between software applications in a distributed computer network such as the Internet. In particular, this invention provides an interaction protocol for enabling process communications among network-distributed software applications, particularly, but not exclusively, among applications having dissimilar platforms, language dependencies or vendor dependencies.
Business entities have long recognized that substantial productivity and marketing benefits may potentially arise from conducting commercial business activities and business processes over distributed computer networks. In order for a business to achieve the full benefits of network-based commercial activity, the firm""s existing commerce-related or business process software application systems must communicate both among each other and with the application systems of other business entities. However, it is often the case that software applications within an organization or among different business entities cannot easily exchange data because they may be built on disparate operating systems or use a variety of internally developed and third-party software that employ diverse programming languages. The inability to exchange data between application programs is sometimes referred to in the relevant literature as the lack of application interoperability. Earlier efforts at business-to-business commerce activity were led by Electronic Data Interchange (EDI) applications. EDI-based commercial activities worked well for certain applications such as order processing and payment exchange, but failed to make significant progress in other types of applications. File and information transfers in an EDI-based network were often performed using multiple communications protocols, requiring expensive application programming development or changes to existing systems in order to achieve a collaborative environment. Because of a lack of any universal data interchange formats, companies were, and still are, often prevented from exploiting their own enterprise systems integration or legacy systems to reach external partner applications.
In recent years, the Internet distributed computer network has developed the infrastructure and data communications protocols to connect all businesses to each other regardless of their size, geographic location or position in the supply chain. Networked distributed computer systems may be configured as intranets, extranets or publicly available systems using Internet technologies. Internet technologies provide business entities with another opportunity to achieve substantial productivity gains and marketing benefits by conducting internal, business-to-consumer and business-to-business Internet-based commercial activities among employees, and with customers, vendors, suppliers and other parties related to their business enterprises. Internet-based commercial activities, referred to generally as xe2x80x9celectronic commercexe2x80x9d, xe2x80x9ce-commercexe2x80x9d, or xe2x80x9ce-businessxe2x80x9d include, but are not limited to, all types of business processes that can take place in a secure manner online, as well as the more traditional buying and selling of goods and services. The Internet environment holds out the promise of true collaborative data exchange and software application interoperability for business firms of all sizes. However, the promise is not yet fully a reality. The deployment of disparate computer systems, operating systems, and collections of operational data in an Internet environment for the purpose of collaborative processing and data exchange presents complex challenges to the successful implementation of e-commerce activities.
The primary Internet technological environment for commercial activities is the World Wide Web (the xe2x80x9cWebxe2x80x9d) which predominantly uses Hypertext Transport Protocol (HTTP) as the standard application-layer interaction protocol and Hypertext Markup Language (HTML) as the standard document authoring language. (Note that a glossary of terms related to the Internet and relevant to this description is provided in the Appendix at the end of this disclosure.) Software tools and techniques currently available for designing and implementing Web-based commercial applications, such as HTML, CGI scripts, Java applets, JavaScript and browser plug-ins, provide Web authors and commercial sites with an array of techniques for displaying data content in a visually compelling and informative manner. However, these tools and techniques alone do not yet have the capabilities necessary to support sophisticated commercial transaction processing in a Web-based environment and do not fully address the application interoperability problem. For example, HTTP, the predominant application interaction protocol, is not extensible and cannot easily support the dynamic integration of application services without additional software interface development.
Standardization efforts toward addressing the problems of Internet- and Web-based application interoperability include industry consortia and vendor-specific e-commerce solutions. A recent new data representation standard, Extensible Markup Language (XML), was adopted by the World Wide Web Consortium in February, 1998. In its broadest sense, XML is a system for defining, validating, and sharing document formats on the Web, providing a universal format for structured documents and data. XML is a markup language for presenting documents on the Web that uses tags to identify data components, in a manner similar to HTML. However, XML is potentially more versatile than HTML because of its extensibility in defining specific subject matter domains of markup tags. Document Type Definitions (DTDs), referred to as dictionaries, vocabularies, or schemas, serve as a uniform source of data definitions for specific industries or fields of knowledge, making it easier to exchange data not only within an organization but also among different companies. Unlike HTML, XML is an extensible standard because users may define their own electronic document type in the form of a DTD. The simple language syntax makes it easy to process by machine while remaining understandable to people. XML style sheets, called XSLs, describe how the tagged data in an XML program should be displayed. Further information about XML and the World Wide Web Consortium, also known as W3C, can be found at the W3C Web site, http://www.w3c.org.
XML is in use in several industries, and forms the basis of several standardization efforts. In the financial industry, for example, J.P. Morgan and Co. Inc. and Price Waterhouse Coopers recently proposed an XML dictionary called FpML (Financial products Markup Language), which would standardize XML tags in areas such as fixed income derivatives and foreign currency exchange. The Internet Open Trading Protocol, Open Buying on the Internet, and RosettaNet have published non-proprietary XML-based standards for use in conducting various types of e-commerce over the Internet. And private vendors are also implementing XML based e-commerce solutions. Some of these standards as they relate to XML-based protocols are briefly discussed here.
The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce that is both payment system independent and optimized for the case where the buyer and the merchant do not have a prior acquaintance. It supports several standard Internet payment systems (e.g., CyberCash, DigiCash, etc.). IOTP is intended to handle cases where such merchant roles as the shopping site, the payment handler, the deliverer of goods or services, and the provider of customer support are performed by one party (i.e., Internet site) or by different parties. IOTP describes the content, format and sequences of messages that pass among the participants, referred to as Trading Roles, in an electronic trade. IOTP defines five different types of Trading Roles (Consumer, Merchant, Payment Handler, Delivery Handler, and Merchant Customer Care Provider) that are the ways in which organizations can participate in a trade. The IOTP framework is centered on an IOTP Transaction that involves one or more organizations playing a Trading Role, and a set of Trading Exchanges. Each Trading Exchange involves the exchange of data, between Trading Roles, in the form of a set of IOTP Messages. Each IOTP Message is the outermost wrapper for an XML document that is sent between Trading Roles that take part in a trade. An IOTP message is a well-formed XML document that contains several components including a collection of IOTP Trading Blocks (Request, Exchange, Response) that carries the data required to carry out an IOTP Transaction. An IOTP Trading Exchange consists of the exchange, between two Trading Roles, of a sequence of documents consisting of three main parts: the sending of a Request Block by one Trading Role (the initiator) to another Trading Role (the recipient), the optional exchange of one or more Exchange Blocks between the recipient and the initiator, and the sending of a Response Block to the initiator by the Trading Role that received the Request Block. For more information regarding IOTP, the reader is referred to an Internet-Draft document describing Version 1.0 of the IOTP, published by the Internet Engineering Task Force (IETF) and available at the IETF web site, http://www.ietf.org, as of February, 2000.
The Open Buying on the Internet (OBI, http://www.openbuy.org) standard from the OBI Consortium aims to standardize and secure the corporate purchasing model, especially the high-volume, low-dollar transactions that account for 80% of most organizations"" purchasing activities. The goal of OBI is to establish a common ground for what is referred to as xe2x80x9cThe Trading Web,xe2x80x9d where OBI standards adopters establish trading relationships with other OBI standards adopters through secured access to extranet facilities connected via the Internet, forming dynamic sets of interoperable systems. OBI defines an architectural approach for e-commerce systems, detailed technical specifications, guidelines for development, record layout formats, file formats, communication structures and protocols, compliance testing guidelines, and implementation assistance. The OBI standard includes precise technical specifications for the security, transport, and contents of OBI Order Requests and OBI Orders. Exchange of OBI Order Requests and OBI Orders is accomplished via HTTP using the SSL (Secure Sockets Layer) protocol to secure communications on the Internet. Within OBI, HTTP is also used for transmission of order documents between servers. In the currently published standard, contents of OBI Order Requests and OBI Orders are based on the ANSI ASC X.12""s 850, a standard for an EDI purchase order. The OBI standard includes an implementation convention (IC), a detailed specification for the use of the 850 standard which reflects the consensus of the companies participating in the development of the standard. The Version 2.0 standards document states that the OBI Consortium may provide, in the future, standard order formats based on EDIFACT and/or XML and may add additional document types. For a complete discussion of the OBI technical specifications, consult version 2.0 of the Open Buying on the Internet standard available at www.openbuy.org/obi/specs/obiv2.html.
RosettaNet (information available at the Web site, http://www.rosettanet.org) is an initiative by a consortium of more than thirty companies in the personal computer (PC) industry, ranging from manufacturers to resellers. As part of RosettaNet""s foundational projects, two XML data dictionaries are being developed to provide a common set of properties required to conduct business among Consortium members. The first is a technical properties dictionary (technical specifications for all product categories), and the second is a business properties dictionary which includes catalog properties, partner properties (i.e., attributes used to describe supply chain partner companies) and business transaction properties. The goal is a common business language that will link the entire PC industry""s supply chain. These dictionaries, coupled with the RosettaNet Implementation Framework (RNIF, an exchange protocol), form the basis for an e-commerce dialog known as the Partner Interface Process or PIP. RosettaNet""s PIPs are specialized system-to-system XML-based dialogs that define how business processes are conducted between electronic component and information technology products manufacturers, software publishers, distributors, resellers and corporate end users. The RosettaNet Implementation Framework (RNIF) enables the execution of these electronic business processes by providing strictly defined protocols. These protocols, which are XML DTDs, specify application interaction formats and exchange sequences. Also, this specification includes authentication, authorization, encryption and non-repudiation implementation aspects that are necessary for conducting secure electronic business over the Internet. The purpose of each PIP is to enable the development of interoperable applications by providing common business/data models and documents that enable system developers to implement RosettaNet interfaces. Each PIP includes one or more XML documents based on Implementation Framework DTDs, specifying one or more PIP services, transactions, and messages. A PIP is encapsulated within a header and trailer specified by an agent protocol that facilitates communication between applications that support the RosettaNet agent protocol. Messages are all complete, valid XML documents and are packaged for transport as MIME messages. The RNIF is built on standard Web protocols and accomplishes information exchange between applications using Web servers. A RosettaNet Object (properly configured PIP) may be directly encapsulated into an HTTP message, into an HTML form, or into a CGI name-value pair. Two methods for transferring RosettaNet Objects between Web servers are supported. In the server-to-server method for directly exchanging information between two Web servers, the RosettaNet Object is directly encapsulated by the HTTP protocol at the transport level. In the server-browser-server method for indirectly exchanging information between Web servers via a Web browser (an agent acting on behalf of a user), the RosettaNet Object is encapsulated into an HTML form as a CGI name-value pair, which in turn is exchanged via the HTTP protocol. For further information the reader is referred to the RNIF document designated as version 1.1 and published Nov. 8, 1999, discussing the RNIF in detail, available from the RosettaNet web site.
Private vendors are also implementing XML based e-commerce solutions. Vendors such as Ariba Technologies Inc., Commerce One Inc., and Concur Technologies Inc. are using XML to simplify the process of matching up RFPs and purchase orders over the Web. The Ariba Network platform also provides a range of Internet services for buying and selling organizations, including supplier directories, supplier catalog and content management, access to supplier content, and secure transaction routing. The Ariba Network platform is built around a multi-protocol architecture that allows buyers to send transactions from their Ariba buyer-enabled application in one standard format. The Ariba Network platform then automatically converts the order into the suppliers"" preferred transaction protocol, eliminating the need for a single standard for electronic commerce and giving suppliers the freedom to transact in their preferred protocol over the Internet. Ariba Network automatically routes and translates transactions between buying organizations and suppliers using many major e-commerce standards, including Internet Electronic Data Interchange (EDI), VAN-based EDI, Open Buying on the Internet (OBI), secure HTML, e-mail, auto-FAX, Catalog Interchange Format (CIF), and a protocol known as Commerce XML (cXML). cXML defines a set of document type definitions (DTDs) for XML to describe the characteristics of non-production Maintenance, Repair, and Operations (MRO) goods and services. cXML serves as a meta-language to enable the development of xe2x80x9cintelligent shopping agentsxe2x80x9d to assist with the corporate purchasing function. cXML""s request/response interaction is used to exchange transaction data between parties. These messages provide support for purchase orders, charge orders, acknowledgements, status updating, shipment notifications, and payment transactions.
BizTalk is an industry initiative started by Microsoft Corporation of Redmond Washington to establish a community of standards users with the goal of driving the rapid, consistent adoption of XML to enable electronic commerce and application integration. The group is defining the BizTalk Framework(trademark), a set of guidelines for how to publish schemas in XML and how to use XML messages to easily integrate software programs together in order to build new solutions. The BizTalk design emphasis is to leverage existing applications, data models, solutions, and application infrastructure, and adapt these for electronic commerce through the use of XML.
FIG. 19 shows a conventional commerce server architecture 700 that supports multiple communications and applications protocols for exchanging information between trading partners 706 and representative service applications 710, 711 and 712. In a typical implementation of commerce server 702, application interfaces 713, 714 and 715 are incorporated as part of the functionality of commerce server 702 to enable server 702 to specifically communicate with applications 710, 711 and 712, respectively. Similarly, communications interface 721 enables server 702 to communicate over communications path 720 with Internet network 707 to reach trading partners A and B, and communications interface 718 enables server 702 to communicate over communications path 722 with EDI network 708 to reach trading partners C and D. These communication interfaces must typically be specially developed to achieve application interoperability.
As described above, there are numerous public and proprietary standardization efforts underway to solve the application interoperability problem in the distributed network environment. Many are XML-based, and most provide application interaction protocols that support and are specific to the interactions required for a particular industry, function or subject matter domain, such as PC supply-chain management or corporate purchasing. These standardization efforts address application interoperability at the transaction or service level and typically support the multiple application layer communications protocols (e.g., HTTP, EDI, etc.) that currently exist in distributed networks today. While these efforts clearly expand the reach of Internet-based e-business to a wider range of enterprises, multiple protocol support still requires extensive software application interface development to enable communications between applications having disparate data requirements over networks using different transport and/or applications communications protocols. What is needed is an application interaction protocol that provides for a common set of generic interactions both to enable full application interoperability in a distributed network environment and to facilitate the automatic processing of today""s complex commercial transactions.
The present invention is premised on the observation that there are at least two basic constituent parts in any e-commerce business model. These are commerce services, such as shopping carts, catalogs, and payment services, and commerce processes, such as catalog updates, purchase order submissions, bids and quotes. A comprehensive e-commerce solution has to integrate these services and processes dynamically, based on configurable interaction definitions. This means that a set of procedures is needed to define the interaction between the applications that establish the services and provide the processes. The present invention is premised on the further observation that an Internet infrastructure solution toward providing the dynamic integration of services and processes should be vendor and platform independent. As noted above, XML and related data representation standardization efforts, combined with industry-based e-commerce standards efforts, are efforts in the direction of an integrated Internet e-commerce environment. But these efforts fall short of the complete integration needed.
The present invention provides for a simple but powerful application interaction protocol that is used to implement secure Internet-wide electronic commerce applications. The protocol is referred to as the Commerce Exchange Interaction Protocol (CXIP) and operates at the application level, providing a formal set of procedures to facilitate functional interoperation among application services and processes. The CXIP protocol specifies the message types that are exchanged between applications, the semantics of these messages, and the exchange order. The application interaction protocol, which is not specific to any particular functional domain and specifies interactions that are independent of transactional content, includes four component parts: message formats, message types, message exchange semantics and transportation assumptions. In an illustrated implementation of the application interaction protocol, data, object and method invocation requests are exchanged between applications by means of structured documents that use XML tags and that are consistent with the protocol. Messages using XML are machine-readable and can be interpreted in a domain-specific fashion. The exchange of self-descriptive XML messages facilitates document life cycle tracking, which is essential in cross-company commerce activity to support auditing and related activities.
A significant advantage of the application interaction protocol of the subject invention is that it provides a robust foundation on which enterprises and service providers can deliver reliable, scalable, and high performance electronic commerce services to their constituencies. It allows for the delivery of core services and processes that are shared across multiple applications that may be built on disparate operating systems, diverse programming languages and various vendor offerings and legacy systems.
Another important benefit of the application interaction protocol of the subject invention is its simplicity and small footprint. CXIP does not require complex frameworks or supporting infrastructures. The simplicity of the protocol in terms of its messages and their interactions avoids dependence on third party libraries, threading models, and other complications that come with heavily distributed object implementations. Also, the message that comprise the protocol are independent of specific functional domains and may be used to implement application interaction in a variety of functional domains. In addition, applications utilizing CXIP may be implemented using scripting languages such as Perl and Tcl.
Still another important advantage of the present invention is that it supports the three most common types of application interaction models in the e-commerce environment. These models are generally known as request/reply, publish/subscribe and broadcast. The request/reply interaction model allows two parties to exchange information in both synchronous and asynchronous fashion. In a synchronous model, one party (the client) sends a request message to the other party (the server). Upon receipt of the request message, the server party processes it in a predetermined manner and sends back a reply message containing the results. The client party waits until it receives the response from the server party. This interaction model is also called the blocking interaction model. In asynchronous interaction, upon receipt of the request message from the client, the server party responds to the request immediately, before acting upon the request. The response typically contains tracking information that allows the requesting party to query the status of the service request. This model is also called the offline, or non-blocking, model. In this interaction model, the receiving application has the capability of implementing either synchronous or asynchronous requests. In a publish/subscribe interaction model, two applications interact via an intermediary party. The applications that are interested in specific information register with the intermediary party. The information generating application posts, or publishes, the information to the intermediary, which in turn passes this to the interested parties. In this model, the information requestor and the information supplier never interact directly. The broadcast model is a special case of a model known as the multicast model, both of which send a message to a group of parties. When the group size is less than the entire membership of a domain, a message is broadcast to the group; when the group size equals the entire membership, sending the message to the entire group is referred to as multicasting. The message sent in this type of interaction model is typically one of two types: a request message, resulting in a reply message returned, or a notify message that simply reports information or events. Note also that in the multicast interaction model, the recipient group may or may not be subscription based. The information receiver application determines this from the content of the broadcast message. The present invention provides for a set of message types that support all three interaction models.
Therefore, in accordance with one aspect of the present invention, a method is provided for operating a first computer to manage application-to-application communication among a plurality of requesting application programs and a plurality of service application programs. The method comprises receiving transaction request data indicating a transaction from a requesting application program, and determining a message type using the transaction request data. The message type is one of a plurality of message types collectively defining an application interaction protocol implementing a request-reply, a publish-subscribe, and a broadcast application-to-application interaction between the requesting application and a service application. Each of the request-reply, publish-subscribe, and broadcast-multicast application-to-application interactions indicating a predetermined sequence of structured documents exchanged between the requesting application and the service application. The method further comprises producing, sending and receiving an ordered sequence of structured documents according to at least one of the request-reply, publish-subscribe, and broadcast-multicast application-to-application interactions of the application interaction protocol. The ordered sequence of structured documents causes the transaction to be performed by the service application and a transaction response to be sent to the requesting application.
In another aspect of the method invention, the plurality of message types include Request, Reply, Publish, Notify, Subscribe and Unsubscribe. In still another aspect of the method invention, when the ordered sequence of structured documents is produced according to the broadcast-multicast application-to-application interaction of the application interaction protocol, at least one of the structured documents is a Notify structured document having a message type of Notify and indicating transaction data to be sent to a subscriber list of service applications. The method for managing application-to application interaction then further includes selecting all service application programs on the subscriber list from among the plurality of service application programs, and sending the Notify structured document to the subscriber list of service application programs to process the transaction data.
In another aspect of the invention, there is provided a system for managing application-to-application communication among a plurality of application programs resident on a plurality of computers in a distributed computer network. The system comprises at least one requesting application program resident on one of the plurality of computers in the distributed computer network, and at least one service application program resident on one of the plurality of computers in the distributed computer network. The requesting application program is capable of producing a transaction request indicating a transaction, and the service application program is capable of performing the transaction and producing a transaction response. The system further comprises a plurality of structured documents each indicating a communication to one of the requesting application and the service application. Each structured document includes one of a plurality of message types collectively defining an application interaction protocol implementing a request-reply, a publish-subscribe, and a broadcast-multicast application-to-application interaction between the requesting application and the service application. Each of the request-reply, publish-subscribe, and broadcast-multicast application-to-application interactions indicates a predetermined sequence of structured documents exchanged between the requesting application and the service application. The system further comprises a process automation application resident on one of the plurality of computers in the distributed computer network. The process automation application produces and sends a sequence of structured documents according to at least one of the request-reply, publish-subscribe, and broadcast-multicast application-to-application interactions of the application interaction protocol to cause the transaction to be performed by the service application and the transaction response to be sent to the requesting application.
In still another aspect of the system of the present invention, the structured document data structure of the system uses Extensible Markup Language (XML) tags indicating control data and input-output data. The control data tag indicates the message type of the transaction message and a service type, and the input-output data tag indicates input data required by the service type and output data produced by the service type. In still another aspect of the invention, there is provided an XML application interaction message document stored on a computer-readable medium comprising a message header data portion indicating message-content size data, and a message content data portion indicating a message type. The message type has one of a plurality of message type values collectively defining an application interaction protocol implementing a request-reply, a publish-subscribe, and a broadcast-multicast application-to-application interaction between a requesting application and a service application. The message content data portion further indicates transaction request data, which, when parsed by a process automation application, causes the process automation application to produce an ordered sequence of XML application interaction message documents according to at least one of the request-reply, the publish-subscribe, and the broadcast-multicast application-to-application interaction. The process automation application controlling exchange of the ordered sequence of XML application interaction message documents between the requesting application and the service application.
The novel features that are considered characteristic of the present invention are particularly and specifically set forth in the appended claims. The invention itself, however, both as to its organization and method of operation, together with its advantages, will best be understood from the following description of an illustrated embodiment when read in connection with the accompanying drawings. In the Figures, the same numbers have been used to denote the same component parts or steps.
USPTO Backgrounds
USPTO Backgrounds