Re: Re[2]: JSR-168 Comments & Dispatching to portlets
Hi Endre,
Well I'm happy to see I'm not the only one with this concern. I was
beginning to think that nobody had this problem except me :)
At 11:54 AM 7/29/2003 +0200, you wrote:
My problem is that is seems impossible to do both of:
a) Have a Portal implemented on top of a standard Servlet Container
b) Run multiple Portlet Applications, preferrably in a standard Portlet
Container, preferrably -the same- container as the Portal is running in.
.. and be able to, in a standard way, to communicate between the portal
and the portlets.
Yes b) is exactly my problem too. I thought a lot about it and it would be
possible to develop a "sub portlet container" within the portal, using a
custom built portlet container (but that would imply also have to develop a
sub-servlet container, with everything that includes such as classloaders,
deployment descriptor handling, dispatching, etc). This solution is
interesting because it guarantees complete control over the process and
*no* vendor lock-in, but it's a bit of a shame because you are no longer
using all the tools that are available for the top-level portlet container.
So in effect you'd have this :
Portlet / Servlet Container
---
Portal
---
Sub-Portlet / Servlet Container
This would be heavy but optimal in terms of performance. In a way this is
very close to how Jetspeed currently works, as Jetspeed is a Web
application in a servlet container, and defines it's own "sub" portlet
container. In my work, I've designed a portal that uses cross context
dispatching to dispatch to standard servlets, and although it works quite
well, it is not as flexible as the interfaces that the JSR 168 proposes.
This is why I was hoping (and unfortunately I got involved to late to be a
real part of the JSR process) that they would address this issue, as it
seemed critical to me.
From what I understand of my discussion in this mailing list, Pluto does
something in between : it adds within the portlet a proxy servlet that
allows dispatching to the portlets. This way the system I have been using
with cross-context dispatching could be adapted, but it's still not as
efficient as having a portal/portlet full-blown API. Maybe this is the
subject for a new JSR ? Or maybe in this project (Apache Jetspeed) we could
develop what we need and then propose this as a reference implementation
and submit it as a JSR (maybe that way things would move faster ?). Seeing
how projects such as Xerces and Xalan got accepted throughout the whole
commercial world it would seem like Apache is in a position to "impose"
defacto standards.
One way of solving it is apparently using WSRP as the "glue" between the
portlet and portal.
Yes but at what cost. Serializing all objects through XML and sending them
through sockets that are being opened / closed all the time is very
expensive in terms of performance.
To me, this seems some a kind of vendor lock-in scheme: you buy the
Servlet Engine from us, and wow, it also have a Portal in there,
effeciently doing proprietary communications with the Portlets. You are
suddenly (as it is already) locked to both the Servlet Engine -and- the
Portal (application).
My guess here is that it's indeed a very political issue. All the current
commercial portal vendors involved in JSR-168 could only agree on the most
common and minimal specifications, and they didn't want to have too much
standardized or they would loose their commercial edge. It might not be the
case, but as this process has been entirely closed (even for me, and I am
part of the JCP but only as community member !), I can only speculate as to
what went on in the expert group.
I would have loved a spec where the Portal was the Container, and had to
be able to host Portlets within it. This way, one could buy the Servlet
Container from Oracle, use JetSpeed as the Portal, and buy Portlets from
CompanyA, B and C, plugging them in / installing like nice little
applications in a normal OS.
Ok, again I agree. Users of portals should be free to migrate from one
system to another, without vendor lock-in. After all the J2EE specs exist
as Sun puts it : "for vendors to compete on implementation, and agree on
standards". This is a nice vision but reality is more like : "vendors
always compete on anything, Jakarta standardises".
Now enough with my whining, I'll start a quick proposition here : this is
what I would have loved to see in JSR-168 :
1. Standard mechanism for portlet lookup. Maybe JNDI ? Or even UDDI ?
Basically be able to do something like this :
Context context = getInitialContext();
PortletRepository portletRepository = (PortletRepository)
context.lookup("PortletRepository");
// list of portlet example : ArrayList portletList =
portletRepository.getPortletList();
Portlet myPortlet = portletRepository.getPortlet("myPortlet");
2. Direct dispat
RE: Re[2]: JSR-168 Comments & Dispatching to portlets
[Moving the thread to Jetspeed Dev]
> >My problem is that is seems impossible to do both of:
> > a) Have a Portal implemented on top of a standard Servlet
> Container
> > b) Run multiple Portlet Applications, preferrably in a
> standard Portlet
> >Container, preferrably -the same- container as the Portal is
> running in.
> >.. and be able to, in a standard way, to communicate between
> the portal
> >and the portlets.
>
I agree that one of the concerns of the JSR 168 is that it does not
describe any public standard API for the communication between
the servlet container and the portlet container.
It does not mean it's impossible, simply that portability between
servlet containers will be an implementation specific feature of
the portlet container and that you may have to write servlet-container
specific adapter code.
Note that there's another related area where the portlet container
will have to have servlet container specific code: the portlet
application deployment requires you to deploy a standard WAR and thus
use the servlet colntainer deployment capabilities. :/
On the whole, I don't think this lack of APIs is a real showstopper
and would rather see that as an opportunity for an OSS project like
Jetspeed to work on the multi-containers approach while vendors will
most likely try to focus on tying their servlet and portlet container.
>
> From what I understand of my discussion in this mailing
> list, Pluto does
> something in between : it adds within the portlet a proxy
> servlet that
> allows dispatching to the portlets. This way the system I
> have been using
> with cross-context dispatching could be adapted, but it's
> still not as
> efficient as having a portal/portlet full-blown API. Maybe
> this is the
> subject for a new JSR ? Or maybe in this project (Apache
> Jetspeed) we could
> develop what we need and then propose this as a reference
> implementation
> and submit it as a JSR (maybe that way things would move
> faster ?). Seeing
> how projects such as Xerces and Xalan got accepted throughout
> the whole
> commercial world it would seem like Apache is in a position
> to "impose"
> defacto standards.
>
Yes Pluto implements something like this. The key issue to solve
here is request dispatching: how does the portlet container retrieves
a portlet pointer while still fullfilling the JSR constraints (like
sharing session between the portlet and objects in its WAR (JSPs, etc...)
The porxy servlet is mainly a portlet container specific implementation
of this request dispatching, using the native servlet API calls and some
custom parameters.
I don't believe there's a major performance impact there.
>
> >One way of solving it is apparently using WSRP as the "glue"
> between the
> >portlet and portal.
>
> Yes but at what cost. Serializing all objects through XML and
> sending them
> through sockets that are being opened / closed all the time is very
> expensive in terms of performance.
>
Agreed, I don't think WSRP is the solution to this problem.
>
>
>
> > I would have loved a spec where the Portal was the
> Container, and had to
> >be able to host Portlets within it. This way, one could buy
> the Servlet
> >Container from Oracle, use JetSpeed as the Portal, and buy
> Portlets from
> >CompanyA, B and C, plugging them in / installing like nice little
> >applications in a normal OS.
>
That would however seriously duplicate concerns as the portal/portlet
container would have to deal with classloading, WAR handling, etc...
There is some sense to try to leverage these functions of the servlet
container (after all, how many times do you *really* want lo load
xerces.jar ? :)
The JSR 168 tries to guarantee that any compliant portlet will run on
any compliant container. It does not try to address portlet container
portability just like EJB does not address portability of EJB
container implementations (any luck porting JBoss to Websphere
recently ?)
> Ok, again I agree. Users of portals should be free to migrate
> from one
> system to another, without vendor lock-in. After all the J2EE
> specs exist
> as Sun puts it : "for vendors to compete on implementation,
> and agree on
> standards". This is a nice vision but reality is more like : "vendors
> always compete on anything, Jakarta standardises".
>
+1. SO we can try to standardize what's missing from the JSR... :)
> Now enough with my whining, I'll start a quick proposition
> here : this is
> what I would have loved to see in JSR-168 :
>
> 1. Standard mechanism for portlet lookup. Maybe JNDI ? Or even UDDI ?
> Basically be able to do something like this :
>
> Context context = getInitialContext();
> PortletRepository portletRepository = (PortletRepository)
> context.lookup("PortletRepository");
> // list of portlet example : ArrayList portletList =
> portletRepository.getPortletList();
> Portlet myPortlet = portletRepository.getPortlet("myPortlet"
