Will, > What I'm still a little fuzzy about is, say I'm already using > .asp to connect to and extract a response from my U2 > database. What does a product like Redback do for me extra? > Why would I need it? > Thanks > Will
Let's start from the basics. Apologies as you will know this already but it is easier for me! 1. There are a myriad of ways to produce HTML out of U2 systems. For static information, the easiest option is to generate it in BASIC or using a reporting tool and throw it out as pages onto a static set of directories visible by your web server. 2. Dynamic pages are more complex: they need to be passed information to control what they render. Again a good reporting tool might be sufficient for this if the information is read only. 3. Update pages are another matter. Here you need much finer control over post-back, validation, locking and so forth. So you need a scripted or programmatic environment of some kind. 4. One obvious option might be to use UniObjects. This can work on a connect-fetch-disconnect model, so long as you do not run out of licences at the server in which case it all looks embarrassing. Also, web servers are highly threaded for performance, and UniObjects is not thread safe :-( so this is only really applicable for (very) small scale requests. You can scale this to some extent by using a connection pooling structure in, say, a DLL visible from the web server. But that takes some work... 5. There are other options to play with, depending on how far you want to get into the programming and what your needs are. At the cludgy end you could use CGI to write a script (select your language here) to write request information to a directory, have a phantom scan it and write the response back, and then have the CGI script send that back to the web server. Very simple, but pretty slow and limited in practice. In the middle is running ASP and using VBScript to control a connection across some COM based middleware. UniObject, UniOleDB, an ActiveX DLL or RedBack. You've been given examples of this so I won't elaborate further, except that this is the way that most of the world writes web pages. Then there is .Net and ASPX. This really is an extension of the ASP model, so read as above. At the top end are things like ISAPI DLLs and plugins that directly extend your web server (e.g. using Delphi), and facilities like rich internet (Macromedia on speed) that are emerging. Or you can expose your subroutines as Web Services and choose from any scripting language that supports it (e.g. PHP). I've written a prototype web services client for UniVerse, and I know David Beahm has done some good work in this area, so it is very plausible. 6. RedBack is designed for high volume, professional web sites: ecommerce sites, intranet applications and the like. I've used it for producing local government software used by hundreds of concurrent users across districts, and for international eCommerce sites. The key things it provides over, say, Objects or OleDB connections are: a) a complete model that abstracts the database from the web site developer. The database programmer designs pseudo-objects that interact with the database through regular BASIC subroutine calls, and can test these without knowing about the web site. The web designer works with the objects and knows nothing about the database or the subroutines. So both are (in theory) happy and each knows where to put the blame. (Except that I usually end up having to do both sides for commercial reasons...) b) Scalability. RedBack uses a request/response model to enqueue requests, cutting down the number of database licences required and increasing availability so that your site won't cut out (though it will slow down) in periods of peak demand. c) licencing. AFAIR RedBack is the only multiplexing middleware allowed under the U2 licencing. Hope this helps, Brian ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
