Blog Posts

Okay, I've written the first-generation RPG proxy program. Basically the proxy's job is to extract the request from the EGL Rich UI runtime and invoke the appropriate business logic.

It's a little more complex than that. If you're testing locally your request is automatically redirected to the local proxy that runs inside the workbench. The proxy calls your CGI service and your service extracts the data from the request. The request looks something like this:

{"bindingName":"PollService","method":"getPoll","params":[0]}

And you return data that looks something like this:

{"result" : { "name" : "Language Poll", "choices" : [{ "choice" : "RPG", "votes" : 87},{ "choice" : "EGL", "votes" : 33},{ "choice" : "PHP", "votes" : 2}]}}

Not too difficult. However, once you deploy to your host machine, things get a little more complex. The runtime no longer uses the proxy in the workbench, and instead it has to send to your proxy. Your proxy program then has to unbundle the request from the larger request, which now looks like this:

{"uri":"http:\/\/IRUIHOST\/cgi-bin\/POLLSVC2.PGM","queryParameters":{},"method":"POST","body":"{\"bindingName\":\"PollService\",\"method\":\"getPoll\",\"params\":[0]}","headers":{"EGLREST":"TRUE","egl_statefulsessionid":"JSESSIONID","Content-Type":"application\/json; charset=UTF-8"}}

A little more ugly, no? Not only that, you have to also buffer your reply into something just as complex. However, I managed to hide most of that complexity in a single program named EGLPRSCGI. I then have two programs, POLLCGI2 and CGIPROXY, each of which calls EGLCGIPRS to get the parameters from the client. Each then calls POLLSVC1, which is the actual business logic, and then formats the response as needed (CGIPROXY does a lot more formatting).

Eventually, CGIPROXY would have to recognize all the various requests and call the appropriate service program. But for now, you can get the project, and you can see the result on the SWICD website:

http://see-what-i-can-do.com/poll2.html

It's pretty slick, actually.

The project interchange file is on the project interchange discussion post.

Over the last few days, I have been asked several times - "Why EGL?". It's a good question. For those of us that have been around EGL, the answer is obvious: spend more time innovating and less time fighting with technology. For those of you that are not familiar with EGL and the new EGL Community Edition tool, here are some of the key benefits. These benefits should resonate if you've ever fought with JavaScript

1. EGL does not replace HTML, JavaScript, or Java, but makes development of HTML, JavaScript, and Java easier. EGL code is compiled (on the fly) based on where it needs to run. EGL code that is expected to run in the browser is compiled into JavaScript and HTML. EGL code that is expected to run on an application server (like Apache Tomcat) is compiled into Java.
2. Build a complete application in one language (EGL). So, instead of coding server-side logic in one language (like Java or PHP) and client-side logic in another (HTML and JavaScript), with EGL CE, you can code the entire application in EGL. This allows you to learn just one language and not several. Another major benefit of this approach is that data is represented the same way in both server-side and client-side EGL code. So, for example, you can define a Record (a record is an EGL concept similar to a Java bean for representing some data object) once and reference in both your server-side code and client-side code. The record is automatically compiled into Java and JavaScript as needed. EGL handles the serialization and parsing of the actual data being transported (between the server and browser) so you don't have to worry about it.
3. Completely code, test, and debug without deploying anything to an application server. The Preview tab of the EGL editor provides a running version of your application. When you switch to this tab in the editor, your EGL code is compiled on-the-fly. You can also set breakpoints in your code for easier debugging (EGL CE uses the standard Eclipse Debug tools and perspective). Best of all, you don't have to deploy services to a server to debug them.
4. Transparent client/server development. With EGL CE, all code - both code that will eventually run as JavaScript in a browser and Java on the server - is developed in the same Eclipse project (of course, you can always develop in separate projects if needed). From within your UI code, you can directly reference and call services. Under the covers, EGL will create a REST service for your services and take care of the bindings necessary at runtime.
5. Integrating with existing services. EGL supports calling existing SOAP and REST (JSON or XML) services. So, if you already have Web services up and running, you can use EGL to build a new UI. Within your EGL code, input and output to the service is represented as EGL variables or records. In the case of SOAP services, EGL will automatically create the input and output records for you - all you need to do it import the WSDL file.
6. Data access. EGL makes interacting with databases simple. EGL provides simple keywords (get, add, delete, etc) to easily work with a database.
7. Easy deployment. With EGL, you can fully develop and test your application before ever deploying it to a server. Once you are ready to deploy, however, EGL CE deploys code into a standard Eclipse Dynamic Web project. This project can be run on Apache Tomcat or packaged as a .WAR file and deployed to an external application server.

