The classic AppServer is a multi-instance architecture where the OpenEdge installation contains the core AppServer libraries, configuration files, and other support files. You created and manage an instance using one of the AppServer administration tools, such as OpenEdge Management or the propmerge command-line tool. Each instance has its own configuration and represents one ABL application (identified by a set of configuration files, r-code files, configuration procedures, and AppServer brokers and agents). You may not have thought of it this way, but the template AppServers asbroker1, restbroker1, and others are in fact classic AppServer instances supplied as development examples. Actual deployed ABL applications do not typically use those development instances.
PAS for OpenEdge also works with instances but with a difference. The PAS for OpenEdge core server is still located in the OpenEdge installation under the $DLC/servers/pasoe directory. It contains the shared libraries, utilities, and default templates used by instances. Unlike the classic AppServer, however, the majority of PAS for OpenEdge libraries, configuration files, default applications, and so forth are contained within the instance itself, rather than being scattered throughout the OpenEdge installation directory tree.
A PAS for OpenEdge configuration is divided between the core Progress Application Server, common to all Progress Web products, and the OpenEdge product that is deployed into it. The command-line utility for managing PAS for OpenEdge instances is TCMAN, which supports a wide variety of operations that range from creating, configuring, and deleting an instance to controlling the deployment of OE ABL Web applications (and other Web applications) contained within an instance. For more information on TCMAN, see the Progress Application Server for OpenEdge: Administration Guide. OpenEdge Management also supports some offline operation of a PAS for OpenEdge instance through TCMAN. For more information, see OpenEdge Management: Progress Application Server for OpenEdge Configuration.
Configuration of ABL applications is managed through the following command-line utilities, which are in the instance's bin directory:
oeprops — A command-line utility for secure installations that allows direct manipulation of the conf/openedge.properties file in the same general way the mergeprops utility manipulates the classic AppServer's ubroker.properties file.
deploySOAP — A command-line utility for secure installations that allows the incremental deployment of a SOAP description (.wsm) file to an ABL application's OE ABL Web application, much like the WSAMAN utility does for the classic Web Services Adapter (WSA).
deployREST — A command-line utility for secure installations that allows the incremental deployment of a REST service description (.paar) file to an ABL application's OE ABL Web application, much like the RESTMAN utility does for classic OpenEdge REST Web applications.
Configuration of ABL applications can optionally be managed through the REST APIs of the OpenEdge Manager Web application (oemanager.war) in unsecured installations on a PAS for OpenEdge development server.
Caution: Do not use remote Web application management applications such as Tomcat's manager.war or OpenEdge's oemanager.war in a secure Internet Web server installation such as a PAS for OpenEdge production server.
The OpenEdge Manager uses the REST APIs to perform on-line administration of ABL applications and their attending Web applications, transports, the session manager, and multi-session agents. The OpenEdge Manager REST APIs are open and available for OpenEdge developers to use them in their own management tools. For more information these REST APIs, see the Progress Application Server for OpenEdge: Administration Guide
Like the classic AppServer, everything starts with creating a PAS for OpenEdge instance. In a PAS for OpenEdge development server installation, a sample instance is provided for you in the installation's $WRKDIR location. This sample instance is defined in the openedge.properties configuration file with the ABL application name oepas1. Within oepas1, is the default OE ABL Web application deployed as /webapps/ROOT. You can incrementally deploy SOAP and REST Web services, and connect OpenEdge clients to this default OE ABL Web application. You can also create your own OE ABL Web application and add it to the oepas1 ABL application.
The following set of tasks compare the creation of instances for the classic OpenEdge AppServer and PAS for OpenEdge.
The general set of steps for creating an instance in the classic production AppServer is:
1. Create the instance and give it a name.
2. Deploy .p and/or .r files.
3. Configure the classic AppServer instance (which implicitly defines an ABL application).
4. Optionally deploy a Web server and install Adapters, for example:
a. Download and install Tomcat.
b. Configure Tomcat.
c. Optionally change Tomcat's debug configuration to a secure production type.
a. Optionally install and configure an AIA adapter Web application.
b. Optionally install and configure a WSA Web application, and deploy and configure zero or more SOAP Web service descriptors (.wsm files).
c. Optionally install and configure a REST Web application (exported from PDSOE), and incrementally deploy zero or more REST Web service definitions (.paar files).
When the PAS for OpenEdge production server product is installed, no default sample instance is installed for security reasons. Therefore, you follow this sequence of steps:
1. Create the PAS for OpenEdge instance and give it a name (which implicitly defines an ABL application with the instance's name ).
2. Configure the instance's core [Tomcat] server.
3. Deploy .r files (.p files cannot be compiled on a PAS for OpenEdge production server).
4. Deploy the ABL application's OE ABL Web application (one or more).
5. Configure the ABL application and its components:
a. ABL session manager and multi-session agents
b. For each deployed OE ABL Web application:
a. Configure the APSV transport (enable or disable).
b. Configure the SOAP transport (enable or disable), and incrementally deploy and configure zero or more SOAP Web service descriptors (.wsm files).
c. Configure the REST transport (enable or disable), and incrementally deploy and configure zero or more REST Web service definitions (.paar files).
oeprops — A command-line utility for secure installations that allows direct manipulation of the conf/openedge.properties file in the same general way the mergeprops utility manipulates the classic AppServer's ubroker.properties file.