Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!pyrltd!tetrauk!rick From: rick@tetrauk.UUCP (Rick Jones) Newsgroups: comp.databases Subject: Re: Any TUXEDO users here? Message-ID: <1079@tetrauk.UUCP> Date: 30 Jan 91 10:48:08 GMT References: <1991Jan23.235807.12928@indetech.com> Reply-To: rick@tetrauk.UUCP (Rick Jones) Organization: Tetra Ltd., Maidenhead, UK Lines: 73 In article denap@alta.sw.stratus.com (Tom DeNapoli) writes: >The definition of what a TP Monitor is, >in todays terms, is of great interest to me. >[ ... ] >But their function, >IMHO, will move towards one of system integrators. Leveraging on >emerging standards like DCE, X/Open DTP, etc. and adding some >value. Not trying to BE the TM, RM etc but living with whatever >flavor the AP decides to use. > >The definition of TP Monitor will no doubt change. But, what >customers come looking for are TP Monitors, so that's what >they're still called. What they'll become is AP environment >configurators/facilitators. This is indeed true. We are using Tuxedo/T to extend our range of business software, because our customers are increasingly demanding better transaction security. We have always been in the mini-computer and Unix sector, so trying to emulate a mainframe TP monitor is not an issue. Furthermore, in a conventional software architecture of "one executable per application", transaction security can be obtained simply by using a database which supports transaction semantics. A client/server architecture allows the separation of the user front-end from the database operations, which is important both as a design issue, and as a way to increase the flexibility of the whole system. But there are also many ways of running a client/server architecture without any form of TP monitor. The key contribution of Tuxedo is to support a client/server architecture where transaction management is handled at a higher level than any of the executing processes. Thus a client process can start a transaction, and then call services in any number of servers, locally or remote, and the work done forms part of that global transaction. Only the process which started the transaction may commit or abort it, but any participating process may signal failure, preventing the originator subsequently making an erroneous commit. The XA interface is a vital component, allowing the distributed transaction management to operate on multiple heterogeneous databases. It also allows a sort of "virtual multi-threading" in servers, in that when a server has completed a segment of work for one transaction, it is free to do work for any other transaction even though the first transaction has not yet been completed. The advantages for development are greater modularity, in that servers can be treated as a form of dynamic library. A service simply performs a requested operation, and either succeeds or fails. The semantics of the surrounding transaction are not its business. The advantages for operation are extensive decentralisation and distribution of operations and resources, and achievement of load balancing by the simple expedient of running multiple copies of heavily used servers. We are not using the Tuxedo tools for building front-ends or servers, since we are using our own object-oriented techniques (using Eiffel) to build these components. We also happen to be using the Tuxedo/D database, since it is a lot easier to integrate than ESQL - that will come later! But we can in principle change the database backend to anything XA compliant without touching the transaction management aspects. Thus to us Tuxedo/T is very much an integration tool, as Tom DeNapoli suggested. In fact it is debatable whether the advantages of encapsulation provided by object oriented methods are compatible with transactions without the help of either an OODB or a TP monitor to manage transactions at a global level. Anyone know of an XA compliant OODB? -- Rick Jones Tetra Ltd. Maidenhead, Was it something important? Maybe not Berks, UK What was it you wanted? Tell me again I forgot rick@tetrauk.uucp -- Bob Dylan