学步园

Introduction

The other day I was on the subway in Boston and couldn’t help but notice the number of people that were using some kind of smart phone. Some were playing games, some were connecting to the Internet, and others were doing still other things using their mobile devices. While there is plenty of attention and mindshare today working on bringing these new electronic devices together with the latest applications, there is also a need to look back and build a bridge that can bring existing z/OS applications to those devices.

This article will show you how you can easily create a Web 2.0 application that reuses an existing z/OS application using IBM® Rational® software products. Following the concepts demonstrated here, you’ll be able to create a Web 2.0 client that invokes a CICS/COBOL application running on a System z mainframe, transformed into SOAP Web services. Although the example in this article uses COBOL and CICS, the same principles and technology can be applied to PL/I or IMS, RPG with System i, as well SOAP or RESTful Web services.

This article describes how to build the Web 2.0 portion of this scenario. However, the entire sample application that results from these steps is included with this file for download. This sample code has been tested using an Apple iPhone. You can also test it with other smart phones with browsers that support JavaScript™, such as Apple Safari, Microsoft® Internet Explorer, Mozilla Firefox, Opera MinI, and others.

Before and after

Before you see how to build a Web 2.0 application that can access a mainframe application, let's take a quick look at the "before" (the z/OS application) and the "after" (the Web 2.0 application) so you can see where you're starting and where you are going.

This scenario used in this article assumes you have an existing CICS/COBOL application. The sample application described here will access a simple IBM demo application that retrieves fictional customer information.

Figure 1 show the traditional 3270 screen (the “before”) for the Client Inquiry demo application, which displays data retrieved from a VSAM data set. In this typical application, the user enters a valid customer number and then presses Enter. Data retrieved from a VSAM data set is used to populate the fields on the 3270 panel..

Figure 1. Existing COBOL/CICS application 3270 map interface

Figure 2 shows the high level architecture of this application. Basically, there are two components:

• The COBOL client component that displays the 3270 map.
• The COBOL server component that accesses the VSAM data set.

The communication between the client and the server components is achieved via the CICS COMMAREA.

Figure 2. Existing COBOL/CICS application

The objective, then, is to access this back-end data through this CICS/COBOL application running on z/OS, but to do so using an iPhone. The actual CICS/COBOL application will not change, but because you want to access it through an iPhone, you have the opportunity to create a much better interface for it. To give you an idea of the kinds of things you can do for an improved interface, the sample application here will use the popular Google Maps Web service for this purpose.

Figure 3 shows the new interface (the “after”) as displayed on an iPhone. The z/OS application returned customer address information, but Google Maps takes it a step further by actually literally showing you where the customer is located. This, of course, would be impossible on a 3270 screen.

Figure 3. The new interface for the z/OS application using an iPhone

Start with good code

Before you begin any implementation, you must be sure that the pieces you are starting with perform well. In this case, you want to be familiar with the operation of the mainframe application, at least with respect to results and performance. That way, you will know if your results are correct, and you will verify the response times.

One of the general advantages of 3270 CICS applications is their excellent response time. However, sometimes a new technology might enable a very nice solution, but then poor response time becomes a roadblock to its implementation. This should always be a primary concern. To measure response time of the z/OS application, a simple routine was used to start counting when the CICS Web service was invoked and then stop counting when the data was returned. Happily, the response time was less than half a second, which alleviated concerns about the demo application. (All the XML parsing in this example was done by COBOL.)

Figure 4 shows the response time to invoke the CICS COBOL demo application from the Web 2.0 client. In this example, the response time for this service invocation was 0.140 seconds. Impressive! (You can check yourself by clicking on the green check mark icon in the Web 2.0 interface.)

Figure 4. Response time to invoke the SOAP CICS Web service

Be aware that the time required to load the client HTML and JavaScript were not considered in this example and at this point still need to be tuned. There are ways to compact the data sent to the browser in order to make it perform better, but the more important measurement in this case was the total response time to go to z/OS, execute the SOAP XML parsing, invoke the CICS/COBOL application, get the VSAM data, and then return to the Web client.

Creating a Web 2.0 iPhone application for a CICS/COBOL application

The next sections describe the process for building the sample Web 2.0 application included with this article. The process is made up of three major steps:

1. Create the CICS Web service provider
2. Create the Web 2.0 service requester (user interface)
3. Extend the Web 2.0 code to invoke Google Maps service

To follow the actual steps described here, you will need access to IBM Rational Developer for System z with EGL V7.5 (or later). If you have IBM Rational Business Developer only, or another Rational software product that contains EGL, you can follow the steps from section 2 forward.

This article assumes familiarity with Eclipse and the concept of perspectives and views. The Rational products mentioned above include tutorials to help you to become familiar with related terms and concepts, and so you do not need to be very experienced to follow along. A general understanding of mainframe terminology and Web 2.0 concepts is also helpful.

Back to top

1. Create the CICS Web service provider

In this first step, the COBOL client program and the 3270 map screens (shown in Figure 2) are eliminated and the server CICS/COBOL code is wrapped as a CICS service and represented by the WSDL (Web Serviced Description Language). This step is key in the transformation of your application. Figure 5 shows the topology of this transformation,

Figure 5. Eliminating 3270 map and COBOL client for WSDL

This is the simplest part of the entire process, and it's made even easier by using CICS utilities. If you use Rational Developer for System z (hereafter referred to as Rational Developer), you can also easily test the service that gets created. There are many tutorials that explain how to perform this task, and so the detailed steps will not be repeated here. Basically, though, you will apply the Rational Developer Enterprise Service wizards to the CICS/COBOL program and the wizards will generate a CICS SOAP Web service and the WSDL. The code can also be deployed into CICS also using Rational Developer facilities.

Figure 6 shows the CICS DFHCOMMAREA used to invoke the CICS/COBOL program. The customer number value that is entered by the user is moved to the CustNo field. The data that is retrieved from the VSAM dataset is sent back in the remaining fields.

Figure 6. CICS/COBOL program DFHCOMMAREA

Remember, the Web service is created, deployed, and tested using Rational Developer without affecting the existing CICS/COBOL application.

Figure 7 shows the WSDL generated by Rational Developer. The input message is CustNo and that the output message the whole DFHCOMMAREA.

Figure 7. WSDL generated by Rational Developer wizards

The generated code is deployed to your CICS using Rational Developer. Even the new CICS resources that need to be configured in CICS can be created using Rational Developer V7.5 or later. A new CICS Explorer perspective makes this task very simple.

After the compilations on z/OS and the creation of the CICS resources, you should test the CICS service created. For the purpopse of this article, this service is already deployed on our z/OS demo system and you can test it using the Rational Developer Web Services Explorer. The Web Services Explorer uses a Web browser as an interface to enable you to test a simple Web invocation. Point the Web Services Explorer to this URL: http://zserveros.demos.ibm.com:9046/wdz/LAB3POT and make sure the CICS service is running as it should (Figure 8):

1. Right click on CUSTINQ.wsdl in the Generation/Targets folder and select Web Services => Test with Web Services Explorer.
2. Click on LAB3POTOperation, then enter a valid customer number (for example, 4), then click Go. This is the WSDL that you will use for the Web 2.0 page creation.

You need to have a successful test before you can continue. In this example, the CICS service is deployed into a mainframe that is listening on port 9046. Be sure that there are no firewalls blocking your connection. If you receive no data or have other errors, correct the problem and retest before you proceed. If the CICS system is down (for example, for maintenance) you will need to try another time.

Figure 8. Invoke the CICS Web service with the Web Services Explorer

Using the sample application

Describing the process of creating the WSDL and other components is beyond the scope of this article. For details on how to perform this activity, refer to the article Wrap existing COBOL programs as Web Services with IBM Rational Developer.

However, you can fast-track this activity if you have Rational Developer installed by importing the Project Interchange file and related assets, including the WSDL, included with this article. (See About the download for information about the sample materials provided with this article.) To import the project into Rational Developer:

1. Download the .zip file that accompanies this article and extract the contents.
2. Start Rational Developer pointing to an empty workspace.
3. Select File => Import... => Other => Project Interchange => Next.
4. Point to the extracted CICS_Services_Project.zip file, select All and click Finish.
5. You must open the Enterprise Service Tools perspective to see what you have imported.

Back to top

2. Create the Web 2.0 service requester (user interface)

You are now ready to create the user interface using Rich User Interface (Rich UI) components to invoke the CICS service you created.

EGL version 7.5.1, provides you with the ability to generate JavaScript that runs in the browser. This is important because it makes the Web page more responsive, and provides greater flexibility so that the user experience can go beyond just submitting and receiving a page. For example, after the user clicks a radio button, the logic might respond by changing the contents of a text box. The change occurs quickly because the JavaScript runs locally and, in most cases, only needs to redraw one area of the page.

