Volume Number: 16 (2000)
Issue Number: 1
Column Tag: WebTech

Intro to WebObjects

by David K. Every

What does WebObjects do?

Many people don't understand what WebObjects is, where it fits in Apple's strategem, what a web-application is, and what WebObjects can do for them. The purpose of this article is to answer those questions and a few more along the way.

WebObjects is a superior environment for creating and deploying high end web applications. In short, WebObjects is an enterprise web application server. However, that begs other questions: "What is enterprise?", "What is an application server?", "How does this fit into a large scale multi-tiered client-server solution?" and of course, "What does it all mean?" Have patience and I'll try to get to it all.

When I defined WebObjects, I said "enterprise" web application server - and Apple uses the term "enterprise" as well - so what is "enterprise"? Whenever I want to know what a word means, I hit the dictionary:

Enterprise - en*ter*prise (en-tor-prize) n. An undertaking, especially one of some scope, complication, and risk. A business organization. Industrious, systematic activity, especially when directed toward profit. Willingness to undertake new ventures; initiative.

WebObjects, along with Cocoa and EOF, are Apple's Enterprise Solutions - and that definition explains what these products are for. If you need to create a product of any complication (large scope) that has some risk, then WebObjects helps. It requires a little initiative and willingness to take on a new venture, but then all business is based on that. It is designed for serious business organizations - and making a profit off of the web.

WebObjects, Cocoa and EOF are what I call the divine trinity of enterprise development: three tools, all related, that all empower each other, and are even aspects of each other. All three frameworks / tools are powerful solutions on their own - but they are complementary and can work together to form a complete solution.

The WebObjects Framework and Cocoa (formerly known as YellowBox, OpenStep, or NeXT STEP) share some functionality, and many of the same classes, including their foundation framework. They are the evolution of the NeXT Step Framework, that is very rich and mature (10 years for Cocoa and 5 years for WebObjects). Their primary difference is the type of applications they target. Cocoa targets stand alone user interfaces (client-side binary applications) while WebObjects targets web-applications; applications that are deployed across a network, and run in either a web browser (HTML) or a Java runtime.

EOF (Enterprise Objects Framework) is a specialized solution that comes bundled with and can be used with either Cocoa or WebObjects. EOF is an abstraction layer that uses modern OOD/P (Object Oriented Design and Programming) techniques to interface with data (usually traditional table/row/column type procedural relational database management systems - RDBMS), other systems (security, commerce, or ERP systems) and legacy programs (like mainframe client-server applications). EOF allows the creation of database schemas, and wiring them together in a visual fashion, and hides almost all of the complexity of working with databases (concurrency issues, caching, uniquing, and so on) from the implementers. EOF is also an excellent abstraction layer on top of any data store. It's basically a way of managing data piped to/from any outside source.

There is a lot of hype of late about EJB. Enterprise Java Beans is a concept whose time will come - but is not completely ready for prime time yet.. As Enterprise Java Beans matures, it should fit in quite complimentary with some other parts of WebObjects - there is less overlap than one might guess at first glance.

Most web applications are client-server solutions where the user is the client (using a web browser) who accesses the web application server to do certain actions. The most common actions are things like tracking what a user wants to buy (via shopping carts), or remotely accessing database information that is stored on the server. Since most of these solutions are dealing with databases, EOF is crucial to most WebObjects solutions. Many Cocoa applications also work with database and legacy systems. In the future, more and more client-server type Applications (solutions) are going to migrate to wider network possibilities (the Internet) and therefore make use of web-centric interface (WebObjects). So neither Cocoa nor WebObjects needs EOF - but it just makes them both more useful.

So your interface and target market will help dictate which of these tools you choose; Cocoa is great for making stand alone applications that can be client-server solutions (using EOF). Cocoa makes it easier to develop, maintain and deploy these apps than traditional Mac Applications. If you want to create similarly easy to develop, maintain and deploy versions of Web-based solutions, or if you desire your application's interface to be a web browser (html) or Java, then WebObjects is the way to go. EOF is used by both to integrate database solution into your solution. And the Foundation Framework layer is common to all of them and is the glue that binds them together.

To understand WebObjects, it helps if you understand the basics of how the Internet (Web Servers and Web Clients) works. The very high level view is that you have a server that has a domain name and an IP address. You type in the URL (domain and path information) or click on a link, which gets directed to that server. The server sees that as a request, and it responds by sending a file that a web-browser can understand, parse, and display.

This request-response cycle is the whole conceptual foundation of the HTTP (Hyper Text Transfer Protocol) and the world wide web. Users request something by typing the URL, choosing a favorite, clicking on a link or image, and the server responds.

