Products
Rob Brooks-Bilson's Blog
I've been doing a lot research into corporate portals lately as part of my job here at Amkor. I've evaluated the offerings of some of the major players such as IBM, Plumtree, and Oracle, and am always interested in how we can leverage our investment in ColdFusion within the portal space, which is dominated (mostly) by Java.
The Portlet specifiation as outlined in JSR 168 and the Content Repository for Java technology API outlined in JSR 170 (both of which Macromedia participate in) standardize the framework for portlets in a vendor/application server neutral way. To me, this standardization and the fact that Java is the portlet technology of choice has me wondering if Macromedia could/will support portlet development within ColdFusion in a furure release of ColdFusion MX.
As I see it, there are (at least) two ways this could be supproted. The first, and probably the simplest would be simply to have ColdFusion MX expose "remote" portlets as web services. WebSphere v5 now supports remote portlet calls, as long as they are registered in a UDDI directory and (presumably) adhere to a specific WSDL format. IBM Portal Server and Web Services, a whitepaper from IBM explains how this works in some detail.
The second way I see ColdFusion supporting portlets would be to actually write the portlet using CFML, and have the underlying CFMX (JRun) application server compile the code to Java and package it up appropriately as a WAR file.
Possibly interesting as well would be how this could be done if you were running ColdFusion MX on top of a J2EE application server (such as IBM WebSphere) that was running as the portal server.
What do you think? Is this something that seems reasonable or even desirable for a future version of ColdFusion?
Aura skin for Raymond Camden's BlogCFC inspired by Joe Rinehart & Steven Erat. This blog is running version 5.9.004.
We don't support the portlet API at this point since it was just published, but we are certainly aware of it.
Jakarta has a project called Pluto (http://jakarta.apache.org/pluto/) which provides a basic portlet container specifically for Portal integration to provide near instant compliance (at least with respect to the portlet invocation). The Jakarta Portal project Jetspeed will leverage Pluto for JSR168.
It's early days yet, but i think a generic CF interface to Pluto would be a fantastic start to providing easy JSR168 tools for CF applications to implement the JSR168 spec.
Are you interested in collaborating?
Very interesting. We've actually just started working on a FarCry implementation here at Amkor for our external web site. We've just begun playing with FarCry and have been impressed so far.
I'm glad to hear that you are thinking of FarCry/Portlet intgration, and I'd definitely be interested in collaborating. As things develop, let's keep in touch on the subject!