FWD » Core Development » Base Language

PASOE is a Tomcat based alternative to appserver which is simplifies/improves the design.

Instead of the appserver operating modes state-reset, state-aware, stateless and state-free there are these operating modes:

• session-managed (supposed to be similar to state-reset, state-aware)
• session-free (similar to stateless and state-free)

The appserver binary protocol (used by the Java and .NET Open Clients as well as 4GL clients) is not supported. Instead, all access is through some kind of HTTP/HTTPS protocol. This was possible in classic appserver using a separate web server along with installing "adapters" into that web server. Those adapters handled the appserver connectivity. In the new PASOE, these are now called "transports" and they are built-in.

• APSV - this provides direct appserver over HTTP/HTTPS (same as AIA or the appserver internet adapter)
• WEB - webspeed
• SOAP - maps SOAP calls to appserver invocations (same as WSA or the Web Services Adapter)
• REST - maps REST calls to appserver invocations

The agent approach is different. There is now a "multi-session agent" which can handle both operating modes at the same time and can handle multiple sessions in the same OS process. I suspect this is a kind of threading support where different sessions are run on different threads. It is related to the THREAD-SAFE option on the PROCEDURE statement and the attribute of the same name on the CALL handle object. Here is the doc on that attribute:

If TRUE, the specified DLL or shared library call is thread safe. When a DLL or shared library has been marked
as THREAD-SAFE, multiple sessions can access it simultaneously. The value of this attribute is ignored if the
LIBRARY attribute is not set or if the application is not running on an instance of the Progress Application
Server for OpenEdge.

It has the same meaning as an option.

Interestingly, we already have this multi-session design. One difference is that we in fact would not same the client processes for these sessions, so we need to discuss if there is a reason to implement changes.

