A distributed transaction processing system is disclosed in which a process automation application receives a transaction request from a requesting application. In response to the request, the process automation application obtains a transaction definition for the transaction requested by the requesting application. This transaction definition comprises a plurality of operation definitions, which indicate a plurality of operations constituting the requested transaction. For each of the operation definitions in the transaction definition, the process automation application produces an operation request. These operation requests are sent to one or more service applications, and one or more responses are received by the process automation application after the operations are performed by the service applications. Based on the responses, the process automation application produces a transaction response, which is sent to the requesting application. In this manner, the requested transaction is completed.

Distributed transaction processing system

Aspects of the present embodiments provide an eCommerce environment adapted to accept and process various message types (e.g., cXML and mXML). In general, requests are provided from a requesting entity to an application hosting entity. Data from incoming requests are mapped to a format understandable to an appropriate application(s). Responses from the application(s) are then mapped into a response format acceptable by the requesting entity. To this end, embodiments disclosed herein provide processes for the development and execution of a data driven process for mapping multiple request/response message pairs to a single application interface or set of application interfaces. In one embodiment, these processes are driven by development time and run time documents that describe a development time view of the message pairs and the application interfaces as well as runtime instructions for providing the mappings, respectively.

Process for data driven application integration for B2B

A light-weight architecture is provided, where each component is in itself its own advanced mini-transaction processing monitor. To accomplish this, the system is most readily implemented as a set of Java classes. The resulting architecture is as follows. In a composite system, each server is an independent component performing its own scheduling and transaction management. These servers are built using Java and inheriting from the classes provided by the system according to the invention. The interface to each server defines the services it implements. An invocation of one of these services (through remote method invocation) results in the creation of a local transaction (child of the invoking transaction and parent of any transaction that might be triggered by invoking the services of other servers). Each transaction is a thread that (in an exemplary system) can invoke SQL statements in a local database (directly connected to that server) as well as services offered by other servers. All the information that is required to build a global composite transaction is implicitly added by the system to each call. Each transaction is, however, independently handled at each server. That is, the servers neither communicate among themselves nor rely on a centralized component to make scheduling or recovery decisions. In this way, components can be dynamically added or removed from the system without compromising correctness. All a new server needs to know is the interface and address of the servers it will invoke. Regardless of the configuration, the system according to the invention guarantees that transactions executed over these servers will be correct (serializable) and recoverable at a global and local level.

Decentralized, distributed internet data management

A process automation application, referred to as a commerce exchange server, for sending transaction messages between application programs uses a transaction definition data structure for specifying the component operations and processing logic that comprise the transaction. The data structure specifies one or more operations that constitute the transaction, instructions for producing the input data needed for each operation, and conditional logic for specifying constraints on the sequence of operation execution. The conditional logic may include one or more expressions, ranging from simple to complex, including variables, math operations and functions, that are evaluated using the inputs or outputs of one or more prior operations to determine execution order of subsequent operations. The transaction definition data structure may also provide for broadcast operations and for conditioning the success of their execution. In an illustrated implementation, the transaction definition data structure is an XML (Extensible Markup Language) document in the form of a directed acyclic graph (DAG). A transaction service architecture provides for storing transaction definitions that define specific types or categories of transactions in a transaction database, and for matching a transaction definition to a transaction definition identifier from a requesting application. The transaction service then builds a transaction instance DAG to perform the transaction, produces the messages needed for performing the transaction, and manages the message flow to and from the service applications that perform the constituent operations of the transaction.

Transaction data structure for process communications among network-distributed applications

Described herein are methods and systems for preparing to efficiently distribute data to be extracted from a data store to clients and for distributing such prepared data to the clients. The methods and system have particular utility in the context of a network monitoring system which captures and stores network event data and makes the event data available to clients according to any desired view or summary. One method for preparing the data involves storing as primary requests one or more client requests for data to be extracted from the event database. Additional client requests for event are each compared to the stored primary requests to determine whether each additional request matches a stored primary request in accordance with a given criterion, such as a filter or summary formula. If the additional request matches a stored primary request, the additional client request is associated with the matching primary request. If the additional request does not match a stored primary request, the additional request is stored as a new primary request. As a result of this method, client requests which match one another can be processed at once and distributed to all clients registering the request.

Method and system for efficient distribution of network event data

An application transaction (AT) server collects multiple user specified application operations for processing as a single application transaction and records essential information about each transaction being performed in a database. Such recordation enables the values of objects targeted by the particular application transaction prior to completion of a transaction to be restored in case of failed operation of the application transaction.

Apparatus, methods, and computer program products for transactional support of network management operations

A method for determining, storing, and managing names for agents and entities installed on a computer network is described. In one embodiment, a method is provided for providing a name service configured to provide unique identifiers and addresses for processes on a computer network. The name service includes a database of identifiers and addresses for the processes. A query is made to the name service that searches the database and the name service returns the answer.

Tony T. Vuong

Papers

Apparatus, methods, and computer program products for transactional support of network management operations

Name service for network management architecture