EGL Rich UI Hub

Overview All Content (53) Documents (14) Blog Posts (39) Set as default tab

EGL Rich UI transforms the way Rich Internet Applications (RIAs) and mashups are developed by dramatically simplifying the programming model, hiding the complexities of JavaScript and Ajax, and enabling developers of all backgrounds to quickly build Web 2.0 solutions.

Why EGL Rich UI?

Hide complexity of JavaScript, Ajax, JSON, etc.
Fully open and extensible
Easily integrate/consume any service (REST or SOAP)
Single language end-to-end (front-end to back-end)
Includes visual composition, libraries of RUI widgets
Instant deploy/visualize while you code
Extends existing enterprise data and processes to Web 2.0

For additional information, view the whitepaper or read the official announcement.

How can I get it?
EGL Rich UI is available in IBM Rational Business Developer 7.5.1. Download the trial now.

Using iPhone to access COBOL/CICS/VSAM, COBOL/IMS and RPG? in Web 2.0 with EGL Rich UI

Posted by RegiBarosa Aug 5, 2009

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..

http://www-949.ibm.com/software/rational/cafe/images/emoticons/happy.gif

:

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

2 Comments Permalink Tags: rpg, cics, richui, modernization, web2.0, z/os, egl, i, cobol, cics, cobol, rui, web, service, soap, iphone, ims

Ground control to major Tom..... Or, How to Debug Service Calls in Web 2.0 with EGL Rich UI

Posted by ChrisLaffra Feb 7, 2009

EGL Rich UI makes it really simple to invoke REST or SOAP web services and to convert the message parameters and result into EGL Records. However, sometimes, the service does not work and you feel like you are stuck. In this blog entry I will share some best practices we developed on the Rich UI team for dealing with services that don't respond as you expect them to.

Most people start out with using the following syntax to make a service call:

function doit() 
    call foo.bar(...) returning to callback;
end     
function callback(...)
    ...
end

When the foo.bar service is invoked, a response will be returned some time in the future, and then the callback function is called. It gets interesting when the service is not available, or when we pass invalid parameters to the service call. How to deal with exceptions?

When using service calls as shown above, the default error you will see will resemble the following message:

Admittedly, this message is not very useful. All it says is that something went wrong. However, it also tells you to add an exception handler to get a more detailed explanation. Following this advise, you might be tempted to rewrite your service call to look like this:

function doit() 
    try 
        call foo.bar(...) returning to callback; 
    onException(exception AnyException)
        ...    // service errors never get here!
    end
end

It would seem like the right thing to do. Call a service. When something bad happens, handle the exception. However, service calls consist of two steps. First, you send out the service request, which is really dealt with in the "call" part of the statement. The service request is sent over the wire, and control immediately continues to the next line. No exceptions will happen at this point, as you can assume we will always be able to send the request over the wire. Now, when the response comes back in the future, the callback is invoked. If the server responds with an error message instead, we have no real place to report the error to the code. This is why we have a special syntax on the call statement looking like this:

function doit() 
    call foo.bar(...) returning to callback onException handleException;
end     
private function handleException(exception AnyException in)
    e ServiceInvocationException = exception;
    writeStdout("OOPS. " + e.message + " " + e.detail3);
end

Now, each time the service is unresponsive, or the server complains about our parameters being incorrect, the handleException function will be called, and we can take evasive actions.

With that in mind, service debugging is already much easier. However, it is still hard to see what request body we sent out, what actual reponse headers we received, etc. In some cases, you actually will need to inspect those to deal with pesky third party services that have a particular way of having to be set up. One example would be a service that establishes a connection in a login screen, and returns a cookie in the response header. In future calls, you are then expected to pass in that same cookie as part of your request parameters. We need a tool to easily inspect and spy upon the services being sent by a Rich UI application. Tools like Firebug help, but it happens to be that it is not too hard to do this directly in Rich UI itself.

To explain our approach to a Service Monitor, let's show the intended end result first:

The Service Monitor shows an extra bar at the top of your application. Each green icon represents a successful service call, and a red icon shows a failed attempt. When you click on one of the green or red icons, a dialog box opens which you can drag around the screen:

The dialog shows the details of the service call. You will see things like the method being used (POST/GET/PUT/UPDATE), the values of the request and response body, the query parameters, and the request and response header. You will also see how long the service took to return. The service monitor is easily added to any application by simply adding a field declaration to your application's RUIhandler:

    monitor tools.ServiceMonitor;

The implementation of the Service Monitor works in two steps. First, we include a bit of extra JavaScript that detects when a service call is made, and when it returns (see ServiceMonitorRuntime.js). As a result, three InfoBus events are generated.

The three InfoBus events that are now generated by the runtime are received by a piece of UI (see ServiceMonitor.egl, implementing the monitor bar shown above). Actions are taken to respond to these events taking place:

function start()
    InfoBus.subscribe("service.monitor.call", serviceCalled);
    InfoBus.subscribe("service.monitor.success", serviceSucceeded);
    InfoBus.subscribe("service.monitor.error", serviceFailed);
    ...
end
function serviceSucceeded(message String in, object any in)
    info ServiceMonitorInfo = object;
    info.setStatus("Service responded successfully (i.e., server actually sent a response)", "tools/ok.png", "#33CC66");
    succeeded += 1;
    showCurrentURL();
end
function serviceFailed(message String in, object any in)
    info ServiceMonitorInfo = object;
    info.setStatus("Service Error: "+info.errorDetail, "tools/error.png", "red");
    failed += 1;
    showCurrentURL();
end

As you can see, if a service call is successful, we will add an OK icon with green background. Otherwise, we add an ERROR icon with red background.

You will see that our entire implementation is surprisingly small (less than 200 lines of EGL and 100 lines of JavaScript). Yet, we have a powerful yet inobtrusive monitoring tool with a nice looking UI. By using the InfoBus we separate the different concerns of event generation and consumption, keeping things nice and clean.

Have fun using this monitor and hopefully you will find it will greatly improve your ability to call any web service out there....

15 Comments Permalink

Developing a Look Ahead Text Field Widget in Web 2.0 with EGL Rich UI

Posted by bsvihovec Dec 9, 2008

When a user is entering a value in a Text Field, the partial text that has been entered can be used to guess the full value that the user is trying to enter. If any complete values match what the user appears to be entering, a set of values can be provided to the user in the form of a pop-up list. The user can then either select a value from this list, which will result in the value of the Text Field being replaced with the value that was selected, or they can continue typing, which will generate a new list of suggestions. This type of widget is sometimes known as a "Look Ahead Text Field", and in this article I will go over some of the steps involved in writing one of these widgets in EGL.

A Look Ahead Text Field widget is actually two widgets in one; a Text Field and a List. When there are no choices to present to the user, the List is hidden. When there are choices to present to the user, the List is made visible below the Text Field:

(A Look Ahead Text Field with two choices)

To begin creating our widget, we first need to define a Text Field so that the user can enter a value. We want to update the list of options for the user after each key is pressed, so we will add an “onKeyUp” event handling function to the Text Field as well:

inputField TextField{onKeyUp ::= handleKeyUp};

(The definition of the Text Field)

In the “handleKeyUp” event handler, we will check and see if the Text Field contains a value. If the Text Field does not contain a value, which can occur if the user has just deleted the last character, we will hide the list of options. If the Text Field does contain a value, we will use that partial value to look up the list of possible complete values that the user is in the process of entering:

http://www-949.ibm.com/software/rational/cafe/servlet/JiveServlet/downloadImage/1272/HandleKeyUp.png

(A code snippet from the “handleKeyUp” event handling function)

Each user of the Look Ahead widget may want to calculate the list of possible choices for a partial text value in a different way. For example, some developers may choose to use a static list of choices, while others may choose to use a Service to compute the list of choices. To support various types of lookup functions, the Look Ahead widget requires that developers specify their own lookup function when the widget is instantiated. The lookup function must conform to the signature specified by the “LookAheadFunction” Delegate:

http://www-949.ibm.com/software/rational/cafe/servlet/JiveServlet/downloadImage/1273/LookAheadDelegate.png

(A users lookup function must match the signature specified in this Delegate)

Since we do not know how long it will take for the provided lookup function to return any choices, the “LookAheadFunction” does not return any values. If the “LookAheadFunction” returned a list of choices, the user would not be able to enter another character until the choices were computed for the previous key press. To keep our widget responsive, the“LookAheadFunction” is only a notification to the developer that a new value has been entered in the Text Field and that a list of choices should be computed. When the list of choices is available, the developer can invoke the “setOptions” function on the Look Ahead widget so that the list of options will appear for the user.

Once we have our list of choices, as specified in the invocation of the “setOptions” function, we need to populate a List widget and display it to the user. When the Look Ahead widget is created, the List widget is instantiated with its position set to “absolute”, and its visibility is set to “hidden”:

http://www-949.ibm.com/software/rational/cafe/servlet/JiveServlet/downloadImage/1274/OptionsList.png

(The definition of the options list)

Setting the position of the List to “absolute” allows us to align the options list directly below the text field, and temporarily cover of any other widgets that may appear below the text field as part of the normal browser layout. Setting the visibility to “hidden” initially means that the list will not appear to the user. When the options are set, the List is positioned underneath the Text Field, and its visibility is set to “visible”. When a user selects a value in the list, which is captured in the “handleOptionClicked” or “handleKeyUpInOptionsList” event handling functions, the values in the list are cleared and the visibility of the list is again set to “hidden”.

The final element of the Look Ahead widget is a DIV widget,which is created to hold both the Text Field and List widgets. The “targetWidget” of the Look Ahead widget is set to the DIV widget, which allows us to add both the Text Field and the List widget to the web page as part of the single Look Ahead widget.

Attached to this article are the source files for the Look Ahead widget and a sample RUIHandler that uses this widget. To run the sample, copy both of the files into a package named ‘lookahead’ in an EGL Rich UI Project and open the LookAheadTest RUIHandler. A list of choices has been statically defined for text entries that start with the character ‘c’ or a ‘d’ in this sample. To see the list of choices, enter a ‘c’ or a‘d’ in the text field. Also, please note that the Look Ahead widget is not completely implemented, as additional features are beyond the scope of this article.

4 Comments Permalink Tags: rui, widget

EGL Dojo Widgets for RBD 7.5.1.4 Available in Web 2.0 with EGL Rich UI

Posted by gpapayia Nov 18, 2009

Today we released the (0.7.1.1) EGL Dojo Widgets for RBD 7.5.1.4. These are the same widgets that were released in the EGL Community Edition (CE), just for RBD. Not to worry though, from this point forward all releases of EGL Dojo Widgets will work in both RBD and CE. We also made available a great Gallery Sample showcasing all Dojo widgets in a single sample! Take a look at it here.

Our apologies for this, but any existing EGL applications using the 0.6.0 version of the Dojo Widgets will most likely require changes to bring them forward. That said, the current API has been firmly defined and will not experience significant changes in future releases.

To download the EGL Dojo Widgets for RBD click here. Be sure to also take a look at the great documentation attached to the page to get a feel for the API.

0 Comments Permalink Tags: ajax, egl, web2.0, rich_ui, dojo

Building Accessible Applications with EGL Rich UI in Web 2.0 with EGL Rich UI

Posted by bsvihovec Nov 20, 2009

When developing Rich Internet Applications, it is important to make the applications accessible to everyone. Due to the fact that EGL Rich UI applications are generated into standard HTML and Javascript, the applications comply with accessibility standards and can be used with utilities such as screen readers, etc. The following are some specific details on working with screen readers, tab indices, and relative sizes in an EGL Rich UI application.

Screen Readers
When working with widgets that map directly to basic HTML controls (e.g. button, checkbox, etc), no additional work is required to enable a screen reader, as the readers are already able to interpret standard HTML tags. In addition to the basic widgets provided by the HTML specification, Rich Internet Applications commonly contain more complex widgets that are rendered using generic HTML tags such as the DIV tag. To make these complex widgets accessible to a screen reader, the W3C organization has defined the Accessible Rich Internet Applications (WAI-ARIA) specification (http://www.w3.org/TR/wai-aria/). This specification defines the 'Role' attribute for all tags, which can be used to instruct a screen reader on how a widget should be interpreted (e.g. "checkbox"). All widgets found in an EGL Rich UI application contain the fields "ariaRole", which can be used to instruct a screen reader on how to interpret the widget.

An example application that uses the "ariaRole" field is provided as part of the attached project, in the file AraiaRoleDemo.egl.

Another common aspect of Rich Internet Applications is the usage of widgets that update their content as the application is running, without re-rendering the entire page (e.g. stock prices, etc). To support these widgets, the ARIA specification defines the 'Live' attribute, which can be used to instruct a screen reader to re-read a widget's content after it has been updated. All widgets found in an EGL Rich UI application contain the fields "ariaLive", which can be used to instruct a screen reader on how often to re-read a widget after its content has changed.

An example application that uses the "ariaLive" field is provided as part of the attached project, in the file LiveRegionDemo.egl.

Tab Index
When developing an application, it is important to consider a user that does not have a mouse or other pointing device. To support these users, the application should enable tabbing so that the application can be used with only a keyboard. All widgets found in an EGL Rich UI application contain the field "tabIndex", which can be used to indicate the Tab order for the widget in the running application.

An example application that uses the "tabIndex" field is provided as part of the attached project, in the file TabIndexDemo.egl.

Relative Sizes
When developing Rich Internet Applications, it is a good idea to size elements using relative values, so that the application will render correctly on different size monitors or at different resolutions. To specify that a widget should take up a certain percentage of the screen in an EGL Rich UI application, you can set size attributes using a value with a percentage (e.g. width = "50%").

Font sizes should also be specified using relative units (e.g. em) instead of fixed units (e.g. px), so that the browser can adjust the font size to the users preferences. You can specify font sizes with different sizes and units (e.g. em, pt, etc) using the "fontSize" attribute found on all widgets in an EGL Rich UI application.

An example application that uses relative sizes and units is provided as part of the attached project, in the file RelativeSizeDemo.egl.

Note: The attached project, AccessibilityDemo, requires the com.ibm.egl.rui_1.0.2 project.

Attachment: AccessibilityDemo.zip

0 Comments Permalink