-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ali Sakebi escribió:
> Do you mean that exposing a web app directly as wsrp (without using
> jsr168 as an intermediate) is not a standard way of using wsrp (in
> Java world)? First I should use some bridge to convert ordinary web
> app to jsr168 and another one to convert jsr168 to wsrp. Doesn't it
> (using jsr168) duplicate complexity of the solution and/or remove some
> functionality of wsrp?
>
> BTW, thanks for useful info about how to develop non-jsr168 solution.
>
> On 12/3/06, Diego Louzán <[EMAIL PROTECTED]> wrote:
> Ali Sakebi escribió:
>> What about non- jsr168 web apps? I there any sample?
>
>> On 12/3/06, Diego Louzán <[EMAIL PROTECTED]> wrote:
>> Ali Sakebi escribió:
>>> Does anyone know what does "producer" do and how does it works? Or how
>>> can I use WSRP4J to expose a web application as WSRP?
>
>> Using Producer you can expose any jsr-168 portlet app as a WSRP
> service.
>> The current svn doesn't work for Producer, so you can't use it. For a
>> working version, you can download an old snapshot from here:
>
>> http://wiki.apache.org/portals/WSRP4J/WorkingSnapshots
>
>> Select "Attachments" on the menu to download the snapshot.
>
>> Regards.
>> Diego.
>
>
> If you're asking about a non-standard solution, I mean, if you have your
> own service developed (non-jsr-168) and you want to expose it as a WSRP
> service, then you'll need to implement your own wrappers around wsrp to
> be able to expose it as wsrp. Using wsrp4j, you can use the classes
> provided by org.apache.wsrp4j.producer to implement your solution. The
> classes under org.apache.wsrp4j.producer are the standard interfaces for
> the producer; the classes under org.apache.wsrp4j.producer.provider are
> the wrappers around the actual backend service for the producer: that
> is, if you provide your own implementation of the
> org.apache.wsrp4j.producer.provider interfaces, you can have your
> service exposed as wsrp.
>
> Regards.
> Diego.
>>
WSRP portlets and JSR-168 portlets share many ideas (in fact, the
specifications were both developed simultaneously and with each other on
mind). Since the JSR-168 release, it has become the standard for
developing portlets in Java: it was its goal and it makes portlet
portability easier. So, WSRP4J provides a way to plug your JSR-168
portlet into the WSRP4J Producer, and producer will expose that portlet
as a WSRP service, there isn't any duplication of work, you must somehow
implement your wsrp services, and this is the "most standard" way in
Java. Why develop a new backend for wsrp portlets when you can expose
your own portable jsr-168 portlets using a bridge? You leverage your
portal container, which can manage jsr-168 portlet natively, by exposing
them as wsrp.
If your portlets aren't jsr-168 you have two options:
* Port them to jsr-168 which is the standard in Java, and then expose
them using wsrp4j. Take into account that jsr-168 specification doesn't
address issues like inter-portlet communication (the new version 2.0,
jsr-286, addresses this but it's still in development).
* Develop your own wrapper around wsrp by implementing your own solution
OR provide your own implementation of
org.apache.wsrp4j.producer.provider classes which connect the Producer
implementation to the actual backend portlets serving the requests. In
case of WSRP4J, these provider classes implementation connect Producer
with Pluto Portal as a proof of concept.
Regards.
Diego.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFc1MYgyzZYflJelERAqSoAJ47IapvpFzgoBeKj4rDiUmWZIbrEgCeLPXj
LY6mRCX2w2h42V5icGFDwZI=
=zpMA
-----END PGP SIGNATURE-----
