EGL provides two kinds of support for service-oriented architecture (SOA): service development and service access.
For a more basic introduction, see [insert reference for “Service-oriented architecture (SOA) for EGL developers,” an essay that is going on a web site. Remove the section there on “Location of an EGL-generated service.”]
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 service is deployed with a Rich UI application, the service is identified as a dedicated service, which means that the Rich UI application has access to the service logic without referencing a service binding. 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.
Neither development nor access of SOAP services is available in version .7
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.
For services as for SQL, a resource binding has a type. For example, the type for REST or REST-RPC services is HttpRest.
myService IMyService?{@Resource{bindingKey = "myBinding"}};
The Resource annotation causes the variable named myService to reference the HTTPRest object named myBinding, which has values that you specified in the EGL deployment descriptor. If you do not specify the bindingKey field in the annotation, the EGL runtime code accesses those values from the binding entry that is named for the variable.
If you are accessing a service that was written in EGL, you do not need to create an Interface part, but can use the Service part as if it were an Interface part. However, your use of a separate Interface part lets you avoid distributing a service implementation to another developer. You might avoid distributing the implementation if it is changeable or confidential.
myService IMyService?{ @Resource{bindingKey = "myBinding", propertyFileName = "myDeploymentDescriptor"}};
If you do not reference the propertyFileName annotation field, its value is the name of the EGL deployment descriptor that is used at deployment time.
When you set the propertyFileName annotation field, do not include a file extension. The name of the file that is accessed at run time includes the following suffix: -bind.xml.
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.
Neither development nor access of SOAP services is available in version .7
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 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 available in version .7. | EGL-generated Java code | No proxy is in use. |
remote EGL: not available in version .7. | EGL-generated Java code | The proxy is in the EGL runtime code. |
EGL REST-RPC: available in version .7 only from JavaScript. | EGL-generated Java code or an HTML file that embeds JavaScript | The proxy is in the EGL runtime code. |
REST available in version .7 only from JavaScript | EGL-generated Java code or an HTML file that embeds JavaScript | The proxy is in the EGL runtime code. |
SOAP: not available in version .7. | 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 services.