Volume Number: 16 (2000)
Issue Number: 7
Column Tag: WebObjects

Introduction to EOF and WebObjects: The State of WebObjects

by Patrick Taylor and Sam Krishna

Before we talk about state management in WebObjects we need to digress a bit because Steve Jobs has blasted one out the park...

Just before press time, Apple announced that the price of WebObjects was going to be slashed. As we mentioned last month, WebObjects was designed for the kind of demands that an Apple Store-like web site might bring to bear, this is not your father's web application server. Because it is enterprise level software, it has had a correspondingly enterprise level price — a shocking $50,000 for a single high-end deployment license and another $1299 for the development tools. At least that was case until the WWDC keynote where Steve Jobs announced that effective immediately a combined development and deployment license was going to be sold for $699.

WebObjects is now within the means of practically any web developer — projects which needed that class of middleware, but couldn't justify the price, are now very possible. A WebObjects, Mac OS X Server and Frontbase or Openbase combo is now price competitive with Windows 2000 Server (which includes IIS and does dynamic publishing via ASP), Visual Studio and SQL Server even when you consider higher comparable Apple hardware prices. The combination of Linux and one of the growing number of open source dynamic serving solutions (like Zope) are probably still cheaper but having the lowest initial price has never been the real reason for choosing this environment.

With the rise of XML, Java Server Pages, Perl/Python/PHP and JDBC, it's quite common to have people asking "If all of these standards are becoming more popular, why should anyone bother with WebObjects (especially when it still had it's transaction limitations based on the price you paid for the license)?" It certainly is possible to do almost anything that WebObjects can do with some combination of pre-existing tools and blood, sweat and tears, however, WebObjects manages many things for you, things you get as part of the standard package.

And one of the most important things is State Management. State management allows the server to be aware of the interactions by numerous clients each ensconced in their own session. Since HTTP is normally stateless, both the browser and the server will forget about client-server interaction as soon as a particular transaction is finished. One it hands of data from a form, a browser will not remember any values or selections made. This can be both a hassle and a security problem for e-commerce.

In the previous article when we discussed the request-response loop, we saw how WebObjects normally uses the URL to manage state over the life of a user's session. Since an HTTP server naturally assumes that every single request it receives from remote users is a unique transaction, it becomes necessary to overcome this hurdle. Normally, the protocol does not allow state to be preserved so it becomes nessary to piggyback on pre-existing feature transmitted back and forth between the client and server. Options include maintaining state via the URL, with a cookie, or more rarely a hidden field in the HTML. As well you can store this session information in the database to provide for long-term continuity for your users. Or if you have very demanding applications, you can even use multiple state management strategies. One example would be a sophisticated e-commerce site using a combination of cookies (to identify a client), database entries (to maintain history) and hidden fields (to maintain session integrity without littering the URL). As well, it is also possible to maintain state without embedding session information using DirectActions.

State management has benefits beyond just providing a "history" between users and the site. It also allows WebObjects to keep business logic on the server since session information is preserved, thereby avoiding the security risk of unscrupolous modification of client-side business logic (the Internet version of the "five digit discount"). It also provides some security for the user by not embedding sensitive information (like credit card numbers) in the HTML and through the complex machine-readable session information (the complex gobbledigook on the URL) makes it very difficult for anyone to hijack a session from a user.

But why would WebObjects need to piggyback on existing features? Because they are there. Seriously ... rather than reinventing ways of interacting with servers and browsers, WebObjects takes the path of least resistance by using whatever already exists as a standard feature in the most effective way possible. In a well designed WebObjects application, it is possible to use Lynx (so long as it supports a recent vintage of the HTML standard) to browse a page. Unlike Microsoft's "works best with Internet Explorer and/or Windows" approach, WebObjects is philosophically inclusive. Consider the case of someone who didn't piggyback on existing standards: recently some wide-eyed and bushy-tailed dot-com announced a new banner ad format that would give web developers far more flexibility than is avalable with the everpresent cgi-based animated gif banners. The deadly flaw is that it was based around a new plug-in. Now maybe the developers had come up with a brilliant way to get people to download an advertising specific plug-in, but while most users accept banner ads as an acceptable annoyance or even a necessary evil, not one person in a hundred is going to download such a plug-in. Take this story as a cautionary tale, it does not pay to make users download plug-ins, especially if you're trying to sell them something. So if a strategy that uses built-in browser or server features is at all practical, stick to it.

Applications, Sessions, Components, Oh My!

The WebObjects engineering team solved the state management problem in a very clean way. Intrinsically there are three levels a programmer will ever want to store state within a web application: the global level, the user level, and the page level. Within WebObjects, this is known as the Application/Session/Component state management system.

Why is State Management good for developers? WebObjects isn't unique in providing state management. There are plug-ins for NSAPI and ISAPI can be used to provide some degree of state management, WebObjects manages to provide state management even on lowly CGI. By "filling in" the missing features from one adaptor to the next, WebObjects manages to provide a consistent target which developers can depend on so that developing an application which uses CGI isn't different than an application which uses an ISAPI connection. Besides consistency, this simplifies the process of transferring applications from one platform to another. For example, you could do your development on a PowerMac G4 running Mac OS X Server 1.2 with Apache 1.3.12 and then deploy on a SPARC Workstation running Solaris 8 using iPlanet Web Server. Short of changing some configuration settings and recompiling, very little needs to be modified to make the transition. In future articles, we'll see how a similar situation plays out with databases and their adaptors.

For the Application layer, there's a class called WOApplication used to manage the entire run-loop of a WebObjects application as well as define and access very specific application-wide behavior. There is a programmer-accessible subclass of WOApplication simply called Application where you can store, for example, an array of the New York Times Bestseller List of books that every user can access when they visit the site. You can also define the behavior for what happens when a user does something illegal (like invalid form values) and redirect them to a page saying they need to re-input their information. Because Session and Component (page classes) derive from and fall under Application, they have access to all features added at the Application level.

