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 zip the entire instance to easily share it with others. For some applications this may be all that is required. As your services evolve, you may choose to create your own web applications which 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 wish to replace ROOT with another web application, undeploy ROOT and deploy the web application that does what you require when a client hits your server with no path specified. This can be a login page, a redirect, or something else depending on what you require.

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

This topic describes how to:
  • Deploy services
  • Deploy web applications

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.

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. Since 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 ), which 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. Using the optional embedding of .r modules in the web application, 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 includeWEB-INF/openedge path of the ABL web application.