An extension of client-side JavaScript is Ajax (Asynchronous JavaScript and XML), a technology that enables the run time invocation of remote code and the subsequent update of a portion of a Web page, even as the user continues working elsewhere on the page. After the user selects a purchase order from a list box, for example, the JavaScript logic might request transmission of order-item details from the remote Web server and then place those details in a table displayed to the user. In this way, the application can access content from the server, but it saves time by selecting -- at run time -- which content is transmitted.

You can write Rich UI applications that use this technology using EGL syntax. Using Rational Developer with EGL, you will create a Rich UI EGL project, import the WSDL to be used, create the Rich UI interface, and create the EGL logic to invoke the SOAP Web service created in section 1. The sequence of tasks is as follows:

1. Create a Rich UI EGL project and import the WSDL
2. Create a Rich UI EGL handler
3. Create EGL Rich UI widgets
4. Create the EGL code to consume the CICS Service
5. Complete the EGL Rich UI code to invoke the CICS service
6. Test the Rich UI application
7. Measure the service call response time

a. Create a Rich UI EGL project and import the WSDL

Using Rational Developer and the EGL Rich UI perspective, create a Rich UI project and import the WSDL you created (or downloaded) in section 1. To create the EGL Rich UI project:

1. Select File => New => Other... => EGL => EGL Project => Next.
2. Name the project something meaningful, select Rich UI Project and click Finish.
3. Click Yes to go to the Rich UI perspective.

To import the WSDL:

1. Right click the folder EGLSource and select Import... => General => File System => Next.
2. Browse to the WSDL file (it should be on your Workspace under your service project and Generation/Targets folder) or point to the WSDL file provided (CUSTINQ.wsdl ) and click Finish.

Figure 9 shows one EGL Rich UI project created with the imported WSDL. The WSDL must be in the EGLSource folder.

Figure 9. EGL Rich UI project with the WSDL imported

b. Create a Rich UI EGL handler

In EGL, a handler is a special kind of program with functions that are tied to specific events that occur when someone uses an interface. A Rich UI Handler has these properties:

• initialUI: Specifies an array of controls (widgets) that makes up the initial display for the Web page.
• onConstructionFunction: Specifies a function to call when the interface is first created.
• cssFile: Specifies a cascading style sheet (CSS) to assign to the file. By default, EGL creates a CSS with the same name as the Rich UI handler, and defines a few basic styles. To customize the appearance of the page, you can modify this file or assign a different one to the cssFile property.

Each EGL Rich UI program has one or more handlers. This example has only one handler for simplicity. A cascading style sheet that fits well in the iPhone is also provided in the download materials with this article.

To create a Rich UI handler:

1. Right click the EGLSource folder and select New => Rich UI Handler.
2. Name the package handlers, name the EGL source file CallCICS, and click Finish. The visual editor will open with a blank page. When you click on the Source tab, you will have the Rich UI EGL source code.
3. Right click the css folder under WebContent and select Import... => General => File System => Next. Point to the provided file iPhoneUI.css and click Finish. (You might need to refresh for the imported .css file to display in your project folder.)
4. Using the CallCICS.egl editor, click on the Source tab and change the cssFile property to point to iPhoneUI.css, as shown in Figure 8.
5. Save the changes.

Figure 10 shows the EGL modified code, but without any widgets created. Later you will need to add the controls (such as title, entry fields, buttons, and so on).

Figure 10. EGL code using iPhoneUI cascade style sheet

c. Create EGL Rich UI widgets

You can easily create Rich UI components using the EGL Rich UI perspective and the drag-and-drop visual editor. Be sure to periodically generate the EGL code and verify the components that are generated. The tutorial Building Web 2.0 applications using EGL explains the basic techniques for doing this. Alternatively, you can import this code from the included download material.

For this example, you will create:

• An entry field for customer number.
• Six non-modifiable fields where you will load the data returned from CICS.
• A button that will invoke the CICS Web service.

In EGL Rich UI:

• The entry field is a widget called com.ibm.egl.rui.widgets.TextField
• The non-modified field is a widget called com.ibm.egl.rui.widgets.TextLabel
• The button a widget called com.ibm.egl.rui.widgets.Button.

