Last week, we talked about the fundamentals of application servers and how they’ve evolved over the years, ending with the Information Age approach used by Apple’s WebObjects. Let’s look more closely at what WebObjects actually provides.
WebObjects Architecture — A typical WebObjects application sits between two adapters. The first adapter connects the application to a Web server, while the second connects it to a database:
Web server <-> WebObjects application <-> Database
The Web server receives and responds to HTTP requests from users on the Web – it handles transferring your application’s interface, which consists of Web pages seen by the user. Apple provides an adapter which enables the Web server to pass requests to the desired WebObjects application. (A single server can run many WebObjects applications simultaneously.) WebObjects comes with two types of Web server adapters: a slower, portable Common Gateway Interface (CGI) adapter and a set of faster adapters for specific Web servers such as Apache or Microsoft’s Internet Information Server. WebSTAR also ships with a WebObjects adapter.
The WebObjects application communicates with the database via another adapter. The database adapter is responsible for generating SQL, sending it to the database, receiving the textual results, and parsing the results into objects. Because the SQL generation is done at the adapter level, the SQL can be optimized for the particular database.
This architecture enables WebObjects to separate the data access, the interface, and the logic of an application by using different tools to deal with each aspect. None of these components have to live on the same machine: a Mac OS 9 Web server running WebSTAR can talk to WebObjects on a machine running Mac OS X Server 10, which in turn can connect to databases on a Windows 2000 system.
Data Access: EOModeler — At the core of WebObjects lies something unlike anything else included with otherwise competitive tools: Enterprise Objects Framework (EOF). This amazing technology gives programmers the capability to access databases via easily manipulated software objects (instead of low-level textual SQL,which could be database-specific).
The first step is to create a database model using a powerful application named EOModeler which creates and manages database models. A model is a file that contains information about how a database is laid out. It includes information such as table names, column names, data types, and more. This is tricky work, but EOModeler offers straightforward ways to create a new model or derive a model based on an existing database (which is a magical thing to me).
With the model in hand, EOModeler then automatically generates Java code to create, update, and delete objects within a database. Database tables become Java classes, columns become class fields, and rows become class instances. These manufactured classes use EOF to control the database. EOF, in turn, uses an adapter to communicate with the database. The adapter generates SQL code, sends it to the database, and parses its replies.
This may sound confusing, but the bottom line is the specific Web application being developed never needs to deal with low-level SQL – it deals only with high-level objects. EOF and the database adapter handle all the yucky SQL generation and parsing. Also, since EOF uses adapters to communicate with databases, EOF is not tied to any particular database. For example, there’s no need to modify the Web application if you move from FrontBase to Oracle.
Interface: WebObjects Builder — Affectionately known as "WOBuilder," this tool is a WYSIWYG HTML editor much like FileMaker Home Page, the defunct Symantec Visual Page, or Adobe PageMill. Although WOBuilder is an older editor and isn’t completely up-to-date (for example, it lacks support for Cascading Style Sheets), it does offer capabilities that no other HTML editor has.
WOBuilder knows about objects. For example, it’s trivial to use graphical tools to create a dynamically generated HTML table that displays every record in a database. Although that’s common with other tools, what’s unique is that creating such a table requires absolutely no typing – it’s just click, drag, and drop.
WOBuilder also makes it easy as drag & drop to control how information flows into an application. For example, it’s simple to create a Web page that contains an editable text field where the user can type her name. Upon pressing the page’s Submit button, WebObjects magically places the information exactly where the programmer wants it. All the response parsing, text decoding, object discovery, and actual copying of data is done for the programmer by the WebObjects framework, leaving the programmer free to concentrate on the application’s unique functionality.
The WebObjects intrusion into a page’s HTML is minimal: it adds only one start/stop tag pair for each component added to a page. The tag is a minimalist placeholder declaring a component’s existence and name. All other information necessary to the component’s task is stored in a separate "bindings" file.
Logic: Project Builder — Project Builder is a multi-language (C, C++, Objective C, and Java) Integrated Development Environment. It is industrial-strength, and is roughly comparable to Metrowerks’s CodeWarrior. Apple uses Project Builder to build large chunks of Mac OS X – it won’t stand in the way of a project, no matter how demanding its logic processing needs.
Each of these tools is impressive, but they’re written to work together. You can drag a database object from EOModeler to a Web page in WOBuilder. WOBuilder parses your Java code from your Project Builder project file and generates code for you. Double-clicking a model file or a Web component in Project Builder launches EOModeler and WOBuilder, respectively.
WebObjects Sore Points — I don’t want you to walk away from this article thinking WebObjects is all sweetness and light. First off, unlike an increasing number of tools, WebObjects is not free or open source (although Apple’s $700 flat pricing is considerably more appealing than the previous $50,000 license for unlimited connections). Nonetheless, this in itself can be a deal-breaker for many smaller organizations.
Although WebObjects demonstrations show how it can build working database-backed Web applications without any code, non-trivial use of WebObjects requires programming. And WebObjects has a very steep learning curve, even for experienced programmers. Although the Information Age’s design (which we examined in the first part of this article) separates interface, logic, and data, the WebObjects design breaks these basic concepts into hundreds of small classes which interoperate. Complexity is compounded by the fact WebObjects uses the framework model of application design, which requires programmers locate and override specific points of functionality to customize an application. WebObjects documentation is better than average, but it’s often unclear how to accomplish a particular task.
One feature WebObjects lacks that some other application servers offer is automatic session fail-over. That means an application can crash, and another application will transparently take over the user’s session. The user is unaware a crash even took place! The backup application could even be on another server altogether, so if a power supply failed, a redundant machine could take up the slack without interruption of service.
Although you can develop WebObjects applications on both Windows NT/2000 and Mac OS X (and Mac OS X Server 10), the tools on Windows have been left behind at version 4.5 and will not be updated. This is a serious blow for many WebObjects developers working within companies that do not allow the purchase of Apple hardware.
The recently released WebObjects 5.0, written entirely in Java, definitely feels like a "point-oh" release. You must enable the root account and then log into your system as root to install the software (you can disable root after the installation). Worse, there is no uninstall option – to remove WebObjects, you must wipe the drive. Some features of version 4.5 have mysteriously disappeared (like the FlatFile and LDAP data source adapters). The promised Linux deployment option hasn’t arrived, leaving only Mac OS X (and Mac OS X Server 10), Windows NT/2000, HP/UX, and Solaris as supported deployment platforms. EOModeler 5 often chokes on EOModeler 4.5 model files, and is generally easy to crash, taking unsaved changes with it. Unless you’re a veteran early adopter, I’d wait until Apple releases the first bug fix update before spending time and money on WebObjects 5.
Why WO is Me — WebObjects has its share of warts; nonetheless, I find the act of building an application using WebObjects almost pure joy. Once you get your mind wrapped around WebObjects fundamentals, you slip into a zone where you build pages in hours that would take days using other tools. The best way to describe it is that feeling you get driving a high-performance car though a curvy, tree-lined stretch of road. You appreciate the features of the machine that allow you to navigate quickly towards your ultimate goal.
[Jonathan "Wolf" Rentzsch is the embodiment of Red Shed Software, and runs a monthly Mac programmer get-together in Northwest Illinois.]