Why WebObjects?

At Jewelry Luv, we develop our site using "WebObjects." It is such a great way to go about development that I feel compelled to explain what it is and why we like it. Please don't confuse it with different technologies with similar names such as BEA's WebLogic and IBM's WebSphere. WebObjects is currently produced by Apple Computer, makers of the Macintosh and iPod.

20,000 Foot Overview - What's In The Box?

An IDE. You get a richly integrated development environment (IDE). This tool is similar to other graphical text editors that Programmer's love to use. It has standard features like debugging with breakpoints and color coded syntax. A standout feature, that I haven't seen elsewhere, is that the IDE will automatically merge java .jar files into a single file just by clicking a button which says, oddly enough, "merge." The latest version of WebObjects calls the IDE "XCode." Older versions call it "Project Builder" or "Project Builder WO."

An HTML editor. You get a tool which allows you to edit HTML and preview the results. It's a bit like Dreamweaver but it only works with pure HTML documents that have no programming code in them. Perhaps it's better to compare it to the HTML editor in Netscape called "Composer." This editor, however, ties in very closely with the development tools allowing you to drag and drop variables to associate them with HTML elements such as text boxes, etc. Unique to this HTML editor, you can actually change the files you are developing while your web application is running WITHOUT recompiling. This HTML editor is dubbed "WebObjects Builder."

A database tool. You get a tool for designing entity-relationships, similar to the Windows product named "ERWIN." This tool is quite remarkable to anything else I've seen in many respects. Not only can you create a graphical view of your entities (tables) and their relationships (foreign keys), but you get to associate the entities to classes that you program with and map those classes to the database tables. This tool will generate the database for you, using the schema you designed. Later, when you need to add tables, alter tables, etc. you just model it and click the "synchronize" button. WebObjects does a good job of keeping all your data but making the database reflect the new schema. This is awesome. The classes you create to represent tables in WebObjects are called "Enterprise Objects" or simply "EO" for short. This database tool is dubbed "EOModeler."

A rich framework. You get a library of object oriented components that you can extend and modify. The default set is very mature. You get basic components for Form elements, Hyperlinks, etc. You also get complex components that query, update, and display data in a variety of ways. This framework has been around since the dawn of time (before the existence of Windows 95), so there are actually quite a few open source and commercial extensions that can add even further functionality.

A database connection pool and caching mechanism. We mentioned that with "EOModeler," you create "Enterprise Objects" and associate them with tables in your database. WebObjects creates an "object graph" in memory from data stored in the database. This object graph is essentially a cached subset of all the data in your database, converted into objects. It is called a "graph" because the referential constraints between entities is adhered to. You can do complex queries, in memory, that are equivalent to the "LIKE, UNION, EXISTS" and other operators in SQL. If you don't have all the objects you need in memory, WebObjects will dynamically create the needed SQL to pull the rest of the data. Because of EOModeler and the object graph, it is trivial to change from one database vendor to another. You just remap the EOs to the new tables with EOModeler. Since you don't use custom SQL (unless you really want to), you avoid trapping yourself with esoteric and vendor specific database operations. The object graph is fast and manages multiple database connections in a pool so you don't have to.

An application server. I hate this term "application server" because it is so generic and practically meaningless, but it is the popular term. You get a way to manage all the WebObjects "applications" you create. For instance, Jewelry Luv is its own application and we run two instances of it to make best use of our dual processor server and provide redundancy. We also run a single instance of a customer service application that does the merchandise image uploads and resizing, amongst other tasks. We also run another instance of an application that handles our credit card processing. The application server allows you start up and shutdown your applications on a schedule (perhaps nightly). Provides fault tolerance (will restart an application if it crashes or becomes unresponsive). Load distribution (divides traffic amongst your application instances in a round robin or other fashion). You even get detailed statistics about how long various pages take to load, how many people view them, etc. This is all managed through a cool web interface with buttons that look like power switches.

Who Should Embrace WebObjects?

