The EGL deployment descriptor controls the details of deployment.
The deployment process is virtually automatic. To deploy an EGL
application:
- 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.
- 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 .
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.