IntraWeb is a component-based Web development framework written in Delphi by AtoZed Software. It combines the visual development normally associated with Borland's RAD tools with a robust collection of dynamic Web site creation features. Better yet, it is included in the latest versions of Borland's premiere RAD development tool: Delphi 7 Studio, and is available for Delphi 5 and 6, Kylix 2 and 3, C++ Builder 5 and 6, and JBuilder 7.

For those of you who are following my The Professional Developer soapbox, you already know that I am in the midst of an extensive series of ClientDataSet articles. That series will continue, as I have many more installments in the works, including discussions of nested datasets, options for applying updates, using parameterized queries, passing data between the ClientDataSet and its DataSetProvider, and much more.

But for now, I want to take a quick break and talk a little about IntraWeb. Why? Because it is fantastic. It is a rare thing when you come across a framework so flexible, so powerful, and so consistent with the "culture of excellence" that is the hallmark of Borland's own software. But IntraWeb is the real thing. If you have not tried it yet, don't wait. It is definitely worth a serious look.

So, that cat is out of the bag. I am a big fan. You may already be a fan, too. But if you haven't yet had a chance to look at it, read on. IntraWeb is Web development done right. While it is not appropriate for every dynamic Web site, it more than meets the needs of a great number of developers. And does so in a style that is elegant, extensible, and downright fun.

Let's begin at the beginning. IntraWeb supports two distinct styles of Web site development: application mode and page mode. In application mode, the IntraWeb application is a self-contained, state-maintaining executable that generates HTML and JavaScript for rendering by a Web browser.

IntraWeb applications designed around application mode can be designed as a Web server extension (such as an ISAPI DLL or an Apache module), or as a stand-alone executable.

When designed as a Web server extension, IntraWeb applications are invoked through a running Web server. Specifically, the URI (uniform resource identifier) referenced by a Web browser will refer to a Web server, which in turn will pass control to the IntraWeb application. In this configuration, all requests are submitted to the Web server, and all responses are returned by the Web server. These responses, however, are generated entirely by the IntraWeb application (at the request of the Web server). This relationship is represented in the following diagram.

I must admit that this diagram is a little misleading, in that it fails to represent the multithreaded nature of the client/server interaction on the World Wide Web. To be more accurate, the IntraWeb DLL or Apache module on the right side of this diagram is executing in the context of a specific thread on the Web server. To put it another way, in almost every situation in which IntraWeb components are generating their HTML, they are operating in a multithreaded environment. The only exception is when you are executing IntraWeb pages in page mode, but more about that later.

In the stand-alone mode, the IntraWeb application is a server, listening for HTTP requests on a specified port. In this mode, the IntraWeb server processes the browser's HTTP requests directly. This relationship is represented in the following diagram.

Again, this diagram fails to capture the complexity of the IntraWeb environment. In these situations, the IntraWeb application is a multithreaded server, with each request from a particular browser window being handled by a different thread on the server.

Now let's consider page mode. By comparison, in page mode IntraWeb is used to define individual pages of the Web site, but it does not take responsibility for all of then internal processing. In page mode, the primary processing is performed by a "bridge," which is simply a Web server extension. Currently, these Web server extensions can be created in Delphi, Kylix, or C++ Builder. In other words, when used in page mode, IntraWeb is used in conjunction with a Web server extension created either using Web Broker or WebSnap.

In this configuration, the HTTP request is received by a Web server, which in turn passes the request to a Web server extension created in Web Broker or WebSnap. The Web Broker's ActionDispatcher or the WebSnap's PageDispatcher directs the request to one of its Web action items, or one of its Web page modules, respectively, based on the pathinfo portion of the URI. This Web action item or Web page module may produce a response using one of the normal Web Broker mechanisms.

But when used with IntraWeb, the Web action item or the Web page module will call on an IWPageProducer to invoke an IWPageForm (a special form class declared in the IntraWeb framework) to produce the HTML and JavaScript that Web Broker or WebSnap returns to the Web server. The Web Broker Web module or the WebSnap Application Module will also include an IntraWeb IWModuleController, which is used when an IWPageForm generates HTML and JavaScript that can post an HTTP request intended for processing by the IWPageForm itself. This relationship is depicted in the following figure.

Like the earlier diagrams, this one also fails to capture the multithreaded nature of this interaction. In page mode, it is Web Broker or WebSnap that either spawns separate threads or is invoked on separate threads to respond to HTTP requests that it receives from a Web server. Unlike in IntraWeb's application mode, in page mode a given thread is not dedicated to a particular browser session or even necessarily to two different requests from the same browser.

In application mode the IntraWeb server controller provides automatic state maintenance. Specifically, the first time the IntraWeb server processes    a request from a particular browser window, it creates an object that is responsible for responding to that and all subsequent requests from that window. This object is often referred to as the session.

I am being very particular about distinguishing between a browser window and a specific computer on the Internet. A user can open multiple browser windows simultaneously. When using IntraWeb, each of these browser windows is associated with a different session, which in turn maintains specific information about what the user is doing in that window.

Like any other object you can define in an object-oriented language, this object can, and does, persist data, including any information that you want to maintain for the particular session that it is responsible for responding to. This information can include simple data, such as the time the session started, the number of pages viewed, and so forth. But it can also include more complicated data, including objects. For example, a particular session can have its own database connection, query result sets, current dataset records, just to name a few examples from the database realm. 

