home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.19 / text0007.txt < prev    next >
Encoding:
Internet Message Format  |  1990-05-17  |  4.5 KB
  1. From: Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.             An Update on UNIX* and C Standards Activities
  5.  
  6.                              January 1990
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.                    Jeffrey S. Haemer, Report Editor
  11.  
  12. IEEE 1003.11: Transaction Processing Update
  13.  
  14. Bob Snead <bobs@ico.isc.com> reports on the January 8-12, 1990 meeting
  15. in New Orleans, LA:
  16.  
  17. Context
  18.  
  19. Our charter is to develop an application profile for POSIX Transaction
  20. Processing (TP).  We're wrestling with both the content of our profile
  21. and the idea of a profile, since the profiles are new to POSIX.
  22. [Editor: Jim Isaak reviews application profiles in the February IEEE
  23. Computer.]
  24.  
  25. The content is influenced by two other TP efforts: OSI's DTP and
  26. X/OPEN's XTP.  We must handle OSI DTP, just to gain ISO acceptance--a
  27. goal of all the 1003 efforts.  In theory, XTP is just another
  28. proprietary concern.  In fact, XTP's ongoing deliberations are
  29. currently confidential.  Moreover, X/OPEN isn't an official standards
  30. body so we can't officially reference XTP in our profile.
  31. Nevertheless, XTP will carry considerable weight, since it will be a
  32. multi-vendor consensus on how to do UNIX TP.
  33.  
  34. Models
  35.  
  36. As at previous meetings, we spent much time discussing TP models.  For
  37. the most part these discussions were based on a snapshot of XTP's
  38. model released to non-X/OPEN members some time ago.  Each model we
  39. discussed consisted of three or four of the following elements:
  40. Application Programs (APs), Resource Managers (RMs, like database
  41. managers), Communications Managers (CMs, like TCP/IP), and Transaction
  42. Managers (TMs, which enforce the transaction protocol among APs, CMs
  43. and RMs).  Here, in chronological order, were the major topics of
  44. discussion.
  45.  
  46. We discussed whether a CM might just be an instance of an RM (viewing
  47. an instance of a communications protocol or link as a resource), but
  48. concluded that attributes of CMs make them fundamentally different
  49. beasts (though, to be honest, it's still not clear to me why).
  50. __________
  51.  
  52.   * UNIX is a registered trademark of AT&T in the U.S. and other
  53.     countries.
  54.  
  55. January 1990 Standards Update     IEEE 1003.11: Transaction Processing
  56.  
  57.  
  58.                                 - 2 -
  59.  
  60. We considered several models based on XTP, but differing from one
  61. another in the roles of the CM and the interfaces between the AP and
  62. CM.  We concluded that each communications protocol would have to have
  63. its own CM, and that our model must support multiple concurrently
  64. active CMs.  A CM, though, is more than just its protocol support.  It
  65. has to include support for additional functionality required for DTP.
  66. We never concluded whether or not an AP should talk directly to a CM,
  67. or to a CM via the TM.
  68.  
  69. Requirements
  70.  
  71. In the course of the model discussions, it became clear that many of
  72. us had different requirements in mind, so we shifted our focus to
  73. requirements to try to reach some consensus.  Ultimately, we decided
  74. that POSIX TP must:
  75.  
  76.    - be mappable onto OSI DTP,
  77.  
  78.    - support global (distributed) transactions,
  79.  
  80.    - support chained and unchained transactions,
  81.  
  82.    - support a conversational mode,
  83.  
  84.    - provide data conversion (e.g., ASN.1),
  85.  
  86.    - ensure that POSIX RPC supports DTP semantics,
  87.  
  88.    - ensure that DTP can be accomplished through RPC,
  89.  
  90.    - provide for location independence via directory services, and
  91.  
  92.    - provide for security of data.
  93.  
  94. Exercises
  95.  
  96. We decided to break the modeling deadlock by focusing on the AP/TM
  97. interface and ignoring communication.  We worked several examples,
  98. following ISO DTP services but using an RPC paradigm, and concluded
  99. that an API based in RPCs would need at least four services:
  100.  
  101.    - one for a caller to start a transaction,
  102.  
  103.    - one for a callee to find out if it is participating in a
  104.      transaction,
  105.  
  106.    - one for a callee to abort a transaction,
  107.  
  108. January 1990 Standards Update     IEEE 1003.11: Transaction Processing
  109.  
  110.  
  111.                                 - 3 -
  112.  
  113.    - one for a caller to commit or abort a transaction.
  114.  
  115. We also identified the following assumptions for TP via RPC:
  116.  
  117.    - A thread of control (TOC) can be in at most one transaction at
  118.      any given time.
  119.  
  120.    - If one TOC communicates with another, the latter joins the
  121.      former's transaction by default.
  122.  
  123.    - No nested transactions are permitted.
  124.  
  125.    - A GTRID (Global TRansaction ID) can be associated with multiple
  126.      TOCs and multiple RMs.
  127.  
  128.    - A transaction has only one initiator and only the initiator can
  129.      issue commit.  Any TOC may abort.
  130.  
  131. January 1990 Standards Update     IEEE 1003.11: Transaction Processing
  132.  
  133.  
  134. Volume-Number: Volume 19, Number 9
  135.  
  136.