Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!crackers!transfer!lectroid!denap From: denap@alta.sw.stratus.com (Tom DeNapoli) Newsgroups: comp.databases Subject: Re: Any TUXEDO users here? Message-ID: Date: 29 Jan 91 15:27:25 GMT References: <1991Jan23.235807.12928@indetech.com> Sender: usenet@lectroid.sw.stratus.com Organization: Society for the Toleration of a Single Fault. Lines: 58 In-reply-to: Jim_Troester@TRANSARC.COM's message of 24 Jan 91 16:16:43 GMT >>>>> On 24 Jan 91 16:16:43 GMT, Jim_Troester@TRANSARC.COM said: Since I originated this thread I thought I'd jump back in... troester> I just wanted to briefly share my view on the evolution of TP Monitors troester> and the direction that they will take on Unix in the 90's. troester> --------------------------------- troester> _History_ troester> TP Monitors grew out of a number of application projects in the late troester> 1960's and early 1970's. A number of independent groups observed troester> that there were common elements in all on-line systems. They culled troester> out the APIs to those elements and the TP monitor was born. troester> Much of the infrastructure that is commonplace in the nineties simply troester> did not exist circa 1970. Layered communications architectures, troester> standard data base APIs, and presentation services were at best troester> research curiosities. Most of these early TP Monitors were products troester> of hardware vendors simply because of economy of scale: all the troester> related infrastructure had to be supplied with the monitor or taken troester> from a proprietary OS and its tools. troester> There was a strong predisposition to ``large'' centralized systems troester> because communications were expensive and slow while the software troester> infrastructure was nonexistent. I agree wholeheartedly. The definition of what a TP Monitor is, in todays terms, is of great interest to me. The 'classic' monitor was a single package providing many of the tools that have since become, or are becoming, commodities in AP programming. I give you: proprietary forms systems vs X, proprietary IPC vs RPC, proprietary transaction semantics vs XA, proprietary AP environment configuration vs ?DME?. They were TM, RM, CM and mini OS rolled into a single, behemoth, package. Todays Monitors must be able to co-exist with these systems, due in part, to large installed bases like CICS. 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. -Tom Tom DeNapoli | Stratus Computer, Inc. denap@alta.sw.stratus.com | 55 Fairbanks Blvd M23EN3 uunet!lectroid!alta!denap | Marlboro, MA 01752 -- Tom DeNapoli | Stratus Computer, Inc. denap@alta.sw.stratus.com | 55 Fairbanks Blvd M23EN3 uunet!lectroid!alta!denap | Marlboro, MA 01752