I f you want to maintain state in a page mode IntraWeb-based application, you must use one of the standard state maintenance techniques from either your Web Broker application, or from the IWPageForm that produces the response. These include inserting state information into HTML tags such as anchor <A> or image <IMG> tags (when those tag refer back to the Web Broker application), inserting hidden fields into HTML forms that will be returned to the server, or writing and reading cookies.

These two IntraWeb modes, application and page, represent very different approaches to building dynamic Web sites. When using application mode, IntraWeb provides both state management as well as a significant amount of processing power. This processing power is in the form of standard component event handlers that you write, and which get executed on the server in response to things that occur on the browser. These features come at a price, however. Specifically, application mode Web sites tend to behave in well-defined ways, which approximate the way most desktop applications operate. This behavior differs slightly from how most dynamic Web sites behave.

For example, in an application mode IntraWeb application it is normally not possible for a user to use their browser's "back" button to return to a previous page (since that page was produced as the result of some processing). In this mode, if you want to permit a user to return to a particular page of your application mode Web site, you provide that feature through your Web site's interface, such as a button or link. When the user clicks that button or link, you produce a new page, which may essentially reproduce a previously viewed page.

Not all versions of Delphi, Kylix, or C++ Builder support the deployment of both application mode and page mode applications. If you are using the Enterprise or Architect version, you can create both types of IntraWeb applications. Professional edition users can develop, but not deploy, application mode IntraWeb applications. Professional edition users must purchase an additional license from AtoZed Software (http://atozedsoftware.com) to deploy application mode IntraWeb applications. 

More About Application Mode

The distinction between application mode and page mode is very important, and it is worth repeating, with a slightly different perspective. In application mode, a browser is assigned a thread upon making its first HTTP request handled by IntraWeb, and that thread will stay alive to service that specific browser session only, until either the browser submits a call to terminate the thread, or the browser times out.

A time out occurs when the browser fails to make another request of the IntraWeb application for a specified period of time. The timeout duration is configurable, and it is set to ten minutes by default. One consequence of this timeout approach is that, using the default settings, a user who simply closes their browser while viewing a page generated by an application mode IntraWeb application will leave a thread alive on the IntraWeb server until the timeout period expires.

Fortunately, the thread created to handle each browser session is fairly lightweight, requiring about one kilobyte of memory per thread, prior to your customizations. Unless you make changes that significantly increase the amount of memory required for each thread (session), you can easily have hundreds or even thousands of these threads in memory at a time.

That the browser session has thread affinity means that IntraWeb application mode applications are much more similar to typical client-side applications than most other interactive Web application frameworks. In a traditional client workstation application, there is one copy of the application running for each user. The user interface of that application provides the options that are available to the user, and when a user selects from a menu or clicks a button the application responds.

The threads of an IntraWeb application are somewhat like the individual instances of a traditional Delphi GUI client. These threads display pages that you design, and the user uses the user interface of these pages to select what they want the application to do. When the user selects from a menu or clicks a button in an application mode IntraWeb page, the thread that produced that page responds.

This is not how traditional Web server extensions, such as CGI or ISAPI Web server extensions work. Each request handled by a Web server extension is independent of every other request. The CGI application must inspect data in each and every HTTP request that it receives (such as query string values, path info values, or posted input fields) in order to produce the next page.

While application mode IntraWeb application do behave similar to traditional Windows applications in many respects, there is one big important difference. Specifically, IntraWeb applications are multithreaded by their nature. Consequently, if there is any data that you want to be able to share between the various threads, you must use thread synchronization techniques in order to access those resources. These include critical sections, thread lists, and multi read/exclusive write synchronizers.

About the Author

Cary Jensen is President of Jensen Data Systems, Inc., a Texas-based training and consulting company that won the 2002 Delphi Informant Magazine Readers Choice award for Best Training. He is the author and presenter for Delphi Developer Days (www.DelphiDeveloperDays.com), an information-packed Delphi (TM) seminar series that tours North America and Europe, and Delphi Developer Days Power Workshops, focused Delphi (TM) training. Cary is also an award-winning, best-selling co-author of eighteen books, including Building Kylix Applications (2001, Osborne/McGraw-Hill), Oracle JDeveloper (1999, Oracle Press), JBuilder Essentials (1998, Osborne/McGraw-Hill), and Delphi In Depth (1996, Osborne/McGraw-Hill). For information about onsite training and consulting you can contact Cary at cjensen@jensendatasystems.com, or visit his Web site at www.JensenDataSystems.com.

Click here for a listing of upcoming seminars, workshops, and conferences where Cary Jensen is presenting.

Breaking News: Get hands-on training with Cary Jensen. Jensen Data Systems, Inc. is proud to announce Delphi Developer Days Power Workshops, focused Delphi (TM) training. These intense, two-day workshops give you the opportunity to explore and implement a variety of Delphi techniques with Cary Jensen, one of the world's leading Delphi experts. Workshop topics include ClientDataSet, IntraWeb, and more. Due to the hands-on nature of these workshops, class size is very limited. Reserve your seat now. Click here for more information about Delphi Developer Days Power Workshops, or visit http://www.DelphiDeveloperDays.com.

Copyright ) 2003 Cary Jensen, Jensen Data Systems, Inc.
ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT CAN BE COPIED IN ANY FORM WITHOUT THE EXPRESS, WRITTEN CONSENT OF THE AUTHOR.