EGL provides two kinds of support for service-oriented architecture (SOA): service development and service access.
Service MyServicePart value STRING = "Hello, "; function myEcho(myString STRING IN) returns (STRING) return (value + myString + "!"); end end
The content of the Service part is the service implementation. In this case, the implementation accepts an input string such as “world” and returns to the requester the concatenation of “Hello,” the input string, and an exclamation point. You can make several functions, or service operations, accessible to service requesters.
If an EGL binary service is deployed with a Rich UI application, the service is known as a dedicated service, which means that the service is deployed with the Rich UI application. Only that application has access to the service logic, which is generated to Java and is local to the Rich UI proxy. This usage is convenient because you do not need to be aware of a separate address for service access.
An EGL REST-RPC service access always uses a POST method, but that detail is hidden to the requester. For other details that are meaningful when you access an EGL REST-RPC service from logic written in another language, see “EGL REST-RPC message structure.”
In a Rich UI application, the EGL runtime code rounds any numeric data that is returned by the service and is greater than 15 significant digits. The rounding does not occur when JSON is returned to EGL-generated Java™ code.
At this writing, you can neither develop nor access SOAP services.
Access to a generated service always conforms to the RPC style rather than to the RESTful style. The parameters and a return value identify the data to exchange. Access to the service does not involve path variables or query parameters.
Service access typically requires that you specify a resource binding in the EGL deployment descriptor. The binding in this case is called a service binding. You can update the binding and redeploy your code, without updating and regenerating the requester.
The runtime architecture for all EGL web service deployments has the same pattern: generated or runtime code acts as an intermediary between the requester and the service. The intermediary code converts data between the text-based format of a service message and the binary format required by the service.
The runtime platform is an application server that is compliant with Java EE. There, the EGL runtime code reads the XML file, invokes the service, and acts as an intermediary between the requester and service.
The runtime platform is an application server that is compliant with Java EE. The application server invokes the service wrapper, which in turn invokes the service and acts as the intermediary between the requester and service. The service wrapper and service are local to one another.
At this writing, you can neither develop nor access SOAP services.
Service access from an EGL-generated requester has a consistent pattern: a proxy acts as an intermediary between the generated requester and the service. The generated requester might be an EGL proxy function, which is different from the proxy being described in this section
The proxy converts data between the format used by the requester and the format required by the service. The next table gives further details, by service type.
Characteristic of the requested service | Characteristic of the deployed requester | Characteristic of the proxy |
---|---|---|
dedicated EGL | An HTML file that embeds JavaScript™ | The proxy is in the EGL runtime code and invokes the service locally, without an HTTP request. |
local EGL: not yet available. | EGL-generated Java code | No proxy is in use. |
remote EGL: not yet available. | EGL-generated Java code | The proxy is in the EGL runtime code. |
EGL REST-RPC: available only from JavaScript. | EGL-generated Java code or an HTML file that embeds JavaScript | The proxy is in the EGL runtime code. |
REST available only from JavaScript | EGL-generated Java code or an HTML file that embeds JavaScript | The proxy is in the EGL runtime code. |
SOAP: not yet available. | EGL-generated Java code or an HTML file that embeds JavaScript and that is deployed on an application server that is fully compliant with Java EE, such as IBM® WebSphere® Application Server | The proxy is a Java class that is generated from the requester-specific deployment descriptor. |
An EGL-generated Java code or an HTML file that embeds JavaScript and that is deployed on any other platform | The proxy is in the EGL runtime code. | |
Another aspect of service access is the location of service-binding detail. For all EGL-generated requesters, the detail is in an XML file that is generated from the requester-specific deployment descriptor and that is deployed with the requester.
Access of web services always involves the HTTP protocol, but other protocols are used for accessing EGL binary services.