The individual visionary is a good candidate. Either you want to create the next great web application or you want to write and maintain code quickly for your clients. When you program with WebObjects, you are standing on the shoulders of giants. You are not reinventing the wheel. You are able to wield years of development and careful design. Projects that were once tough, and are still difficult for most development environments, are trivial for you. The structure WebObjects provides actually streamlines your thoughts. You start to understand database tables and relationships more effectively. You begin to create schemas that are so good, that the applications practically write themselves. In the most simplest terms, you can complete tasks as an individual that normally only a team of developers should attempt.

The team lead with a small but loyal full-time development team. There is a steep learning curve associated with WebObjects. Realistically, it will take the average developer 3 months to gain a usable proficiency, and a very clever programmer, approximately 1 month. A crash course training for a week, or more, is probably a good idea especially if the entire team is new to WebObjects. There is nothing like learning from an expert, especially when the method of thinking is so radically different from anything else developers are likely to understand. Once your engineers are up to speed, they can rocket through tasks that previously were unattemptable. Their coding efforts will also be highly maintainable and lend them selves to alteration without pain and frustration.

Who Should Avoid WebObjects?

The individual hobbyist should stay away. WebObjects is great, but you are going to have to put in the time to learn something new. If you don't enjoy mastering new operating systems, studying new technology, etc. then you won't get much from just dabbling with WebObjects. Your time would be better spent learning one of the scripting languages such as PHP, JSP, ASP or Perl. You could quickly learn their basic syntax and literally start hacking within an hour. You'll be able to create some simple blogs and other types of software in your free time but would be hard pressed to do more without convincing others to join your cause and work together. Additionally, those scripting languages tend to look better on a resume than WebObjects. It's a sad fact of life but the best ideas and products are often not the most popular or well known.

The team lead that is expected to work with a large team, especially if the team is made up of contractors or staff that can be expected to change every 6 months should stay away. Developers who know how to use a scripting language are everywhere. And if you can't find one, you can make one in a day or two from a fresh college graduate. Also, J2EE is the buzzword of the day so those developers are somewhat easier to find. So your choice is either J2EE or a scripting language like PHP, JSP, ASP, or Perl. You'll pay more for J2EE developers because they have a learning curve and maturity that resembles WebObjects but is not on par. You'd have to be a strong willed and articulate team lead if you were to suggest a WebObjects solution. You'd be challenging the status quo and suggesting that three long term employees are better than twenty contractors. If you convinced management to use WebObjects and things went wrong, you'd be blamed for a bad technology choice and fired. If you use JSP, for example, you could fire the contractors and get some more, blaming them for bad coding.

Truth is a few good programmers can do much more than a large team. Use boat building as an analogy. Take one person who knows how to build a four person sail boat. Working alone, it might take him a year. Give him three people, he could spend the first month making mini-experts out of those three. One to cut the wood, one to modify the wood, and one to help him assemble the boat. With the extra help, it might cut the time from 1 year down to 4 months. How about give the boat builder 15 people? Will the boat be done in two weeks? Most likely the boat would get done in a year, perhaps a year and a half. There is a limited amount of space to work on the boat and the people doing the assembly can only move so fast. Add too many people and chaos is likely to erupt. There is a fine line when adding engineers before it becomes detrimental to completing a project. It's worth reading a book titled "The Mythical Man-Month" and then giving WebObjects some serious consideration.

The Learning Curve

It's not that WebObjects is hard to learn, it's the wealth of information which takes time to wrap your head around. Without doubt, the first day you could start doing enough to get your juices flowing. To prove this point, Jonathan 'Wolf' Rentzsch has put together a 15 minute video where he builds a functioning blog from scratch. WebObjects 5 in 15 minutes.

It took me roughly 3 months to feel somewhat comfortable with WebObjects. This was spending roughly 8 hours a day during a time when I purposely was between jobs. I really wanted to learn the depth of what the WebObjects frameworks offered. This has paid off because now I can spend roughly an hour and a half developing applications on my own time, every day, but see real results. I doubt I could do so much, in so little time, if I were working in a scripting environment like JSP.

