Deploying an EGL application by using the EGL deployment descriptor

The EGL deployment descriptor controls the details of deployment.
The deployment process is virtually automatic. To deploy an EGL application:
  1. Locate the EGL deployment descriptor for one of the application projects. The EGL deployment descriptor is in the EGLSource folder and has the file extension .egldd. By default, the base name is the same as the name of the current project.
  2. In the workbench, right click the deployment descriptor file name and click Deploy EGL Descriptor.

EGL then deploys the application automatically, based on information in the deployment descriptor.

Use the EGL deployment descriptor editor to change the deployment descriptor. To launch the editor, double click the deployment descriptor file.

The following sections describe the information that you need to complete each page of the EGL deployment descriptor.

Overview

The overview page shows the Target Name, which is the name of the Web Project to which you want to deploy your handlers and services. In addition, the overview page summarizes the information from the other pages of the file, and provides links to those pages. Typically, you deploy all the handlers and services in a project to the same target. If you need to deploy some handlers or services to a separate target, create an additional EGL deployment descriptor. You can create an additional deployment descriptor by right-clicking the project name and clicking New > Deployment Descriptor.

Service Deployment

After you code an EGL Service part to expose as a Web service, you must add information to the deployment descriptor that EGL uses to generate the necessary Web service wrapper. For more information, see Adding Web service deployment information to the deployment descriptor.

EGL Rich UI Deployment

An EGL project typically contains a complete application, which can consist of multiple Rich UI Handlers. You can only deploy Rich UI Handlers from a single project at a time. On the EGL Rich UI Deployment page, you can select the Rich UI Handlers that you want to deploy together.

The page displays all available Handlers. By default, the Deploy all Rich UI Handlers checkbox is selected. If you clear the Deploy all Rich UI Handlers checkbox, additional buttons are available to Enable All Handlers in the list or Disable All Handlers. You can also click the Open button to open a Handler in the EGL editor.

Service client bindings

Service client bindings give the client of a service the information it needs to access that service. You can either enter that information here, or provide it in a complex property that is associated with the declaration of the Service or Interface part. The @RESTBinding complex property contains binding information for REST services, and the @WebBinding complex property contains binding information for SOAP services. Both properties bind the associated service at generation time.

If the Service or Interface part includes the @bindService complex property instead of @RESTBinding or @WebBinding, EGL uses the deployment descriptor for binding information at run time.

If you use the deployment descriptor for service client binding, the information that you need depends on the type of service that you access:
SOAP Web Binding
A simple object access protocol (SOAP) service typically uses HTTP for transmission and XML for its message format. A SOAP service always uses a Web Services Description Language (WSDL) file as an interface to the client. To access a SOAP service, you need the following information:
  • The name of a WSDL file in your workspace
  • An EGL Interface part to use with the service
  • A Web Binding Name, which must match the value of the bindingKey property field of the @bindService complex property for the associated service
  • A WSDL URI, if you want to override the WSDL file name; for example, if you need a different version of the service for production or testing
REST Web Binding
In EGL, a representational state transfer (REST) service provides a single unit of business data for each request. Requests specify a uniform resource identifier (URI), typically a base URL for a Web site, which is followed by qualifiers for the requested data. For example, the URI www.example.com/employee/123 requests data for an employee with the number 123. REST services do not use WSDL files. To access a REST service, you need the following information:
  • A REST Binding Name, which must match the value of the bindingKey property field of the @bindService complex property for the associated service.
  • A Base URI that qualifiers are added to.
  • A Session Cookie ID that you use to keep a session open with the host for the service. The default value is JSESSIONID, which is always the session ID when your application runs on Apache Tomcat.
EGL Binding
An EGL service is based on an EGL Service part. The service might be local to your server or accessible through one of several standard protocols. To access an EGL service, you need the following information:
  • An EGL Binding Name, which must match the value of the bindingKey property field of the @bindService complex property for the associated service
  • A Service Name, which is the name of the EGL Service part
  • An alias, if the Service part uses one
  • A protocol type. If the EGL service is not local, you can either choose one of the listed protocols, or click Choose from protocols to display a list of available options.
Native binding
You can use this binding to access a System i® service program. To access a System i service, you need the following information:
  • A Native Binding Name, which must match the value of the bindingKey property field of the @bindService complex property for the associated service
  • A protocol type. You can either choose one of the listed protocols, or click Choose from protocols to display a list of available options.

Protocols

Shared protocols are reusable definitions of a service connection that you can apply to one or more of the entries in an EGL deployment descriptor file. For more information, see Creating and using a sharable protocol.


Feedback