Portlet 2.0 specification released for review

Discussions

News: Portlet 2.0 specification released for review

  1. The JCP has released an early review of JSR-286, the Portlet 2.0 specification, and is requesting comments. The review doesn't contain everything that the specification will have, but focuses on collecting comments on WSRP 2.0 (Word document, URL found by Frank Bolander on a previous thread on TSS) from OASIS. WSRP is a specification for Web Services for Remote Portlets - which means that a portal can theoretically include a WSRP consumer with a URL endpoint, and the portal could then use that URL to include a portlet from a remote site. One example of this is a shipping portlet. If Shipping Company X has a portlet that can be downloaded to a portal locally, then when Shipping Company X updates their portlet, every portal using that portlet needs to upgrade. However, if the portlet is invoked via WSRP, then updates would be reflected automatically on every remote portal. It's possible that Your Humble Editor misunderstands WSRP on some fundamental level; anyone want to step in to correct/educate/confirm?
  2. What are scenarios where a person really needs a big portal from a big vendor? * Using Acegi Security, you have a great security framework to manage all aspects of security. * With cascade style sheets, you can manage the look and feel throughout the application. * With Ajax, you can get many of the benefits of portals like components in the page that behave independently. Data aggregation is useful, so is single sign on, but you don't need a big portal from a big vendor to do both.
  3. yeah, Portlet also need a heavy Portlet container, maybe with ajax and other web framework. Portlet is out of use...
  4. Portlet is out of use....??[ Go to top ]

    yeah, Portlet also need a heavy Portlet container, maybe with ajax and other web framework. Portlet is out of use...
    Are you pointing towards the consumption of WSRP2.0 based portlets on your ajax based application that runs on a portlet container.Partially it is the part of WSRP2.0 spec but the ajax framework is what that your client side have to take care may be your IDE or your code. We can wait for some kind of IDE fron JCP that gives you all the framworks with a portlet container. And yes, Portlets are still in use ;) Cheers!! Lokesh Pant http://lokeshpant.blogspot.com
  5. What are scenarios where a person really needs a big portal from a big vendor?

    * Using Acegi Security, you have a great security framework to manage all aspects of security.
    * With cascade style sheets, you can manage the look and feel throughout the application.
    * With Ajax, you can get many of the benefits of portals like components in the page that behave independently.

    Data aggregation is useful, so is single sign on, but you don't need a big portal from a big vendor to do both.
    The benefit to the portal is actually quite big, they lie in not just the heavyweight container, but rather in the actual portal webapp implementation, which provides a customization/configuration interface. The biggest benefit lies in the actual spec, that allows you to design portlets that can be dropped in pretty much any compliant container. This is a huge benefits for vendors of products that people want to integrate into a company portal implementation, instead of having to write these yourself, the vendor might already provide one. A good example would be liferay and alfresco say. If we're using liferay and would like to offer document management services, instead of utilizing both apps, we consolidate them into a portal utilizing a freely available portlet for alfresco. Now, I'm not saying that portlet 1.0 spec is great, it's actually pretty ridiculous if you read it, especially in today's async web 2.0 environments, but the idea is actually pretty good. Ilya
  6. What are scenarios where a person really needs a big portal from a big vendor?

    * Using Acegi Security, you have a great security framework to manage all aspects of security.
    * With cascade style sheets, you can manage the look and feel throughout the application.
    * With Ajax, you can get many of the benefits of portals like components in the page that behave independently.

    Data aggregation is useful, so is single sign on, but you don't need a big portal from a big vendor to do both.
    I think the big portals from big vendors are only required when extensive personalization and customization are also nearly as important as security, standard look and feel etc. and you want all that in a single package. If only some of these are required then a 'big portal' is not required.
  7. Division of Labor[ Go to top ]

    In addition to security, customization, and personalization, most big vendors support a web based portal builder tool. This tool typically allows for a division of labor, where developers build everything leading to portlets, and non technical business users build portals - assembling portlets, provisioning users/security etc.
  8. What are scenarios where a person really needs a big portal from a big vendor?

    * Using Acegi Security, you have a great security framework to manage all aspects of security.
    * With cascade style sheets, you can manage the look and feel throughout the application.
    * With Ajax, you can get many of the benefits of portals like components in the page that behave independently.

    Data aggregation is useful, so is single sign on, but you don't need a big portal from a big vendor to do both.
    Wow, the enthusiasm for portals is overwhelming. What was I thinking to question the values of portals? It's clear we have reached a point where you can just drop a portlet made in Weblogic into an Oracle portal a vice versa. Darn my lying eyes fooled me again, because I could have sworn developing portlets for big portals from big vendors is the biggest waste of time.
  9. What are scenarios where a person really needs a big portal from a big vendor?

    * Using Acegi Security, you have a great security framework to manage all aspects of security.
    * With cascade style sheets, you can manage the look and feel throughout the application.
    * With Ajax, you can get many of the benefits of portals like components in the page that behave independently.

    Data aggregation is useful, so is single sign on, but you don't need a big portal from a big vendor to do both.


    Wow, the enthusiasm for portals is overwhelming. What was I thinking to question the values of portals?

    It's clear we have reached a point where you can just drop a portlet made in Weblogic into an Oracle portal a vice versa.

    Darn my lying eyes fooled me again, because I could have sworn developing portlets for big portals from big vendors is the biggest waste of time.
    Well today you can't take a web app from WebSphere and drop it in Oracle and expect it to work. You still use web apps, don't you. The point is that if you require personalization and customization, portals provide a defined framework for achieving that.
  10. Hi, Does the new specification specify an interface that enables other portal pages to be browsed and linked from a portlet? It's quite common that you need to make a link pointing to another portal page and passing parameters to one or many portlets in that page. Another common problem with portals has been, that they all implement URL mapping, or friendly URLs, differently. It would be great if the mapping rules were defined in the new specification.
  11. Does the new specification specify an interface that enables other portal pages to be browsed and linked from a portlet?
    JSR 286 specifies an interface that allows a portlet to issue an Event. It is up to a portal whether or not it provides the functionality you mention. However, a portal could potentially act upon an Event by returning a particular page. @Joseph The other important benefit WSRP provides is that the remote portlet can be written in a different language from the consuming portal.
  12. It is up to a portal whether or not it provides the functionality you mention. However, a portal could potentially act upon an Event by returning a particular page.
    Thanks. In other words we are still left in a vendor wild wild west with a functionality that should be one of the basic building blocks of any web application. :P A common, searchable model for portal pages seems to be missing also. It would be great if you could create links to other pages by just finding the page first with some API and then passing the resulting object to a link builder. http://docs.jboss.com/jbportal/v2.4/user-guide/en/html/images/management/tree.gif http://docs.jboss.com/jbportal/v2.6/referenceGuide/html/portalapi.html#d0e4435
  13. Many errors in this article[ Go to top ]

    This news item has a number of errors: * The wording and link in the news item points to an early review, not the current Public Review Draft, which is pretty much full featured. Here is the correct link: http://jcp.org/aboutJava/communityprocess/pr/jsr286/ . Comments on the Public Review Draft, which should be directed to jsr-286-comments at jcp dot org, will be accepted until August, 27. * The WSRP link does not work. Here is the WSRP site: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp * The 'previous thread' link points to an old WSRP draft (see http://blogs.sun.com/portal/entry/wsrp_v2_public_review for a link to the current draft, which is also now under public review). Apparently, TSS is more interested in controversy than getting the facts straight.
  14. Re: Many errors in this article[ Go to top ]


    * The 'previous thread' link points to an old WSRP draft (see http://blogs.sun.com/portal/entry/wsrp_v2_public_review for a link to the current draft, which is also now under public review).
    Given that my post was referenced here, in all fairness it should be noted that thread was from almost two years ago and at the time that was the current spec draft. I don't think there is any nefarious intent here. I am a big proponent of portals/portlets as an integration design. I am somewhat disappointed to the lack of substance this next gen spec has come up with after all these years.

    Apparently, TSS is more interested in controversy than getting the facts straight.
    Not sure what you're talking about here but I'm going through the public review and still see a spec that still has a significant amount of implicit service contracts with portal/portlet containers. No management interfaces nor registry interfaces which would be of great use to the developer and container implementor alike. As far as the Event handling code(one of the most awaited features I bet), I'm not sure why it is even in the spec given statements like this: (PLT 15.2 Line 21)
    Portlet programmers should therefore not make any specific assumptions about the environment of portlets they are running together with. The means of wiring different portlets together is portal implementation specific.
    If you can't assume a spec contract is going to be enforced in a consistent way across all containers, why put it in the spec at all? I hope the JSR 268 group grabs more of the WSRP spec. There is a least several interfaces for management, registration and eventing that seem consistent. This might be one of those times where specifying at the edge like WSRP might be a better solution than trying to extend or superset the Servlet spec.
  15. It's possible that Your Humble Editor misunderstands WSRP on some fundamental level; anyone want to step in to correct/educate/confirm?
    Your descriptions sounds like WSRP is the WebStart of portlets. I don't think that would be a correct presentation of WSRP. It provides access to remote portlets (the RP part of the acronym). You can expose a portlet through WSRP and it can be consumed by an external portal. The application code is still executing on your WSRP provider server (with the WSRP consumers portal sitting between you and the end-user). I have not yet encountered usage of public access or hosted WSRP providers. The installations where WSRP was implemented (or planned) were primarily for aggregation of multiple intranet portals. There are also frameworks for .Net, which allows to implement WSRP providers on that runtime. Lastly, I have also seen WSRP being touted as the solution to a, IMHO, very serious shortcoming (unable to install/update portlets without doing the whole portal) in the architecture of one major brand's portal. WSRP could allow you to update the portlets individually without re-installing the main portal (of course, this would also require several more runtime licenses....)