Use any Windows® test editor to open the provided CallCICS_incomplete.egl file. Copy and paste the contents of this file into the CallCICS.egl file that you are editing. This will accelerate the creation of your RichUI file.

You can simultaneously edit the same EGL code using the Visual Rich UI Editor and the standard EGL Rich UI editor. Just right click in the EGL code and select Open with => EGL Rich UI Editor to edit with the visual editor. Repeat this operation, but using Open with => EGL Editor for the standard editor. Using the Eclipse capabilities, you can re-arrange your screen as shown in Figure 11.

Figure 11. EGL Rich UI code using two editors simultaneously

d. Create the EGL code to consume the CICS service

Service invocation in Rich UI is always asynchronous, which means that the requester (the Rich UI client) continues running without waiting for a response from the service. The user can still interact with the user interface while the Rich UI handler waits for the service to respond. After the invocation, the service does some task and, in most cases, responds to the EGL runtime, which in turn invokes a Rich UI function that you code, called a callback function.

To invoke a service from Rich UI, you need to create an EGL interface part that includes properties that indicate how the service is accessed at run time. You then create a variable based on the Interface part and use the variable in a call statement. The call statement includes the details necessary for the EGL runtime to issue a callback.

Again using Rational Developer with EGL, you need to create the EGL interfaces that invokes the CICS service from the generated WSDL:

1. Using the EGL Rich UI perspective, right click CUSTINQ.WSDL and select EGL Services => Create EGL Client Interface. Be sure that Create Web Services Client Bindings is selected and click Next twice.
2. Select Update all existing bindings and then click Finish.
3. The package files.target (the default name) will be created and the EGL editor will show the EGL code CUSTINQ.egl that was created. No changes are required. The generated EGL is shown in the Listing 1.
4. Two other EGL packages are created with variables that map the input and output messages. Remember that the input message is the customer number (CustNo) and the output message is the entire CICS DFHCOMMAREA.

Listing 1. EGL service created from WSDL

package files.target;

//@webBinding{wsdlLocation="CUSTINQ.wsdl", wsdlPort = "CUSTINQPort", 
	wsdlService = "LAB3POTService"}

interface CUSTINQPortType{@xml {name="CUSTINQPortType", namespace="file://target.files"}}

function LAB3POTOperation(DFHCOMMAREA com.LAB3POTI.www.schemas.LAB3POTIInterface.
	DFHCOMMAREA in) returns(com.LAB3POTO.www.schemas.LAB3POTOInterface.DFHCOMMAREA)
	{@xml {name="LAB3POTOperation"}};
	end 

Figure 12 shows the EGL code generated from the dialog sequence to create the EGL client interface.

Figure 12. EGL Rich UI project with EGL code generated

e. Complete the EGL Rich UI code to invoke the CICS service

You still need to associate an event on the Rich UI that will invoke the CICS service. In this scenario, you can associate the Rich UI button with the service invocation. When the button is clicked, the EGL code will invoke the CICS service.

This is done using an EGL event called onClick. Under the findCustomer function, a variable named srv binds to the CICS service and the port. Data is assigned from Rich UI to the EGL record, is passed as input message, and calls the CICS service.

This is an asynchronous call. When the service returns without errors, the function getCustomerDataCallback runs. When the service returns an exception, another function named handleGetCustomersError runs (Figure 13).

Figure 13. EGL code to invoke the Web Service call and process the results

See CallCICS_complete_noServiceMonitor.egl in the download material for the complete code.

f. Test the Rich UI application

The code is ready to be tested. Figure 14 shows the preview mode when testing this EGL Rich UI code. To test the code:

1. Open callCICS.egl using the EGL Rich UI Editor.
2. Click on the Preview tab, type a valid customer number value (such as 4), and click Call CICS Service. The CICS Service will be invoked and the results should display.

Figure 14. Testing the EGL Rich UI interface

Try this with other customer number values, from 1 to 9. Did you notice the response time? Did you also notice that there is no application server running? The call is made from Rational Developer to the CICS that provides an Ajax proxy, avoiding any application server requirement. When you deploy this code to WebSphere Application Server, this proxy will also be deployed.

g. Measure the service call response time

You can measure response time by modifying one of the provided EGL programs. Open CallCICS.egl in a text editor. Before the function initialization () statement, add the line of code shown in Figure 15. (Note that this line ends in curly brackets { } not parentheses ().)

