JSR168 support with WSRP- good or bad?

Discussions

News: JSR168 support with WSRP- good or bad?

  1. JSR168 support with WSRP- good or bad? (14 messages)

    As Portlets are coming to their full swing, people around big web-applications are discussing about porting to Portlet technology. I was recently working analysing the efforts required to port an existing web-application to a propritery portal server. Such issues are appearing in greater numbers now. One of the alternative is to rebuilt the whole applications from scratch (reusing some components if possible, which ruled out if the backend is not in Java). But one approach could be to use WSRP support to use the existing applications in portal and add over it what ever new functionality we need as portal application.

    As I am not much into WSRP, I am not sure how far this idea is implementable. Secondly, Peoplesoft Portal 8.9 and Oracle Portal supports JSR168 specifications but through WSRP. Is this the right way to do so? Won't it have an affect in efficiency of the portal application? Is it not better to provide the JSR168 support as a part of developement environment (without using WSRP) as is done in IBM, BEA and open sources like eXo, Liferay etc?

    Vikramark
    http://www.portlets-jsr168.blogspot.com

    Threaded Messages (14)

  2. Easier for the enterprise[ Go to top ]

    WSRP portlets tend to be much easier for an enterprise portal. You get mired in deployment issues with JSR168 portlets when you have hundreds of portlets and thousands of pages.

    WSRP lets you move the development and integration issues closer to the business units involved. It also lets you share the burden of hosting and processing.

    The primary purpose of a portal is to integrate.
  3. I can't imagine why someone would want to port a complete web application to a portal unless it was a small application. It just doesn't seem to make sense to have to live within the confines/limitations of a portal container for a web application of any significant size. Plus, you can't deploy large applications in to a portal (if you're talking JSR-168) -- portal admins aren't going to like deploying an app that needs a lot of memory when they might have a 100+ portlet apps loaded on a decent sized portal server deployment. And even more important, that app will only run in a portal in this case. And if you try to make it both a portlet based app and a regular app then you're going to have sacrifice somewhere.

    My personal preference would be to build portlets that can access certain kinds of data within your application that make sense to display in the portal -- and then if you need to go to the full web application have it take you to that web application.

    This is where WSRP could come in and addresses your question somewhat. It'd be great if you could generate WSRP from a web application to show certain pages of workflows in your application within a portal. Then you can pull those exposed portlets into your portal via WSRP. Best of all, when you upgrade your web app you don't have to deploy new portlets (assuming you haven't changed your WSRP exposed services list). I'm unaware of any decent open source tools, however, that make this feasible. But I really haven't looked for these kinds of tools lately so that landscape might have changed.

    And yes, WSRP will affect efficiency in one way and help in another (the portal won't be overloaded with bloated portlets). But then again, when are portals efficient when you're pulling data from so many different sources?

    -Mike
  4. Apps should not be ported to a portal[ Go to top ]

    I think you are right on, and this is why Oracle has chosen to go the WSRP route. They're all about "Enterprise Portals," i.e. portals bringing together data from large apps. Oracle sells lots of large apps, but they don't sell hardware. Thus they aren't going to advocate putting all these large apps in the same container -- enter WSRP.

    That being said, I do think that a lot of your large app functionality can be exposed efficiently through a WSRP portal. I think the key is using a REST architecture for your portlet web services.
  5. Apps should not be ported to a portal[ Go to top ]

    Mike,
    I can't imagine why someone would want to port a complete web application to a portal ..

    You don't / shouldn't. (At least from what I've seen to date.) But you _can_ expose pieces of applications in a portal, which is what integration is all about.
    It just doesn't seem to make sense to have to live within the confines/limitations of a portal container for a web application of any significant size.

    That sounds more like a problem with the container spec ;-)
    [..] portal admins aren't going to like deploying an app that needs a lot of memory when they might have a 100+ portlet apps loaded on a decent sized portal server deployment.

    That's why WSRP exists. I've already witnessed this exact thing. See:

    http://dev2dev.bea.com/pub/a/2005/11/federated-portal-cache.html

    That's from a bank that has lots of different applications that each deploy their portlets separately (different versions, different server clusters, etc.) and they tie them together via WSRP.
    My personal preference would be to build portlets that can access certain kinds of data within your application that make sense to display in the portal -- and then if you need to go to the full web application have it take you to that web application. This is where WSRP could come in and addresses your question somewhat.

    That's exactly right.
    It'd be great if you could generate WSRP from a web application to show certain pages of workflows in your application within a portal. Then you can pull those exposed portlets into your portal via WSRP. Best of all, when you upgrade your web app you don't have to deploy new portlets (assuming you haven't changed your WSRP exposed services list). I'm unaware of any decent open source tools, however, that make this feasible.

    Talk to Rickard / Senselogic.
    [..] WSRP will affect efficiency in one way and help in another (the portal won't be overloaded with bloated portlets). But then again, when are portals efficient when you're pulling data from so many different sources?

    Portals are inefficient. Portlets are inefficient. WSRP is inefficient. The whole stack is inefficient.

    Yet they can solve some very difficult and expensive business problems better than the alternatives, so the processing inefficiencies are minor annoyances. (But they are definitely annoyances when you're deploying large portals! ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  6. I think it makes perfect sense to build applications in portal if portal is your main platform. I don't see why any application should be ruled out based on it's 'size'.
    you can't deploy large applications in to a portal (if you're talking JSR-168) -- portal admins aren't going to like deploying an app that needs a lot of memory when they might have a 100+ portlet apps loaded on a decent sized portal server deployment.

    I guest you are talking about 'putting it al in one war file'. Creating an application that consumes a large amount of memory is bad in any way. Not only within a portal. If you cut it up in pieces (Session beans for the backend that can be put elswhere) you can scale the application. If it is not scalable you have a point, but then you have created a bad design, and you should fix that first.
    that app will only run in a portal in this case. And if you try to make it both a portlet based app and a regular app then you're going to have sacrifice somewhere.

    I seem to miss the point of sacrificing. I find the portlet API (jsr168) a clean API. It does not limit you more than a regular servlet API or HTTP in general (in fact it helps you with the clean separation between action and render phases). You only have to take in account the name spacing, but the rest of the view/controller layer is handled crystal clear.
    Just put your model behind stateless session beans, keep a strong hold on what you get from the model and where and how you cache, and you can built heap friendly apps without any problem.
    It only gets cumbersome once you start combining struts or JSF in the portal. Have not had good experiences with those technologies within the portal. The state pattern is an excellent replacement for these technologies.

    So in general, if you app leans to heavy on the heap, fix the application. Don't 'blame' the portal for your bad design.
    If you have build a 'bad' application, and you are unable to fix it, why not have it run on a separate portal instance, so you can control the resources used? There is nothing wrong with running an extra portal within the same environment. Also WSRP could solve the problem you have with memory consumption, by running it remotely.

    Imho, once you picked the portal as your platform, run all you have on it. It makes integration so easy. Portal as a platform does NOT limit you (more than HTTP does for anybody). If your app is a heap killer, fix it, or run it (or parts of it) remote/separately.
  7. Apps should not be ported to a portal[ Go to top ]

    I am not opposing the points of apps not to be ported on poral,but my concern is that if u are building a portal application,its better that all the preexisting apps should be aggregated on ur portal.The basic idea behind portal is 'aggregation'.If we take an example of a company's intranet ,we will try to collaborate all the new and the old aplication in one place of access.
    Now as far as the effort is concern to change a web-app to a portal app that to jsr168,it depends upon how big-small-clean the application is..More the number of JSP's more the time will take to change as per the portlet.

    --lokesh
    http://lokeshpant.blogspot.com
  8. One of the alternative is to rebuilt the whole applications from scratch (reusing some components if possible, which ruled out if the backend is not in Java).

    I would not recommend porting the entire application to a set of portlets, unless the application was already slated for an intense makeover OR if the move will benefit the application maintenance/maintanability/scalability in the future. Frankly, allowing the portal to perform the "heavy-lifting" will allow your developers to focus on the components and not the underlying mechanics.

    Two options not mentioned here (I think):

    - Why not create portlets that communicate to the existing application's exposed API's?

    - Why not, at least in the interim, use web clipping portlets to act as the user-interface for the existing application? We have several customers doing this already during migration phases, with existing Coldfusion, PHP, etc... apps. ie, http://www.portletbridge.org/
    Secondly, Peoplesoft Portal 8.9 and Oracle Portal supports JSR168 specifications but through WSRP. Is this the right way to do so?

    Right/Wrong is subjective. Since those Portals existed before the Portlet Spec, it may explain why they took that approach. Sounds like a hackjob to me, but who am I to say, really? ;-)
    Won't it have an affect in efficiency of the portal application?

    *Maybe*, but since they price you per-cpu licensing bla bla bla, the inefficiency is *really* in *your* wallet and/or decision makers. ;-)

    STAY METAL!
    Roy Russo
    http://jboss.org/jbossBlog/blog/rrusso/
  9. We are doing quite a lot of integration of existing apps in our portal, and so far we have mainly used two techniques: either a generic simple iframe-portlet with additional functionality to handle SSO with the integrated app, or a generic proxy portlet a la portletbridge.org (actually, portletbridge.org is based on a code donation I made of our own proxy code). The iframe variant works with any application, whereas the proxy variant works with most applications that don't do any funky stuff with frames and/or CSS and/or JavaScript and such. For most smaller apps it works quite well, and provides a good end-user experience. We've even had customers write PHP-apps specifically intended for consumption by the proxy portlet, which is very neat and tidy, and the customer gets to develop his app in any way he sees fit.

    For our own stuff, we have about 60 different portlets available in the standard product (SiteVision), and they all run as JSR168 portlets in a portlet container running in Tomcat. They range from tiny (e.g. "show this text") to reasonably large (e.g. online survey app with admin, statistics, user management). See senselogic.se/referenser for a list of reference websites that use SiteVision in a wide range of ways.

    From a performance point of view we have had a Large Customer do extensive testing and benchmarks, and their new portal-based website with everything dynamic beat their old static Apache+DreamWeaver site in terms of performance and scalability. With realistic usecases we could handle 400k hits/machine/hour with subsecond responses, using a relatively plain Dell/Suse 8 machine (which is way way way cheaper than their old solution). So IMO to say that JSR168 portals are inherently slow is incorrect.

    The long term goals we have for integration is indeed to use WSRP to integrate with all apps. As has been mentioned previously on this forum, I started working on a WSRP implementation with a producer that used proxy techniques a la portletbridge.org to expose a webapp. In other words, it should be possible to take any webapp (within the limits of what is technically possible) and expose it with WSRP by using this producer as a proxy. This minimizes the work required by the app implementor, and also gives them an easy way to validate that what they produce can be integrated in a portal setting. IMO the rule of thumb for when a portal integration should be done is when you have more than one webapp. I.e. it might be a good idea to think about it sooner rather than later. The main reason this isn't happening is (IMO) mainly because of licensing and usability issues with existing offerings, but that is in no way an inherent problem. It's fixable.

    Anywho, just a couple of thoughts on the subject...
  10. Hey Rickard,

    how do you integrate with non markup features of WSRP like user identity and personalization ? does your application integration needs to implement an SPI that would integrate it in the producer ?
  11. Hey Rickard,how do you integrate with non markup features of WSRP like user identity and personalization ? does your application integration needs to implement an SPI that would integrate it in the producer ?
    Well, the WSRP proxy stuff isn't written yet, but our own internal proxy code can do either BASIC auth, or submit login forms and such (which is BY FAR the most common scenario, as most apps are written be relatively clueless developers). It should be relatively easy to make that part pluggable in the WSRP producer proxy. In other words, there is no SPI since most of those things can be done using standard protocols. See Jamie's post about how PortletBridge works, and look at that code. I'm very impressed with what he's done with it!
  12. Disclaimer - I'm the author of the PortletBridge project:

    While I can't speak for the efficiency of using WSRP, one of the options available right now for hosting existing web applications as JSR 168 portlets is the PortletBridge (www.portletbridge.org) project.

    Built on top of code that Rickard has kindly donated, the PortletBridge project can handle most downstream sites and includes configuration options for complex javascript and css rewriting, authentication, proxy support, etc.

    PortletBridge has been tested in JBoss Portal, Liferay, Gridsphere, uPortal and Pluto and has been seen to work in Weblogic and JetSpeed.

    Jamie McCrindle.
  13. PortletBridge packaging[ Go to top ]

    With PortletBridge available I think it would be interesting to see application vendors simply package their existing functionality in pre-configured PortletBridge portlets. I.e. instead of each user having to download PB and configure it to work with an app, the creator of that app could make pre-packaged configurations that has been tested and verified.

    This will make it easy for app vendors to add the "JSR168" checkbox, and also makes it easier for users of JSR168 containers who want to integrate apps.

    This is similar to the idea I had about wrapping existing apps with a WSRP proxy producer, except that it is a Java-only variant, which has its perks (performance being one of them).

    I mean, why don't folks like Atlassian make portlets for Jira and Confluence available which simple contains PortletBridge with some pre-configuration done. It'd make it trivial to add those apps to a standard portal without much fuss. I think that would be a good way to bootstrap the whole portlet market.

    Which is, concidentally, why I suggested that something like PortletBridge should be done in the first place...
  14. PortletBridge packaging[ Go to top ]

    +1.

    The JBoss Portal team has worked with Jamie, originally, and are impressed with what you both have done with PortletBridge. It is being considered for inclusion in the default distro for 2.4, to introduce developers/enterprises to the concept and hopefully add support for the PortletBridge project.
  15. PortletBridge packaging[ Go to top ]

    That gives me an idea. Currently PortletBridge uses HttpClient to make downstream calls but it could use a RequestDispatcher (or PortletRequestDispatcher) if it's deployed as part of a web application.

    If anyone wants to use PortletBridge to bootstrap their application like Rickard describes, let me know (dkfn at users.sourceforge.net).