WebSpeed
Developer’s Guide
Running Primary and Secondary Web Objects
The fundamental requirement for a secondary Web object is that it generate or map a Web page so that the Web client must make the next transaction request back to the primary Web object.
The primary Web object typically sets the time-out period for the WebSpeed transaction. As the primary and secondary Web objects respond to requests from the client, the time-out counts down. The time-out does not reset unless the primary Web object explicitly resets it by calling setWebstate. Note that all secondary Web objects are implicitly state aware by virtue of the primary Web object’s being state aware.
The primary Web object typically generates the HTTP header for the Web page. However, for embedded SpeedScript Web objects, the primary Web object must call the setWebstate method procedure to propagate the state-aware cookie for the next request service before calling any embedded SpeedScript Web object.
Figure 8–2 shows the relationship among a Web client, a primary Web object (Web Object A), secondary Web objects (Web Objects X, Y, and Z), and the transaction request cycle (solid arrows) in a state-persistent WebSpeed transaction. In this scenario one might imagine that Web Object A, in addition to controlling the secondary Web objects, defines shared variables that can be referenced by Web Objects X, Y, and Z.
Figure 8–2: Primary and Secondary Web Objects in a WebSpeed Transaction
![]()
The request cycle shown in Figure 8–2 illustrates these points:
At some point Web Object A determines that the user is done, unlocks the Agent and possibly sends a Web page back to the user telling them that the transaction is terminated.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |