IBM Business Developer (RBD) provides business developers with an integrated environment to develop Enterprise Generation Language (EGL) applications, which are generated into COBOL, Java, and JavaScript applications. The developers work only with EGL to develop their applications. Thus, RBD takes away the complexity of working with multiple technologies and frameworks, while maintaining uniformity at the same time.

IBM Business Developer (RBD) supports Windows, Linux, Mac OS, z/OS, z/VSE, and IBM i target platforms. The scenarios described in this paper explain how to handle different requirements for these target platforms.

Prerequisites

• IBM Business Developer (RBD)
• Knowledge of developing using EGL and RBD
• Knowledge of generating and deploying applications to the target platform

Scenario 1: RUI – Java Web Service – Data Access

As an IBM Business Developer user, following are the scenario expectations:

• I want to rapidly create lightweight rich UI pages that can be accessed from different browsers.
• I want to quickly create a dedicated EGL service or a Web service (REST/ SOAP) and deploy it on a server like IBM WebSphere Application Server (WAS) or Apache Tomcat, running on Linux/Windows/Mac OS environment.
• My database (optionally) is also located in the Linux/ Windows/ Mac OS environment. I want to access the database from my application through the services.

Figure-1 shows a high-level deployment architecture of Scenario-1 described. This is a simple and powerful case of a modern SOA application with a UI, a Web Service, and a DB, which are located on a target server, for example, Tomcat on Linux. All are developed using EGL and then generated into code for the target platform.

This scenario is an example of how EGL-generated SOA architecture applications can be robust and flexible. For example, after 5 years, if there is a need to re-develop the GUI with a different framework that supports responsive design to adapt to mobile devices; it could be easily done using an EGL RUI. However, there is no need to change anything on the Web Services and the business logic can remain intact.

                                                              Figure-1: RUI – Java Web Service – Data Access

Scenario 2: RUI – Java Web Service – Remote Data Access

As an IBM Business Developer user, following are the scenario expectations:

• I want my application to have a Rich UI and the services as described in scenario 1.
• My database (optionally) is located on the z/OS, z/VSE, or the IBM iSeries environment. I want to access the remote database from my application through the services.

This scenario describes access to a remote database located on, say, z/OS. Figure 2 shows a high-level deployment architecture for scenario 2.

                                                              Figure-2: RUI – Java Web Service – Remote Data Access

Scenario 3: RUI – COBOL programs – Remote Data Access

As an IBM Business Developer user, following are the scenario expectations:

• I want my application to have a Rich UI as described in scenario 1.
• I want to keep the application business logic in mainframes/AS400 as native COBOL programs and call those programs from EGL-generated Java Web services.
• My database (optionally) is located on the z/OS, z/VSE, or the IBM iSeries environment. I want to access the remote database from my application through the COBOL programs.

Figure 3 shows a scenario where the COBOL programs contain the business logic on the z/OS or z/VSE or IBM i servers. For example, this deployment architecture is recommended when it is necessary to keep these COBOL programs intact and the GUI needs to be on a Tomcat server on Linux.

The GUI is a modern Rich UI application which calls wrapper Web service that in turn calls the COBOL programs. This model provides the user with the flexibility of keeping the core functionality as-is, thus avoiding regressions while the user gets the benefit of a modern evolved GUI.              

                                                              Figure-3: RUI – COBOL programs – Remote Data Access

Scenario 4: RUI – Hybrid of Java Web Service and COBOL Program – Remote Data Access

As an IBM Business Developer user, following are the scenario expectations:

• I want my application to have a Rich UI as described in scenario 1.
• I want to keep a part of my application business logic in mainframes/AS400 as native COBOL programs and call those programs from EGL-generated Java Web services.
• I also want to create Java Web Services which can access the data directly from mainframes/AS400 and the EGL-generated SOAP/REST web service contains a part of my application business logic.
• My database (optionally) is located on the z/OS, z/VSE, or the IBM iSeries environment. I want to access the remote database from my application through the COBOL programs or Java Web Services or both.

This scenario describes a hybrid between scenario 3 and scenario 2. It demonstrates a migration from COBOL programs to Java Web Services partly, while keeping the data on z/OS.    

                                                                        Figure-4: RUI – Hybrid of Java Web Service and COBOL Program – Remote Data Access

Scenario 5: RUI – COBOL Program/ Lib Services – Remote Data Access

As an IBM Business Developer user, following are the scenario expectations:

• I want my application to have a Rich UI as described in scenario 1.
• I want to keep the application business logic in mainframes z/OS as CICS COBOL Web Services and call those services from an EGL Rich UI or other EGL Services, using SOAP.
• My database (optionally) is located on the z/OS environment.

Figure 5 describes a scenario where the client makes a SOAP request from a web browser, running a RUI web page. The flow of request is as follows:

1. The request is sent to CICS web service runtime. It processes the URL, reads the web service definitions, and refers to the WSDL and WSBIND files from HFS. WSDL file provides the web service definitions and the WSBIND file provides the information to convert XML to Binary data.
2. EGL COBOL web service proxy reads the data from the containers and calls the COBOL program.
3. COBOL program runs and returns to the proxy, which returns the data in containers to CICS web service runtime.
4. The SOAP response message is sent back to the web browser.

                                                                        Figure-5: RUI – COBOL Program/Lib Services – Remote Data Access

Scenario 6: External Web Service invocation from EGL COBOL Programs/Services

As an IBM Business Developer user, following are the scenario expectations:

• I want my application to have a Rich UI as described in scenario 1.
• I want to keep a part of the application business logic in mainframes z/OS as CICS COBOL Web Services and enable those services to call a third-party web service (SOAP/REST) or other EGL CICS web services (SOAP) or a local EGL COBOL service.
• My database (optionally) is located on the z/OS environment.

Figure 6 shows a call made to third-party SOAP services from an EGL COBOL program that is running in CICS on z/OS. The flow is as follows:

1. COBOL program invokes an external web service.
2. COBOL binding program is invoked to create a service object. As and when an external web service is called, an EGL COBOL web service proxy is also called.
3. Proxy puts the data in a container and calls the CICS web service runtime, which uses the right WSBIND file to convert the data to XML.
4. The correct third-party web service is called using SOAP; it returns with the SOAP message, which is sent back to the COBOL program.

                                                              Figure-6: External Web Service invocation from EGL COBOL Programs/Services

Figure 7 shows calls from an EGL COBOL program to a local EGL COBOL service. In this case, the proxy is not involved. The COBOL binding program is called to create a service object and it directly invokes the EGL COBOL service.                       

                                                                        Figure-7: Invocation of  EGL COBOL Programs/Services Without Using Proxy