You are training your mind. That's the proper way to look at things. The WebObjects frameworks have already tackled a plethora of programming challenges for you. But you wouldn't realize it, unless you put the time in, up front, to know what WebObjects can do. In fact, I've found that if things are getting difficult, it's time to research and see if there is something in the frameworks that I've overlooked. Either that or I made a bad schema design decision, at which time I launch EOModeler, make the necessary schema changes, and "synchronize" them.

In addition to the frameworks, design patterns are abundant. You'll quickly learn about "Key-Value-Coding" (KVC). You may have learned about getter and setter methods in object oriented design, but KVC adds much more depth and utility to this. Perhaps most important of all, you'll start to understand how object inheritance trees should be built.

The Price

On a technical level, nothing is as mature and robust as WebObjects. With all this power, you'll be amazed to know that you can get all of it for almost nothing. To be honest, before Apple acquired WebObjects, it would cost $50,000.00 for the full blown application server and several thousand dollars per developer. Once Apple released version 5 of WebObjects, they cut the price to only $700. Now, WebObjects is at version 5.3 and it comes with the purchase of Mac OS X. The developer tools come with vanilla OS X ($99) and the full application server comes with "OS X Server" ($500).

Versions 5 - 5.2 officially supported developing applications under MS-Windows. Version 5.3 on, only supports development on the Mac. At this stage of the game, if you don't have a Mac and want to get into WebObjects, you might as well spend $500 on a Mac-Mini. You'd get a whole computer plus the WebObjects development license. Later you could upgrade to Mac OS X Server.

The Dawn Of Time

In the beginning, there was WebObjects. I'm not trying to be funny, I'm dead serious. WebObjects was the first "Application Server" in a time when that term didn't even exist. It was also a complete development solution, not just an application server, a fact which makes it unique even after all these years.

When Steve Jobs was forced to leave Apple in 1985, he started a new computer company that he hoped would make Apple's Macintosh a piece of history. This company was called "NeXT" and their first computer was the black magnesium "NeXT Cube" with no hard drive, no floppy, just a 256 megabyte magneto optical drive. Steve told developers that customers would "download software from the Internet" in a time when most people hadn't heard of the Internet. He told students that they could "carry their entire world" in their backpack, as the magneto optical disk would store everything they'd need.

The NeXT was a neat piece of hardware, but the operating system, "NeXTSTEP" was the ultimate achievement, along with its object oriented development tools. The World Wide Web was first created on the NeXT. Yes the first webserver (CERN httpd) and Web browser were made on the NeXT by Tim Berners-Lee who is now head of the W3C. In 1994, the first search engine was written on the NeXT called "WebCrawler" by Brian Pinkerton. Even the hit game, DOOM, was first designed on the NeXT because the development tools were so rich. id Software actually found it easier to build a game, intended for the PC, on the NeXT first and then port it to the PC than to start developing on the PC from the beginning. It all comes down to good object oriented patterns and beefy frameworks. The NeXT engineers just gave us all so much to work with.

In March of 1996, the first official WebObjects 1.0 was released by NeXT. At the keynote presentation, Steve Jobs said "Act one of the Web focused on enhancing the user interface and expanding the capabilities of Web browsing software. But the server will be the epicenter of act two." This was the first release that integrated all the tools and frameworks. Items like EOModeler and the Index Kit had existed long before this release.

Now we've come full circle. In 1997, Apple purchased NeXT for $400 million. Steve Jobs came back to the helm as iCEO. Then after the release of the iMac, Steve became the full fledged CEO once again. NeXTSTEP replaced the traditional Macintosh operating system and was dubbed "Mac OS X."

Key Features

Direct To Web — There is a particular set of frameworks, known as "Direct To Web," which seems to inherently understand your database schema. You can use this framework in your applications to quickly and easily make databases queries and updates. It has extremely flexible widgets for handling one-to-many and one-to-one mappings. You can also make a "Direct-To-Web" project where it automatically builds a customer service type of application giving nothing but your database schema. Here at Jewelry Luv, we use Direct-To-Web Projects to quickly test out schema designs. If the relationships and choices don't make sense, it will be immediately evident in the Direct-To-Web application. You can then proceed to update your schema, restart your Direct-To-Web app (not recompile), and retest. We also use the Direct-To-Web Project as the starting point for all our customer service applications. It is fast and easy to tweak settings and to add new functionality. This is a far cry from "wizard" based approaches that some development environments offer. "Wizard" designs are inflexible, usually hard to extend and modify, and have limited ability. Direct-To-Web is truly the only product of its kind.

