EGL Rich UI Hub

I am sure that there is many ways to accomplish this task...
But I want to show one that I have done using Web Services and Rich UI.

Do you have an iPhone or iPod touch?

Click here:
For COBOL/CICS/IMS:
http://testiphone.com/?address=on&url=http://zserveros.demos.ibm.com:9080/iPhone/egl.html
(the options 1, 2,3 and 5 were done with EGL Rich UI; the #4 was done by COBOL/CICS only and not discussed in this blog.)
For RPG:
http://testiphone.com/?address=on&url=http://iseriesd.demos.ibm.com:59900/isys/rpg.html(Application Server on System i)
Or
http://testiphone.com/?address=on&url=http://zserveros.demos.ibm.com:9080/isys/rpg.html
Application Server on System z)

I have done all that above (the client and the server piece) in less than 12 hours and I am an old generation guy. I started doing COBOL development punching IBM 029 cards.. Since then I had learned lots of new stuff, but as you all know this is a never ending.... and this is the beauty of EGL: simplifies that learning curve.
I am familiar with the EGL language and Rational Developer for z with EGL (RDz) as well some skill on Rational Developer for system i for SOA Construction(RDi SOA). Using those tools I created these simple demos, reusing existing COBOL/CICS/VSAM, COBOL/IMS and RPG code.

What really impressed me in this small demo is the response time to invoke either CICS, IMS or RPG Services... Try it..
Another surprise.. when the parsing is done by COBOL (CICS demo) I got the same or even better response time compared to parsing done by Java (IMS and RPG demos).

Using the Service Monitor (available here in the EGL Café) when you click in the green icon:
The response time to invoke the web services will vary from 0.15 to 2 seconds.. Really impressive. This is like green screens response time.. and remember that we have SOAP XML parsing, etc..

You also can see this in action using the YouTube links below:
CICS: http://www.youtube.com/watch?v=5JyJ0XXR_3c
IMS: http://www.youtube.com/watch?v=c2bGHjCQQZo

I have created those demos using 4 different topologies:

1. Demos #1, # 2, and #3 - All the code was deployed into our WebSphere Application Server (WAS) located in our demo z/OS system in Austin, Texas.
http://zserveros.demos.ibm.com:9080/iPhone/egl.html



2. RPG Demo #1 - (WAS and RPG Web Service on System i)
http://iseriesd.demos.ibm.com:59900/isys/rpg.html


3. RPG Demo #2 (WAS on System z and RPG Web Service on system i)
http://zserveros.demos.ibm.com:9080/isys/rpg.html



4. IMS Demo #4 (WAS on System z and the IMS Service deployed as Java - JCA using RAR connectors - in the WAS also)
http://zserveros.demos.ibm.com:9080/iPhone/IMS.html

---

1.0 Creating the iPhone Web 2.0 for COBOL/CICS

To explain this code creation I will split in two parts.. Creating the Web Service provider (under CICS) and creating the Web Service requester (iPhone).

Part 1 – Create the COBOL/CICS SOAP Web Service

This was very easy, since I have been doing that since 4 or more years ago.
Basically using an existing COBOL/CICS program and the RDz wizards the CICS SOAP Web Service is created and WSDL is generated. The code is deployed into the CICS also using RDz facilities. The XML parsing is done by the COBOL generated by RDz.

You can see a tutorial as well do it yourself using the System z Sandbox and the tutorial Wrap existing COBOL programs as Web Services with IBM Rational Developer for System z.
This is the same service that I am using in the option # 2 and option #3 of the demo link.
The option of the demo link is also being explained in the article Modernize your CICS applications with SOA and Web 2.0 using Rational tools.

It’s not easy? The service can be created, deployed and tested using RDz and without any change in the existing COBOL/CICS code.

Part 2 – Create the Web 2.0 that will invoke the CICS Web Service

This is my favorite piece.. I can use the latest technologies and deploy the code in the iPhone or iPod touch as well in black berries with Opera Mini browsers, without having to learn JavaScript, AJAX, REST,etc.. Just EGL..
Given the WSDL generated on part 1, I used RDz and the EGL wizards to create the Rich UI piece.
All the code was deployed into our WebSphere Application Server located in a z/OS system in Austin, Texas.

---

2.0 Creating the iPhone Web 2.0 for RPG

Again to explain this code creation I will split in two parts.. Creating the service provider (under System i ) and creating the service requester (iPhone), that is similar to the CICS piece.

Part 1 – Create the RPG SOAP Web Service.

This is easy and you need the RDi SOA to wrap the RPG existing code into service.This is a bit different that the CICS piece since the Web Service here is deployed in the Application Server, not handled directly by CICS like in the previous example..Using RDi SOA and an existing RPG the SOAP Web Service is created and WSDL is generated. The code is deployed into the System i WebSphere Application Server System i WebSphere Application Server.Again this is very easy, let the tool generated the Java wrapper. The service can be created, deployed and tested using RDi SOA and without any change in the existing RPG code.