Normally the web servers just respond with static files (unchanging text and pictures to present information) that are web pages. Sometimes websites want to do more than just serve static pages - and that is where application servers (like WebObjects) come in.

Application servers are far more versatile, they typically don't just serve static pages and images. The "pages" that an application server serves contain links and form elements that the client can manipulate to do more than request static files. These links can pass information to the server and thus control applications running on the server. Such applications running on the server can do a number of things which are better suited for the server than the client, such as performing a database query, or crunching compute intensive calculations, or taking information from the client and adding it to a database on the server based on form submission or by remembering previous selections and behaviors. Basically a web application allows a website to do anything that an normal client-side application can do, with the only limitation being that the user interface is what you can pass and return from a web browser.

Traditional web serving could be described as providing access to books (of many pages) on-line and letting the user turn the page, or choose other related topics. You can extend this static functionality with dynamic capabilities and animation using DHTML, Flash, QuickTime and JavaScript. For the most part these extension typically just provide you with a more eye-catching book - they don't fully utilize the potential provided by the interconnectedness of this new medium (the web).

Putting static links on a page also requires a lot of forethought. The web designer has to know a priori what the user might want to do at every step, and then add links representing a limited set of options to choose from. This is not unlike the menuing systems of old - a fairly low brow interface - the user points at one choice among a few and grunts, implying "that one". The user then gets to make another choice among a few and so on. This is not the highest form of communication.

Application serving allows for many, many more possibilities, and allows the user to offer real input. With applicaion servers, users can ask very complex things, submit larger amounts of information (to be processed) and allow for far more growth over time. The simplest form of an application server is having a search tool (application) for a site - then at least the user experience is growing a little beyond point and grunt - however, application servers are usually much more sophisticated than that. Instead of serving static pages (the same pages to everyone), web applications can customize pages for each user based on information learned about them (by asking, watching their behavior, or based on information the customers enter) which means that the pages served are more customized, dynamic and change based on the users needs. These capabilities offer web site developers a much greater ability to track information, control information, and get input based on browsing habits and so on. With application servers the site can audit what the users are doing, where they are going, and how users are using the site. Instead of serving all pages and information to a user, the site can prefilter that information and give the user only what they have interest in. This can save bandwidth, helping performance of the web site, and reduce costs.

Application serving can also save companies in the design and maintenance time of a website. It allows designers to look for commonality, and instead of serving many near identical duplicates of the same page (that only vary slightly), they can have one page (common format) that fills in all the unique information based on variables, parameters and context. This means less duplication of effort, more code reuse, and higher degrees of consistency (again improving the user experience).

So regular web serving is about almost all output, serving pages, and limited input; while Application serving is much more two-way, including many more possibilities that such as real input and bidirectional communication. This is analogous to the differences between watching a TV show and clicking to change channels versus having a video conference and interacting with whoever is on the other side. Businesses can be collecting information as well as just spewing it out. Instead of only being able to spew information blindly they can instead send out the right information (information more likely to fit the context of what the user wants). Application serving gives a company's website a competitive advantage by allowing it be more powerful, pleasant and useful - which should result in a better user experience and more payoff for creating the site. Application servers allow companies to use this new medium (the web) to it's full interactive interconnected potential - and this is what web applications and WebObjects is all about.

WebObjects is an application server but is also what is known as middleware. In an n-tier client server solution you can have many layers of things going on. At the bottom tier you have your database and other legacy systems (the data storage), at the top tier you have your clients - and in between many other servers and services (tiers). Somewhere in the middle is the go-between and the integration solution - the key that binds it all together and makes many separate solutions feel like one integrated whole. That key is middleware, and in the Internet this is usually the application server (WebObjects).

To be a good application server you need to be a great development tool and rich framework to allow companies to create applications quickly and cost effectively. WebObjects does this - however, the details are so extensive that it deserves to be a separate in-depth article and will be available in a future issue [WebObjects: the Internet Application Development Environment]. That article will go into more depth about the tools, framework, and how WebObjects does what it does. This article will focus on what WebObjects is, and the other aspects of being a good application server: versatility of deployment and being an open solution.

A good Web Application solution needs to be able to integrate many different systems into one cohesive whole, and allow any part of the system to be replaced with some other system or to allow any part of the system to grow. Scalability is the keyword.

