This section describes how the components of the WebSpeed Transaction Server interact to respond to a request from a client browser.
1. The Web server receives the request from a Web browser. Each request is in the form of a URL, as shown:
2. The Web server sends the request to a WebSpeedMessenger (either CGI, ISAPI, NSAPI, or WSASP), as shown:
3. The WebSpeed Messenger communicates with the NameServer, requesting an appropriate WebSpeed broker, as shown:
Note: The NameServer can be eliminated. It is possible to configure the WebSpeed Messenger to contact the broker directly. However, if the NameServer is eliminated, the Messenger can only contact a single broker.
4. The Messenger initiates a connection to the WebSpeed broker at the address returned by the NameServer and forwards the request to that broker, as shown:
Note: If load balancing is enabled, the NameServer can manage multiple WebSpeed brokers that support the same application service. It will choose a broker based on load-balancing criteria.
5. The WebSpeed broker consults its pool of WebSpeed agents and assigns the request to an idle agent, as shown:
6. The WebSpeed agent and the WebSpeed Messenger establish a connection. The Web object name and the environment for the request are passed to the agent, as shown:
7. The WebSpeed agent executes the Web object. It also performs the necessary reads from and writes to a data source. Notice that the WebSpeed agent maintains its connection with the WebSpeed Messenger while the Web object is executing, as shown:
8. The WebSpeed agent passes the generated HTML Web Page to the Messenger, which sends it to the browser through the Web Server, as shown:
Assuming that this is a stateless transaction, the agent disconnects from the Messenger, and it updates its availability with the broker. No context for the transaction is maintained and the agent is free to service another request. (However, you can preserve context by using cookies, URL query strings, hidden HTML form fields, or connection identifiers.)
If the transaction is state-persistent, the agent remains locked to the Web browser client until a specified time-out period passes. However, in actual practice state-persistent WebSpeed applications are rare. Locked agents slow down performance.
For more information about managing application states and context, see OpenEdge Application Server: Developing WebSpeed Applications.