Part 2 - Create the Web 2.0 that will invoke the RPG Web Service

Given the WSDL generated on part 1 above, I used RDi SOA and the EGL wizards to create the Rich UI piece.
All the code was deployed into our WebSphere Application Server located in the System i, also located in Austin, Texas.
In this demo I decided to have to different options. In the demo RPG demo #1 this is on System I and in the RPG demo #2the Rich UI and AJAX proxy are located in our z/OS system. In both demos the SOAP Web Service is deployed in the System I Application Server.

---

3.0 Creating the iPhone Web 2.0 for IMS

I could create Web services as I did with CICS, generating COBOL adapters to do the SOAP parsing, but I decided to have other approach here. I used the Java connectors to create the web services using the JCA adapters (using RAR - J2EE Resource Adapters) and deployed the generated Java web service to WAS on z. The XML parsing here is done by Java, not by the COBOL adapters. The idea was to compare the response time.

Part 1 – Create the Java SOAP Web Service.

This is easy and you need the RDz with Java or RAD (Rational Application Developer) to wrap the existing COBOL/IMS code into Java Web Services.
I used the J2C wizards (part of RDz with Java or RAD). The wizards also generated the WSDL as well the Java code (EAR file) that I deployed into WAS on z. Again, note that this is a bit different that the CICS demo since the XML parsing is done by JAVA (not COBOL as in CICS) and the EAR iss deployed in the Application Server.

Part 2 - Create the Web 2.0 that will invoke the Java Web Service that will invoke the existing COBOL/IMS code.

Given the WSDL generated on part 1 above, I used RDz with EGL as I did before with CICS to create the Rich UI piece.
All the code was deployed into our WebSphere Application Server located in the System z.
To execute this use:
http://zserveros.demos.ibm.com:9080/iPhone/IMS.html-----

4.0 Running the demo

You can demonstrate this using either an iPod touch connected via WI-FI or using an iPhone connected to a network. Also you may demonstrate using Browser emulators for the iPhone.

If you want to use another smart phone like a BlackBerry, you will need to install a better browser than the provided. The default BB browser doesn't have JavaScript enabled, but Opera Mini does. From your BB browser, go to *mini.opera.com*and click on Download Opera Mini. The new browser will be installed under Applications and a large O will be created.

For the demo sequence as well a PDF that you can print, see the attached file.

---

5.0 Flash movies provided.

I have uploaded two movies that may help you. You must download the *.wmv appended on this blog. Sorry my "Boston" accent.. :

1. How the COBOL/CICS Demo was built using RDz and EGL Rich UI.
Iphone_CICS_Build.wmv

2. The demo in action using an iPhone browser emulator.
Iphone_CICS_RUN_WMV.wmv

3. The demo in action using an iPhone browser emulator.
Iphone_IMS_Run_ONLY_WMV.wmv

Let me be the last person to wish you a Happy New Year!

This is a quick post to remind everyone to pay attention to the event handlers you decide to use in your EGL RUI applications. On the surface the event handlers onClick and onChange do the same thing for a ListMulti widget. That said, making sure you use onChange allows your application to function as expected when using the keyboard.

Here is an example to show you what I mean. The following RUIHandler creates a ListMulti widget and prints beneath it the number of items selected. When using the mouse, regardless if I used onClick or onChange the text label would print the correct value. Now, if I select the first element with the mouse, then hold the SHIFT key and use the UP/DOWN keys to select the other list elements, if I had the event handler as onClick those keyboard actions wouldn't be registered. Most of the time you would want them - so be sure to use the onChange event handler.

Handler MultiSel Type RUIHandler { initialUI = [ Box, TextLabel ] }
	TextLabel com.ibm.egl.rui.widgets.TextLabel{ text="TextLabel" };
	Box com.ibm.egl.rui.widgets.Box{ padding=8, children=[multilist] }; 
	
	multilist ListMulti{values = ["One", "Two", "Three", "Four", "Five"], onChange ::= multiSelFunc};

	function multiSelFunc(e event in)
		sz int = multilist.getSelection().getSize(); 
		for(i int from 1 to sz)
			TextLabel.text = "MultiSel: " + i + " selected \n";
		end
	end	
End  

All the best,
George

Many EGL Rich UI applications are migration targets from a legacy desktop application developed in VisualAge Generator, PowerBuilder, VisualBasic, or similar technologies. Personally, I think menus have no place in web2.0 applications. Just go find the menubar in gmail, or in Google Finance. They're not there. However, if you have to maintain superficial compatibility between the old application and the new one, and you really need a menu, EGL Rich UI comes with a powerful menu solution that lets you completely customize and style your menu.

Those of you who are already dabbling with menus will discover they are hard to use in the RBD. What is happening here is that our Text UI and Rich UI technologies are fighting over the same types being available for lookup. Namely, we automatically include the Text UI's Menu and MenuItem on the search path. This is for historical reasons. We are looking at IDE solutions to better separate the search paths, without ruining the lives of existing CUI programmers. For now, if you use menus in EGL Rich UI, simply write the import statements by hand. Ctrl-Shift-O, nor Ctrl-Space, will introduce the import statements automatically.

Anyway, back to the power of menus. With all the flexibility that comes with the menus, allowing you to attach behaviors, etc, a price is paid for ease of use. When Jon Sayles and I talked about his upcoming Rich UI training materials he is working on, he mentioned the need for a simpler menu. One with just text, and one event handler. One that is not so flexible perhaps, but one that works quickly.

What you will see below is a Menu implemented using our general solution, including defining a behavior to set styles and handle events. Rather than setting up the menu with MenuItems, and gobble together the entire menu, I tried to make the declaration as simple as possible, using just an array of String. It limits what the menu can do. It has no sub-menus, and no icons in the menu, and all menu item elements look the same. Imagine a virtual slider with on the left side ease of use and abstration, and on the right side full detail with maximum power. SimpleMenu sits way on the left. Our Rich UI menu solution sits way on the right. You may come up with a menu solution called IconNestedMenu that sits somewhere in the middle. I find that aspect of software design the most intriguing: where to put your solution on that imaginary slider.

To create a SimpleMenu, you say the following:

    menuBar SimpleMenuBar { 
        listeners ::= menuSelected, 
        menus = [
            "File", [ "New", "Open...", "Import...", "Export...", "Print..." ], 
            "Edit", [ "Cut",  "Copy", "Paste" ],
            "Help", [ "Welcome", "Search", "About..." ]
        ]
    }; 
 

You specify one or more listeners, and introduce each menu (we add three menu in this sample). Each menu has a number of options that will be shown when the menu is activated. This is what the menu will look like:

The menubar is grey, and the menus are white. When the mouse is hovered over a menu title or menu item, the background turns to a shade of blue. We handle a few extra events to hide the menu automatically, and close existing menus when hovering to another one on the menubar.

When a menu item is selected, the SimpleMenu will trigger the listeners that have registered:

    function menuSelected(menu String in, item String in)
        case (menu + ">"+ item)
            when ("File>New") 
                WriteStdOut("Create a new File!");
            otherwise
                WriteStdOut("Select: '" + menu + "' , '" + item + "'");
        end
    end

All styling for the menubar and the menu items is done in CSS, so you can control the look and feel easily. This is what the CSS looks like originally:

.EglRuiSimpleMenuBar {
	font-family: Arial;
	background-color: #cccccc;
	line-height: 1.4em;
	font-size: 0.9em;
}

.SimpleMenuTitle {
	padding: 0px 8px 0px 2px;
	background-color: #cccccc;
}

.SimpleMenuItem {
	background-color: white;
}

.SimpleMenuTitle:hover, .SimpleMenuItem:hover {
	background-color: #5a9bd1;
}

.SimpleMenuOptionsBox {
	background: white;
	border: 1px solid gray;
	border-width: 0px 2px 2px 0px;
}	

Changing the look and feel is easy. For instance, if you change the background color to the menu title and item to this:

.SimpleMenuTitle:hover, .SimpleMenuItem:hover {
	background-color: orange;
}

you will get this result:

The implementation of SimpleMenu uses the existing Rich UI menu, adds a behavior to it, and converts our simplified list of menu item strings into instances of MenuItem and set up the menu.

When a SimpleMenu is created, we use the exsiting menu and set up a behavior:

private menu Menu { menuBehaviors = [ highlightMenu ]};

The hightlightMenu behavior function is called by the Rich UI menu each time a menu is created and allows us to customize the menu as we see fit. In our case, we set up event handlers and styles on the menu as follows:

private function highlightMenu(menu Menu in, titleBar Span, optionsBox Box, options MenuItem[])
    menu.onMenuOpen = menuOpened;
    titleBar.class = "SimpleMenuTitle";
    optionsBox.class = "SimpleMenuOptionsBox";
    titleBar.onMouseOver ::= enterTitle;
end

When we move the mouse around and enter a menu item, we want to show it and also close any menu item that is already open. The enterTitle function takes care of that:

private function enterTitle(e Event in)
    InfoBus.publish("simple.menu.enter.title", menu);         
end

private function switchTitle(event String in, menuOpened any in)
    if (menuOpened != menu)
        menu.hideOptions(false);
    else
        menu.showOptions();
    end
end

The enterTitle function is called whenever the mouse enters a menu item. We now want to inform all the other menus to close themselves. To avoid us having to go back to the menubar and ask it to close the other menus for us, we use the InfoBus to generate an application level event that is broadcasted to all the other menus.

During the SimpleMenu construction we register an InfoBus listener as follow:

InfoBus.subscribe("simple.menu.enter.title", switchTitle);

As a result, each menu will be informed when it should close itself. This is how numerous menus can talk to each other without needing a third party to help out in the communication.

Anyway, try out the SimpleMenu, and feel the power of our Menu architecture allowing you to fully customize the menu's look and feel.