For the Session layer, there's a class called WOSession which lays out the basic behavior of a user's session with the app. The session represents the complete lifecycle of a user's interaction with a WebObjects application. The WOSession class has a subclass called Session which provides programmatic hooks for a developer. This subclass inherits a collection class called an NSMutableDictionary which can be used to store information beyond just the instance variables that have already been defined. For example, the Session can be used to contain a shopping cart with credit card information, books selected, and other various and sundry items.

In the Component layer, there's a class called WOComponent which manages all of the general interaction with the request-response loop and the actual hooks into a given HTML page for direct access to instance variables. You can literally create a new page, create instance variables for that page, bind the instance variables to the HTML elements on that page, and, after all that, have a functional — though slightly homely — web page without having to write much code.

The Component subclass is responsible for interacting with the WebObjects system to generate all of the HTML on-the-fly for a particular page based on the state of the information to be displayed and what the developer has instantiated in the Session and Application objects. The component can ask the session and the application objects for any particular state that the developer sees fit to access. A Component can be used to display the detail information and a particular image to represent a book currently browsed by the user.

What's so amazing about this system is that after you start using it for a while, you'll wonder why anyone worries that the Web is a stateless system at all.

So many different ways of managing state

We have already have explained some of the mechanics of storing session information in the previous article on the request/response loop. A WebObjects application by default stores the session ID in the URL automatically along with the component ID. Some developers (and users) don't care for the long URLs with machine readable session data partly because they are ugly, but as the least invasive method to maintain state.

Cookies are a useful way of tracking transactions but can be problematic. Not everyone enables cookies in their browsers so you may turn people away if you make your site cookie dependent. It is possible to request that the Session object store the Session ID in a cookie instead of in the URL (which it does by default). You can send the message to your Session object like this:

In Java:

	session().setStoresIDsInCookies(true);

In Objective-C:

	[[self session] setStoresIDsInCookies:YES];

This code will force the session to stuff all session ID and element ID information into a pair of cookies named "wosid" and "woinst", respectively. These two cookies keep all session ID and element ID information that normally would be in the URL and keeps too much of the session "noise" from littering the URL.

The basic way to use a cookie for state management is by simply instantiating a WOCookie object.

In Java:

WOCookie.cookieWithName("someName") 

In Objective-C:

[WOCookie cookieWithName:@"someName"]

Then it is possible to set the name, domain information, expiration information, path information (if applicable), and finally its value (the actual state information you want to store).

To do this, you would probably want to override public void appendToResponse() in your Component subclass. You would do this in Objective-C with appendToResponse:inContext:

The sequence would look something like this:

In Java:

public void appendToResponse(WOResponse response, WOContext context) {
	// Assume for sake of example that we're generating cookie for first time
	// Also assume that passwordValue is an instance variable prebound to some 
	// secure text field that the Component knows about

	// Set expiration date for one month from now
	NSGregorianDate oneMonthFromToday = new NSGregorianDate();
	oneMonthFromToday = oneMonthFromToday.dateByAddingGregorianUnits(0, 1, 0, 0 , 0, 0);

	WOCookie cookie = WOCookie.cookieWithName("password", passwordValue, null, "www.mydomain.com", 
		oneMonthFromToday, false);

	response.addCookie(cookie);
	return;
}

In Objective-C:

- (void)appendToResponse:(WOResponse *)response inContext:(WOContext *)context
{
	// Assume for sake of example that we're generating cookie for first time
	// Also assume that passwordValue is an instance variable prebound to some secure text 
	// field that the Component knows about

	// Set expiration date for one month from now
	NSCalendarDate *oneMonthFromToday = [NSCalendarDate calendarDate];
	WOCookie *cookie = nil;


	oneMonthFromToday = [oneMonthFromToday dateByAddingYears:0 months:1 days:0 hours:0 minutes:0 seconds:0];
	cookie = [WOCookie cookieWithName:@"password" value:passwordValue path:nil domain:@"www.mydomain.com" 
		expires:oneMonthFromToday isSecure:NO];
	
	[response.addCookie:cookie];
	return;
}

Erratum In the historical list of WebObjects team members, we gave last month some people were accidentally left out. The WebObjects 3.5 and 4.0 teams included Laurent Romontianu and Patrice Gautier. Charles Lloyd left the team after WO 4.0 (and eventually ended up at Ariba with Craig Federighi).

There is another type of URL state management known as a Direct Action, a type of WebObject class that can track information without a session, taking state from one component and passing it to another component via the URL. For example, a Direct Action object can be used to track the user ID and the password of a user in the URL. All the state information will be passed through the URL. The advantage of this is that you have the ability to bookmark pages within a WebObjects application (since version 4 of WebObjects). However, the downside of this is that a developer now has to think about the implications of not having a session and having to manage state from component to component.

All Direct Action methods should be defined in the WODirectAction subclass called DirectAction. It is common convention that all the action methods end with the word "Action" in order to be distinguished as direct action methods. As well , when using Direct Actions, debugging is simplified if you name your WOTextFields and other input elements with meangingful names. Otherwise, the WORequest object will assign arbitrary names for your input elements and make it practically impossible for you to access your input variables unless you choose to conform to their arbitrary naming style (i.e. using latent ESP while programming direct actions and using the method takeValuesFromRequest() or in Objective-C - takeValuesFromRequest:inContext: to access form values from a WORequest.)

End of Session

Having received a taste of WebObjects in the last two articles, it's time to jump to something different. Next month, we'll go back to EOF and look at EOModelling. Is it relational or is it object-oriented? It's the entity-relational system that tastes great and is less filling.