Notice the drawing which shows the Application Server as the middle. Well, in a small organization (low load) this server may be doing everything. You can start with a single server being all things - running a web server, an application server, and hosting the data. Over time, as your requirements change (your load grows), you can add more servers, more services, and balance the load over many more levels and systems. This potential for growth in both features and scale is critical - because any downtime while scaling up can seriously hurt a business. The multiple costs of conversion can put companies out of business. So a web application needs to be able to deliver that integrated application over the web, while still allowing any area to change or grow over time. These openness and deployment issues are another area where WebObjects shines - and is critical to understanding what differentiates WebObjects from other solutions.

Using WebObjects you can create great web applications, but there are many tools that can create applications - so a differentiating issue becomes how do you deploy your solution, how open is the solution, how scalable and how well can it grow. Well good news - Apple is very open with this solution, and WebObjects solutions can really grow.

On the top end (one side of the middleware) you need to interface with the client. WebObjects does this with the help of a web server. It doesn't just require one company's web server, like some competing solutions do. WebObjects has adapters that allow it to work with many different HTTP servers including any that use CGI, ISAPI, WAI and NSAPI interfaces. Which in English means Apache, Microsoft's IIS, and Netscape servers are all supported native. That covers about 95% of the market. Everyone else is covered through the use of the CGI interface - which while a little slower performing than the native interfaces, still works very well. In fact, it works so well that many competing solutions only offer this slower interface. So with CGI support, it means that WebObjects can interface with about any web server that matters - and in the future, if something new matters, Apple or an interested third party is likely to write another adapter to keep you covered. As a last resort, if you really need some new adapter then you can write your own (Apple offers source code for doing that).

WebObjects itself runs on a variety of platforms, including; Windows NT, Solaris, HP-UX (1) and Mac OS X. Many of the competitors solutions are less open, and may only run on a single platform, or have other limiting dependencies. There are a few solutions that run on more platforms than WebObjects. WebObjects requires a native runtime for each platform, to offer the highest level of performance. Native runtimes require Apple to QA each version and tune for each platform. Most of the solutions that allow more platforms are running interpreters, virtual machines or emulators of one sort or another, and so perform far below the level of WebObjects. Because of this native platform support, you can not just port the runtime yourself - Apple will need to support the platform by creating the runtime (and you aren't going to get source code to their run time). However, WebObjects is still more open than most solutions in this area - and I think Apple made the right tradeoffs (better performance with the limitation of running on only four of the best platforms). Another key point of versatility to remember is that the WebObjects Application Server(s) don't have to run on the same machine as the HTTP server, nor the database server, nor any of the other servers - and WebObjects can still interact with all those others servers.

At the back end (talking to the data stores and other servers), EOF enables the back end data to work with any one (or many) of the following databases as your back end - Oracle, Sybase, Informix, OpenBase and any ODBC compliant database. I expect support for even more choice in the future. If you have a database that isn't supported by default, you can write a plug-in on your own to fill that gap (or find someone else who will) - I've heard of people using IBM's DB/2 or Ingres among others. Third parties offer mainframe host applications, PeopleSoft and SAP support for the ERP side of things. WebObjects can work with Corba/IIOP, DCOM, and JavaBeans - and there are extensions and services for security, directory services, mail, eCommerce and so on. Thus the back-end is also a wide open solution.

The openness at every level gives me a lot of security and confidence in the solution - and is another reason why I would choose this type of solution over something like ASP and a Microsoft solution. Microsoft's' solutions tend to all be proprietary and lock you in to their tools; they work with their databases, their servers, only on their OS, and only using their development tools. That concerns me. Apple has a complete solution that works well with just about anything I can think of - and has hooks or plug-ins (where possible) to make WebObjects an even safer, more open, solution.

This article should have given you a better understand of how Apple's Enterprise Solutions, and WebObjects, can fill some needs within your organizations - and learn that WebObjects is the premier solution for creating web applications.

Web applications allow companies to improve the Internet experience by changing the normal push-only form of web distribution into a much more bidirectional (push-pull) experience. Web apps also allow companies to deliver far more services to their own people at many different locations (like around the globe), and using a web-based interface can reduce the costs of development and deployment, compared to traditional corporate solutions - all while increasing the quality of the user experience.

WebObjects has many key customers, many deployed solutions. It has been proven over time, and has earned many industry accolades. WebObjects does critical things like save you money and offer you a safe path for growth. If you are trying to create some sophisticated web solutions, guarantee some scalability, have a high degree of openness and expandability in your design, and you want to leverage the most powerful and versatile solution out there - then WebObjects fits the bill. There doesn't seem to be anything else that competes as well in all the different areas - maybe this is why WebObjects is the leading web application solution.

David K. Every is a Senior Software Engineer who has done many client-server solutions, a WebObjects programmer, and the creator of the MacKiDo website (http://www.MacKiDo.com). You can reach him at dke@mackido.com.