RE: [U2] U2 to web software
George, I'm just going by experience here: I've written various web stuff at various times, and found CGI versions to be slow on turnaround time - individual requests complete quickly but the overheads mount up quickly as the number of requests grow until it becomes noticeable. Of course, I'm quite open to accept that this was down to the way I did it, and that others may have come up with better CGI based solutions. At the time I was using Apache under Linux to run shell scripts (for want of a better option) to write requests; these being picked up and processed by one or more waiting phantoms. Cheap, cheerful, reliable but slow. Whether it is down to the web server creating a process for each CGI call, overhead in the scripts writing the request, overheads on the phantom selecting for, reading and then processing the request, or time to return the data I didn't get down to investigating. I suspect it is more likely the accumulated effect of small delays at each stage. By that time I had moved on to faster solutions: generally anything running in-process of the web server and making a more direct (if pooled) connection to the database. In practice that has meant either using RedBack, small scale UniObjects pooling through ActiveX DLLs or creating ISAPI DLLs. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Gallen Sent: 23 February 2005 16:09 To: u2-users@listserver.u2ug.org Subject: RE: [U2] U2 to web software Brian, 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. The above method is what I use at present. (it works and management doe$n't to change method$). Cludgy is a good word. What I don't understand and maybe someone can explain. Why is this method slow as compared to Redback? Not saying Redback isn't faster...Just curious why? Is it that much faster? and what limits do you feel it has in practice (the cgi method that is). George --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] U2 to web software
Brian, 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. The above method is what I use at present. (it works and management doe$n't to change method$). Cludgy is a good word. What I don't understand and maybe someone can explain. Why is this method slow as compared to Redback? Not saying Redback isn't faster...Just curious why? Is it that much faster? and what limits do you feel it has in practice (the cgi method that is). George --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] U2 to web software
server. A batch file could conceivably obtain CGI data and send content to 'standard output'. That's not advisable though. Languages such as C, Perl, Python, PHP, Ruby, and even Bash are all known for CGI client development. The smarter the CGI client is, the less worries you have on the other side. As far as 'cludgy' architectures, take a look at LPR. It's not a very pretty spooler, but it is quite fast and reliable. I've studied and conceived many web-interfacing architectures over the past 6 years. I've written and tested out several architectures on my own. I've learned far more than I wanted to about TCP/IP, threading, memory heaps, and the differences between Winsock and *real sockets*. The MVWWW project is an attempt at producing a fast and portable, yet flexible HTTP layer solution that everyone can learn on. Does it replace commercial solutions? Nope. It's not even close to that caliber(yet). I've gotten some positive feedback on the project so far, but it's still in the beginning stages. I have big tandem project plans for it though. A generic Pick XML service, using WSDL, is currently in design and development. Btw, I have released a Win32 binary and VC++6.0 project for the spooler. Get it under CVS Web or anonymous CVS. It haven't tested it yet, so that's why it's only in CVS. I also posted a how-to install guide for the Windows spooler. Look under the project Docs. In the end, the best solution is either: 1) The long-lived commercial solution you can afford, that also provides the security, features, and support you need. 2) The free solution you can _properly_ build yourself, that doesn't inherit security and stability issues. Oh.. you'll need to support it yourself too. 3) The bundled non-commercial solution that follows the 'guidelines' I wrote about. You'll also need to support this yourself. If you don't understand the components, then don't bother with it. -Glen PickSource: http://picksource.com MVWWW: http://mvwww.mvdevcentral.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of George Gallen Sent: Wednesday, February 23, 2005 11:09 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] U2 to web software Brian, 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. The above method is what I use at present. (it works and management doe$n't to change method$). Cludgy is a good word. What I don't understand and maybe someone can explain. Why is this method slow as compared to Redback? Not saying Redback isn't faster...Just curious why? Is it that much faster? and what limits do you feel it has in practice (the cgi method that is). George --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] U2 to web software
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? Will, I'm coming in on the middle of this thread, so I may be missing some details. What do you mean by extract a response? Do you mean return generated HTML/XHTML/WML/XML or return extracted data to be converted into a web page using ASP/PHP/Cold Fusion/others? Brian Leach touched on some of the key benefits of RedBack: thread safe connection pooling application development tools (URL parsing, session management, etc.) and all of them are also implemented by the other Web Development tools (Web Wizard, Coyote, etc.) that are out there and to one degree or another in the bare connection tools (mvInternet and others). Some other factors to consider are: your knowledge and or willingness/availalbe time to learn HTML, WML, etc., cross platform compatibility and ease of re-using existing code. Web Wizard enables you to use externally created HTML/XHTML/WML/XML, if you have the knowledge and expertise available, or you can use a Web API that allows you to build web pages using just BASIC subroutine calls. Another advantage of the Web API is that it will automatically adjust if it needs to send out WML, etc. instead of plain HTML. I'm assuming that most folks on this list use U2 because that's what their employer uses, but for the consultants, and any company that is thinking of migrating to another multi-value database, cross platform compatibility is an issue. Redback is essentially the same across U2, but if your customers use D3, mv.Base, U2, jBase, etc. there's a definite advantage using a tool that will be the same across platforms. There are tools beside Redback that can be used with U2 and I'm not aware of anything in the licensing that prohibits the use of web tools other than Redback (if there was than the 600+ DataTel schools would all be in violation, some of them doubly so because they use Web Wizard in parallel with DataTel's WebAdvisor). The other factor regarding cross platform compatibility is at the web browser side. Some tools rely on an ActiveX component, which will limit the end users to a recent version of Internet Explorer on Windows (typically OK in a business INtranet setting, but not good in Education, Publishing, Architecture, Graphic Arts, etc. or any EXtranet settings). There are similar issues with Java connections. Java is supposed to be write once, run everywhere, but unfortunately it isn't always the case. IMHO, the best solution is to keep the data going back and forth standards compliant HTML, XHTML, etc. via HTTP. And the third factor is the ease in which the tool allows you to reuse your existing code. This is definitely easier in some tools than others and only a careful evaluation will tell if the tools fits your programing style. Ray -- .=. | =-=-=-=-=-=-= Eagle Rock Information Systems Corp =-=-=-=-=-=-= | | -=-=-=-=-=-=- web and database business solutions -=-=-=-=-=-=- | | http://www.eriscorp.commailto:[EMAIL PROTECTED] | |Midwest Regional Office: 815-547-0662 (voice) 815-547-0353 (Fax)| .=. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] U2 to web software
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 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] U2 to web software
Will, The main thing that Redback does is connection pooling. In other words it reduces the number of licenses that you'll use. HTH, Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 02/20/2005 07:59:06 PM: 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 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] U2 to web software
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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
