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"