AppleScript used to be Apple's best kept secret. It broke technological ground that is still unmatched by any other platform, but was largely ignored except by a handful of enthusiastsShow full article

Hide full article

AppleScript used to be Apple's best kept secret. It broke technological ground that is still unmatched by any other platform, but was largely ignored except by a handful of enthusiasts. The situation has improved in the last few years, with the technology even making it into a Steve Jobs keynote (although widespread AppleScript support in Mac OS X remains elusive). One way or another, these days more people know about AppleScript, but now Apple has a new best kept secret: WebObjects.

In NeXT's waning days, WebObjects was the product that kept the company going. It wasn't cheap: an unlimited connection license cost $50,000. But even at that price, WebObjects was cost-competitive with other similar products.

At last year's World Wide Developer Conference (WWDC), Jobs dropped a bombshell: a new, flat price of $700 for WebObjects. Although WebObjects isn't an attention-getting consumer product like the much-hyped iTools or iDVD, the price drop caused interest to boom. And at this year's WWDC, Apple released WebObjects 5, written entirely in Java, which promises to be especially interesting for customers running Mac OS X or Mac OS X Server.

<http://www.apple.com/webobjects/>
<http://db.tidbits.com/article/05950>
<http://db.tidbits.com/article/06440>

Before we talk about WebObjects specifically, though, it helps to gain an understanding about WebObjects' class of software: application servers. This article provides a brief history of application servers and offers an overview of the various software architectures used by WebObjects and its competitors. The next installment will focus on WebObjects, including its three major tools and sore points.

Application Servers -- WebObjects was the original application server - an environment for developing and deploying applications meant to be accessed via a Web browser.

In many ways, application servers are a throwback to the days of the mainframe. Back then, a single big machine would do everything, while multiple inexpensive terminals plugged into the mainframe. The terminals were extremely lightweight computers - they could do little more than display received text and transmit keystrokes back to the mainframe.

The personal computer revolution gave individual users the capability to run their own software, freeing them from the tyranny of the corporate information systems priesthood. But a funny thing happened on the way to the revolution: people wanted to share their information and programs.

Personal and centralized file sharing helped folks share their information, but sharing software was problematic. Programs developed for one platform wouldn't run on another. Software had to be purchased, installed and maintained for each and every computer, dramatically raising costs and complexity. Programs also had to be specialized to handle different types of data; for example, some shared information should only be accessed through programs which can ensure validity, such as customer databases.

Then the Web happened. The message was HTML and the medium was HTTP. Any computer could retrieve documents from any other computer, diminishing the platform problem. Even more exciting was that the Web enabled folks to set up programs that could be accessed using HTML's rudimentary support for inputting data.

In short order, the Macs in Graphics and the PCs in Accounting could access the same vacation forms served by the Unix box in Human Resources. What's more, the capability to communicate between platforms meant that software installation and maintenance could happen on the company's central server. When a bug was fixed or a feature was added, only the server needed to be updated - all the clients instantly and automatically took advantage of the upgrade the next time they used it.

"Thin clients" - inexpensive computers running lightweight software like a browser or Java interpreter - captured all the buzz. Why spend resources catering to lots of individual computers on a network when you can manage them centrally like the former mainframe system? But to remove weight from the clients, weight had to be added to the servers. The servers held all the program's logic as well as all of the user's data. Multiple users across the company (or the world!) would all simultaneously hammer the servers night and day.

Programmers faced tight software development timelines, amazing software complexity, and the requirement that the server almost never go down. NeXT was in a unique position to create and sell tools and services that addressed all these issues.

NeXT was known from the beginning as having some of the finest development tools available. Object-oriented to the core, these tools enabled quick development of complex applications. And NeXT's software ran on Unix and Windows NT - industrial strength operating systems that could provide the needed uptime requirements of mission-critical servers. NeXT leveraged all this to create WebObjects.

Three Fundamentals -- Application servers consist of three parts: the interface, the program's logic, and the data access.

• The interface is what we users see and interact with. Typically it's the HTML we view via our Web browsers, though Java can also provide an interface.