• documentation how to configure and setup PASOE: multi-session agents, how to set the propath, working dir, how to configure the procedures: startup/shutdown, connect/disconnect, activate/deactivate, number of initial/min/max agents (can these be set for PASOE?), other configurations options, etc.
• testing how to connect to the PASOE agent (the CONNECT statement's syntax, for the first argument), and what errors can be shown if the connect fails.
• the procedures: startup/shutdown, connect/disconnect, activate/deactivate (including raised errors, QUIT, etc by these procedures), with bound/unbound session-managed/free modes. There are some cases where the procedure is ran persistent (like in case of connect procedure), so we need to identify where the program is ran persistent or not.
• what is the role of these attributes and how they behave: SERVER-CONNECTION-BOUND-REQUEST, SERVER-CONNECTION-BOUND, SERVER-CONNECTION-ID, SERVER-CONNECTION-CONTEXT, SERVER-OPERATING-MODE, CLIENT-TYPE
• determine the rules when a connection becomes bound - some details here, https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-migrate-develop%2Fmaking-a-connection-bound.html%23
• determine the rules when a connection becomes unbound - some details here, https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-migrate-develop%2Fmaking-a-connection-unbound.html%23
• behavior of the LOCAL-VERSION-INFO, REQUEST-INFO, RESPONSE-INFO, CURRENT-REQUEST-INFO, CURRENT-RESPONSE-INFO (and their associated 4GL classes, like Progress.Lang.OERequestInfo).
• examples how the SERVER-CONNECTION-ID is formatted (is it a generic UUID?)
• how raised conditions are handled and passed to the requester: STOP, QUIT, ERROR, ENDKEY, Progress.Lang.AppError and Progress.Lang.SysError
• running a remote program persistent, deleting a remote program, running in async mode, running internal procedures/functions in a remote program, RETURN-VALUE behavior
• passing of OO parameters to remote calls (testing for serializable classess); how data members are serialized (here it gets tricky, can you send an instance which has frames, temp-tables, buffers members, or the class definition must contain members of only some specific types?).

I assume non-OO parameters for RUN and other calls will behave the same as for classic AppServer. The testing should focus on the bound/unbound and session-managed/free, to determine how the Agent is bound to the connection and how its state is kept accross calls (use i.e. global and non-global shared vars which are set by a call, and subsequent calls will see - or not - these same values). This is important because we need to replicate the same rules.

Above should be for the APSV transport.

I'm not sure the REST/SOAP/WEB can be handled via the 4GL SERVER handle (and CONNECT statement) - these are specific to REST/SOAP services, right?

I'm not sure the REST/SOAP/WEB can be handled via the 4GL SERVER handle (and CONNECT statement) - these are specific to REST/SOAP services, right?

Yes, except that WEB can be used for more generic support. My impression is that it is a "handler" approach, similar to servlets. It is used for WebSpeed, but can be hooked to implement your own subclass of the handler that allows custom web processing. A do-it-yourself (DIY) REST transport is a good example.

From Marian:

Other than that the rest of the day was for setting up one PASOE instance for each and start deploying some REST services using the service mapper from PDSOE (Eclipse) which is the tool you're referring to in the Redmine task. To close the SOAP tests we will try to deploy the same services to this new PASOE instance and run them against it to check that we get the same result as when using the 'classical' application server.

Good.

Deployment for PASOE is easier when done from PDSOE, a bit of an adventure otherwise... do you have an application server available for this or how do you plan to run the tests?

We don't have one, but we do need configuration and instructions to set one up.

Or you don't really care about the Progress appsrv and the plan is to be able to somehow deploy the same artifacts on your FWD appsrv and come up with the same results?

Yes, we are planning to deploy the same artifacts in FWD OR we will process them during conversion into a better form that can be used in FWD.

Although we will mostly be testing using FWD, we do also need the ability to run the tests in the original PASOE environment, so the setup of that is definitely needed.

From Marian:

There is a bit of difference in how session managed/unmanaged modes works for the application server (classical) so I wonder if we need to test all those

Yes, I think so.

From Marian:

and if yes do we need to setup different instances or just change the session management mode and run the tests again?

Constantin: What do you think?

From Marian:

The new PASOE application server uses Spring security and depending how that is setup it might set a client-principal instance in the context - session management is done in Tomcat but then the appsrv makes sure on each request the client principal is loaded back so we know the current user on each request. This is quite a complex topic, the setup is not less complicated either so if we need to test something in that area it will help to know what use-case(s) we need to cover.

I'm not sure about this. In #3810 we are working on an intersecting set of features, including finishing CLIENT-PRINCIPAL. My best guess here is that we need to do enough to show the differences between the "generic 4GL usage" in #3810 and the usage that is possible via PASOE. I think this needs to be done for all transports (APSV, WEB, SOAP, REST) which can show this behavior.

Constantin Asofiei wrote:

A high-level plan on testing the PASOE behavior:

• documentation how to configure and setup PASOE: multi-session agents, how to set the propath, working dir, how to configure the procedures: startup/shutdown, connect/disconnect, activate/deactivate, number of initial/min/max agents (can these be set for PASOE?), other configurations options, etc.

For PASOE, as opposed to classical APPSRV, one application server instance can have multiple ABL Applications - each can have REST/SOAP/WEB sub-apps. Some configuration is global, most is at the ABL application level and some can be set for each sub-app. I did added the configuration for one of the PASOE instances we were using for tests in appsrv/config/fwd-pasoe. As for classical APPSRV each PASOE instance will have an entry in $DLC/properties/pasmgr.properties file but that one is just for the OE Explorer/Admin service to be able to find those instances.

Each instance have a separate folder where the PASOE (Tomcat) server is deployed - when adding a new PASOE server the skeleton is copied over from $DLC/servers/pasoe. When creating one instance is important to select the right mode - development/production, for production it is impossible to deploy code from PSDOE (remote) - aka Spring security is more strictly enforced.

A limited number of configuration options can be set through the OpenEdge Explorer - the web management interface - more advanced ones need to be set in various configuration files. For someone experienced with Tomcat/Spring like FWD team would probably be easier to find the way through all that than for the regular OpenEdge customers :)

