Verse Of The Day

Friday, February 17, 2006

OpenLaslo And Java RPC

Continuing on my evaluation of the OpenLaszlo 3.1.1 web application development environment ( ), I’ve got the Java RPC stuff working. You can build POJO Java classes and put them in the Laszlo’s WEB-INF classes or lib directory, and then call them from your LZX code.

Last night I built a simple class with a method that returns an XML snippet. Easy enough, it took maybe a half hour to get it all perfect. Today, I got a little more complex and made a class that talks to a WebSphere MQ server, getting queue depths, and putting and getting messages from queues.

I tied that into my little sample LZX app, and have buttons that get queue depths and put messages on a queue. Still simple, but I’m starting to see how this can be very powerful. I still need to get better with the front-end LZX language and events handling to make the GUI more robust, but for now I am happy to be able to talk to server-side classes that tie into existing business logic and applications.

To let your LZX code know about a class and allow it to be called, you drop it in the WEB-INF/classes or WEB-INF/lib for JAR files, and then add this snippet of code to the LZX. This explicitly allows the class to be run from LZX via RPC, all others are implicitly denied:


The pattern can be a regular expression, for example to allow everything with a certain package. You could also specify each class individually by putting in multiple <pattern> elements.

To create an instance (or really client side stubs), a chunk of code would look something like this:

<javarpc name="rpcadapter" scope="none" classname="BaseRpcAdapter">

<remotecall funcname="getMqQueueDepth">
<param value="'RAN.TEST.QUEUE'" />

<remotecall funcname="putMqMsg">
<param value="'RAN.TEST.QUEUE'" />
<param value="'blah blah'" />


And then to call the methods, you could do something like this to create a button and tie it to the method:

<button onclick="rpcadapter.getMqQueueDepth.invoke()">
Get Queue Depth

So far it’s impressive, even with the lack of direct DB support. To make this viable in the enterprise, I also have to figure out the security models, and how to lock everything down better.

Side note from yesterday’s post: Still no direct database access. The options right now as I see them are to front-end your persistence and business logic layers with either an RPC adapter like I’ve done here, or expose them via Servlets, JSP, or web services (Session EJB & Apache AXIS is what we generally use).

No comments: