JSR 168 Portlet Specification is final

Home

News: JSR 168 Portlet Specification is final

  1. JSR 168 Portlet Specification is final (16 messages)

    The Expert Group of JSR 168 Portlet Specification has published the Final Release of its specification.

    The Portlet specification will define a Portlet API that provides means for aggregating several content sources and applications front ends. It will also address how the security and personalization is handled.

    Now we have a final specification, we *really* will see what comes of portlets. There are many portal containers, and mroe and more portlet components being announced.

    View JSR 168 Details

    Download the JSR 168 Portlet Specification (Final Release)

    View TSS coverage of the vote

    Threaded Messages (16)

  2. Most J2ee Portals are slow in their initialization and running. With 186 spe u we need a Factory to convert HttpRequest into an action or Render Request which is quite the same as the infamous ejb Home interface. K.I.S.S is key to make J2ee platform the viable choice for developing web application or portals
    Faisal
    UK,B'Ham
  3. I think the standard api and portability is much more important than performance. Also when you break the portal into many fragment (portlet) you can cache a lot of thing. I believe that you will have better performance with JSR 168 compilant portal. My current linux box (athlon 700M) take only 30ms to handle a request without caching enable

    Tuan Nguyen
    eXo development team
  4. brings up the problem of distributed cache .. and no i can't afford coherence right now ... but i'm personally thrilled that app developers can take advantage of the multi vendor spec.
  5. It's off to the races![ Go to top ]

    It turns out that there are at least 14 open source portal servers than plan on supporting JSR-168. (see http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java/view )
    I expect some consolidation and a massive upsurge in portlet development.

    Pickings are aplenty in the java world!
  6. You statement is false, at least for the eXo platform implementation:

    " we need a Factory to convert HttpRequest into an action or Render Request which is quite the same as the infamous ejb Home interface"

    In the eXo platform, PortletRequest (and then inherited ActionRequest and RenderRequest) and PortletResponse are transient objects that are taken from a pool and fill with the incoming HttpServletRequest and HttpServletResponse.

    Also, as Tuan precised, we made some stress tests (using JMeter) and the results are very good without cache and even better with cache (not manadory in JSR 168 spec) enable.

    Also even if we were using a factory this would not be the same as the "the infamous ejb Home interface" because that would be totally transparent to portlet developer.

    Cheers,
    Benjamin
  7. IBM portal and JSR 168...[ Go to top ]

    Any idea when is the IBM websphere portal going to support JSR 168.

    Also , presently IBM stuff builds on Jetspeed. But in my understanding Jetspeed2 is in direct competition to websphere portal . and Jetspeed 2 is going to be built on pluto.

    how does IBM relate to Pluto and Jetspeed now????

    Still wondering if I should write my portlets as of now or maybe wait till 2004
  8. weblogic portal server[ Go to top ]

    do weblogic portal server support JSR 168
  9. weblogic portal server[ Go to top ]

    Yes. Go and checkout dev2dev.bea.com.
  10. Nah, stick with WPS 5...you'll be better off[ Go to top ]

    IBM is a co-Spec lead of Java Specification Request (JSR 168), which is
    designed to facilitate a common development approach for portal integration.

    At such time as the specification is finalized and published, IBM intends to
    provide technical information outlining differences in capabilities when
    using the JSR 168 Portlet API to create portlet applications, and additional
    features supported by the current WebSphere Portal API. Technical
    information provided will include programming guidelines when using the
    WebSphere Portal API to migrate portlets to the JSR 168 Portal API. After
    the JSR 168 specification is finalized and published, IBM intends to support
    applications created using the JSR 168 Portal API operating on WebSphere
    Portal platform via a fixpack release to WebSphere Portal V5. "
  11. Surprising.....[ Go to top ]

    Quite a discouraging comment.....

    It seems that you represent IBM and it is very disappointing to see that IBM is not pleased with the spec(JSR168) and says there are not many features that will be supported in JSR .

    If IBM is one of the spec leads then why did it not make the efforts to make the spec as per what they wanted.
  12. JSR 168 vs WSRP[ Go to top ]

    How do end-customers and ISV's feel about the pros and cons of JSR168 vs WSRP?
  13. JSR 168 vs WSRP[ Go to top ]

    These standards are not competing, but are complementary. JSR168 specifies a programming model, while WSRP specifies plumbing for aggregating remote portlets into portals. So, I'm not sure what you mean by "JSR168 vs WSRP".
  14. WSRP & JSR168[ Go to top ]

    If you are an ISV you may have a choice to make. Imagine you are an ISV who has a product. You want to provide a series of portlets to interact with and administer that product. You have two choices.

    1) Build out JSR168 portlets which can be deployed into any JSR168 complaint portal server

    2) Provide a WSRP end-point which provides the portlets.

    The two can and do accomplish the same thing for the ISV which is a single common piece of code to create a portlet front end to their application. One is a push mode (JSR168) where you stick your portlets into a portal server, one is a pull model (WSRP) where you let the portal browse for, then pull down your portlets.
  15. WSRP & JSR168[ Go to top ]

    I think you're speaking with some specific implementation details in mind. As far as these two specifications are concerned, these are complimentary. JSR168 just specifies an API for writing portlets. It does not deal with any aggregation model (such as the push or pull models you're talking about). As far as this spec is concerned, a portlet container is one that can host compliant portlets.

    On the otherhand, WSRP is just concerned about aggragating a remote portlet into another app (such as a portal). It does not matter how that portlet is implemented. It may as well be a legacy webapp, or a portlet written using some API (such as JSR168).

    Typically, an implementation of a portlet container for JSR168 implements the WSRP web services, while portals consume those remote portlets by invoking WSRP web services.

    In your example, the ISV may just implement JSR168 and aggregate them locally, or deploy the JSR168 container remotely and use WSRP to aggregate those portlets.

    Subbu
  16. Portlet article @ ibm.com[ Go to top ]

    http://www-106.ibm.com/developerworks/websphere/library/techarticles/0312_hepper/hepper.html
  17. ATG Portal supports JSR 168[ Go to top ]

    ATG is now shipping support for JSR 168 in its portal product. To download an evaluation copy see http://www.atg.com.