For forums, blogs and more please visit our
Developer Tools Community.
By: Cary Jensen
Abstract: IntraWeb is a framework and component set that permits you to quickly and easily build interactive Web sites using Delphi, Kylix, C++ Builder, and JBuilder, and it may very well change the way you develop Web applications from now on.
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
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
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
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
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
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
for processing by the IWPageForm itself. This relationship is depicted in the
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
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 (https://atozedsoftware.com) to deploy
application mode IntraWeb applications.
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
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
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.
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 email@example.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
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 https://www.DelphiDeveloperDays.com.
) 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.
Could not retrieve comments. Please try again later.
Download Delphi 10 now!
Webinars on demand!
More social media choices:
Delphi on Google+
@RADTools on Twitter
Server Response from: ETNASC01