• The program's logic is composed of the rules and procedures that run businesses. For example, it's the program's logic that won't let you purchase a book from an online bookseller if the book is no longer in circulation. Applications contain hundreds or thousands of such rules. When to add tax. How much tax to add. How big a box to use for the shipment. Is the credit card valid? Do any ongoing sales apply to the current purchase? And so on.

• Finally, data access is the portion of the application which interacts with the database to create, view, update and delete information. As I discussed in "Relational Databases and Mac OS X" in TidBITS-580 and TidBITS-581, businesses prefer relational databases for these kinds of tasks.

<http://db.tidbits.com/series/1197>

WebObjects is no longer alone in the application server marketplace. There are now numerous players, and they differ primarily in how they separate the three fundamentals above. It's instructional to study the different models: you can see a clear evolution of design. What I find most impressive is that all these models are slowly moving towards a common design: the design of WebObjects.

Follow along with this slightly artificial evolution of application servers. For each one, I'll lay out the background and talk about some of the different packages out there. Some are free, open source. Some cost tens of thousands of dollars per processor. Although these lists are cursory, over-generalized and will be outdated quickly, they should give you the lay of the land.

Stone Age: Logic First, Everything Bound Together -- The Stone Age design is typified by a focus on the logic of dynamic page generation. Almost all programming languages can be made to accept Web queries and generate HTML documents based on the query's results (some commonly used languages are C, Perl, AppleScript, and Java).

These Web applications usually access a data source to answer the incoming query. Some may manually scan a file for the information, others will generate an SQL query based on the client's query, and fire it off to a database. If the Web application is calculation-focused, then it may not need to access a data source.

I don't intend to disparage the Logic First design with the Stone Age label. Instead, I'm simply trying to indicate its age (it was the first design) and complexity (not much at all). The Stone Age design is lightweight, and everything lightweight has advantages. It feels natural to programmers, and it is quick and easy to get a dynamic page up because everything is in one place. For calculation-intensive applications, Stone Age design may be the best.

However the Stone Age design is not without disadvantages. The first problem is that data access information is embedded into the logic. Technologies were introduced to help deal with this hard-wired database reliance. C and C++ programmers on Windows (and to a much lesser extent, on the Mac) have Microsoft's Open Database Connectivity (ODBC), Java programmers have Java Database Connectivity (JDBC), while Perl has its Database Interface (DBI).

It's important to understand that these technologies only provide a means of finding and connecting to a database. When it comes to moving data in and out of a database, you must still write and embed SQL into your program logic. Since SQL refers to specific table and column names, the onus is on you to keep the embedded queries synchronized with your database.

Another disadvantage is that the logic plus interface plus data design fundamentally ties one page to one chunk of code. If you need to share logic among multiple pages, it's up to you to work out a code sharing strategy and keep it all up to date.

The final disadvantage of the Stone Age design is that the interface is embedded within the application's logic. This means only a programmer can change how a page looks, or how it displays its information.

Examples of Stone Age tools include AppleScript, C/C++, Java, JavaScript, Perl, Python, and the Windows-only Visual Basic. You can tell that these tools focus on logic because they're all programming languages. They're great at representing logical decisions and operations, but suffer when forced to deal with data access and interface generation. Later models use some of these languages to handle the logical part of a Web application.

Bronze Age: Interface First, Everything Bound Together -- After churning out a few hundred dynamic pages, programmers found themselves in an interesting situation. Quite often, their dynamic pages were a thin veneer of logic and data access, containing a huge glob of interface in HTML. Plus, the business folks and graphic artists were always bugging the programmers with appearance change requests.

Programmers, being the lazy clever folks they are, simply flipped the Stone Age design relationship. Instead of embedding interface within logic, they embedded logic within interface. Now you had pages composed predominately of HTML, with custom tags containing the globs of logic. With a sigh of relief, the programmers could give the files to the better Web designers (the kind who work at the raw textual HTML level), tell them to avoid the logic globs, and the Web designers could change the page's appearance without going through the programmer.

Some programmers even went so far as to write WYSIWYG-style HTML editors which knew about (and hid) the logic globs, so even non-professional Web designers could change a page's appearance.