Direct To Web Services — another set of frameworks, called "Direct To Web Services," is designed to quickly, and painlessly, allow you to produce SOAP/XML content or consume it. I must confess, I have not used these frameworks, but it sure is nice to know they are there when I need to publish data for other web sites to utilize or I want to consume data feeds from other sites. The idea is that, given a database schema, WebObjects does all the hard work for you. With a WSDL file (Web Services Description Language), it is possible to figure out all the getter and setter methods for XML interaction with a data provider. But who creates this WSDL file? Usually a programmer has to put it together by hand. I believe, with Direct To Web Services, WebObjects automates this task for you.

Direct To Java — is the newest framework in WebObjects. With "Direct-To-Java" you have the ability to create desktop applications, not web browser based applications. It consists of a set of frameworks to communicate between your server application and multiple desktop Java applications. This opens up the possibility of more dynamic user interactivity than what can be achieved with a web browser. In the same style as the other "Direct To X" projects, you can build a Direct-To-Java project just by pointing it toward your database schema. Immediately, a Java based, double-clickable desktop application that you can use for customer service activities, will be created. Here again, I know of nothing else remotely like this product.

Enterprise Objects Framework — also known as "EOF," is considered to be the ultimate data persistence framework. It has been around for eons, it even predates WebObjects. You create what is called an "editing context" which can loosely be considered a SQL transaction, because you can operate on it and either save the changes or roll them back. The editing context maintains a mapping of database objects in memory. It's a type of advanced cache that is capable of evaluating most SQL queries in memory. Thus it maintains an "internally consistent view" of what the database is. This gives you the flexibility to manage how "fresh" the data is a user interacts with in the Database. You can constantly flush your editing context's cache to reflect updates other users may have made to the data. Or, you can keep the user's view independent and resolve conflicts when it comes time to commit the data. In the most simplest terms, EOF gives you everything you need to make efficient and intelligent use of your database. EOF is also database agnostic, it will generate the SQL statements you need for practically any database. Your EOF application can be ported from Oracle to Sybase in mere hours. A popular competitor is Hibernate. An alternative that attempts to recreate EOF for open source is Cayenne.

Dynamic Components — are the miscellaneous object oriented widgets which represent items like radio buttons, checkboxes, and hyperlinks. Practically any HTML element you can think of, WebObjects has a widget for. If it is already part of HTML, what good is a special framework of widgets? For starters, it simplifies the setting of data. Instead of having to programmatically pull data from an HTTP request, the widgets automagically do this for you. In Web Objects, every page is a component. You can nest components and you can extend components via inheritance trees. The components also verify and format data to facilitate saving to the database.Struts is a popular competitor to WebObjects Dynamic Components, as is Tapestry which tries to emulate WebObjects in an open source project.

Clean Separation of Logic and Content — WebObjects is the only environment that completely separates your HTML in one file, and your programming logic in a .java file. All of your business logic happens in pure java files ending with a .java extension. All of your content placement happens in an HTML file. This is a pure HTML file with one addition, the <webobject> tag. This means you can edit your HTML file in any application, even Netscape Composer (if you wanted to). This is something you can't do with JSP or any other scripting language. I love this separation so much that I flat out get frustrated when dealing with scripting languages. It drives me crazy seeing lines and lines of programming logic interspersed with HTML elements?s; I go completely bonkers! It is so hard to make heads or tails of your HTML layout with all that programming code thrown around in the same file. At Jewelry Luv, we love clean separation so much, that we also split our HTML files in two. We use CSS for all our layout and place it in a .css file. Our HTML files make heavy use of the defined CSS properties and never use a single <table> tag. The human mind can only process so much at once, it really excels when it can focus on one thing at a time. The "divide and conquer" approach achieved by clean separation can work wonders.

Further Reading