Enterprise Objects

First decide if you are using Enterprise Objects. You use Enterprise Objects if you need to access data from a back-end database and use that data to drive the content generated by your application. All types of WebObjects applications including HTML-based, Java Client, and web services can use Enterprise Objects to model their data. Enterprise Objects is extremely scalable supporting large data stores and clients—it is used by many successful online stores. The only reason not to use Enterprise Objects is if you don't have persistent data or you have a proprietary data store that is incompatible with Enterprise Objects. In the later case, you might still be able to use Enterprise Objects by writing your own adaptor.

Web Applications

Creating web applications that are HTML-based is the most popular choice because any user on any computer with a web browser can access your website. Typically, web applications don't require the user to download software. You can create login pages and track user sessions in a web application but you don't have to use this feature—your users can access pages directly. You can combine dynamic with static pages to improve performance, too. You can use JavaScript, Flash, and Quicktime to improve the user experience. Because of this, web applications is a common choice for public websites/Internet applications with a large and broad user base—such as community websites and online stores.

Java Client

In contrast, Java Client applications are more suitable for intranet applications. Java Client is a popular choice for enterprises that have some control over the client computers. Choose this option when downloading client-side software is not a problem.

The user must wait for client-side software to download and the quality of the user’s Java virtual machine determines whether the application runs correctly and efficiently. Java Web Start can help in making Internet deployment of Java Client applications more user friendly.

Java Client can provide a better user interface similar to other desktop applications. The user interface response time may be better in a Java Client application also because some computations can take place on the client side.

Web Services

Web services are used when you don't have a user interface and just want to provide a service to other web applications. For example, a medical system might have many different components used for billing, patient records, and scheduling. Each of these components might have its own data storage and web interface. However, data may need to be shared across different components while at the same time controlling access to sensitive data—controlling read/write permissions. In this case, web services can be used to control access from one application to another and perform common tasks, such as fetching demographic information about a patient. Typically, web applications can extend their usefulness by providing web services to other web applications including Dashboard widgets on Mac OS X.

You can provide and consume web services on the Internet or an intranet. However, due to the emerging nature of web service technology, you should take into account security issues before making web services available on the Internet.

Choosing web services doesn't exclude other approaches. Fortunately, using Direct to Web Services you can create a web services application easily from an existing web or Java Client application. All you need is your business logic framework and EO model.

Rapid Prototyping

You can use the rapid prototyping tools—Direct to Web, Direct to Java Client, or Direct to Web Services—to create an application faster and with less effort. All you really need to create a rapid prototype is an EO model and optionally, your business logic.

Choosing one of the rapid prototyping tools doesn't exclude any of the other approaches either. Your business logic framework and EO model can be the same for all types of WebObjects applications. However, using a rapid prototyping tool for the production system has some advantages and disadvantages.

In all cases, the rapid prototyping tools are great for testing your model and business logic. Often these prototypes help define system requirements and identify design problems. Later, they can be used to debug an application. You can use it to inspect and edit your data too. Because of this, prototypes make ideal data entry and administration tools. Rapid prototyping may be your only choice if your EO model is evolving and it is impossible to maintain hundreds of custom pages. For these reasons, prototypes are often used throughout the lifetime of a project.

The user interface generated by a rapid prototyping tool is not, however, flexible or fancy enough for high-profile websites. The webpages of a Direct to Web application are generated from templates—for example, a query, inspect, edit, list and master-detail template per entity. The layout and flow of the website is predetermined—you just customize each of the entity pages using the Web Assistant. You can freeze pages and use WebObjects Builder to modify the look, but you need a combined approach to change the control flow.

Your decision whether or not to use Direct to Java Client is similar. If your Java Client user interface has specific layout and flow requirements, then don't use Direct to Java Client. Keep in mind that the Direct to Java Client approach—including the user interface it generates—is designed expressly for viewing and editing databases, especially large ones. If your application requires this capability, you will find the Direct to Java Client user interface well-suited for the task.

If a rapid prototyping tool doesn't meet your needs, consider combining approaches as described in Combining Approaches.

Combining Approaches

WebObjects does not confine you to a single approach. You can switch your approach as you develop your application or combine it with another approach. This is possible in WebObjects because the business logic is encapsulated in enterprise objects and not in the application.

For example, the web application and Direct to Web approaches can be combined in many ways. You can start with a Direct to Web application and freeze templates and pages to create a custom look. You can also replace the main pages with your own login, tunnel, and navigation pages. You create all these custom pages using WebObjects Builder.

You can also use Direct to Web reusable components, located on the palette in WebObjects Builder, in any web application. The components—corresponding to inspect, edit, and list pages—can be customized using the Web Assistant. If your application employs forms and lists that work with enterprise objects, these components can save you a tremendous amount of time.

You can also mix Java Client and Direct to Java Client applications. If you’re developing a Java Client application and you need a Direct to Java Client controller—for example, a window that edits an enterprise object—you can easily instantiate one. Also, you can freeze an interface in Direct to Java Client and edit it with Interface Builder.

It's not uncommon to implement several approaches in parallel until you determine which is the best for your application. This is a typical development path:

1. Create your EO model

2. Create a Direct to Web application

3. Create a Direct to Java Client application (as a comparison)

4. Choose an approach and create your custom application

5. Create a Direct to Web Services application

Using Direct to Web Services is just another way to extend the usefulness and lifetime of your application. Usually after several releases of your application, you discover some valuable services that you can provide to other applications. If you use Enterprise Objects, you can easily create and deploy web services using Direct to Web Services.