In an earlier posting I mentioned the importance of using external style sheets to separate look and feel from behavior in EGL Rich UI applications. In practice, some EGL Rich UI users have experienced challenges in keeping the CSS syntactically valid. The CSS editors that come with Eclipse/WTP, and which we use without change in RBD, do not validate the CSS that is being edited inside them. And RBD does not add any extra help either.

Not having CSS validation in our tooling makes CSS error detection and debugging more difficult. The best technique we can come up with is to use Firebug in Firefox, but that requires quite some extra setup and work by the developer. A very useful online service called Jigsaw is also available at w3.org. You simply enter your CSS into a form, and the service will tell if it is valid CSS or not. Here is the service with an intentionally invalid sample:



After pressing the "Check" button, you will see a result looking like this:



While using the Jigsaw service, I was thinking that the Rich UI application that I was developing could easily validate itself by making a REST service call to the same Jigsaw service, passing its own CSS files as an argument. So, I wrote an EGL Rich UI widget (without needing any JavaScript, of course). It basically does the following:

1. Inspect the document body, and find all elements with tag name equal to "LINK".
2. Download each CSS file and send it to the CSS to the Jigsaw service.
3. Parse the result by finding all the "td" elements with class equal to "parse-error" (which is how Jigsaw reports its errors).
4. If we find any error, report them. Otherwise, be silent.

handler CSSErrorsDemo type RUIhandler { 
		initialUI = [ validator ], 
		includeFile="css/bad.css" // located in WebContent directory!
	}
	validator css.CSSValidator{};
end

The actual widget is shown below. Copy it to your workspace, feel free to rename the package name. Let me know when you find any problems with it.

When developing browser applications, you will sooner or later want to call a service to download some data. That service itself is encoded in either SOAP or REST, and can reside at either the same server where the UI came from, or be at a completely different server. EGL hides all this complexity and generalizes the access and encoding of services into a clean and easy to use abstraction.

What is an Ajax Proxy?

The following picture would be a practical situation:



In the above sample we show a EGL Rich UI application that is served up from a given web server. While executing, it makes service requests to 3 services, one of which is located on the same server it was hosted on, and two services from other servers.

To understand what a proxy is, let’s look at this online definition at dictionary.reference.com:

1. the agency, function, or power of a person authorized to act as the deputy or substitute for another.
2. the person so authorized; substitute; agent.
3. a written authorization empowering another person to vote or act for the signer, as at a meeting of stockholders.
4. an ally or confederate who can be relied upon to speak or act in one's behalf.

In our case, the Ajax proxy takes care of routing the service requests to local or remote services. It can handle SOAP and REST. It is also able to deal with HTTPS tunneling to authenticate to remote services, for instance. It acts on behalf of the program running in the browser to call services on its behalf.

Why an Ajax Proxy?

But, why do we actually need a proxy at all? The reason is the so-called same origin policy, implemented by all web browsers, and that aims to avoid cross-site scripting attacks. It basically ensures that JavaScript hosted on server A can only make Ajax calls to services directly defined on server A, and not on server B or C. A spoofing hacker would love to be able to load his or her JavaScript in your web page, and later make service calls to completely unrelated servers to send them all your cookies and passwords, for instance. To overcome this policy, so that we can actually make a mashup, an Ajax proxy is needed.

It is not just EGL that needs an Ajax proxy. This is a common requirement for Web 2.0 frameworks. A Google search on Ajax Proxy yields over 2 million hits, for instance.

During development, both RBD and EGL CE have an Ajax proxy running right in the IDE. This allows you to call third party services while previewing an EGL Rich UI application in the IDE.

When you deploy an EGL Rich UI application to WAS or Tomcat, which are the supported modes, the EGL tooling will automatically generate an Ajax Proxy servlet and transparently publish it for you, right next to the deployed application. The servlet is implemented in Java (actually it’s really small).

If you want to deploy your EGL Rich UI application yourself to a server without using Tomcat or WAS, an alternative proxy is needed. Alternative are to use a proxy written in PHP (for a LAMP stack) or RPG (for IBM i).

How about Security?

Finally, a few more words on security…. As the EGL tooling puts the Ajax proxy in place to allow browsers to make cross-site calls, it is potentially opening you up for a security attack. For critical applications, the proxy should be secured using JEE security. Furthermore, the proxy should filter the set of third party services it supports, to avoid injected code calling third party rogue services.

Currently, the Ajax proxy used by RBD and EGL CE is not published API, but here is something that may work for you. Once you created a web project to deploy your Rich UI application to, locate its (Java) src folder. In that create a new package called com.ibm.javart.services. In that package, create a new Java class called FilteringAjaxProxy and insert the following code:

package com.ibm.javart.services;


import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * Servlet implementation class for filtering Ajax proxy
 *
 */
 public class FilteringAjaxProxy extends RestServiceServlet {
	 
	//
	// The function that allows filtering of the URL
	// 	 
	private void applyFilter(HttpServletRequest httpServletReq) {
		if (!httpServletReq.getServerName().equals("localhost")) {
			throw new IllegalArgumentException("Filtered URL: "+httpServletReq.getServerName());
		}
	}
	
	//
	// Overloaded methods from RestServiceServlet
	//
	protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
		applyFilter(req);
		super.doPost(req, resp);
	}
	protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
		applyFilter(req);
		super.doGet(req, resp);
	}
	protected void doDelete(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
		applyFilter(req);
		super.doDelete(req, resp);
	}
	protected void doPut(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException	{
		applyFilter(req);
		super.doPut(req, resp);
	}
}

Inside the applyFilter method you can do whatever filtering you want. In this sample, I simply limit all Ajax calls to target only localhost. Use content assist on request to see what other things you can filter on, such as port number.

Then edit the web.xml for this project (under WebContent/WEB-INF). Make sure the ajax proxy is configured as follows:

<servlet>
	<display-name>EGLRichUIProxy</display-name>
	<servlet-name>EGLRichUIProxy</servlet-name>
	<servlet-class>com.ibm.javart.services.FilteringAjaxProxy</servlet-class>
	<load-on-startup>-1</load-on-startup>
</servlet>

Just be aware that RestServiceServlet is internal API and is subject to change.

Once you download and run Rational EGL Community Edition, you'll notice the Welcome page which provides useful information about the product and links to tutorials, samples, and Web resources.

You'll also notice some projects are loaded into your workspace. These projects contain the widgets for EGL Rich UI and Dojo, as well as samples of how to use the widgets. Explore the com.ibm.egl.rui.samples.ce project, by opening the contents.egl file under EGLSource>gallery and clicking on the Preview tab. Similarly, you can start exploring the com.ibm.egl.rui.dojo.samples project by opening Gallery.egl under EGLSource>dojo.sample. The Preview tab allows you to interact with the running application. You can make changes and see them in action, without having to deploy to a Web application server. Using the Preview can really help speed up your development.

Once you've had a chance to explore the samples, create your own EGL project. More on EGL projects in a later post...

We hope you'll find EGL easy to learn and use!

It looks like I may have bitten off more than I can chew with this little project. I'm not completely certain, but it looks like the concept of an EGL Rich UI application using nothing but an HTTP server is not going to work. Unless I'm mistaken it looks like the Rich UI REST calls go through a proxy servlet. This is done for a practical reason; it allows the Rich UI to make calls to services other than the original host, a feat which is not allowed in normal AJAX calls. However, it does mean that even if the actual REST service is served by Apache (such as my RPG-CGI service), the proxy servlet still needs to be running in a web application server on the host.

Thus the vision of a Java-free Rich UI application has hit what may be a fatal roadblock. (Note: the reason it worked in debug is that evidently the workbench has that proxy server magically enabled. I still don't have all the details on that bit of sleight-of-hand, but I'll let you know if I get more specifics.)

It was still a useful learning experience, but all in all I'd have preferred a better outcome. In any case, I think it's time to put the Java-free RUI on the side and get back to traditional Rich UI development. And if nothing else, I've got a cool widget written.

Look for the "normal" version in the next day or two.

Given how easy it was to create an RPG-only service, I've decided to kill two birds with one stone with V2R1. I'm going to create my first persistent widget, and I'm going to do it without any Java code (and thus, without the requirement for a web application server). I'll eventually return to this code and rewrite it using traditional host-side EGL for the service, but this first non-Java version will be an interesting exercise.

The concept of a "persistent widget" is going to be crucial to this project. The term means a widget that persists between accesses and can be accessed by multiple sessions. In its simplest form, a persistent widget is simply a widget backed by a database. In my first go-round I think I'll create a "Poll" widget. A poll will have a unique name, and for children it will have choices, each of which has an attribute of choice text and number of votes.

The EGL record for this will be wonderfully simple, and unless I'm mistaken the RPG program will be very simple as well. I think that by my next blog entry I ought to be able to create an RPG program that not only returns a Poll object, but also allows update. That should then make it almost trivial to create a user interface that allows anyone to vote in the poll.

What do you think? My idea is that we ought to be able to create a whole library of self-contained persistent widgets which can then be used to build applications. What other widgets do you think might make sense?