Talk:Tuxedo (software)

message: This is a pretty small page. Could we merge it into BEA systems? WP:CORP#Recommendations_for_products_and_services: 
:"Information on products and services should generally be included in the article on the company itself, unless the company is so large that this would make the article unwieldy".
Saganaki- 06:34, 18 October 2006 (UTC)
replies: text: This article is excellent - concise but complete description of this venerable SW system. Let's not drown it in BEA article. --bonzi (talk) 15:04, 24 April 2009 (UTC)
thread_title:  Merge with BEA Systems 

message: It appears that BEA has been acquired by Oracle corporation, and the BEA brand is showing evidence of being submerged by Oracle's branding.  Anyone knowledgable care to comment?  —Preceding unsigned comment added by 202.53.35.24 (talk) 05:14, 19 June 2008 (UTC)
thread_title:  BEA acquisition by Oracle 

message: If anyone were interested, there is more to the history of this product/package than just the brief mention of AT&T's involvement.
Here is my own understanding, based on not one, but actually two separate involvements with Tuxedo predecessors while working at AT&T.  In 1985 or 1986, I was working on a project at AT&T as a contractor where they were developing a system for PBX's using a platform called "CORE" (I forget now what that stood for).  It used Packet Manipulation Langauge (PML) to store and retrieve information.  The PML packets were passed using the same Bulletin Board mechanism referred to in the article.  There were several layers to the CORE system, including the user level APIs as well as interfaces for the data storage which was specified by something called Database Manipulation Language (DML).  The physical storage layer implementation (called Physical Layer), as I recall, could be separated from the logical implementation (called Logical Layer) of the data.  At that time, there was only one of each, but it opened the possibility of very diverse and varied solutions for any number of hardware platforms and applications requirements.
I was only on that project for about 6 months.  A few years later, about 1988 or so, I was working at another location at AT&T, this time as an employee, in the Unix Technical Support Division (UTSD) in Piscataway, NJ.  That division supported a number of commercial and internal software products for the Unix platform.  My group was responsible for databases, and I was assigned to the Tuxedo /T package (a coworker supported the /D).  As I read the documentation, which included a description of FML, I recognized the format and recalled some of the names used in the examples, and I remembered having worked on a very similar product!  I put in a call to someone who had worked on the other project and he confirmed that, indeed, some of the developers of the CORE tool they were using split off to create the Tuxedo product.  So there was a connection.  The FML had been renamed from PML, and maybe a couple of other changes.  The basic database and TP monitor (Bulletin Board) were for the most part architecturally identical.  Essentially, I was supporting the same architecture as the other project had been using.
At that time, there was talk of replacing the database portion, called "the Dux" until version 3.0, and thereafter "/D." The /D portion, it seems to me now, pretty much what is today called a "NoSQL" database... I've also heard it referred to as Codasyl and maybe some other descriptions.  The flexibility of the CORE/Tuxedo architecture would easily permit that to happen, too.  RDBMS was all the rage in the late 1980's so this seemed justified, and my group worked on Informix, Ingress, Teradata, and a few others so we could try integrating these with /T and compare performance.  This was easily accomplished, though I'm not sure if we every thoroughly benchmarked all of them against one another using the TP monitor (first called "the Tux", then "/T" from Tuxedo 3.0 on).  It is very interesting to see Oracle and others patting themselves on the back for cleverly inserting Tuxedo's TP monitor into their line as middleware interfacing to myriad other DBMS's when we had been doing that a good 20 years before.
I am not too clear on what Novell did with Tuxedo, but I think I heard that when BEA got it, they dropped the database (/D) completely, leaving the product solely a TP monitor.  The reason I mention this part is that the wiki page on NoSQL does not mention /D or Dux, DML, or related.  I wonder if this now forgotten part of the history belongs on that page being that it was sort of a fore-runner of the current offerings (just for completeness).
Sorry for the long-windedness; that's how I write stuff.  — Preceding unsigned comment added by 75.76.145.74 (talk) 06:45, 11 April 2013 (UTC)
thread_title:  Tuxedo History