Kbase P113674: What is the basic flow of communication surrounding the AppServer?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
07/02/2009 |
|
Status: Verified
GOAL:
What is the basic flow of communication surrounding the AppServer?
GOAL:
How does the AppServer talk to the NameServer?
GOAL:
How do clients make a direct connection to the AppServer?
GOAL:
How does the communication flow differ as the result of running the AppServer in various modes?
GOAL:
What protocols are used by clients to connect to he AppServer?
FACT(s) (Environment):
Progress 9.x
FIX:
Knowing the flow of communication surrounding the AppServer will help in troubleshooting.
Assuming all the required pieces are in place and configured correctly, this will guide you through some of the basic communication flow by a client to and from the AppServer.
PROTOCOLS USED:
There are several different protocols supported by the AppServer and the connection process:
TCP/IP - is intended for the Intranet/LAN and is the fastest.
HTTP - is slower than TCP/IP due to wrapping of the 4GL packets and is intended for use where tunneling is required over the intranet/Internet.
HTTPS - is slowest of the three protocols due to the added security/encryption
UDP is used for communication to and from the NameServer only, all additional communication is done with one of the above 3 protocols
CONNECTION METHODS:
Basic examples of client connections using TCP/IP:
Run sample code to connect and run a job via the AppServer:
1. Create server handle
2. Connect to the AppServer using handle
3. Run procedure
4. Disconnect from AppServer
5. Delete the handle to the AppServer
Sample code creating the server handle:
DEFINE VARIABLE hAppSrv AS HANDLE N0-UNDO.
DEFINE VARIABLE ret AS LOGICAL N0-UNDO.
CREATE SERVER hAppSrv.
Then use one of the following connection strings:
1. 4GL client connections to the AppServer via a NameServer:
Furthermore there are 2 different modes of connection using the NameServer:
a)
ret = hAppSrv:CONNECT("-AppService AppLab -H <hostname> -S 5162", "","") NO-ERROR.
AppLab is the registered service of the AppServer(case sensitive) and 5162 is the default port of the NameServer.
The first "" is for a username, the second "" is for the password, when required.
b)
ret = hAppSrv:CONNECT("-URL AppServer://hostname:5162/AppLab") NO-ERROR.
(hostname is for the NameServer host server)
2. 4GL client connections direct to an AppServer:
There are 2 option syntaxes for an AppServer Direct Connect:
a) ret = hAppSrv:CONNECT("-H localhost -S 3090 -DirectConnect") NO-ERROR.
b) ret = hAppSrv:CONNECT("-URL AppServerDC://hostname:3090") NO-ERROR.
NOTE: hostname is the AppServer host and the port reference is for the AppServer
Basic examples of client connections using HTTP/HTTPS:
1. 4GL connection using HTTP:
ret = hAppSrv:CONNECT("-URL http://aia/Aia?AppService=AppLab") NO-ERROR.
2. 4GL connection using HTTPS:
ret = hAppSrv:CONNECT("-URL https://aia/Aia?AppService=AppLab") NO-ERROR.
NOTE: The AIA is written as a Java servlet and requires the installation a Java Servlet Engine and a web sever, neither is supplied by Progress. The AIA accepts HTTP or HTTPS packets from a client and unwraps them into AppServer TCP packets and the reverse, thus it acts as the clients proxy to the AppServer.
After the connection command is given a statement can be given to the AppServer to run a specific piece of code or pieces of code.
Once the code has been run, the Ap.pServer should be given a disconnect statement.
Sample code to disconnect from the AppServer:
ret = hAppSrv:DISCONNECT() NO-ERROR.
Once disconnected the AppServer handle should be deleted to release the memory used by the handle.
Sample code to delete the AppServer handle:
DELETE OBJECT hAppSrv.
COMMUNICATION FLOW:
When a connection is made using a mode other than Direct Connect, the communication flow starts from the client to the NameServer. When an AppServer first starts it is programmed to register with its controlling NameServer The NameServer uses this list of registered Services to redirect the client's request to the appropriates host and port where the clients AppServer service is available.
Connections made through the AppServer Internet Adapter (AIA) pass through the Java Servlet Engine. The Java Servlet Engine reads the method request for connection and queries the NameServer for the AppService. The AIA passes the client's request to the appropriate AppServer Broker.
How the clients request is handled by the AppServer broker, once received from the client/AIA (client proxy) via the NameServer or as a direct connect to the AppServer broker, will depend on the mode of the AppServer. The operating mode determines how the AppServer will manage it's agent pool and assign requests to the AppServer Broker agents (servers).
The direct connection to the AppServer will bypass the use of UDP, the protocol used to talk with the NameServer, but will also eliminate the ability to load balance and to configure fault tolerance using multiple NameServers.
Communication flow for the modes StateReset & StateAware:
1. 4GL client connects to the AppServer broker using TCP/IP directly or using the hostname and port number received from the NameServer.
2. The broker checks the pool of available agents and returns a port of a free agent to the client.
3. The 4GL client disconnects from the broker and connects to the agent...then executes the coded run statement. Broker no longer involved.
4. _proapsv executes the requests ...once finished, the agent returns the data to the client.
5. The client will make a new run or disconnect the AppServer.
6. The client sends a disconnect to the agent, which in turn will send a message to the broker that it is ready for a new connection.
NOTE: The number of available simultaneous client connections in this mode corresponds to the number of agents that the AppServer can start up and manage at one time.
If all agents are busy, a new agent will be started on the next client request, or if the limit is reached , an error will be returned.
Communication flow for the mode Stateless:
1. 4GL client connects to the AppServer broker using TCP/IP directly or using the hostname and port number received from the NameServer.
2. Once connected it executes the coded run statement. The broker is fully involved with this mode.
3. Broker checks the pool of available agents and connects to one of them, sending the run request.
4. _proapsv executes the request and once finished it sends the results to broker and signals the broker that it's done.
5. The broker returns this information to the client and signals the end of the run request to the client.
6. The client accepts the results and continues by calling another run or by disconnecting from the AppServer.
TE dir=ltr style="MARGIN-RIGHT: 0px">
NOTE: If no agents are available, the broker will queue the client request. Best for short run requests. This mode scales better.
With the introduction of the Unified Broker, AdminServer and its associated files, Progress has supplied a larger number of log files that will provide information that is useful to monitor the health of the processes. Each log file will record specific information related to the startup and communication flow between the various pieces. Different levels of logging can be set to allow for additional information while troubleshooting a specific error. See the below references 18834 and P53220 relating to log files..