Hi, I'm Campbell Boucher-Burnet, another core developer in the HSQLDB development team.
When I'm not actively developing HSQLDB (which has been most of the time for the last year), I'm a Programmer/Analyst with the Government of Saskatchewan's Corporate Information Services. In my professional role, I am currently (among other things) working on HSQLDB/PowerBuilder integration and implementing updateable result sets for HSQLDB. The second effort is to allow better integration of HSQLDB into our recently adopted J2EE standard, which is basically Java Server Faces on Tomcat, using Sun Creator Studio/NetBeans (and possibly Oracle JDeveloper with the Java Server Faces extention to wrap UIX/ADF, when it comes out of early access). While there is no intention to replace any of our corporate databases (serveral installations each of Oracle 9i on K and L class HP-UX and SQL Server 2000 on Quad Xeon Windows Server 2003 clusters) directly with HSQLDB, there is certainly quite a bit of interest in using it as a high-speed SQL cache within Tomcat and/or any other Java application server environment upon which we may eventually standardize. Currently, the "war" is between going totally open source, starting with a Tomcat/JSF/HSQLDB/Hibernate/Oracle9i configuration v.s. Oracle IAS(oc4j)/UIX-ADF/9i v.s. WebSphere/Oracle9i, and then eventually evaluating which of the crop of open source full J2EE containers to use, once again v.s. WebSphere (and perhaps v.s. Oracle IAS/UIX-ADF). Regarding use of HSQLDB as a high-speed SQL cache in a WebContainer and/or Applet/JWS app, I've also been assigned to research projects such as cjdbc (ObjectWeb's clustering/replicating JDBC driver technology). Regardless of the WebSphere references, we simply have too much data and application code tied up in Oracle and PL/SQL (and to a lesser extent, SQL Server and T-SQL) to even vaguely consider DB2/CloudScape at present. Rather, our biggest concern at this point is whether and/or how to wrap some of our recently inherited Data Center concerns (aging mainframe/cobol apps) in J2EE via JCA, v.s. simply migrating the data and back-end business logic to some RDBMS (likely Oracle/PLSQL). The bottom line here is speed of migration, as the expertise required to maintain the mainframe work is quickly evaporating. It is hoped that JCA will buy some time and cost (at lease initially) significantly less than a full data and core business logic migration. The WebSphere references stem mostly from the fact that we just amalgamated our storage into an IBM SAN solution and, given the overall satisfaction with the solution, there is further activity taking place to close an IBM/Rational RUP solutiuon for our business and systems analysts, which (if the solution takes root) probably leads naturally to a sale involving the entire, end-to-end tool chain, including ClearCase, WebSphere and WSAD. Another point of interest at work is in using HSQLDB to back Applet/Java Web Start based (yet still j2ee-driven) presentation layers with Sybase DataWindow-like client-side functionality, i.e. SQL-based client-side sorting, filtering, data import/export and datastore linkages (hierarchical data sets, typically presented in master, multi-detail views, such as tabs and flyouts), without requiring repeated hits outside the client presentation tier or a wholesale conversion to purely OO client-side techniques to achive the same end. The reason for such interest is that we currently support quite a few scientific and engineering applications that do not bend easily to the current internet convention of displaying 5-10-50-100 rows of data at a time. Currently, we support these applications as PowerBuilder clients accessed via Citrix and hosted on some Windows Terminal Server clusters. But as time has marched on, it has become evident that there are, at least eventually, some essentially insurmountable scalability, administration and network bandwidth issues to contend with. It is hoped that moving to a unified identity managment solution (starting with a shift to ActiveDirectory coupled with an LDAP fedration solution to bring in Oracle) and farming out some of the scientific calculations and more advanced and CPU-intensive rich-client presentation layer processing once again to client PCs will aleviate portions of these issues. And Java so far _seems_ to fit this bill (especially with Thinlet or Zaval based widget sets and scaled-down WebRowSet support, aka JDK 1.1 v.s. J2SE/Swing based), because of the almost zero client administration factor and ability to run directly in the browser, as compared to having to revert to individual PowerBuilder fat client upgrades or at least enter PowerBuilder OLE/ActiveX hell. ----- Original Message ----- From: [EMAIL PROTECTED] Date: Saturday, October 2, 2004 2:49 pm Subject: [Hsqldb-developers] What are you using HSQLDB for? > Hi, > > I'm Bob Preston: I'm a core developer in the HSQLDB development > team, and I could use your help. I have the opportunity to get the > first book about HSQLDB published. HSQLDB is the heart of many > applications, and a book about it would be well deserved. There > seems to be the opinion out there that HSQLDB is used primarily for > embedded applications. I would like to find out if that's true. > Also, there is an opinion that now that Cloudscape(Derby) is open > source, developers will be porting their applications to it. So, > please send me email briefly describing your application and if you > are planning to port to Cloudscape, and maybe we can get this book > published. > Many thanks, > > Bob ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
