portals-wsrp4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ridwan Habbal <ridwanhab...@hotmail.com>
Subject RE: Concerns about WSRP
Date Mon, 11 Aug 2008 08:47:52 GMT
Hello Manish, 
 
Thanks for your detailed explanation. you have the right not to understand the forth point,
I don't know why i mix words together sometimes. Threre you are the correction: 
 
It seems that the portal server that hosts the portlet should also be exposed for end-user
interactions since WSRP only manage markup fragments (html my case), but usually downloads
are not done through portal! 
 
In other words, usually when you call a url from a portal you call something like http://portal_ip_address:portal_port/portal_app_name
and this would each portlet to generate markup fragments, probably html, and portal would
aggregate them as one html page. 
However when we want to perform downloads, either for files generated dynamically such as
exporting data to excel, or static data like images, we call a different pattern of urls,
it would be actually such http://portlet_ip_address:portlet_port/portlet_app_name (ofcourse
portlet_ip could be portal_ip, similarly to the port) and this would call a servlet with http
request & response. As you know this is due to the need to change the MIME type of the
response from html to some binary. 
Now, this won't be a problem sine end-user interacts directly with the server that hosts both
portlet and the portal. In WSRP situation, the portlet won't be on the same server the end-user
interacts. So the question should the host server that contains portlet exposed via WSRP,
should that server be exposed for network access by end user? cause i guess the user that
way calls portlet directly not through portal. 
 
Now, plz let me ask you for further assistance, I see that https://portal.dev.java.net/ is
the parent project of https://wsrp.dev.java.net and project https://portlet-container.dev.java.net
so what i understand is that https://portal.dev.java.net/ a whole portal project, and the
other two projects are just portlet container, and the second is to produce and consume portlets
via WSRP. so in case I would like to use the whole portal i would use https://portal.dev.java.net/
and all it's sub-projects. However if my ultimate goal is merely to expose some portlets deployed
on tomcat to be available to WebSphere via WSRP, then i just need to use https://portlet-container.dev.java.net
to host portlet, and https://wsrp.dev.java.net to expose my portlet through WSRP. 
 
Final question, should i do any change my portlet code, or the portlet would stay the same
whether it's accessed normally (by the hosting portal) or by WSRP. I guess i just need to
add some glue code for the WSRP producer. 
 
Sorry this a long email, but i would be thankful to get a response from you. Others are of-course
invited. :)
 
Regards
Ridwan
 
 



Date: Sun, 10 Aug 2008 09:04:43 -0700From: manish_guptaji@yahoo.comSubject: Re: Concerns about
WSRPTo: wsrp4j-user@portals.apache.org



Hi Ridwan, There are free alternate available..for example, WSRP implementation at https://wsrp.dev.java.net.
You can try it. Here are answers to your concerns:1. Your assumption that you need portal
server at both producer and consumer end is not fully correct. At producer side, you need
only producer webservice implementation. This webservice can itself provide run time environment
to your portlets or it may use any other implementation of Portlet runtime (also called portlet
container). In case of above WSRP implementation, this run time is provided by another project
at https://portlet-container.dev.java.net. At consumer end, you need portal or some sort of
application which can assemple markup returned by different portlets on a single page.2. Most
of the comercial offerings of Portal servers and few open source portal server provides wsrp
consumer and producer implementation. Yes, you can deploy above mentined WSRP implementation
on tomcat and publish your portles using producer webservice.3. Yes, whever you mentined in
point 3 is possible but I am not aware of Gridsphere.4. I am not able to understnad your 4th
concern.Please let me know if I am not clear on above.Regards'Manish.--- On Sun, 8/10/08,
Ridwan Habbal <ridwanhabbal@hotmail.com> wrote:
From: Ridwan Habbal <ridwanhabbal@hotmail.com>Subject: Concerns about WSRPTo: wsrp4j-user@portals.apache.orgDate:
Sunday, August 10, 2008, 5:25 AM










Hi,  I'm new to WSRP. The purpose made me interested in WSRP is that i am developing a portlet
that will get deployed on WebSphere portal server. Since the license of WebSphere portal is
expensive i would try to deploy the portlet on a cheap or maybe free web application, and
then expose my portlet as WSRP for my WebSphere portal server. That way the logic that consume
recourses would not be on WebSphere portal that has an expensive license.I would like some
one to confirm these tiny questions before i spend much time on doing it.  Based on my reading
so far it seems that i do need portals on both sides, Producer, as well as Consumer! is that
right? WSRP producer and WSRP consumer seems to be built-in in portals. so I wonder if i can
deploy my portlet on
 say tomcat, and that tomcat has producer, so i can publish my portlet as WSRP using that
producer. since WSRP is a webservice, so if i have to use portals on both sides, i can deploy
my portlet on say Gridsphere using tomcat and then publish it as WSRP and then consume it
from the WebSphere portal server. It seems that the portal server that hosts the portlet should
also be exposed for end-user interactions since WSRP only manage markup fragments (html my
case), but usually downloads and not done throw portal!  Could u please answer my 4 concerns
i mentioned above? thanks in advanceRidwan  

Get Windows Live and get whatever you need, wherever you are. Start here. 
_________________________________________________________________
Your PC, mobile phone, and online services work together like never before.
http://clk.atdmt.com/MRT/go/108587394/direct/01/
Mime
View raw message