EGL Development User Group - Group home

As the lead for RBD service development, the question I dread the most is "which is better SOAP or REST services?".  That question is similar to asking what color is the sky. If you ask 10 people and you will get 12 different answers, and the answers vary depending on the direction the wind is blowing that day.

The main factors you need to keep in the forefront are: what is the application I'm developing, what is the production environment, and what are the controlling corporate standards that the application must be deployed into. This blog is the beginning of a series I'll write on the topic of how we implement SOAP and REST in RBD. My goal is not to explain the technology, there are plenty of web sites that can explain JAX-RPC, JAX-WS, REST and compare and contrast. My goal is to explain how we implement the technologies in RBD. With this information you can make a better decision to the "SOAP or REST?" question.

As of RBD 8011 the following are supported, the newest being JAX-WS WSDL SOAP (added in 8011):

	JAX-WS WSDL SOAP	JAX-WS RPC SOAP	EGL REST RPC	REST	WSDL SOAP
Services:
WebSphere
Tomcat
CICS COBOL
IBM i COBOL
Service invocations:
WebSphere
Tomcat
CICS COBOL
IBM i COBOL
Java
JavaScript

Each of the above WSDL SOAP implementations use a runtime component that is not developed by the RBD team.
With all of the variations there is a lot to talk about! Today's topic will be a basic web service and web service invocation overview.  First, we'll look at the heart of all EGL web services -- an  EGL service part. An EGL service part contains the business logic you write which gets generated to the generation target language just like any other part like programs, libraries etc.


This diagram shows the anatomy of a deployed EGL web service.

1. The HTTP Request is received by the application server.
   
2. The request is converted into application server specific data.
3. The application server calls the web service wrapper.
4. The wrapper converts the application server specific data to EGL runtime data.
5. The EGL service is called passing the EGL runtime data.
6. The EGL service executes the coded logic.
   
7. The EGL service returns.
8. The web service wrapper converts the EGL runtime data back to application server specific data.
   
9. The wrapper returns.
   
10. The application server converts the data to an HTTP response.

An EGL service is exposed as a SOAP or REST endpoint by editing the EGL deployment descriptor (.egldd file) and choosing SOAP, EGL REST RPC, or both. When the .egldd file is deployed or generated, we generate the wrapper code and configure the application server container for each service. Configuration of the container tells the application server to listen for an HTTP request on a specific URL and what logic to invoke after the request is converted to data. The specifics are different for each server, but concepts are the same for all web services and application servers.



This diagram provides the anatomy of an EGL service invocation request.
In the EGL code:

1. An EGL service invocation is variable declaration where the type is an interface or service.
2. The declaration must then be bound to a runtime service technology like SOAP or REST.
   The binding information can be provided by creating service bindings in the .egldd file or by coding specific inline bindings like @WebBinding or @RESTBinding. This information is generated into a runtime file that is read and provides the proxy information.
   
3. The service is invoked.
   This can be synchronous for Java and COBOL generation or asynchronous for JavaScript generation. Synchronous looks just like a function invocation and asynchronous uses a call statement with a returning to.
   

The runtime request:

1. The request is initiated by EGL by instantiating a proxy based on the service binding ie, SOAP service, REST service.
   
2. The proxy converts the EGL runtime data to the runtime specific data.
   
3. The proxy invokes a service runtime component.
   
4. The service runtime creates an HTTP request.
   
5. The service runtime invokes the service.
   
6. The service returns.
7. The service runtime decodes the data from the HTTP response.
   
8. The proxy then converts the service runtime data back to EGL runtime types.
   
9. The proxy returns.
   

In up-coming blogs, I'll discuss JAX-RPC SOAP for Java, Tomcat and WebSphere, EGL REST RPC service, and JAX-WS SOAP for Java, Tomcat and WebSphere.  Let me know what service topics you'd like to hear about!

Joe Vincens