Re: Newera 3.0

David Williams wrote: > > In article <330DF6E6.26B5@ix.netcom.com>, Jason Jonas > <jejonas@ix.netcom.com> writes > > > >one thing we are looking at and have used on a project is a vb front-end > >and tuxedo back-end. this has proven to be an excellent solution for > >some of our clients. if you want some more info, just let me know and > >i'll give you a brain dump of what i know about the product... > >cheersm80! > > > >-jason > > Why not post a brain dump document to the newsgroup, that way > we can all look it up on Dejanews if we need it in the future? > > PS I'll like it now!!! > > -- > David Williams david et al, tuxedo is a server-side tool that allows client applications to make requests of its services via a simple function call. these services are the server-side processes that you develop and plug-in to tuxedo. the services can perform any server-side function from a database query to anything you can program. you can run multiple instances of each service and the tuxedo manager will call the least busy. you can also spread the tuxedo manager and all services among multiple systems. the only caveat to the server-side is that someone with more than an operator's mind set should be in charge of setting up tm with the proper service config. the client (VB/VC...) makes a function call defined in some tuxedo dll's and it communicates to the server-side tm. information is passed between the client and server as a large buffer. a stateless approach works best because the tm services don't have to somehow maintain state. basically, it should be in and out. of course one can complicate matters. :) some advantages of this approach is that tuxedo obviously scales well compared to newera and partitioning. if you partition a ne app, each client has a corresponding server-side process or partition (this is similar to the sqlturbo's in 5.0). this takes up memory and processing time. with tuxedo you can increase or decrease the number of server instances and tune the system. it's also apparent that all of the layers of DAO/ODBC/RDO/... are no longer there to slow things down on the client. the project we used tux on was a vb front-end, tux back-end to informix online 7.1. the tux services were all written in esql/c and they screamed. we realized some sub-second response times and no times were out of line with expected results. vb performed well because there wasn't alot the application had to do to communicate with the server other than calling a function. the interface was totally 96ish and standard. we never tried writing 4gl services because 1) we dig esql/c and thought 4gl would be a waste of time (sorry you 4glers - no offense) and 2) the stack used in 4gl along with the push/pop routines would probably have been a prolem because the tm passes along any arguments to the service. anyway, me brain is knackered and i need to save some energy to call the trouble and strife on the dog and bone. if you have any questions, just email me. -jason