Like the Stone Age, the Bronze Age design has the advantages that it's easy to start and everything is in one place. But while the Bronze Age design somewhat relieved the Stone Age design's final disadvantage, it didn't address the first two. Namely, data access is still embedded (either within the page's interface or logic) and code sharing among pages is still a problem.

Examples of Bronze Age tools include Active Server Pages (ASP), Java Server Pages (JSP), Lasso, and PHP. These tools all embed programming logic inside HTML. ASP typically uses Visual Basic, JSP uses Java, Lasso has its own proprietary tag-based language, and PHP uses its own language as well.

With some fancy footwork, all of these solutions can be moved to the Industrial Age model, but that's not how they were initially designed. Although both JSP and PHP run fine on Mac OS X, Lasso is uniquely Macintosh friendly, with the capability to run under the Classic Mac OS and offering direct connections to FileMaker Pro and 4D. Future versions of Lasso will also work with Mac OS X.

Industrial Age: Interface First, Separate Interface -- As projects got larger, the code duplication of the Bronze Age design became a nightmare.

Whenever a bug was discovered or a feature added, the programmers would have to go through each file and apply the fixes. Programmers had to spend time keeping track of all code copies and variants, or just hope they remembered to update everything. Software quality quickly degraded as everything became an entangled patchwork of slightly different code.

The Industrial Age design solved the code duplication problem by moving logic out of the interface. However, the data access is still embedded within the logic, leading to much of the same synchronization problems as the Bronze Age's embedded logic model.

Examples of Industrial Age tools include Cold Fusion, WebLogic, WebSphere, and customized Bronze Age tools. For instance, with some up-front work and consistent discipline, you can use the Industrial Age model for projects using Active Server Pages, Java Server Pages, and PHP. Lasso also supports server-side JavaScript in addition to its proprietary tag-based language.

Alas, short of Lasso, none of these tools are offered explicitly for the Mac. Cold Fusion puts most of its logic in separate server-side files containing a proprietary JavaScript-like language called CFScript. WebLogic and WebSphere are implementations of the so-called "Enterprise Java Beans" (EJB) container specification, and they provide Java-based logic and object storage to Java Server pages. Although WebLogic and WebSphere don't disallow putting logic directly into pages, most folks know enough not to make a habit of it.

Information Age: Everything Balanced and Separated -- The Information Age design separates everything from each other. Interface, logic and data access all stand alone and interact via explicit architectural channels.

You can hand a bunch of pages to an outside Web design firm without handing them your business logic. The crazed nerds in the back room can crank code without having to worry about color coordination of Web pages, or which brand of database the company is currently using. The database folks can move and rename databases, tables and columns without fear of breaking the Web application.

Or one developer can work incredibly quickly.

The Information Age design is not without it flaws. Everything is spread out, in different places. Often it's not immediately obvious how modifying one aspect changes another, and the learning curve tends to be much steeper.

The only two examples of Information Age tools in my mind are customized Lasso and WebObjects. Since Lasso can shield you from SQL and allows separation of your JavaScript-based application logic from its interface, it fits into the Information Age model. It's the only product that spans the Bronze Age all the way to the Information Age. That's interesting - you can start off using the fairly easy-to-understand Bronze Age model and work your way up to the Information Age model as necessary. Sure, you'll throw away a lot of work as you grow, but it's an option that simply doesn't exist with other tools.

Although WebObjects has a much steeper learning curve than Lasso, and doesn't run on the Classic Mac OS, it beats Lasso in terms of maturity and power. In the next installment of this article, I'll look more closely at exactly what WebObjects provides.

[Jonathan "Wolf" Rentzsch is the embodiment of Red Shed Software, and runs a monthly Mac programmer get-together in Northwest Illinois.]

Hide full article

Das Keyboard — The keyboard that makes you type faster. Our
German-engineered, gold-plated, mechanical key switches produce
a tactile click that helps you type faster with greater accuracy.
Start saving time today. Money-back guarantee. <http://goo.gl/2FaL5>

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 WebObjectsShow full article

Hide full article

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.

<http://db.tidbits.com/article/06465>
<http://www.apple.com/webobjects/>

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.]

Hide full article

READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <http://tidbits.com/member_benefits.html>
Special thanks to Fred Pollak, Kenneth Brunges, Jan, and Geoff Duncan
for their generous support!