1.1 Glossary

This document uses the following terms:

application: A participant that is responsible for beginning, propagating, and completing an atomic transaction. An application communicates with a transaction manager in order to begin and complete transactions. An application communicates with a transaction manager in order to marshal transactions to and from other applications. An application also communicates in application-specific ways with a resource manager in order to submit requests for work on resources.

atomic transaction: A shared activity that provides mechanisms for achieving the atomicity, consistency, isolation, and durability (ACID) properties when state changes occur inside participating resource managers.

authentication level: A numeric value indicating the level of authentication or message protection that remote procedure call (RPC) will apply to a specific message exchange. For more information, see [C706] section 13.1.2.1 and [MS-RPCE].

connection: In OleTx, an ordered set of logically related messages. The relationship between the messages is defined by the higher-layer protocol, but they are guaranteed to be delivered exactly one time and in order relative to other messages in the connection.

connection type: A specific set of interactions between participants in an OleTx protocol that accomplishes a specific set of state changes. A connection type consists of a bidirectional sequence of messages that are conveyed by using the MSDTC Connection Manager: OleTx Transports Protocol and the MSDTC Connection Manager: OleTx Multiplexing Protocol transport protocol, as described in [MS-CMPO] and [MS-CMP]. A specified transaction typically involves many different connection types during its lifetime.

contact identifier: A universally unique identifier (UUID) that identifies a partner in the MSDTC Connection Manager: OleTx Transports Protocol. These UUIDs are frequently converted to and from string representations. This string representation must follow the format specified in [C706] Appendix A. In addition, the UUIDs must be compared, as specified in [C706] Appendix A.

core transaction manager facet: The facet that acts as the internal coordinator of each transaction that is inside the transaction manager. The core transaction manager facet communicates with other facets in its transaction manager to ensure that each transaction is processed correctly. To accomplish this, the core transaction manager facet maintains critical transaction state, in both volatile memory and in a durable store, such as in a log file.

endpoint: A network-specific address of a remote procedure call (RPC) server process for remote procedure calls. The actual name and type of the endpoint depends on the RPC protocol sequence that is being used. For example, for RPC over TCP (RPC Protocol Sequence ncacn_ip_tcp), an endpoint might be TCP port 1025. For RPC over Server Message Block (RPC Protocol Sequence ncacn_np), an endpoint might be the name of a named pipe. For more information, see [C706].

globally unique identifier (GUID): A term used interchangeably with universally unique identifier (UUID) in Microsoft protocol technical documents (TDs). Interchanging the usage of these terms does not imply or require a specific algorithm or mechanism to generate the value. Specifically, the use of this term does not imply or require that the algorithms described in [RFC4122] or [C706] must be used for generating the GUID. See also universally unique identifier (UUID).

higher-layer business logic: The application functionality that invokes the functionality that is specific to this protocol.

incoming authentication: A mode in which each party (the reference party) verifies the identity of the other party, as specified in [RFC3748] section 7.2.1, but not vice-versa.

message: A data structure representing a unit of data transfer between distributed applications. A message has message properties, which may include message header properties, a message body property, and message trailer properties.

mutual authentication: A mode in which each party verifies the identity of the other party, as described in [RFC3748] section 7.2.1.

Name Object: An object that contains endpoint contact information (as specified in [MS-CMPO] section 3.2.1.4).

OleTx: A comprehensive distributed transaction manager processing protocol that uses the protocols specified in the following document(s): [MS-CMPO], [MS-CMP], [MS-DTCLU], [MS-DTCM], [MS-DTCO], [MC-DTCXA], [MS-TIPP], and [MS-CMOM].

OleTx transaction manager (OleTx TM): A transaction manager that implements the OleTx Transaction Protocol [MS-DTCO].

OleTx Transaction Protocol: The protocol that is specified in the MSDTC Connection Manager: OleTx Transaction Protocol, as specified in [MS-DTCO].