You also need to import a Project Interchange file:

1. Select File => Other => Project Interchange => Next and point to com.ibm.service.monitor.zip. Click Select All and then Finish. It’s fine to overlap already existing projects.
2. Adjust the EGL Build Path project properties to point to this new project. Right click on your EGL RichUI project and select Properties => EGL Build Path. Select com.ibm.service.monitor and click OK.
3. You can use the Organize Imports feature when editing the code (you can also use Ctrl + Shift + O in the editor page).
4. Use Project => Clean => Clean all projects to fix any possible errors. There should be no errors in the Problems view. (Warnings are fine.)

When you add this code to the EGL Rich UI handler, you have a screen that monitors the Web service invocation.

Figure 15. EGL code that to monitor the service call

Run the preview tests again and click on the green arrow icon in the top left corner of the panel. Figure 16 shows this screen monitor in action. In this example, you will notice that it took 265 ms of response time to invoke the CICS Web service and get a response back. This is really impressive, considering that you are: sending XML data over the line, which is parsed by the COBOL adapter, which invokes the CICS/COBOL code, and returns XML. You can click on the Request tab to see the service requested.

Figure 16. Measuring the service call response time

You now have a demo of a CICS Web service invocation -- but you can still improve this code. Because you are using Web 2.0, you can enhance the application with mashups. For the purpose of this example, you will use the address provided by the CICS program, send it to the Google Maps service, and then graphically show the customer location in a Google Map. This is all shown in section 3.

Back to top

3. Extend the Web 2.0 code to invoke Google Maps service

One of the advantages of using Web 2.0 is that you can easily integrate EGL Rich UI with existing Web services. One such commonly used service is the Google Maps Web service, which anyone can use over the Web. The main tasks to accomplish this integration are:

1. Import project with the Google Maps interface
2. Modify the Rich UI to add more controls and invoke the Google Maps service
3. Test using a standard Web browser
4. Test using an iPhone emulator
5. Deploy the code to an application server
6. Modify the HTML to avoid iPhone resizing
7. Deploy and test the code using WebSphere Application Server
8. Deploy the Rich UI to WebSphere Application Server
9. Run the code that is deployed on System z

a. Import project with the Google Maps interface

You need to import the com.ibm.egl.misc project into your workspace. If it is already loaded into your workspace, jump to step 3, otherwise:

1. Select File => Import... => Other => Project Interchange and point to the com.ibm.egl.misc.zip file provided.
2. Select All and click Finish to import this project. It's fine to overlap existing projects.
3. Right click on the Rich UI project and change the EGL Build Path property, selecting the project com.ibm.egl.misc that you have imported. This enables you to use the EGL code that is included in this project.

b. Modify the Rich UI to add more controls and invoke the Google Maps service

You need to change the Rich UI controls and make another button to invoke the Google Maps service when pressed. You also need to add a control to display the map. Using the Project Interchange function, import the provided CICS_Services+RichUI+Google.zip file.

Aside from the new controls for the Google Maps, you also need to define a new EGL variable named googleMap to be defined as ExternalType GoogleMap (Figure 17). This EGL code is provided as part of the com.ibm.egl.misc project.

Figure 17. EGL code to invoke the Google Map service

After importing the Project Interchange file, the solution for invoking the Google Maps service is located in the project LAB3_EGL_RichUI. Remember to run Project => Clean => Clean all projects after the import. No errors should be listed in the Problems view (aside from warnings).

Figure 18 shows how the Google Map service is invoked when the Google Map button is clicked. The button invokes the showMap function, which then invokes functionshowAddresses defined in the google.map package in the com.ibm.egl.misc project.

Figure 18. When button is clicked invokes showMap EGL function

c. Test using a standard Web browser

To test the application using a standard Web browser:

1. Right click CallCICS.egl and select Open With => EGL Rich UI Editor
2. Click the Preview tab to make sure that the application is running properly.
3. To display the Google Map, click the green Google Mapbutton.
4. From this tab, click on the globe icon (Figure 19) to display the Web page in the external browser. The application will display in your default Web browser.
5. Copy the address that was returned from the CICS/COBOL application to the Windows clipboard and paste it into your browser. You will need to paste this later into the iPhone emulator. An example of this generated address is: http://localhost:5590/LAB3_EGL_RichUI/handlers/CallCICS.html?contextKey=3, although yours will be different, depending on your settings, project name, and so on.
6. Test the application a few more times with this browser using valid customer number values. Do not close the browser.

