US20080147474A1 - System and method for electronic business transaction reliability - Google Patents
System and method for electronic business transaction reliability Download PDFInfo
- Publication number
- US20080147474A1 US20080147474A1 US12/017,880 US1788008A US2008147474A1 US 20080147474 A1 US20080147474 A1 US 20080147474A1 US 1788008 A US1788008 A US 1788008A US 2008147474 A1 US2008147474 A1 US 2008147474A1
- Authority
- US
- United States
- Prior art keywords
- transaction
- business message
- workflow
- business
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06311—Scheduling, planning or task assignment for a person or group
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0633—Workflow analysis
Definitions
- the present invention disclosure relates to increasing the reliability of electronic business transactions.
- B2B business-to-business
- e-commerce electronic commerce
- Processes such as procurement, sales, order fulfillment and customer service are typical examples of processes suitable for B2B integration.
- These processes drive a company's e-commerce interactions with their customers, partners, distributors, and suppliers; they can also streamline the company's internal business.
- Software frameworks for B2B integration can support these process by providing workflow processing, messaging and enterprise application integration. However, the value of a B2B framework is diminished without robust methods for handling hardware and software faults as they arise.
- FIG. 1 is an illustration of business process management functionality in an embodiment of the invention.
- FIG. 2 is an illustration of workflow collaboration in an embodiment of the invention.
- FIG. 3 is an illustration of prior art business partner interaction.
- FIG. 4 is an illustration of prior art B2B engine transaction scenarios.
- FIG. 5 is an illustration of an additional prior-art B2B engine transaction scenario.
- FIG. 6 is a modified system in accordance to one embodiment and by way of illustration.
- FIG. 7 is an illustration of how a transaction can be structured to take advantage of the system of FIG. 6 and thus avoid delays and deadlocks
- One embodiment is an XML (eXtensible Markup Language) and JAVATM-based e-commerce platform that facilitates e-commerce on the World Wide Web.
- XML is a text-based language for describing data in a machine-independent way.
- the XML specification is available from the World Wide Web Consortium (http://www.w3.org).
- JAVA is an object-oriented programming language and run-time environment available from Sun Microsystems, Inc. of Mountain View, Calif.
- One embodiment includes a software framework and a set of services built on top of an application server, such as the BEA WebLogic Server® available from BEA Systems, Inc. of San Jose, Calif.
- B2B e-commerce The basic building blocks of B2B e-commerce are software applications that create interactions among business partners.
- the term “partner” for purposes of this discussion is synonymous with the B2B software applications that a given partner uses to carry out e-commerce transactions.
- a partner interacts with one or more other partners to form an e-commerce community.
- partners in an e-commerce community can represent large enterprises or small divisions within an enterprise.
- An e-commerce community can: 1) exist entirely within a company, spanning multiple corporate departments (e.g., the business purpose for such a community might be inventory management); 2) span multiple companies across firewalls and over a network such as the Internet (e.g., the business purpose might be supply chain management or multi-step purchasing interactions); and 3) include business partners both within a company and in other companies (e.g., one or more of the business partners within a company communicates with business partners in other companies across a network).
- partners can participate in a business conversation.
- a business conversation is a sequence of one or more business messages exchanged between business partners.
- a business message can contain one or more XML documents, one or more attachments, and/or any combination of these.
- the exchange of business messages is determined by roles business partners play in a conversation.
- a conversation can be associated with a unique name and version, and can define two or more roles to be used by business partners in a conversation.
- a conversation can also be associated with any communication protocol that supports a conversation identifier and/or a message identifier (e.g., ebXML, RosettaNet, etc.). It will be appreciated that the present disclosure is not limited to any particular communication protocol.
- a business partner can be configured to communicate directly with other business partners in a peer-to-peer mode, through an intermediary in a hub-and-spoke mode, or both.
- the different configuration modes allow for either direct or mediated messaging among business partners.
- An intermediary in the message flow can perform tasks such as routing and filtering of messages, or it can provide services to the business partners in the conversation.
- FIG. 1 is an illustration of business process management functionality in one embodiment of the invention.
- BEA WebLogic IntegrationTM software available from BEA Systems, Inc. is a commercial implementation of such a system.
- this diagram depicts objects as functionally separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the objects portrayed in FIG. 1 can be arbitrarily combined or divided into separate software, firmware or hardware components. Furthermore, it will also be apparent to those skilled in the art that such objects, irregardless of how they are combined or divided, can execute on the same computing device or can be arbitrarily distributed among different computing devices connected by a network.
- a process engine 100 manages the run-time execution of business processes for a business partner.
- the process engine is JAVA-based and multi-threaded.
- Visual development tool 102 can used to design business processes.
- the development tool can provide a graphical user interface in which familiar flowchart elements can be employed to create a workflow 104 .
- a workflow is an automated business process through which information is communicated to the right participant at the right time according to a set of intelligent business rules that allow computing devices to carry out business transactions.
- a user identifies required elements and defines the process flow by arranging the flowchart elements (or nodes) into a proper logical sequence. This sequence can then be saved as a workflow template definition in template storage 106 .
- Workflow templates can be given meaningful names such as “Billing” and “Order Processing”.
- a workflow template can be invoked or executed through a number of mechanisms, including but not limited to JAVA Message Service (JMS) 108 , timers 110 , manually via an application program interfaces or from a work list 112 , or from another workflow 114 (as a sub-workflow).
- JMS JAVA Message Service
- the process engine instantiates it by activating the workflow's Start node.
- the Start node can initialize variables and activate any successor nodes (per the sequence specified in the development tool). When a node is activated, it is evaluated based on its type according to the rules in Table 1.
- a node may evaluate actions, such as integrating with external software (e.g., when an action invokes an Entity JAVABeanTM method 116 or sends an XML message to another application 118 ). Once a node has completed its actions, it activates the next node(s) in the sequence based on its evaluation rules and the sequence specified in the Development tool.
- actions such as integrating with external software (e.g., when an action invokes an Entity JAVABeanTM method 116 or sends an XML message to another application 118 ).
- a plug-in framework 120 supports the development of plug-ins.
- Plug-ins 122 extend the process engine functionality.
- a plug-in can implement classes and/or interfaces such that it can integrate with the plug-in framework.
- a B2B integration plug-in provides workflow actions and extends workflow node properties in the Development tool so that they can be used in a multi-business partner environment.
- the B2B integration plug-in allows for workflows that implement roles in a conversation based on one or more protocols.
- a Decision node Upon activation, a Decision node first evaluates its condition, executes the appropriate list of true or false actions, and then activates its true or false successor nodes. Done Upon activation, the Done node executes any associated actions, and marks as complete the current workflow, regardless of whether all Done nodes have been reached. Event Upon activation, an Event node checks for any addressed messages that may have previously been received, and, if none are found, registers itself in the Event Watch table. Once triggered, an Event node can perform the following tasks: Initialize variables Execute associated actions Activate successor nodes. The activation of successor nodes proceeds according to the rules for each node type.
- an OR Join node evaluates the OR condition; upon activation by all incoming paths, the AND Join node evaluates the AND condition. If conditions are met, the Join node activates its successor nodes.
- API application program interface
- a collaborative workflow is a workflow that implements a role for a business partner in a conversation.
- a conversation may have two or more roles, each of which is associated with a collaborative workflow.
- FIG. 2 is an illustration of workflow collaboration in one embodiment of the invention.
- the workflows can execute in the same process engine, in different process engines on the same computing device, or in different process engines on different computing devices connected by one or more networks (e.g., Internet, wireless, satellite, etc.).
- the buyer's start node 200 is invoked and, after performing any initialization, it activates task node 202 in the sequence.
- Node 202 composes a PriceAndAvailabilityQuote request message to send to the supplier. As its name implies, this message requests a price quote and availability information for a particular product carried by the supplier.
- Node 202 activates task node 204 which sends the message 206 to the supplier. The buyer then waits for a response from the supplier at event node 222 .
- the supplier's workflow start node 208 is invoked when the message is received.
- Task node 210 extracts the message.
- a sub-workflow (not shown) is invoked at task node 212 to processes the request.
- the supplier workflow waits at event node 214 to receive an event from the sub-workflow indicating that the request has been processed. Once the event is received, the supplier composes a response message with the price quote determined by the sub-workflow at task node 216 and then sends the message to the buyer at task node 218 . The sender then completes processing at done node 230 . Once the message is received by the buyer at node 222 , the buyer extracts the message at node task 224 , processes it at task node 226 and then completes execution at done node 228 .
- processing node 224 might store the price/stock quote in a database, invoke a sub-workflow to further process it, and/or return the information to a form on a web browser.
- FIG. 3 is an illustration of prior art business partner interaction.
- BEA WebLogic IntegrationTM software available from BEA Systems, Inc., is a commercial implementation of such a system.
- this diagram depicts objects as functionally separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the objects portrayed in FIG. 3 can be arbitrarily combined or divided into separate software, firmware or hardware components. Furthermore, it will also be apparent to those skilled in the art that such objects, irregardless of how they are combined or divided, can execute on the same computing device or can be arbitrarily distributed among different computing devices connected by a network.
- Process engine 300 communicates with B2B engine 302 through plug-in framework 304 .
- the B2B engine enables workflows executing in the process engine to communicate/collaborate with other business partners' process engines.
- the plug-in framework can include an API (application program interface) which is used by the process engine and an SPI (service provider interface) which is implemented by the B2B engine.
- the plug-in framework can include a communication protocol through which the process engine and the B2B engine communicate.
- the process engine and the B2B engine reside on different computing devices yet communicate through the plug-in framework.
- the B2B engine processes and routes business messages among business partners at run time.
- the contents and format of a business message can depend on the protocol chosen for the conversation.
- the protocol specifies the structure of business messages, how to process the messages, and how to route them to the appropriate recipients.
- a protocol may also specify characteristics of messages related to persistence and reliability.
- a business partner may also implement process engine 300 and B2B engine 302 .
- a business partner need only support the particular protocol used by the B2B engine which initiates the conversation.
- the B2B engine includes support for a number of protocols, including but not limited to RosettaNet 308 and ebXML 306 .
- RosettaNet is a self-funded, nonprofit consortium of major companies working to create and implement industry-wide, open e-business process standards (see http://www.rosettanet.org.). These standards form a common e-business language, aligning processes between supply chain partners on a global basis.
- RosettaNet provides specifications for the RosettaNet Implementation Framework (RNIF), the Partner Interface Processes (PIPs), and business and technical dictionaries.
- the ebXML Message Service Specification which defines the message enveloping and header document schema used to transfer ebXML messages with a communication protocol such as HTTP.
- a communication protocol such as HTTP.
- one embodiment supports the creation and execution of workflows that model ebXML business messages.
- the ebXML Message Service Specification is a set of layered extensions to the base Simple Object Access Protocol (SOAP) and SOAP Messages with Attachments specifications.
- SOAP Simple Object Access Protocol
- the ebXML Message Service provides security and reliability features that are not provided in the specifications for SOAP and SOAP Messages with Attachments (see http://www.ebxml.org).
- the B2B engine can communicate a business message to another business partner within the context of a transaction.
- a transaction specifies a series of actions that must be completed successfully or, in the case of failure, must be undone such that any data that was modified by the transaction is returned to its pre-transaction state. If a transaction succeeds, it is committed. Commitment of a transaction means that any changes to data made therein will survive a system failure.
- FIG. 4 is an illustration of prior art B2B engine transaction scenarios. Each scenario in the figure is labeled with a scenario number in parenthesis. In each scenario, “A” and “B” represent two different business partners which may or may not be executing on the same computing device. The vertical lines represent time wherein time increases down the page.
- Scenario ( 1 ) illustrates a successful transaction. A begins a new transaction at time 400 . At time 402 , A sends a message to B. B receives the message at time 404 , processes the message during time span 406 , and sends an acknowledgement at time 408 . After sending the message to B, A waits for an acknowledgment from B (e.g., event node 222 in FIG. 2 ).
- B e.g., event node 222 in FIG. 2 .
- an acknowledgement is an HTTP status message.
- A receives the acknowledgement at time 410 and commits the transaction at time 412 .
- the duration of A's transaction is from time 400 to time 412 . This time span can be very long, depending on how responsive B is.
- a transaction can lock resources during its lifespan to prevent other threads of execution from changing them before the transaction has committed its own changes.
- the other threads of execution must wait until the transaction unlocks the resources before they can complete their work.
- long transactions can introduce bottlenecks by holding onto resources needed by other threads/transactions.
- a deadlock is a situation where two (or more) threads of execution cannot proceed because each is terminally waiting for the other to do something, such as releasing a lock on a shared resource.
- a deadlock will arise if B needs to access resources A has locked. This can occur in practice when A and B are co-located on the same computing device (e.g., when they are on the same server using the same database).
- Scenario ( 2 ) in FIG. 4 illustrates a send failure.
- A commences a transaction.
- A sends a message to B, however the message never reaches B. This could be due to a network failure of some sort.
- A waits until a message acknowledgement time-out occurs at time 410 .
- the transaction then fails at time 412 .
- A's transaction cannot complete until either it receives a message from B or it fails as a result of a time-out.
- scenario ( 1 ) other processes/transactions are prevented from accessing resources locked by A until A's transaction fails.
- Scenario ( 3 ) in FIG. 4 illustrates a system failure of B.
- the failure could be due to a hardware fault, software bug, or any combination of the two.
- A begins a new transaction.
- A sends B a message at time 402 which B receives at time 404 .
- B experiences a failure at time 406 .
- A never receives an acknowledgment from B and the transaction remains open until a time-out occurs at time 408 .
- the transaction then fails at time 410 .
- Scenario ( 4 ) in FIG. 4 illustrates an acknowledgement failure.
- A commences a transaction. Within that transaction at time 402 , A sends a message to B. B receives the message at time 404 and processes it until during time span 406 . A waits until a message acknowledgement time-out occurs at time 410 . At time 408 , B sends an acknowledgement to A, but it is received after A's transaction fails at time 412 . Thus, even though the message was transferred successfully from B's point-of-view, A's transaction has nonetheless failed. As a result of the transaction failure, A can try to re-execute the transaction. However, this will cause a second (duplicate) message to be sent to B which itself may introduce an error at B unless B can recognize the message as such and provide an acknowledgement to A.
- FIG. 5 is an illustration of an additional prior-art B2B engine transaction scenario.
- Scenario ( 5 ) illustrates a scenario in which A's system fails. The failure could be due to a hardware fault, software bug, or any combination of the two.
- A begins a new transaction.
- a time 502 A sends a message to B which B receives at time 504 .
- A fails at time 506 . Since A's transaction also fails as a result, A can try to re-execute it when A is no longer in a fail state. As with Scenario ( 4 ), this can cause a second (duplicate) message to be sent to B which may introduce an error at B.
- FIG. 6 is a modified system in accordance to one embodiment and by way of illustration.
- plug-in framework 602 and B2B engine 604 To process engine 600 , plug-in framework 602 and B2B engine 604 , a persistent FIFO (first in, first out queue) 606 and an escrow process 608 have been added.
- the B2B engine is no longer response for sending messages and receiving acknowledgments. This is undertaken by the escrow process and performed outside of the primary transaction.
- the B2B engine undertakes routing a business messages to a business partner, it transfers the message to the persistent FIFO.
- the persistent FIFO will persist the message—even across system failures—until the escrow process removes it.
- the persistent FIFO is implemented as a JMS message queue.
- the persistent FIFO can be implemented by an Enterprise JAVABeanTM (available from Sun Microsystems, Inc.) or any other approach that can provide persistent storage.
- the escrow process attempts to send the message at the head of the FIFO to its destination via a protocol such as ebXML 612 or RosettaNet 610 . If the message send fails for some reason (e.g., scenarios ( 2 )-( 5 )), the escrow process can retry until successful. Once a message has been successfully sent (e.g., an acknowledgement is received before a time-out occurs), the escrow process can remove the message from the FIFO. In this way, messages are never taken from persistent storage until the have been successfully transferred.
- FIG. 7 is an illustration of how a transaction can be structured to take advantage of the system of FIG. 6 and thus avoid delays and deadlocks.
- A begins a new transaction.
- A provides a business message to a persistent FIFO 606 .
- A simply commits the transaction at time 704 . This releases any resources locked by the transaction for use by other threads of execution/transactions.
- Escrow process 608 removes the message from the FIFO at time 706 . Once A has provided the message to the FIFO, the message is no longer considered within A's transaction.
- the escrow process sends the message to B at time 708 .
- B receives the message at time 710 and sends an acknowledgment to the escrow process at time 712 .
- the escrow process receives the acknowledgment at time 714 .
- the escrow process can re-send the message.
- the message is not lost due to the persistent FIFO.
- the escrow process receives the acknowledgment at time 714 , it can remove the original message from the persistent FIFO. If the escrow process times-out before receiving an acknowledgment from B, it can resend the message.
- B can implement duplicate message detection to filter out any duplicate messages that are sent by the escrow process.
- One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art.
- Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.
- the invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
- One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein.
- the storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
- the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention.
- software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and user applications.
Landscapes
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Engineering & Computer Science (AREA)
- Entrepreneurship & Innovation (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Operations Research (AREA)
- Marketing (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Data Mining & Analysis (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
A system and method for performing a business transaction including delivering a business message, comprising providing in a first transaction the business message to a first workflow process; transferring the business message from the first workflow process to a second process wherein the transfer is not part of the first transaction; wherein the business message is transferred to the second process using a protocol; and wherein transferring the business message to the second process will be successful even if the first workflow process abnormally terminates.
Description
- This application is a divisional of U.S. application Ser. No.: 10/428,880, entitled “SYSTEM AND METHOD FOR ELECTRONIC BUSINESS TRANSACTION RELIABILITY”, by Komal Mangtani, et al., filed on May 2, 2003 [Attorney's Docket No.: BEAS-01281US1] which claims priority from U.S. application Ser. No.: 60/377,309; entitled “HIGHLY-AVAILABLE INTEGRATION COMPONENTS” by Komal Mangtani, et al., filed on May 2, 2002. [Attorney's Docket No.: BEAS-01281US0].
- A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
- The present invention disclosure relates to increasing the reliability of electronic business transactions.
- Enterprises strive to integrate, automate and streamline internal and external business processes to improve their performance in today's dynamic business-to-business (B2B) electronic commerce (e-commerce) environment. Processes such as procurement, sales, order fulfillment and customer service are typical examples of processes suitable for B2B integration. These processes drive a company's e-commerce interactions with their customers, partners, distributors, and suppliers; they can also streamline the company's internal business. Software frameworks for B2B integration can support these process by providing workflow processing, messaging and enterprise application integration. However, the value of a B2B framework is diminished without robust methods for handling hardware and software faults as they arise.
-
FIG. 1 is an illustration of business process management functionality in an embodiment of the invention. -
FIG. 2 is an illustration of workflow collaboration in an embodiment of the invention. -
FIG. 3 is an illustration of prior art business partner interaction. -
FIG. 4 is an illustration of prior art B2B engine transaction scenarios. -
FIG. 5 is an illustration of an additional prior-art B2B engine transaction scenario. -
FIG. 6 is a modified system in accordance to one embodiment and by way of illustration. -
FIG. 7 is an illustration of how a transaction can be structured to take advantage of the system ofFIG. 6 and thus avoid delays and deadlocks - The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
- In the following description, various aspects of the present invention will be described. However, it will be apparent to those skilled in the art that the present invention may be practiced with only some or all aspects of the present invention. For purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the present invention.
- Parts of the description will be presented in data processing terms, such as data, selection, retrieval, generation, and so forth, consistent with the manner commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. As well understood by those skilled in the art, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, and otherwise manipulated through electrical and/or optical components of a processor and its subsystems.
- Various operations will be described as multiple discrete steps in turn, in a manner that is most helpful in understanding the present invention, however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.
- Various embodiments will be illustrated in terms of exemplary classes and/or objects in an object-oriented programming paradigm. It will be apparent to one skilled in the art that the present invention can be practiced using any number of different classes/objects/interfaces, not merely those included here for illustrative purposes. Furthermore, it will also be apparent that the present invention is not limited to any particular software programming language or programming paradigm.
- One embodiment is an XML (eXtensible Markup Language) and JAVA™-based e-commerce platform that facilitates e-commerce on the World Wide Web. XML is a text-based language for describing data in a machine-independent way. The XML specification is available from the World Wide Web Consortium (http://www.w3.org). JAVA is an object-oriented programming language and run-time environment available from Sun Microsystems, Inc. of Mountain View, Calif. One embodiment includes a software framework and a set of services built on top of an application server, such as the BEA WebLogic Server® available from BEA Systems, Inc. of San Jose, Calif.
- The basic building blocks of B2B e-commerce are software applications that create interactions among business partners. The term “partner” for purposes of this discussion is synonymous with the B2B software applications that a given partner uses to carry out e-commerce transactions. A partner interacts with one or more other partners to form an e-commerce community. By way of a non-limiting example, partners in an e-commerce community can represent large enterprises or small divisions within an enterprise. An e-commerce community can: 1) exist entirely within a company, spanning multiple corporate departments (e.g., the business purpose for such a community might be inventory management); 2) span multiple companies across firewalls and over a network such as the Internet (e.g., the business purpose might be supply chain management or multi-step purchasing interactions); and 3) include business partners both within a company and in other companies (e.g., one or more of the business partners within a company communicates with business partners in other companies across a network).
- In one embodiment, partners can participate in a business conversation. A business conversation is a sequence of one or more business messages exchanged between business partners. In one embodiment, a business message can contain one or more XML documents, one or more attachments, and/or any combination of these. The exchange of business messages is determined by roles business partners play in a conversation. In one embodiment, a conversation can be associated with a unique name and version, and can define two or more roles to be used by business partners in a conversation. A conversation can also be associated with any communication protocol that supports a conversation identifier and/or a message identifier (e.g., ebXML, RosettaNet, etc.). It will be appreciated that the present disclosure is not limited to any particular communication protocol. A business partner can be configured to communicate directly with other business partners in a peer-to-peer mode, through an intermediary in a hub-and-spoke mode, or both. The different configuration modes allow for either direct or mediated messaging among business partners. An intermediary in the message flow can perform tasks such as routing and filtering of messages, or it can provide services to the business partners in the conversation.
-
FIG. 1 is an illustration of business process management functionality in one embodiment of the invention. BEA WebLogic Integration™ software available from BEA Systems, Inc. is a commercial implementation of such a system. Although this diagram depicts objects as functionally separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the objects portrayed inFIG. 1 can be arbitrarily combined or divided into separate software, firmware or hardware components. Furthermore, it will also be apparent to those skilled in the art that such objects, irregardless of how they are combined or divided, can execute on the same computing device or can be arbitrarily distributed among different computing devices connected by a network. - A
process engine 100 manages the run-time execution of business processes for a business partner. In one embodiment, the process engine is JAVA-based and multi-threaded.Visual development tool 102 can used to design business processes. The development tool can provide a graphical user interface in which familiar flowchart elements can be employed to create aworkflow 104. In one embodiment, a workflow is an automated business process through which information is communicated to the right participant at the right time according to a set of intelligent business rules that allow computing devices to carry out business transactions. To create a workflow using the development tool, a user identifies required elements and defines the process flow by arranging the flowchart elements (or nodes) into a proper logical sequence. This sequence can then be saved as a workflow template definition intemplate storage 106. Workflow templates can be given meaningful names such as “Billing” and “Order Processing”. - A workflow template can be invoked or executed through a number of mechanisms, including but not limited to JAVA Message Service (JMS) 108,
timers 110, manually via an application program interfaces or from awork list 112, or from another workflow 114 (as a sub-workflow). JMS is available from Sun Microsystems, Inc. Once a template is invoked, the process engine instantiates it by activating the workflow's Start node. The Start node can initialize variables and activate any successor nodes (per the sequence specified in the development tool). When a node is activated, it is evaluated based on its type according to the rules in Table 1. As part of its activation, a node may evaluate actions, such as integrating with external software (e.g., when an action invokes an EntityJAVABean™ method 116 or sends an XML message to another application 118). Once a node has completed its actions, it activates the next node(s) in the sequence based on its evaluation rules and the sequence specified in the Development tool. - A plug-in
framework 120 supports the development of plug-ins. Plug-ins 122 extend the process engine functionality. In one embodiment, a plug-in can implement classes and/or interfaces such that it can integrate with the plug-in framework. A B2B integration plug-in provides workflow actions and extends workflow node properties in the Development tool so that they can be used in a multi-business partner environment. The B2B integration plug-in allows for workflows that implement roles in a conversation based on one or more protocols. -
TABLE 1 Workflow Node Types in an Embodiment NODE TYPE EVALUATION RULES Decision Upon activation, a Decision node first evaluates its condition, executes the appropriate list of true or false actions, and then activates its true or false successor nodes. Done Upon activation, the Done node executes any associated actions, and marks as complete the current workflow, regardless of whether all Done nodes have been reached. Event Upon activation, an Event node checks for any addressed messages that may have previously been received, and, if none are found, registers itself in the Event Watch table. Once triggered, an Event node can perform the following tasks: Initialize variables Execute associated actions Activate successor nodes. The activation of successor nodes proceeds according to the rules for each node type. Join Upon activation by any single incoming path, an OR Join node evaluates the OR condition; upon activation by all incoming paths, the AND Join node evaluates the AND condition. If conditions are met, the Join node activates its successor nodes. Start Upon activation, a Start node can perform the following tasks: Initialize variables Execute associated actions Activate any successor nodes. The activation of successor nodes proceeds according to the rules for each node type. Task Upon activation, a Task node executes a list of Activated tasks in sequence. The following summarizes the subsequent actions that may be taken: If the task is executed, the Execute actions listed are executed. If a task is marked done by an action or API (application program interface) request, the MarkedDone actions are executed. If an action marks the workflow as complete, or if it aborts the workflow, no further processing occurs. - A collaborative workflow is a workflow that implements a role for a business partner in a conversation. A conversation may have two or more roles, each of which is associated with a collaborative workflow.
FIG. 2 is an illustration of workflow collaboration in one embodiment of the invention. By way of a non-limiting example, there are two participating roles, that of buyer and supplier, and hypothetical workflows for each. The workflows can execute in the same process engine, in different process engines on the same computing device, or in different process engines on different computing devices connected by one or more networks (e.g., Internet, wireless, satellite, etc.). - The buyer's
start node 200 is invoked and, after performing any initialization, it activatestask node 202 in the sequence.Node 202 composes a PriceAndAvailabilityQuote request message to send to the supplier. As its name implies, this message requests a price quote and availability information for a particular product carried by the supplier.Node 202 activatestask node 204 which sends themessage 206 to the supplier. The buyer then waits for a response from the supplier atevent node 222. The supplier'sworkflow start node 208 is invoked when the message is received.Task node 210 extracts the message. A sub-workflow (not shown) is invoked attask node 212 to processes the request. The supplier workflow waits atevent node 214 to receive an event from the sub-workflow indicating that the request has been processed. Once the event is received, the supplier composes a response message with the price quote determined by the sub-workflow attask node 216 and then sends the message to the buyer attask node 218. The sender then completes processing at donenode 230. Once the message is received by the buyer atnode 222, the buyer extracts the message atnode task 224, processes it attask node 226 and then completes execution at donenode 228. By way of a non-limiting example,processing node 224 might store the price/stock quote in a database, invoke a sub-workflow to further process it, and/or return the information to a form on a web browser. -
FIG. 3 is an illustration of prior art business partner interaction. BEA WebLogic Integration™ software available from BEA Systems, Inc., is a commercial implementation of such a system. Although this diagram depicts objects as functionally separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the objects portrayed inFIG. 3 can be arbitrarily combined or divided into separate software, firmware or hardware components. Furthermore, it will also be apparent to those skilled in the art that such objects, irregardless of how they are combined or divided, can execute on the same computing device or can be arbitrarily distributed among different computing devices connected by a network. -
Process engine 300 communicates withB2B engine 302 through plug-inframework 304. The B2B engine enables workflows executing in the process engine to communicate/collaborate with other business partners' process engines. In one embodiment, the plug-in framework can include an API (application program interface) which is used by the process engine and an SPI (service provider interface) which is implemented by the B2B engine. In another embodiment, the plug-in framework can include a communication protocol through which the process engine and the B2B engine communicate. In yet another embodiment, the process engine and the B2B engine reside on different computing devices yet communicate through the plug-in framework. - In one embodiment, the B2B engine processes and routes business messages among business partners at run time. The contents and format of a business message can depend on the protocol chosen for the conversation. The protocol specifies the structure of business messages, how to process the messages, and how to route them to the appropriate recipients. A protocol may also specify characteristics of messages related to persistence and reliability. In one embodiment, a business partner may also implement
process engine 300 andB2B engine 302. In another embodiment, a business partner need only support the particular protocol used by the B2B engine which initiates the conversation. - The B2B engine includes support for a number of protocols, including but not limited to
RosettaNet 308 andebXML 306. RosettaNet is a self-funded, nonprofit consortium of major companies working to create and implement industry-wide, open e-business process standards (see http://www.rosettanet.org.). These standards form a common e-business language, aligning processes between supply chain partners on a global basis. To support its mission, RosettaNet provides specifications for the RosettaNet Implementation Framework (RNIF), the Partner Interface Processes (PIPs), and business and technical dictionaries. - The ebXML Message Service Specification, which defines the message enveloping and header document schema used to transfer ebXML messages with a communication protocol such as HTTP. In addition, one embodiment supports the creation and execution of workflows that model ebXML business messages. The ebXML Message Service Specification is a set of layered extensions to the base Simple Object Access Protocol (SOAP) and SOAP Messages with Attachments specifications. The ebXML Message Service provides security and reliability features that are not provided in the specifications for SOAP and SOAP Messages with Attachments (see http://www.ebxml.org).
- The B2B engine can communicate a business message to another business partner within the context of a transaction. A transaction specifies a series of actions that must be completed successfully or, in the case of failure, must be undone such that any data that was modified by the transaction is returned to its pre-transaction state. If a transaction succeeds, it is committed. Commitment of a transaction means that any changes to data made therein will survive a system failure.
-
FIG. 4 is an illustration of prior art B2B engine transaction scenarios. Each scenario in the figure is labeled with a scenario number in parenthesis. In each scenario, “A” and “B” represent two different business partners which may or may not be executing on the same computing device. The vertical lines represent time wherein time increases down the page. Scenario (1) illustrates a successful transaction. A begins a new transaction attime 400. Attime 402, A sends a message to B. B receives the message attime 404, processes the message duringtime span 406, and sends an acknowledgement attime 408. After sending the message to B, A waits for an acknowledgment from B (e.g.,event node 222 inFIG. 2 ). In one embodiment, an acknowledgement is an HTTP status message. A receives the acknowledgement attime 410 and commits the transaction attime 412. The duration of A's transaction is fromtime 400 totime 412. This time span can be very long, depending on how responsive B is. - To ensure reliability, a transaction can lock resources during its lifespan to prevent other threads of execution from changing them before the transaction has committed its own changes. However, if the transaction endures for a long period of time, the other threads of execution must wait until the transaction unlocks the resources before they can complete their work. Thus, long transactions can introduce bottlenecks by holding onto resources needed by other threads/transactions. In addition to this problem, if A and B happen to be dependent on the same shared resources, a deadlock can arise. A deadlock is a situation where two (or more) threads of execution cannot proceed because each is terminally waiting for the other to do something, such as releasing a lock on a shared resource. For example, a deadlock will arise if B needs to access resources A has locked. This can occur in practice when A and B are co-located on the same computing device (e.g., when they are on the same server using the same database).
- Scenario (2) in
FIG. 4 illustrates a send failure. Attime 400, A commences a transaction. At time 402 A sends a message to B, however the message never reaches B. This could be due to a network failure of some sort. As a consequence, A waits until a message acknowledgement time-out occurs attime 410. The transaction then fails attime 412. A's transaction cannot complete until either it receives a message from B or it fails as a result of a time-out. As with scenario (1), other processes/transactions are prevented from accessing resources locked by A until A's transaction fails. - Scenario (3) in
FIG. 4 illustrates a system failure of B. The failure could be due to a hardware fault, software bug, or any combination of the two. As with the previous scenarios, at time 400 A begins a new transaction. A sends B a message attime 402 which B receives attime 404. Before acknowledging the transaction, B experiences a failure attime 406. As a result, A never receives an acknowledgment from B and the transaction remains open until a time-out occurs attime 408. The transaction then fails attime 410. - Scenario (4) in
FIG. 4 illustrates an acknowledgement failure. Attime 400, A commences a transaction. Within that transaction attime 402, A sends a message to B. B receives the message attime 404 and processes it until duringtime span 406. A waits until a message acknowledgement time-out occurs attime 410. Attime 408, B sends an acknowledgement to A, but it is received after A's transaction fails attime 412. Thus, even though the message was transferred successfully from B's point-of-view, A's transaction has nonetheless failed. As a result of the transaction failure, A can try to re-execute the transaction. However, this will cause a second (duplicate) message to be sent to B which itself may introduce an error at B unless B can recognize the message as such and provide an acknowledgement to A. -
FIG. 5 is an illustration of an additional prior-art B2B engine transaction scenario. Scenario (5) illustrates a scenario in which A's system fails. The failure could be due to a hardware fault, software bug, or any combination of the two. Attime 500, A begins a new transaction. Atime 502, A sends a message to B which B receives attime 504. Before A can receive a response from B, A fails attime 506. Since A's transaction also fails as a result, A can try to re-execute it when A is no longer in a fail state. As with Scenario (4), this can cause a second (duplicate) message to be sent to B which may introduce an error at B. - The problems exhibited in scenarios (1)-(5) can be remedied in one embodiment by excluding message sending from A's transaction.
FIG. 6 is a modified system in accordance to one embodiment and by way of illustration. Toprocess engine 600, plug-inframework 602 andB2B engine 604, a persistent FIFO (first in, first out queue) 606 and anescrow process 608 have been added. In this embodiment, the B2B engine is no longer response for sending messages and receiving acknowledgments. This is undertaken by the escrow process and performed outside of the primary transaction. When the B2B engine undertakes routing a business messages to a business partner, it transfers the message to the persistent FIFO. The persistent FIFO will persist the message—even across system failures—until the escrow process removes it. In one embodiment, the persistent FIFO is implemented as a JMS message queue. In another embodiment, the persistent FIFO can be implemented by an Enterprise JAVABean™ (available from Sun Microsystems, Inc.) or any other approach that can provide persistent storage. The escrow process attempts to send the message at the head of the FIFO to its destination via a protocol such asebXML 612 orRosettaNet 610. If the message send fails for some reason (e.g., scenarios (2)-(5)), the escrow process can retry until successful. Once a message has been successfully sent (e.g., an acknowledgement is received before a time-out occurs), the escrow process can remove the message from the FIFO. In this way, messages are never taken from persistent storage until the have been successfully transferred. -
FIG. 7 is an illustration of how a transaction can be structured to take advantage of the system ofFIG. 6 and thus avoid delays and deadlocks. Attime 700, A begins a new transaction. Attime 702, A provides a business message to apersistent FIFO 606. Rather than wait for the message to be sent to B (or for the acknowledgment to be received), A simply commits the transaction attime 704. This releases any resources locked by the transaction for use by other threads of execution/transactions.Escrow process 608 removes the message from the FIFO attime 706. Once A has provided the message to the FIFO, the message is no longer considered within A's transaction. The escrow process sends the message to B attime 708. B receives the message attime 710 and sends an acknowledgment to the escrow process attime 712. The escrow process receives the acknowledgment attime 714. - In one embodiment, if the send fails to reach B due to a system failure on A or a transmission error, the escrow process can re-send the message. The message is not lost due to the persistent FIFO. When the escrow process receives the acknowledgment at
time 714, it can remove the original message from the persistent FIFO. If the escrow process times-out before receiving an acknowledgment from B, it can resend the message. In one embodiment, B can implement duplicate message detection to filter out any duplicate messages that are sent by the escrow process. - One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
- One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
- Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and user applications.
- The foregoing description of the preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention, the various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.
Claims (27)
1. A method for performing a business transaction including delivering a business message, comprising:
persisting a business message within a first transaction;
providing the business message to an escrow process wherein the providing is not part of the first transaction;
transferring the business message from the escrow process to a second process;
wherein the escrow process transfers the business message to the second process using a protocol; and
wherein transferring the business message from the escrow process to the second process will be successful even if the first workflow process abnormally terminates.
2. The method of claim 1 wherein:
the workflow process is an instantiated workflow template.
3. The method of claim 2 wherein:
a workflow template is a sequence of one or more tasks derived from a graphical representation of the tasks.
4. The method of claim 1 wherein:
the first transaction is an set of one or more operations that can be rolled-back in the event that the first transaction does not complete.
5. The method of claim 1 wherein:
the protocol is one of: 1) ebXML; and 2) RosettaNet.
6. The method of claim 1 wherein:
the business message is based on Extensible Markup Language (XML).
7. The method of claim 1 wherein:
the first transaction holds an exclusive lock on a first set of shared resources.
8. The method of claim 1 wherein:
the first workflow process and the second process both execute on the same computing device.
9. The method of claim 1 wherein:
the transfer of the business message is reliable.
10. A system for performing a business transaction including delivering a business message, comprising:
a first workflow process to persist the business message within a first transaction;
an escrow process coupled to the first workflow process, the escrow process to accept the business message from the first workflow process wherein the transfer takes place outside of the first transaction;
a second process coupled to the escrow process, the second process to accept the business message from the escrow process using a protocol; and
wherein transferring the business message from the escrow process to the second process will be successful even if the first workflow process abnormally terminates.
11. The system of claim 10 wherein:
the workflow process is an instantiated workflow template.
12. The system of claim 11 wherein:
a workflow template is a sequence of one or more tasks derived from a graphical representation of the tasks.
13. The system of claim 10 wherein:
the first transaction is an set of one or more operations that can be rolled-back in the event that the first transaction does not complete.
14. The system of claim 10 wherein:
the protocol is one of: 1) ebXML; and 2) RosettaNet.
15. The system of claim 10 wherein:
the business message is based on Extensible Markup Language (XML).
16. The system of claim 10 wherein:
the first transaction holds an exclusive lock on a first set of shared resources.
17. The system of claim 10 wherein:
the first workflow process and the second process both execute on the same computing device.
18. The system of claim 10 wherein:
the transfer of the business message is reliable.
19. A machine readable medium having instructions stored thereon that when executed by a processor cause a system to:
persist a business message within a first transaction;
provide the business message to an escrow process wherein the providing is not part of the first transaction;
transfer the business message from the escrow process to a second process;
wherein the escrow process transfers the business message to the second process using a protocol; and
wherein transferring the business message from the escrow process to the second process will be successful even if the first workflow process abnormally terminates.
20. The machine readable medium of claim 19 wherein:
the workflow process is an instantiated workflow template.
21. The machine readable medium of claim 20 wherein:
a workflow template is a sequence of one or more tasks derived from a graphical representation of the tasks.
22. The machine readable medium of claim 19 wherein:
the first transaction is an set of one or more operations that can be rolled-back in the event that the first transaction does not complete.
23. The machine readable medium of claim 19 wherein:
the protocol is one of: 1) ebXML; and 2) RosettaNet.
24. The machine readable medium of claim 19 wherein:
the business message is based on Extensible Markup Language (XML).
25. The machine readable medium of claim 19 wherein:
the first transaction holds an exclusive lock on a first set of shared resources.
26. The machine readable medium of claim 19 wherein:
the first workflow process and the second process both execute on the same computing device.
27. The machine readable medium of claim 19 wherein:
the transfer of the business message is reliable.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/017,880 US20080147474A1 (en) | 2002-05-02 | 2008-01-22 | System and method for electronic business transaction reliability |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US37730902P | 2002-05-02 | 2002-05-02 | |
US10/428,880 US8170896B2 (en) | 2002-05-02 | 2003-05-02 | System and method for electronic business transaction reliability |
US12/017,880 US20080147474A1 (en) | 2002-05-02 | 2008-01-22 | System and method for electronic business transaction reliability |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/428,880 Division US8170896B2 (en) | 2002-05-02 | 2003-05-02 | System and method for electronic business transaction reliability |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080147474A1 true US20080147474A1 (en) | 2008-06-19 |
Family
ID=29401478
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/428,880 Active 2029-03-17 US8170896B2 (en) | 2002-05-02 | 2003-05-02 | System and method for electronic business transaction reliability |
US12/017,880 Abandoned US20080147474A1 (en) | 2002-05-02 | 2008-01-22 | System and method for electronic business transaction reliability |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/428,880 Active 2029-03-17 US8170896B2 (en) | 2002-05-02 | 2003-05-02 | System and method for electronic business transaction reliability |
Country Status (3)
Country | Link |
---|---|
US (2) | US8170896B2 (en) |
AU (1) | AU2003228800A1 (en) |
WO (1) | WO2003094055A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7792871B1 (en) * | 2005-12-29 | 2010-09-07 | United Services Automobile Association | Workflow administration tools and user interfaces |
US7792872B1 (en) | 2005-12-29 | 2010-09-07 | United Services Automobile Association | Workflow administration tools and user interfaces |
US7822706B1 (en) | 2005-12-29 | 2010-10-26 | United Services Automobile Association (Usaa) | Workflow administration tools and user interfaces |
US7840526B1 (en) | 2005-12-29 | 2010-11-23 | United Services Automobile Association (Usaa) | Workflow administration tools and user interfaces |
US20140316844A1 (en) * | 2013-04-22 | 2014-10-23 | Nipendo Ltd. | Messaging engine |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8135772B2 (en) * | 2002-05-01 | 2012-03-13 | Oracle International Corporation | Single servlets for B2B message routing |
EP1560137A1 (en) * | 2004-01-30 | 2005-08-03 | Sap Ag | Technique for reliable message confirmation |
US7774006B2 (en) * | 2006-02-02 | 2010-08-10 | Airwide Solutions Inc. | Apparatus and method for improving short message service dependability |
US8276167B2 (en) * | 2007-03-21 | 2012-09-25 | International Business Machines Corporation | Distributed pluggable middleware services |
AU2010337848A1 (en) * | 2009-12-30 | 2012-07-26 | Infosys Limited | Partner portal solution for financial sector |
US20120030094A1 (en) * | 2010-07-27 | 2012-02-02 | Verizon Patent And Licensing Inc. | Design, deployment, and use of an automated flow-model-view-controller workflow |
US20140053060A1 (en) * | 2012-08-17 | 2014-02-20 | Launchbase, LLC | Website development tool |
US9749280B2 (en) * | 2013-09-20 | 2017-08-29 | Oracle International Corporation | Techniques for reliable messaging for an intermediary in a network communication environment |
CN111066033A (en) * | 2017-08-30 | 2020-04-24 | 谷歌有限责任公司 | Machine learning method for generating labels of fuzzy results |
CN107730077A (en) * | 2017-09-13 | 2018-02-23 | 平安科技(深圳)有限公司 | Node tasks data display method, device, storage medium and computer equipment |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5751958A (en) * | 1995-06-30 | 1998-05-12 | Peoplesoft, Inc. | Allowing inconsistency in a distributed client-server application |
US6266304B1 (en) * | 1993-09-28 | 2001-07-24 | Sony Corporation | Disc eccentricity measuring apparatus and method thereof and apparatus for recording and/or reproducing disc-shaped recording medium |
US20020040304A1 (en) * | 2000-10-02 | 2002-04-04 | Subrao Shenoy | Methods and systems for creating and managing capital asset business exchanges |
US20020120537A1 (en) * | 2001-02-28 | 2002-08-29 | Dominic Morea | Web based system and method for managing business to business online transactions |
US20020156693A1 (en) * | 2000-02-16 | 2002-10-24 | Bea Systems, Inc. | Method for providing real-time conversations among business partners |
US20020161707A1 (en) * | 2001-03-30 | 2002-10-31 | Alan Cole | Method and system for multi-currency escrow service for web-based transactions |
US20020188653A1 (en) * | 2001-06-07 | 2002-12-12 | Intel Corporation | Systems and methods for recoverable workflow |
US6510439B1 (en) * | 1999-08-06 | 2003-01-21 | Lucent Technologies Inc. | Method and system for consistent update and retrieval of document in a WWW server |
US6915274B2 (en) * | 2001-03-14 | 2005-07-05 | Hewlett-Packard Development Company, L.P. | Reverse logistics method for recapturing value of used goods over internet exchange portals |
US7249069B2 (en) * | 2001-08-27 | 2007-07-24 | United Parcel Service Of America, Inc. | International cash-on-delivery system and method |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3956615A (en) * | 1974-06-25 | 1976-05-11 | Ibm Corporation | Transaction execution system with secure data storage and communications |
US6266340B1 (en) * | 1998-04-03 | 2001-07-24 | Vertical Networks, Inc. | Systems and methods for multiple voice data communication which includes interface cards including configurable clocks that are dynamically coupled to a TDS bus |
US20020013722A1 (en) * | 2000-07-27 | 2002-01-31 | Kanaga Samantha J. | Enhanced document escrow service |
US7013289B2 (en) * | 2001-02-21 | 2006-03-14 | Michel Horn | Global electronic commerce system |
US20030018563A1 (en) * | 2001-07-13 | 2003-01-23 | Efficient Capital Corporation | Trading and processing of commercial accounts receivable |
-
2003
- 2003-05-01 AU AU2003228800A patent/AU2003228800A1/en not_active Abandoned
- 2003-05-01 WO PCT/US2003/013606 patent/WO2003094055A1/en not_active Application Discontinuation
- 2003-05-02 US US10/428,880 patent/US8170896B2/en active Active
-
2008
- 2008-01-22 US US12/017,880 patent/US20080147474A1/en not_active Abandoned
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6266304B1 (en) * | 1993-09-28 | 2001-07-24 | Sony Corporation | Disc eccentricity measuring apparatus and method thereof and apparatus for recording and/or reproducing disc-shaped recording medium |
US5751958A (en) * | 1995-06-30 | 1998-05-12 | Peoplesoft, Inc. | Allowing inconsistency in a distributed client-server application |
US6510439B1 (en) * | 1999-08-06 | 2003-01-21 | Lucent Technologies Inc. | Method and system for consistent update and retrieval of document in a WWW server |
US20020156693A1 (en) * | 2000-02-16 | 2002-10-24 | Bea Systems, Inc. | Method for providing real-time conversations among business partners |
US20020040304A1 (en) * | 2000-10-02 | 2002-04-04 | Subrao Shenoy | Methods and systems for creating and managing capital asset business exchanges |
US20020120537A1 (en) * | 2001-02-28 | 2002-08-29 | Dominic Morea | Web based system and method for managing business to business online transactions |
US6915274B2 (en) * | 2001-03-14 | 2005-07-05 | Hewlett-Packard Development Company, L.P. | Reverse logistics method for recapturing value of used goods over internet exchange portals |
US20020161707A1 (en) * | 2001-03-30 | 2002-10-31 | Alan Cole | Method and system for multi-currency escrow service for web-based transactions |
US20020188653A1 (en) * | 2001-06-07 | 2002-12-12 | Intel Corporation | Systems and methods for recoverable workflow |
US7249069B2 (en) * | 2001-08-27 | 2007-07-24 | United Parcel Service Of America, Inc. | International cash-on-delivery system and method |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7792871B1 (en) * | 2005-12-29 | 2010-09-07 | United Services Automobile Association | Workflow administration tools and user interfaces |
US7792872B1 (en) | 2005-12-29 | 2010-09-07 | United Services Automobile Association | Workflow administration tools and user interfaces |
US7822706B1 (en) | 2005-12-29 | 2010-10-26 | United Services Automobile Association (Usaa) | Workflow administration tools and user interfaces |
US7840526B1 (en) | 2005-12-29 | 2010-11-23 | United Services Automobile Association (Usaa) | Workflow administration tools and user interfaces |
US8244668B1 (en) | 2005-12-29 | 2012-08-14 | United Services Automobile Association (Usaa) | Workflow administration tools and user interfaces |
US20140316844A1 (en) * | 2013-04-22 | 2014-10-23 | Nipendo Ltd. | Messaging engine |
Also Published As
Publication number | Publication date |
---|---|
AU2003228800A1 (en) | 2003-11-17 |
US20030208374A1 (en) | 2003-11-06 |
US8170896B2 (en) | 2012-05-01 |
WO2003094055A1 (en) | 2003-11-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20080147474A1 (en) | System and method for electronic business transaction reliability | |
US10489730B2 (en) | Managing virtual business instances within a computer network | |
US7627631B2 (en) | Systems and methods for collaborative business plug-ins | |
US7912895B2 (en) | System and method for managing service interactions | |
US7603476B1 (en) | Pseudo-synchronous messaging | |
US7480916B2 (en) | Exploiting services in an integrated development environment | |
US7661106B1 (en) | Distributed transaction processing system | |
US20090024514A1 (en) | Method and System for Process Brokering and Content Integration for Collaborative Business Process Management | |
Myerson | The complete book of middleware | |
US7467371B1 (en) | Binding for business workflow processes | |
US7373424B2 (en) | Exactly once protocol for message-based collaboration | |
US20050188201A1 (en) | Technique for reliable message confirmation | |
Abreu et al. | Specifying and composing interaction protocols for service-oriented system modelling | |
EP1531394A2 (en) | Software agents incorporating message-driven beans for a J2EE computing environment | |
Pope | Business transaction protocol | |
Bussler | Public process inheritance for business-to-business integration | |
US20050096927A1 (en) | Handling a delivery failure as a program exception in a distributed asynchronous architecture | |
Kumaran et al. | A framework-based approach to building private trading exchanges | |
Tai et al. | Conditional messaging: extending reliable messaging with application conditions | |
Leymann | Managing Business Processes via Workflow Technology. | |
Zhu et al. | Quality attribute scenario based architectural modeling for self-adaptation supported by architecture-based reflective middleware | |
US20040122720A1 (en) | Meta-coordination of distributed computations | |
Dayal et al. | Workflow technologies meet the internet | |
Liu et al. | Enhancing web services conversation with exception contexts for handling exceptions of composite services | |
Wetherbee et al. | EJB Message-Driven Beans |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |