WSRP4J is architected so that "provider" is pluggable. WSRP4J comes
with an implementation of the provider interface that works with Pluto,
but you can write your own. "Provider" is interface between the WSRP4J
engine (the actual web service responding to SOAP requests), and the
portlet container (i.e. provider).
In your architecture WRT GridSphere, are you trying to implement a
Consumer or a Producer? The WSRP4J Apache project is really all about
providing an open source Producer. We do provided a piece of code
called the Swing Consumer, but this is primarily used to test the
Producer and portlets. You are certainly welcome to use the code in the
Consumer, but it is not fully compliant with the spec, nor is it a very
nice Portal.
Here's a little background you might need. Maybe you know this already:
There are 2 major components in the WSRP spec. One is the Consumer and
the other is the Producer. The role of the Consumer is the Portal. It
is the part of the system that communicates with actual end users, and
aggregates content from remote WSRP Producers and locally hosted
portlets. A WSRP Producer exposes portlets via a webservice
interface. WSRP is agnostic as to how those portlets are implemented.
A simplified way to look at it is that the WSRP Producer is a server of
portlet markup, and the WSRP Consumer is a client.
Hope this helps.
Jason Novotny wrote:
>
> Hi,
>
> I'd like to know what it would take to use wsrp4j in our own
> portlet based portal, GridSphere, available at www.gridsphere.org. We
> our now JSR 168 compliant and have implemented our own implementation
> of the spec. I would rather not have to implement wsrp spec as well
> and would like to use wsrp4j. In the source code, I see lots of files
> pertaining to Pluto, and I wonder what I have to do to support our
> portal-- is this supported/documented anywhere, or is it pretty much
> glued to Pluto?
>
> Thanks, Jason
>
>
--
Julie MacNaught
IBM Research
jmacna@apache.org
jmacna@us.ibm.com
|