Figure 19. Showing the preview using an external browser

d. Test using an iPhone emulator

Because the objective here is to show the application running through an iPhone, you can demonstrate these results using a Web browser running an iPhone emulator. There are a number of iPhone emulators available on the Web. To use an emulator:

1. Select an iPhone emulator. For the purpose of this article, go to http://www.testiphone.com/.
2. Paste the http address shown in the external browser in the entry line of the emulator and press Enter. The result is a look and feel more representative of an actual iPhone (Figure 20).
3. Test the application again using valid customer numbers, use the Google Map button, and observe the response time.

Figure 20. iPhone simulator

e. Deploy the code to an application server

At this point, you are ready to deploy the EGL Rich UI to your application server. Rational Developer supports publishing the Rich UI to either WebSphere Application Server or Apache Tomcat. The steps shown here are for WebSphere Application Server, but the steps for Tomcat will be similar:

1. From any Rational Developer perspective, navigate to Window => Preferences => EGL => Rich UI. From the Application Generation/Generation Mode drop down menu, select Deployment and click OK. This will force all parts used by Rich UI applications on your workspace to be re-generated. You should have no errors in the problems view (warnings are fine).
2. From the EGL Rich UI perspective, right click on CallCICS.egl (under the handlers package) and select Deploy EGL Rich UI Application.
3. Select WebSphere Application Server deployment => Next.
4. Select New Web project and type a name for project Name, such as LAB3.
5. Select your defined runtime server (WebSphere Application Server V6.1 or V7) and click Finish. The code will be deployed and a new Web project will be created. A dialog (Figure 21) will display the HTML created in the WebContent folder. Here, the file created is named CallCICS-en_US.html.

Again you should have no errors. You might need to clean the generated projects using the Project => Clean process.

Figure 21. Dialog showed when code is deployed

f. Modify the HTML to avoid iPhone resizing

At this point, you can publish and test the code running in WebSphere Application Server. If you ran the application on an iPhone, you would discover that the page is very small. You can use the iPhone resize capability, but there is an easy technique you can use (there are probably several) to rectify this, and it involves adding just one line of code to the generated HTML:

1. Make a copy of your original code to preserve it before making this modification. Righht-click on CallCICS-en_US.html (the generated HTML file) in the LAB3/WebContent folder, select Rename, and change the name to CallCICS.html.
2. Open the renamed file with your HTML editor and insert the bold lines in Listing 2 after the <html> and <-- begin-comment tags.
3. Save the modified code.

Listing 2. Line to be added in the generated html file

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www....
<html>
<head><meta name="viewport" content="width=320,
user-scalable=no"></head>
<!-- Generated at Fri Jul 31 14:56:52 EDT 2009 by EGL 1.0.0.v20090608_2230 -->
<title>CallCICS</title>

g. Deploy and test the code using WebSphere Application Server

Assuming that you have WebSphere Application Server installed in Rational Developer or Rational Business Developer, just right click CallCICS.html and select Run As => Run on Server. Select WebSphere Application Server and click Finish.

Notice now that the port number that WebSphere Application Server is listening on is different than the previous tests. For example: http://localhost:9081/LAB3/CallCICS.html

If you have an iPhone with Wi-Fi connectivity in the same network where this application server is running, you can use the application server’s IP address instead of localhost, for example: http://192.168.1.105:9081/LAB3/CallCICS.html. Remember that the address is case sensitive.

A dialog will display with a message: The Google Maps API server rejected your request. This could be because the API key used on this site was registered for a different web site. This message means that your server is not registered on the Google server as our demo server is. Ignore the message and click OK. (You can research Google Maps for instructions on how to register a server to use this Web service.)

Figure 22 shows an image from an iPhone. Notice that the screen displays without the image having to be resized. Cool?

Figure 22. Picture taken from iPhone running Rich UI code

h. Deploy the Rich UI to WebSphere Application Server

Ultimately, you will want to run your code on a server outside of your development environment. Assuming that you have access to a WebSphere Application Server running outside of your development environment:

