Skip to content

Jini as a replacement for WSRP

January 13, 2005

I was attending a presentation on WSRP, when it struck me that Jini could solve this problem in a much more elegant fashion.

WSRP “Web Services for Remote Portlets” is a standard for aggregating content from remote producers. A typical use case might be your HR department exporting an employee lookup portlet that can then be aggregated into other portals throughout the organization. WSRP is an attractive alternative vs. having to distribute and install the portlet in each portal instance.

During the presentation I got to thinking about how Jini could solve this problem. What if each remote producer was a Jini service that implemented a well known Portlet API (let’s call them Jinlets). Remote Jinlet services register with all available Jini Lookup Services (LUS). An aggregating Jini portal would show the user a list of all Jinlet services that can be found in the LUS. The user would choose which Jinlets they want to subscribe to.

This solution would have all the administrative benefits of WSRP (namely, zero installation effort on the aggregating portal). But a Jini solution would offer additional benefits over WSRP.

WSRP introduces additional latency because user interaction
is required to be passed through the aggregating portal to the remote provider. This interaction is over SOAP/HTTP – not exactly the speediest protocol on the planet.

Jini could support this model (i.e. all the “smarts” are on the remote provider end), but it could also support smart proxies where some or all of the logic is on the portal consumer side of the wire. Additionally, Jini is protocol agnostic, so communication to the remote service could use a high performance protocol.

You could also do some interesting things that leverage Jini’s self adapting nature. Remote services that go down would no longer be registered in the LUS, allowing the aggregating portal to alter it’s list of available services. Service availability can be increased by running multiple copies of the remote service. For example, user’s probably don’t care which particular instance of a stock quote service they subscribe to.

What do folks think? Is this a good idea or just crazy talk 🙂

  1. January 14, 2005 11:08 am

    Warren this is exactly where Jini adds value in this kind of environment.

  2. January 27, 2005 5:29 am

    Sounds interesting. But I am now very sure about it’s possibility of implementation. Let’s wait for few more responses.

Comments are closed.

%d bloggers like this: