WebObjects Overview
Volume Number: 13
Issue Number: 5
Column Tag: OPENSTEP
An Introduction to WebObjects
by David Neumann, System Engineer, NeXT Software
An overview of Apple's new high end application
development & deployment vehicle for the Internet
This article gives a technical introduction to NeXT's WebObjects web application
development platform. The content is primarily geared toward developers with at least
some Internet-based application building experience.
First and foremost, WebObjects means server-based application development. It is not
an authoring tool. When you layout a page with WebObjects, you are laying out your
application's user interface.
WebObjects as a product ships with three major components: a cross-platform set of
object-oriented frameworks, developer tools on top of those frameworks, and a
deployment infrastructure for running apps built on those frameworks. This article
will go into detail on all three components. First, we'll delve into "Logical
Architecture" of the frameworks, and then "Physical Architecture" of deployment, and
finally tools & custom code used to wire the functionality together.
Although WebObjects is full of highly extensible objects ideal for heavy-duty
customization, WebObjects also includes tools that make it a first-class "RAD" (rapid
application development) environment for the web. For instance, WebObjects includes
drag-&-drop access to industrial-strength relational databases and offers a Database
Wizard for creating complete database-aware applications (or parts of applications)
with a few mouse clicks.
Note that a developer may elect to write a WebObjects application in either Java,
Objective-C, or WebScript. Virtually all of NeXT's examples ship with both Java and
Objective-C/WebScript equivalents. However, the developer does not have to stick to a
single language, all three may be used simultaneously. For example, NeXT encourages
the use of a compiled language like Java or Objective-C for business logic (for
example, rules, policy, and vertical-oriented computations) and WebScript for
"application" logic (such as, when you punch this button, select this field and jump to
page XYZ, etc.).
Logical Architecture
Below is a look at the logical architecture of the WebObjects family of frameworks.
Frameworks are the programming building blocks of the largest granularity. These
frameworks include: Foundation (the non-GUI aspect of the OpenStep spec),
Enterprise Objects Access (bidirectional RDBMS-to-object mapping), Enterprise
Objects Control (persistent object transaction management), and WebObjects (web
presentation & deployment).
Note that you may have an application split into separate services or tiers that use all
of the frameworks and/or only Foundation and/or only Foundation+Enterprise Objects
Access & Control. It is also possible to write a WebObjects application that only uses
Foundation and WebObjects (no object/relational datasource). See the side-bar
"WebObject Class Functional Groupings" for details about classes available in the
WebObjects Frameworks.
All applications must include the Foundation Framework. It provides basic services
needed by any program. It is also the layer of objects that provides operating system
independence. In other words, you should never have to make a direct system call again
for most applications when you have the luxury of using Foundation. Foundation
provides operating system independence across the upcoming Rhapsody OS for Mac,
Windows NT, Solaris, HP-UX, and of course NeXT's OPENSTEP/Mach operating system.
Figure 1. WebObjects Frameworks. Foundation provides operating system
independence, Enterprise Objects Access provides RDBMS independence for object
persistence, Enterprise Objects Control provides object persistence transaction
management, and WebObjects provides objects useful for web based presentation and
deployment. Note that actual linking dependencies are different than implied in the
figure.
The Enterprise Objects Frameworks (Control & Access) also known collectively as
"EOF" are extremely feature rich. Truly doing EOF technology justice would require an
entire article unto itself and so unfortunately this discussion can only skim the
surface. Consider that EOF is NeXT's third generation solution for database aware
applications. The sidebar on "WebObjects Class Functional Groupings" should give the
reader at least a flavor for what's available in the technology.
It's EOF that facilitates the use of true business objects in WebObjects. EOF makes
your application completely database and schema independent. With it, you can create
"live" entity-relationship diagrams in a tool called "Enterprise Objects Modeler" (or
just "EOModeler") that ships with WebObjects. EOModeler will emit new schema and
(perhaps more importantly) let you reverse engineer an existing relational database
into a default object mapping - that you can then enhance without affecting the
underlying schema. You can write business logic in the same language you write your
application code and take advantage of both composition and inheritance relationships
in that business logic. This is highly different from "normal" approaches to database
driven applications: 1) forcing policy into a proprietary, database-specific stored
procedure language (not object-oriented) or 2) scattering business logic across
applications in event handlers. Furthermore, EOF makes it trivial to build
applications that integrate resources from several databases - not just one. Add-in
technology from third parties allows you to extend this integration to mainframe
applications via 3270, 5250, and ASCII data streams.
Figure 2. EOModeler application. This tool ships with WebObjects to let developers
graphically create "live" entity relationship model of their business objects. The
model can be targeted to any datasource known to WebObjects including Oracle,
Informix, Sybase, and ODBC. Note how the attribute (name) on the selected entity
(Studio) is abstracted from its external database name and type. If the datasource
changes, only the external information need change insulating application code from
the database implementation.
The fundamental difference between WebObjects database access compared to
traditional data access methods is this; when you fetch a "row" from a database, you do
not get naked data, you get an object with behavior, an object that knows about its
relationships to other objects. You get an object that is watched, uniqued, deleted, and
updated from within a document context (kind of like a super transaction) with
automatic support of undo, redo, revert, and efficient change flushing to the
underlying database or databases. You specify the kind of object you get for a row (for
example, its Class) using EOModeler.
Since the business objects you create with EOF don't care about the underlying database
or how their values are presented in user interfaces, they may be re-used over and
over in any number of different applications (web, Windows, or Macintosh Rhapsody)
and indeed may be maintained by a crew of developers only loosely coupled to those
building specific apps.
Physical Architecture
Now that we know what kinds of building blocks are available from a developer's
perspective, how does that logical architecture get laid out physically into a running
application? Figure 3 shows the tiers involved in a typical deployed WebObjects
application.
Unlike traditional modes of Internet programming such as Perl scrips, a WebObjects
application does not "disappear" between page processing/generation transactions. It
stays up and maintains a persistent database connection. The task of state management
is completely subsumed by the WebObjects framework. State management is also
abstracted to the point that alternative state management policies may be implemented
with little or no impact on existing code (such as, state in the process, state in the file
system, state in the page, state in the someplace-not-invented-yet, etc.).
With WebObjects, browsers interact with HTTP servers in their normal way taking
advantage of any technologies that enhance this browser-to-web server link. For
example, secure socket layer communication protocols in Netscape and Microsoft
browser/server products.
Figure 3. WebObjects Deployment. Browsers communicate with HTTP servers which
communicate with the WebObjects web server adaptor. The WebObjects adaptor load
balances across one or more application server processes (also called instances)
running on one or more machines. Once running, WebObjects application instances do
not go away between user requests; they maintain themselves, their sessions' state for
users, and their database connections. They are efficient, fast, and by definition,
redundant.
It's the job of the HTTP server adaptor, as indicated in Figure 3, to communicate
with a given HTTP server and forward requests to one or more application "instances
- an instance is a separate copy of a given application process. A WebObjects app