1. Using Rational Business Developer or Rational Developer for System z, select File => Export => Java EE => EAR file => Next. Because this example uses WebSphere Application Server, the deploy dialog created a J2EE™ EAR file. If you selected Tomcat, you will export a WAR file.
2. Select the EAR project (LAB3EAR), the destination, and click Finish. This will create the EAR file named LAB3EAR.ear (also provided with this article).
3. Close whichever Rational Developer you are running and start WebSphere Application Server as the administrator.
4. From the WebSphere Application Server administrative console, expand Applications => Install New Application => Local File System and browse to where you exported the LAB3EAR.ear file. Click Next. Figure 23 shows this sequence.
5. Accept all the defaults and click Next. Accept the defaults again and click Next, then Finish. The application will be deployed and you must Save the configurations.
6. Select Enterprise Applications => LAB3EAR and click Start button. The application will start and you are ready to begin testing from the server.
7. To run on an iPhone, point to this server and use the HTTP address to run the iPhone application, for example: http://192.168.1.105:9080/LAB3/CallCICS.html.

Figure 23. Installing the EAR file in the WebSphere Application Server V6.1

i. Run the code that is deployed on System z

Point your iPhone or other browser to the demo application at: http://zserveros.demos.ibm.com:9080/iPhone/CICS-en_US.html. This code also contains a help feature that you can access by clicking the question mark icon. This will show you the topology that is in use (Figure 24). In this example, the EAR file was deployed to WebSphere Application Server for z/OS V6.1 running in the same LPAR that the CICS/COBOL application was running in.

Figure 24. Invoking CICS Web services from iPhone

Back to top

Summary

EGL Rich UI has many benefits over lower level implementations (like JavaScript and Ajax). Among them, EGL:

• Reduces development costs, accelerates time to market, and helps deliver new, higher quality Web 2.0 based business solutions, due to the higher productivity and simplicity involved.
• Has very good performance with a rich user interface.
• Requires shorter learning curve and lesser training costs; developers only need to learn one language (EGL) in order to build back-end business logic and services, and front-end user interfaces.
• Supports multiple browsers (write once, run in most popular browsers).
• Extends the value and the life of the reliable business logic that resides in System z and i systems by enabling applications that run transactional services within innovative applications that improve user experience and productivity.
• Seamlessly integrates enterprise information and processes with other sources of information, data, and services across the enterprise or on the Web to better serve users, customers, and partners (through mashups).
• Leverages emerging SOA-based industry-vertical services provided by vendor and free or fee powerful services (for example, Google Charts, Google Maps, Xignite, and so on).
• Lowers advanced skills barrier and leverages traditional business-oriented developers while delivering innovative and powerful state-of-the-art solutions to the business.

Back to top

About the download

The download materials included with this article contains code that you can use to implement the ideas presented here. Download the iPhone_EGL_Assets.zip file to a temporary drive on your computer and unzip it. Rather than build all the pieces on your own, the code for the entire example solution is provided so you can focus on the concepts being described. The download file includes:

• CICS_Services_Project.zip: Exported Rational Developer for System z Project Interchange file that can be used to test the CICS Web service.
• CUSTINQ.wsdl: WSDL that invokes the CICS Web service.
• iPhoneUI.css: Cascading Style Sheet for the iPhone Web applications.
• CallCICS_Incomplete.egl: EGL Rich UI code containing widgets only, without any logic that invokes the CICS service.
• CallCICS_complete_noServiceMonitor.egl: EGL code necessary for implementing the CICS services invocation and the EGL Rich UI widgets.
• com.ibm.service.monitor.zip: Exported EGL Project Interchange file to be used to track and measure the service invoked. You must import this file to the workspace. For more information on this service monitor, visit the Ground control to major Tom... EGL Cafe blog entry.
• com.ibm.egl.misc.zip: EGL code required when using the Google Maps Web service.
• CICS_Services+RichUI_noGoogle .zip: Exported Rational Developer Project Interchange files for test the CICS Web service.
• CICS_Services+RichUI+Google .zip: Exported Rational Developer Project Interchange file that you need to load when using Google Maps.
• LAB3EAR.ear: J2EE EAR file to be deployed to WebSphere Application Server V6.1 or 7.0.

Back to top

Download

Information about download methods

Resources

Learn

• You Tube: Demonstration of a CICS Transaction on an iPhone
• IBM Rational Developer for System z product information
• IBM Rational Business Developer product information
• IBM Rational Developer for System i for SOA Construction product information
• IBM Enterprise Modernization Sandbox
• Tutorial: Wrap existing COBOL programs as Web Services with IBM Rational Developer for System z
• IBM developerWorks WebSphere