About Web Broker and Web Snap

Part of the function of any application is to make data accessible to the user. In a standard application you accomplish this by creating traditional front end elements, like dialogs and scrolling windows. Developers can specify the exact layout of these objects using familiar form design tools. Web server applications must be designed differently, however. All information passed to users must be in the form of HTML pages which are transferred through HTTP. Pages are generally interpreted on the client machine by a Web browser application, which displays the pages in a form appropriate for the user's particular system in its present state.

The first step in building a Web server application is choosing which architecture you want to use, Web Broker or WebSnap. Both approaches provide many of the same features, including

  • Support for CGI and Apache DSO Web server application types. These are described in "Types of Web server applications" on page 33-6.
  • Multithreading support so that incoming client requests are handled on separate threads.
  • Caching of Web modules for quicker responses.
  • Cross-platform development. You can easily port your Web server application between the Windows and Linux operating systems. Your source code will compile on either platform.

Both the Web Broker and WebSnap components handle all of the mechanics of page transfer. WebSnap uses Web Broker as its foundation, so it incorporates all of the functionality of Web Broker's architecture. WebSnap offers a much more powerful set of tools for generating pages, however. Also, WebSnap applications allow you to use server-side scripting to help generate pages at runtime. Web Broker does not have this scripting capability. The tools offered in Web Broker are not nearly as complete as those in WebSnap, and are much less intuitive. If you are developing a new Web server application, WebSnap is probably a better choice of architecture than Web Broker.

The major differences between these two approaches are outlined in the following table:

Table 33.1 Web Broker versus WebSnap Web Broker

Backward compatible

Only one Web module allowed in an application.

Only one Web dispatcher allowed in the application.

Specialized components for creating content include page producers, InternetExpress components, and Web Services components.

No scripting support.

No built-in support for named pages.

No session support.


Although WebSnap applications can use any Web Broker components that produce content, the Web modules and dispatcher that contain these are new. Multiple Web modules can partition the application into units, allowing multiple developers to work on the same project with fewer conflicts.

Multiple, special-purpose dispatchers handle different types of requests.

Supports all the content producers that can appear in Web Broker applications, plus many others designed to let you quickly build complex data-driven Web pages.

Support for server-side scripting allows HTML generation logic to be separated from the business logic.

Named pages can be automatically retrieved by a page dispatcher and addressed from server-side scripts.

Sessions store information about an end user that is needed for a short period of time. This can be used for such tasks as login/logout support.

Table 33.1 Web Broker versus WebSnap (continued) Web Broker WebSnap

Every request must be explicitly handled, using either an action item or an autodispatching component.

Only a few specialized components provide previews of the content they produce. Most development is not visual.

Dispatch components automatically respond to a variety of requests.

WebSnaplets you build Web pages more visually and view the results at design time. Previews are available for all components.

For more information on Web Broker, see Chapter 34, "Using Web Broker." For more information on WebSnap, see Chapter 35, "Creating Web Server applications using WebSnap."

Was this article helpful?

+1 0

Post a comment