• testing how to connect to the PASOE agent (the CONNECT statement's syntax, for the first argument), and what errors can be shown if the connect fails.

The same CONNECT statement is used from 4GL for both APPSRV and PASOE instances - the PASOE does (still) support the native APSV protocol. To connect using the WEB transport the -URL connect option can be used - same like for APPSRV when using AIA.

For errors, you mean what are the actual error number/messages for each cases when the connect can fail?

• the procedures: startup/shutdown, connect/disconnect, activate/deactivate (including raised errors, QUIT, etc by these procedures), with bound/unbound session-managed/free modes. There are some cases where the procedure is ran persistent (like in case of connect procedure), so we need to identify where the program is ran persistent or not.

The same 'hooks' as for the APPSRV are available in PASOE, the only difference is that there is also a notion of agent session - because each agent is not a multi-session agent. So we now have: startup/shutdown at agent level and startup/shutdown/activate/deactivate/connect/disconnect at session level. The only ones that are ran persistent are the one for startup.

• what is the role of these attributes and how they behave: SERVER-CONNECTION-BOUND-REQUEST, SERVER-CONNECTION-BOUND, SERVER-CONNECTION-ID, SERVER-CONNECTION-CONTEXT, SERVER-OPERATING-MODE, CLIENT-TYPE

We do have test procedures for those (get_connection_bound.p, get_connection_bound_request.p, set_connection_bound_request.p) - basically SERVER-CONNECTION-BOUND tells you if the agent you are running on is bound (for stateless), SERVER-CONNECTION-BOUND-REQUEST is read/write and can be used to ask for the agent to became bound/unbound - only works if SESSION:REMOTE is true (aka, running on the application server not on the client). When you use that to unbound the agent all remote persistent procedures in the agent are deleted (if any). For state-aware/state-reset those have no effect, for state-free when requesting to bound the agent a warning is issues (not an error condition) and the agent isn't bound since that is not possible with state-free anyway.

• determine the rules when a connection becomes bound - some details here, https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-migrate-develop%2Fmaking-a-connection-bound.html%23

Apart from running a remote procedure persistent it is not possible to request the agent to be bound using SERVER-CONNECTION-BOUND-REQUEST (set to true), see before.

• determine the rules when a connection becomes unbound - some details here, https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-migrate-develop%2Fmaking-a-connection-unbound.html%23

Deleting all remote persistent procedure handles or set the SERVER-CONNECTION-BOUND-REQUEST to false.

I was looking for some details on the support of the server-connection-context attribute is. I looked at the code, and it looks to be fully supported for conversion, and stubbed for runtime.

Marian, in PASOE, is the format for server-connection-id always abcdefghijklm_abcdefgh? (aka 13 chars, underscore, 8 chars)?

Some improvements are in 4231b rev 11490.

• versioninfo fields are read-only, but writing them is a runtime error and not compile error in FWD.
• oerequestinfo: adapterType requires enum, which is not supported by FWD yet
• agentId, sessionId, threadId: these are 'plugged in' but the Agent doesn't set the to anything (remain unknown).
• VersionInfo:clientType supports only 4GLCLIENT and APPSERVER at this time
• SESSION:CURRENT-REQUEST/RESPOSE-INFO don't know yet how this can be unknown or not
• some errors throw by SERVER:CONNECT are not the same
• argument translation to remote definition type I think is done the same as the CALL statement does it...
• OO instance serialization and transmission to remote side
• a QUIT on the remote side quits the client
• misc errors related to the ERROR, STOP, RETURN ERROR, raised by the remote side

I'll continue fixing some of them while I work on SOAP #3310

Is there any reason to leave this task open? As far as I understand it, all the remaining work is in #6417.

Greg Shah wrote:

Is there any reason to leave this task open? As far as I understand it, all the remaining work is in #6417.

It can be closed.