EGL and i

Previous Next
8

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.

Tags: example, rich_ui, richui, i, rui, rpg, web2.0, soa


Sep 7, 2009 8:13 AM Click to view Ortwin's profile Ortwin

Too bad Joe. I also got all excited for a Java-free RUI. Maybe in time IBM will include a proxy-free call mechanism for HTTP requests...

Sep 7, 2009 9:43 AM Click to view JoePluta's profile JoePluta in response to: Ortwin

Yes, I agree a Java-free environment would have been very nice to have, especially for the IBM i. Most RPG programmers can write RPG-CGI programs; it's simply a matter of a couple of API calls. And setting up the HTTP server for CGI is a snap. A proxy-free request mechanism is definitely something to ask for. Even if it were sort of a "raw" service: execute the supplied URL with the protocol removed rather than the proxy, and make the service extract the data and format the return value as a JSON string. That would be the price you pay to avoid Java.

Sep 7, 2009 11:29 AM Click to view ChrisLaffra's profile ChrisLaffra in response to: JoePluta

The browser forces what is called a "same origin" restriction on Ajax calls. That means that JavaScript code that wants to make an XmlHttpRequest call it can only go back to the same server+portnumber combination where it was originally served up from. This is to avoid hackers performing cross-site scripting (XSS) attacks on unsuspecting clients.

When you deploy your EGL Rich UI application on WAS or Tomcat, the EGL tooling will automatically create a servlet for you and deploy it with your RUI application in the same EAR. The servlet is resolved as __proxy, and is used to do cross-site Ajax calls.

When you deploy your application to the local file system (which is one of the options), you can take the resulting files, and copy/ftp them yourself to an existing Apache HTTP server (or IIS). The challenge that remains is how to serve up the service calls. When I deployed my conference schedulers on http://eglplanner.com, I wrote such an Ajax proxy in PHP (which is really not hard at all). RBD and EGL CE do not support that in our current products.

Sep 7, 2009 11:33 AM Click to view ChrisLaffra's profile ChrisLaffra in response to: ChrisLaffra

See http://www-949.ibm.com/software/rational/cafe/docs/DOC-3247 for a PHP proxy

Sep 7, 2009 11:44 AM Click to view ChrisLaffra's profile ChrisLaffra in response to: ChrisLaffra

You can also download the proxy here: http://eglplanner.com/rsc2009/___proxy.zip

Sep 7, 2009 11:47 AM Click to view ChrisLaffra's profile ChrisLaffra in response to: ChrisLaffra

In order to use the PHP proxy, instead of the default __proxy, add the following JavaScript code to any externalType you define in your application: http://eglplanner.com/rsc2009/UsePhpProxy.js

Sep 7, 2009 11:49 AM Click to view JoePluta's profile JoePluta in response to: ChrisLaffra

So really all I need to do is write my own RPG-CGI proxy. It can process the calls and call the appropriate program. I just need to make it respond to the ___proxy request.

Sep 7, 2009 11:52 AM Click to view JoePluta's profile JoePluta in response to: ChrisLaffra

Or, as you've written here, I can write my own version of the doInvokeInternal routine. That might also be a cool option, because I'd be able to pass parameters however I wanted, including using parameters on the query string (?parm1=this&parm2=that). Either way would work, because it's basically a one-time infrastructure effort.

Okay, maybe I haven't written myself completely into a corner :).

Blogs at a Glance

Can't find a specific blog? Try using the Blog page to browse and search blogs.

Request a Blog

Interested in blogging on EGL Cafe? Contact us!

Popular Blog Posts

Bottom Banner