Tackling Enhydra: A Developers First Look
By Glenn Cole
The SIG-Java meeting at SIG3000 included an interesting presentation from David Young of Lutris, keepers of Enhydra. As a long-time e3000 developer currently working with the Tomcat server engine on the HP 9000, it looks to me like Enhydra might help many of us create more disciplined Web applications.
Young noted that Enhydra developed out of a consulting project, with FedEx being the first to use it as a tool for their sales force. Until recently, Kinkos was the largest user, with Enhydra installed in each store. There was also a passing reference to a Fortune 10 customer, but Young was not at liberty to identify the customer.
Enhydra, Tomcat, and JSP
Of interest to me was Youngs revelation that while Enhydra includes the Tomcat Web container (which is what runs servlets and JavaServer Pages), Tomcat is provided almost coincidentally with Enhydra. (See more about Tomcat at jakarta.apache.org.) When I say coincidentally, I mean Lutris believes that the Enhydra way of developing Web applications is more robust than JavaServer Pages (JSP), so effectively Tomcat is included primarily to allow quick migration to the Enhydra product. This is because one does not have to convert JSP pages to some other format prior to installing the product; Enhydra can be used immediately.
Young said a problem with JSP pages is that they require Java code to be intermingled with HTML. This makes it quite difficult for Web designers to focus on the design without the ready assistance of a Java programmer.
This is true, but a primary goal in creating JSP pages is to avoid intermingling Java code with HTML. Mixing the two is convenient, but not a good idea. The current way of avoiding this is to use tag libraries, though my knowledge of this technique is deficient enough that I cannot yet comment on its effectiveness (theres more detail on these libraries at java.sun.com/products/jsp/taglibraries.html).
Young also noted that while tag libraries do indeed help to approach the goal of separating Java from HTML, each installation is left to its own devices of which taglibs to use and how to implement their own. However, as this separation is native to Enhydra, the technique is standard from one installation to the next.
Young noted that development with Enhydra can begin using only Enhydra itself. That is, while there is a piece called Director that can interface with Apache for production Web use, development can proceed using only Enhydra. This is similar to Tomcat, which includes a Web server suitable for HTML, servlet and JSP development, but not for production.
The development environment even includes a functional database system written in 100-percent Java, called InstantDB. Enhydra can access IMAGE/SQL as well: either through the JDBC driver provided with the e3000 on MPE/iX 6.0 Express 2 and later; the JDBC driver from Minisoft (available for a demo download at www.minisoft.com/jdbc/jdbc_reg.htm); or through a third-party direct-to-IMAGE product such as ADBC from Advanced Network Systems. (Going to www.advnetsys.com/ftp.html will get you a 90-day evaluation copy of ADBC.)
If nothing else, InstantDB should enable one to determine whether or not the Enhydra architecture is appropriate for the intended project.
Enhydra, being an open-source effort, has a 3.1 version freely available for download, though Lutris will be happy to provide a commercial version and support, each for a fee. With the current development pace of Web technologies, purchasing support is probably a good idea.
While Enhydra was developed to use a command-line interface, Young noted that this enables it to interface well with current IDEs, including Borlands JBuilder.
An additional advantage of Enhydra over Tomcat is that Enhydra was developed with mobile technologies in mind. This means that if a wireless Palm device connects to the Web site, Enhydra is able to recognize this, and thus delivers the content that is appropriate for that device. In contrast, a Web site developed using JSP pages likely has no idea of the display size, and thus serves the large-screen content.
Jon Diercks of ORBiT also gave a presentation to the e3000 Solutions Symposium last month which discussed his experience using Enhydra on MPE. Young relayed that the Lutris folks thought the presentation was excellent. Diercks has thoughtfully made the material from his presentation available on the Web, at diercks.net/jon/papers/enhydra-ix.html.
I would recommend at least skimming the paper by Diercks, as well as the Enhydra session transcript provided by the indefatigable Lars Appel (referenced therein) prior to downloading the free 3.1 version of Enhydra.
Young also recommended a couple of articles from WebTechniques magazine. A review of the commercial product is available online at www.webtechniques.com/archives/2001/03/progrevu/. The other referenced article in WebTechniques was written by Young, comparing Enhydra with JSP and XSL. The article includes code samples, and is available at www.webtechniques.com/archives/2001/02/young/.
I have never used Enhydra. I am very happy using JavaServer Pages (on a 9000), though clearly I have much more to learn there. Getting started with JSP was easy (once Tomcat was installed and running), and development has proceeded quickly since the release of Tomcat 3.2.
However, as Young noted is a common practice, I am currently caught in the trap of including too much Java code in my JSP pages. I fully expect taglibs to remedy much of that, but I have not yet set aside enough time to learn how to use them.
I have a little concern about the sheer size of Enhydra; large packages generally mean much to learn. Still, just because something is there doesnt mean you have to use it.
Young did note that Enhydra takes up just 30Mb of disk space. Since a bloated word processor consumes as much space these days, the small footprint is indeed notable. My concern is actually with the scope of the package. A block diagram of the Enhydra architecture shown during Youngs presentation included Tomcat as just one small block. Since I know from experience that Tomcat alone is non-trivial, I infer that the learning curve for Enhydra is much larger. The online documentation at the Lutris site, particularly the Getting Started guide, should help to alleviate that concern.
In any case, though, I highly recommend e3000 developers start somewhere. Perl CGIs are relatively easy to understand; Perl itself is quite usable on the e3000 outside the context of Web pages, and there is not much needed to get started. You can see a primer on CGIs at www.cgi101.com
However, site development and maintenance are not nearly so easy with Perl CGIs as with JSP pages, though with JSP there is more to install. Perhaps Enhydra can take this a step further.
As it stands, Enhydra appears to take a more disciplined approach to Web site development. This, together with support for industry standards and ready access to documentation, makes it worth a look. Lutris even certifies the 3.5 Enhydra commercial version for use with the e3000, which can only be a good thing. Showing your CEO the latest report summary served from the e3000 to his Palm VII should put to rest any notions of the e3000 being a legacy system.
Glenn Cole is an independent consultant who has worked with the e3000 for over 20 years. His current clients include Hewlett-Packard and the Stanford Alumni Association, and he can be contacted via email at firstname.lastname@example.org.