jsh@usenix.org (Jeffrey S. Haemer) (03/20/90)
From: Jeffrey S. Haemer <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.11: Transaction Processing Update Bob Snead <bobs@ico.isc.com> reports on the January 8-12, 1990 meeting in New Orleans, LA: Context Our charter is to develop an application profile for POSIX Transaction Processing (TP). We're wrestling with both the content of our profile and the idea of a profile, since the profiles are new to POSIX. [Editor: Jim Isaak reviews application profiles in the February IEEE Computer.] The content is influenced by two other TP efforts: OSI's DTP and X/OPEN's XTP. We must handle OSI DTP, just to gain ISO acceptance--a goal of all the 1003 efforts. In theory, XTP is just another proprietary concern. In fact, XTP's ongoing deliberations are currently confidential. Moreover, X/OPEN isn't an official standards body so we can't officially reference XTP in our profile. Nevertheless, XTP will carry considerable weight, since it will be a multi-vendor consensus on how to do UNIX TP. Models As at previous meetings, we spent much time discussing TP models. For the most part these discussions were based on a snapshot of XTP's model released to non-X/OPEN members some time ago. Each model we discussed consisted of three or four of the following elements: Application Programs (APs), Resource Managers (RMs, like database managers), Communications Managers (CMs, like TCP/IP), and Transaction Managers (TMs, which enforce the transaction protocol among APs, CMs and RMs). Here, in chronological order, were the major topics of discussion. We discussed whether a CM might just be an instance of an RM (viewing an instance of a communications protocol or link as a resource), but concluded that attributes of CMs make them fundamentally different beasts (though, to be honest, it's still not clear to me why). __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1003.11: Transaction Processing - 2 - We considered several models based on XTP, but differing from one another in the roles of the CM and the interfaces between the AP and CM. We concluded that each communications protocol would have to have its own CM, and that our model must support multiple concurrently active CMs. A CM, though, is more than just its protocol support. It has to include support for additional functionality required for DTP. We never concluded whether or not an AP should talk directly to a CM, or to a CM via the TM. Requirements In the course of the model discussions, it became clear that many of us had different requirements in mind, so we shifted our focus to requirements to try to reach some consensus. Ultimately, we decided that POSIX TP must: - be mappable onto OSI DTP, - support global (distributed) transactions, - support chained and unchained transactions, - support a conversational mode, - provide data conversion (e.g., ASN.1), - ensure that POSIX RPC supports DTP semantics, - ensure that DTP can be accomplished through RPC, - provide for location independence via directory services, and - provide for security of data. Exercises We decided to break the modeling deadlock by focusing on the AP/TM interface and ignoring communication. We worked several examples, following ISO DTP services but using an RPC paradigm, and concluded that an API based in RPCs would need at least four services: - one for a caller to start a transaction, - one for a callee to find out if it is participating in a transaction, - one for a callee to abort a transaction, January 1990 Standards Update IEEE 1003.11: Transaction Processing - 3 - - one for a caller to commit or abort a transaction. We also identified the following assumptions for TP via RPC: - A thread of control (TOC) can be in at most one transaction at any given time. - If one TOC communicates with another, the latter joins the former's transaction by default. - No nested transactions are permitted. - A GTRID (Global TRansaction ID) can be associated with multiple TOCs and multiple RMs. - A transaction has only one initiator and only the initiator can issue commit. Any TOC may abort. January 1990 Standards Update IEEE 1003.11: Transaction Processing Volume-Number: Volume 19, Number 9