WebSpeed on PAS for OpenEdge (PASOE) has some basic advantages over classic WebSpeed because:
WebSpeed on PASOE employs a more integrated architecture compared to classic WebSpeed because both the Web server and the WebSpeed Transaction sever are combined in a single instance.
WebSpeed on PASOE is more efficient than classic WebSpeed regarding the management and the availability of the agents that handle client requests.
Classic WebSpeed only supports the GET and POST HTTP verbs. WebSpeed on PASOE supports all standard HTTP verbs.
WebSpeed on PASOE supports event procedures that were not supported on classic WebSpeed.
PAS for OpenEdge includes support for multiple servers in a single instance; you do not need to configure and run separate Web server, WebSpeed Transaction server, and AppServer instances.
PAS for OpenEdge shares a single security context among the WEB transport that supports WebSpeed and the other transports (REST, SOAP, and APSV).
Architectural overview
The following figure is a simplified overview of the architectural differences between classic WebSpeed and WebSpeed on PAS for OpenEdge.
Notice that the classic WebSpeed implementation requires a Messenger application deployed on a third-party Web server to handle client requests. There maybe an optional NameServer that the Messenger consults to find a WebSpeed Transaction Server that has the resources that can satisfy the client request.
The PAS for OpenEdge instance, however, includes an Apache Tomcat Web server thereby eliminating the need for a third-party Web server, a Messenger application, and a NameServer. Instead, there is a Web Transport application to respond to client requests. The Web Transport is part of the OEABL application deployed in the Java Servlet Container of the instance.
Also note that the classic WebSpeed Broker is performs some of the same functions as the PASOE WebSpeed Session Manager. Both find an agent that can process a client request and return results. However, in classic WebSpeed agents are individual processes that the Broker starts and stops.
The Session Manager, on the other hand manages one or more multi-session agents that are instantiated on server startup. The client request is assigned to a session from a pool of readily available sessions. After the request is satisfied, the session is released and returns to the pool of available sessions. In this architecture, you avoid the overhead of having to start and stop agent processes.
WebSpeed on PASOE employs a more integrated architecture compared to classic WebSpeed because both the Web server and the WebSpeed Transaction sever are combined in a single instance.