protocol extension: An addition of new integrated behavior to an existing protocol.

protocol message: A message that is specific to the MSDTC Connection Manager: OleTx Transaction Internet Protocol, as specified in [MS-DTCM].

protocol participant: An implementation of one of the protocol roles defined in a specification.

protocol role: A class of protocol functionality that is identified as such for the purposes of a specification.

protocol type: A special set of standardized rules that the endpoints in a communications connection use when transferring data.

pull propagation: An operation that enables the untargeted marshaling of a transaction from one application or resource manager to another. Pull propagation allows the source participant to marshal the transaction without the prior knowledge of the contact information of the transaction manager of the destination participant.

session: In OleTx, a transport-level connection between a Transaction Manager and another Distributed Transaction participant over which multiplexed logical connections and messages flow. A session remains active so long as there are logical connections using it.

state machine: A model of computing behavior composed of a specified number of states, transitions between those states, and actions to be taken. A state stores information about past transactions as it reflects input changes from the startup of the system to the present moment. A transition (such as connecting a network share) indicates a state change and is described by a condition that would need to be fulfilled to enable the transition. An action is a description of an activity that is to be performed at a given moment. There are several action types: Entry action: Performed when entering the state. Exit action: Performed when exiting the state. Input action: Performed based on the present state and input conditions. Transition action: Performed when executing a certain state transition.

subordinate-to-superior relationship: The relationship between a subordinate transaction manager and a superior transaction manager, for transaction coordination.

superior-to-subordinate relationship: The relationship between a superior transaction manager and a subordinate transaction manager, for transaction coordination.

TIP: An acronym for the Transaction Internet Protocol, which is specified in [RFC2371] section 13.

tip communication: An exchange of TIP commands and responses that follows message exchange patterns that conform to the TIP specification, as specified in [RFC2371].

tip connection: A TIP connection that is initiated and used, as specified in [RFC2371] section 4.

TIP Interoperability Application Name: A name object that is used to identify the TIP interoperability application with the underlying transport infrastructure of MSDTC Connection Manager: OleTx Transports Protocol, as specified in [MS-CMPO].

TIP Interoperability Provider Name: A name object that identifies the TIP interoperability provider that the TIP interoperability application MUST use.

TIP pull propagation: The pull propagation of a transaction that is performed by using TIP communication.

TIP push propagation: The push propagation of a transaction that is performed by using TIP communication.

TIP transaction coordination: Transaction coordination that is performed with TIP communication.

tip transaction manager: A transaction manager for the transaction management functionality specified in TIP.

TIP transaction propagation: Either TIP pull propagation or TIP push propagation.

TIP transaction recovery: Transaction recovery that is performed with TIP communication.

TIP transaction table: A table of entries to transaction objects, as specified in [MS-DTCO] section 3.2.1, that are keyed by the TIP URL of the TIP transaction with which a transaction object that is managed by the OleTx transaction manager is associated through TIP propagation.

TIP URL: A URL that is formatted in accordance with [RFC2371] section 8.

transaction: In OleTx, an atomic transaction.

transaction coordination: The set of activities performed by one or more transaction managers as part of the Two-Phase Commit Protocol.

transaction identifier: The GUID that uniquely identifies an atomic transaction.

transaction manager: The party that is responsible for managing and distributing the outcome of atomic transactions. A transaction manager is either a root transaction manager or a subordinate transaction manager for a specified transaction.

transaction object: Object representing a transaction, as specified in [MS-DTCO] section 3.2.1.

transaction propagation: The act of coordinating two transaction managers to work together on a single atomic transaction. When propagating a transaction to a transaction manager that is not already a participant in the transaction, that transaction manager plays the role of subordinate transaction manager to the originating transaction manager, which will play the role of superior transaction manager. When propagating a transaction to a transaction manager that is already a participant in the transaction, no new superior or subordinate relationship is established.

trusted domain: A domain that is trusted to make authentication decisions for security principals in that domain.

MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.