Each PAS for OpenEdge instance configuration contains a default web application called ROOT. The ROOT application is a starting point for deploying new services. For simple services and early development, you can deploy artifacts to ROOT and then create a ZIP file of the entire instance to easily share it with others, or create an OpenEdge Application Archive of the ABL application which contains the ROOT web application. For some applications, this may be all that is required. As your services evolve, you can create your own web applications that group related services into separate deployment packages for security or user permissions reasons.

Deploy services to the existing web application, ROOT, or generate a PAS for OpenEdge web application from Progress Developer Studio that is deployed outside of ROOT. If you want to replace ROOT with another web application, then undeploy ROOT, and deploy the web application that does what you want when a client makes a request to your server with no path specified. This can be a login page, a redirect, or something else, depending on your needs.

This topic focuses on deploying services to the ABL web application, ROOT.

You can deploy the following artifacts to a PAS for OpenEdge instance:

  • Individual SOAP service descriptors (.wsm files) to an existing ABL web application.
  • Individual REST service definitions (.paar files) to an existing ABL web application.
  • ABL and WebHandler services to an existing ABL web application.
  • One or more new ABL web applications and their services as a .war file.
  • An ABL application as an OpenEdge Application Archive, which contains ABL web applications and services.

System administrators can deploy an ABL application as one or more ABL web applications:

  • Deploy a single ABL web application by packaging it in one .war file that follows the standard web application directory structure. For improved performance and resource consumption, deploy an ABL application using an ABL web application—making the full application accessible from a single server URL.
  • There are situations where deploying an ABL application as multiple ABL web applications (where the application is accessible across multiple server URLs) is desirable. Because using multiple ABL web applications slows performance and consumes more OS process resources, use this approach only when your ABL web application is designed as a set of discrete, individually deployed, services where the ABL web application encapsulates a "service set" within your ABL application.
The standard directory structure for a web application is:
  • instance-name/webapps/webapp-name—This directory is the root directory for the application by default. The root directory contains the /WEB-INF folder, and any files that are visible to the client browser, like HTML and JSP pages. These files can be organized into a subdirectory for more complicated applications.
  • instance-name/webapps/webapp-name/WEB-INF—This folder contains the web application deployment descriptor (web.xml) that contains the configuration information for the application in a standard format.

When deploying ABL web applications, you can pre-deploy and configure transports. This content focuses on deploying services to the existing ROOT application. You also have the option of deploying the SOAP, REST, and APSV service interface API .r files as part of each web application WEB-INF/openedge directory. If you optionally embed .r modules in the web application, then you ensure that the version of the transport interfaces remains consistent with their transport (URI) definitions. You may need to change the PROPATH of the ABL application to include WEB-INF/openedge path of the ABL web application.