Try OpenEdge Now
skip to main content
WebSpeed Essentials
Introducing WebSpeed : WebSpeed request round-trip : Web request round-trip
 

Web request round-trip

The common administration mechanism provided by the AdminServer lets you spread the WebSpeed components across your network. This flexibility gives you choices in how to set up your WebSpeed configuration. In the configuration shown in the following figure, the Web server and the WebSpeed Messenger are on the same machine, as required. The AdminServer, the NameServer, and the WebSpeed Transaction Server (consisting of a WebSpeed broker and its WebSpeed agents) reside on a second machine.
Figure 2. How WebSpeed processes a Web request
The numbered steps of a Web request in the previous figure are explained in the following sequence:
1. The HTML client, running in a Web browser, generates a connection request. The request is in the form of a URL and is sent to a Web server, which forwards it to a WebSpeed Messenger.
2. The Messenger sends a request to the NameServer for an available WebSpeed broker that supports the required application service.
Note: In a "No NameServer" configuration, the Messenger is hard-wired with connection information for a single WebSpeed broker. The Messenger passes all Web requests directly to that broker.
3. The NameServer selects a broker, which supports the requested application service, from the pool of brokers that have registered with it. The NameServer sends the broker's host name or IP address and the broker's port number to the Messenger.
4. Using these details, the Messenger connects to the broker and requests a WebSpeed agent to process the request. This request is put in a queue by the broker, so requests are not lost in peak load times.
5. If there are requests in the queue, the broker checks for an available agent in its pool. The broker allocates the next available agent to the request and marks that agent as busy. The broker then returns that agent's port number to the Messenger.
Note: If there are no free agents and the broker's maximum number of agents has not been reached, the broker starts a new agent to process the request.
6. The Messenger connects to the agent through that port and passes the Web request to the agent.
7. The agent executes the Web request and creates an HTML page that it returns to the Messenger.
8. The agent informs the broker that it is available again.
9. The Messenger passes the HTML page to the Web server, which passes it back to the HTML client.
Step 2 through Step 5 create only small amounts of network traffic, usually less than 500 bytes. The large amounts of data are in the final request and response, Step 6 and Step 7. The data sent from the Messenger to the WebSpeed agent includes all of the environment variables, as well as the input parameters from the URL or HTML form. The environment variables alone can be up to 3000 bytes. When the response comes back from a WebSpeed agent, it could be a simple HTML page of around 1000 bytes, but it also could be a large.ZIP file or similar. With special programming, WebSpeed can send binary files to the Web browser.
All of these components (the Web server, the WebSpeed Messenger, the WebSpeed broker, the WebSpeed agents, and the NameServer) can reside on a single physical machine. However, you can also distribute them on separate machines, with the following restrictions:
*The Web server and the WebSpeed Messenger must reside on the same physical machine.
*The NameServer can reside on any machine, but requires an AdminServer.
*The WebSpeed Transaction Server (the WebSpeed broker and the WebSpeed agents) requires an AdminServer on its machine. The broker and the agents that it supports must reside on the same physical machine. You can have multiple WebSpeed Transaction Servers spread over several machines, but registered with a single NameServer.
See Configuring WebSpeed for examples of how to distribute the components across a network. You can also distribute the databases over a network. For more information about distributing OpenEdge databases across a network, see OpenEdge Data Management: Database Administration. For information on accessing a non-OpenEdge data source, see the appropriate OpenEdge DataServer guide. When you read these manuals, which describe a typical client/server environment, substitute the term Agent for Client.