Article: Web services, Portlets and WSRP

Discussions

News: Article: Web services, Portlets and WSRP

  1. Article: Web services, Portlets and WSRP (24 messages)

    In this article, Daniel Rubio explores the benefits of a portlet design for Web applications. He looks at how the Web Services Remote Portlet (WSRP) specification can be used to create interoperable portlet apps and provides a list of commercial and open source portal server providers that offer WSRP support.
    Among portal server vendors that offer support for WSRP are the following :

        * BEA Web Logic Portal
        * Apache WSRP4J
        * IBM Websphere Portal
        * PlumTree
        * OracleAS Portal Server
        * Sun Portal Server

    The actual complexity or ease with which a WSRP application can be rolled out in any of these products will depend heavily on your familiarity with similar portal tools from the same producer because most WSRP support is built upon earlier JSR-168 server implementations. If you have previously used Pluto –Apache's JSR-168 portal server – then Apache WSRP4J might be a good fit for you. On the other hand, if your organization is committed to the IBM product line, then Websphere Portal will surely be an obvious choice to test out WSRP deployments.
    Read Web Services, Portlets and WSRP

    Threaded Messages (24)

  2. Full list[ Go to top ]

    You can find the full list here:

    http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp
  3. Article: Needs login![ Go to top ]

    Isn't this article available somewhere where we don't need to login?

    -John-
  4. BugMeNot Firefox Extension[ Go to top ]

    Isn't this article available somewhere where we don't need to login?-John-

    If you're using Firefox, try the BugMeNot extension.
  5. Tech Buzzword Bingo?[ Go to top ]

    I have this feeling that appears every time I hear about portlets. Since most portlet articles or vendor portlet support announcements all seem to employ weaselwordish, I get the impression that portlets are a phantom technology.

    For example, this article claims that portlets can:

    - Ability to be customized by end users once deployed as an application
    - Capacity to target many user devices from the same design
    - Ability to process messages and events once executed

    ...okay...yet he describes nothing about portlet architecture that inherently does this.

    - The first bullet doesn't say how they can be customized, since the word customized means nothing without context.
    - The second bullet implies portlets will magically translate their output to HDML, WML, cHTML, HTML, including device-specific dialects. Right.
    - Ability to process messages and events? Yet another horribly vague statement that explicitly requires context.

    Forgive me for my bias, but the second I heard the word "portal" and the associated "portlet" with its horribly abused "-let" suffix, I classified this as a BS technology. But, I try to understand things in case there is a wrinkle.

    Unfortunately, articles like this do nothing to change my view. Is a portlet just a servlet talking to an IFRAME? Is a portlet any different that a plain-old-servlet? Is a portlet a fancy name for an XML transformer that adapts to a device's specific lingo and manages a contained conversation?
  6. Tech Buzzword Bingo?[ Go to top ]

    Carl:

    I used to think the same way... However, after I went through a prototype and used IBM Portel (the IBM internal we site), I have convienced my self this technology is really cool and it can chnage the way 'servlet' is done.

    After experience my my self, I think companies shoudl make decisions like: let's make our web apps using portal technolgy so that we can assembly them together into different'apps' much like stack lego together... It is that powerful..

    Jerry
  7. Tech Buzzword Bingo?[ Go to top ]

    You make great points here.

    The reality is that almost all portlet implementations that are delivered on Java technology are extensions to the servlet engine. This type of implementation is a logical way to add higher level features from the portal framework implementation to "any" application that is deployed to the portal server. What the article misses is going into greater depth or comparisons on how vendors have implemented the actual portal architecture, how well they actually support plugging in various types of applications and applications frameworks, etc.

    Today, the JSR 1.0 specification is just that - a 1.0 specification. Hopefully the 2.0 or future direction of JSR 168 will incorporate more of the innovations that are actually happening in WSRP.

    While vendor implementations of WSRP vary - and here I will walk the fine line as since I work at BEA I do beleive we have a very good implementation for both consumption and production of WSRP - it is moving along faster and making progress to support real customer use cases. In addition, the WSRP TC group is really tackling practical issues for security, inter-portlet communication, context and other issues now that will be reflected in the next version.

    The Oasis WSRP page has a good overview of status and plans for WSRP 2.0.

    Shane
    BEA Systems, Inc.
  8. WSRP Support Very Limited[ Go to top ]

    I think it's worth mentioning that the WSRP support in a majority of the products listed above is abysmal. In some of the products you have to download special ad-ons and install them seperately in order to obtain WSRP support. In other portals the WSRP support is very buggy. This means two key things:

    (a) TEST YOUR PRODUCT'S WSRP support BEFORE counting on it.
    (b) WSRP support is still very immature in the average product.
  9. WSRP Support Very Limited[ Go to top ]

    I think it's worth mentioning that the WSRP support in a majority of the products listed above is abysmal. [..] TEST YOUR PRODUCT'S WSRP support BEFORE counting on it.

    As an FYI, we've had very good results with WebLogic Portal and WSRP.

    I've also been talking to Rickard about the open source WSRP project that his company (senselogic) is sponsoring. I haven't had time to look at it yet, but one of the benefits of WSRP is being able to go cross-vendor to put a portal together (e.g. some portlets from an app running on one vendor's portal engine, some from an app running on another vendor's portal engine, and maybe some portlets just scraping other web apps to make them appear to be portlets).

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
  10. WSRP Support Very Limited[ Go to top ]

    I am familiar with config WSRP in WPS 5.1, and WPS 5.1 has a very nice support for WSRP.
    Currently, there is a serious limitation of WSRP that can not support C2A (Click to Action) portlet. C2A portlets means that when the user click a menu in the certain portlet, another portlet in the portal page will be changed because the portal server maintaince a relationship of portlets. But a remote portlet can not send message to another portlet.
    Anyone know if in the future the WSRP spec can support it?
  11. WSRP Inter portlet communication[ Go to top ]

    As Far I know Click to Action is a functionality provided by IBM for the development of WebSphere Portlets. The AIM of WSRP is to provide a platform independent communication mechanism between portal platforms and portlet producers. So, no proprietary extensions should be included in this kind of portlets.

    The real aim of the IBM C2A is to provide a inter-portlet communication even if the portlets are provided by different producers as the integration is driven by the portal using the metada included in the markup produced by the portlet . This is the real gap of the WSRP an JSR168 specifications.

    Now standards provide a great opportunity to create a real Portlet market and in this way increase the functionality that can be offered through portals, but I think that the real challenge of the specification is to define inter-portlet communication mechanisms that allows portal platforms to evolve into application integration platforms.


    Juan José Rodríguez
    LKS, S. Coop.
  12. WSRP Support Very Limited[ Go to top ]

    I am familiar with config WSRP in WPS 5.1, and WPS 5.1 has a very nice support for WSRP. Currently, there is a serious limitation of WSRP that can not support C2A (Click to Action) portlet. C2A portlets means that when the user click a menu in the certain portlet, another portlet in the portal page will be changed because the portal server maintaince a relationship of portlets. But a remote portlet can not send message to another portlet. Anyone know if in the future the WSRP spec can support it?

    You can accomplish this today with IBM (b/c the session ID is shared across the portlets) and BEA (b/c you can pass custom identifying info in the WSRP). With that "global identity" problem solved, you can use messaging (e.g. JMS) or shared data (e.g. Coherence in a cluster). We've got a white paper on it; send me a request by email for it (cpurdy at tangosol dot com).

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
  13. WSRP Support Very Limited[ Go to top ]

    Click 2 action is not even part of JSR 168 spec, it is IBM's extension.
  14. WSRP 2.0 Coordination Model[ Go to top ]

    WSRP 2.0 supports a few coordination models. One of these models allows portlets to handle events raised by other portlets. In this model, any portlet on a producer can raise an event, which the consumer can route to all portlets interested in that event.
  15. WSRP Support Very Limited[ Go to top ]

    You need to write a WSRP client-portlet that acts like a reverse-proxy calling PropertyBroker and inserting C2A code into html. The properties that need to enable to C2A can be matched using xpath.
    If you really need this kind of proxy portlet, send me an email (dvisentin-at-santineassociati.com)

    Ciao, Diego
  16. I've also been talking to Rickard about the open source WSRP project that his company (senselogic) is sponsoring. I haven't had time to look at it yet, but one of the benefits of WSRP is being able to go cross-vendor to put a portal together
    Well, one of the reasons you haven't looked at it is because it has not been officially published yet :-)

    In any case, Cameron is right that for the time being I think having the ability to re-purpose old applications by slapping a WSRP interface on top of them in order to put them into a portal will be a decent way to go.

    The discussions, and complaints, about WSRP and portlets that I've seen so far talk about it from a developer perspective. This is natural, but perhaps not very useful. The thing about portlets and WSRP is that their goals are, in my opinion, more geared towards helping the user rather than the developer. From a user perspective they want a "web experience" that is integrated on all levels: authentication and credentials, as well as "look and feel"-wise.

    The current approach that I see many web apps doing is to have each application be their own little universe: their own user database, their own templating system, their own sense of graphics design. From a developer perspective that is natural, but perhaps not very useful. IF I SEE YET ANOTHER APPLICATION SPECIFIC USER DATABASE I AM GOING TO SCREAM. It is such a waste of time. What portlets and WSRP gives us is a framework which says: "hey, forget about user logins and graphics design, and focus ONLY on providing functionality". After all, that is what developers usually are best at doing. The rest is "handled" by the portal.

    And I say "handled" in quotes, because there is of course no magic to it; the developer has to consider using standard CSS classes, and also has to consider that the application will be used in a bigger framework and hence should think twice about including things like headers and footers and so on. Such things are just soooo Web 1.0.

    As to the OpenWSRP project that Cameron mentioned, it is an OpenSource (Apache2.0 license) project that is from the ground up built around extensibility, and it is expected that it will be extended and used in many different kinds of commercial applications, our own included. The point is that it would be far too costly for all of us small/medium sized vendors to implement WSRP from the ground up, and for application developers they are not so inclined to think about WSRP at all (as evidenced by some remarks in this thread), and hence having something that they could "slap on" to their apps in order to at least have minimal WSRP support is a good start.

    One of the first serverside plugins to OpenWSRP will be a web scraper, using techniques similar to what I donated to portletbridge.org, which will allow even non-Java apps (I hear PHP is popular, and I recall seeing ".aspx" files once or twice) to be relatively easily exported as WSRP services. Having a scraper on the serverside also makes it possible to adapt existing apps to use the standard CSS classes, since the HTML can be transformed *before* it is sent to the client instead of putting that burden on the client.

    I have already approached several application vendors in our region to adopt this project, and so far the response has been very enthusiastic. Many of our customers are also very much looking forward to it, for reasons mentioned above (=cleaning up the mess that is multi-app heterogeneous environments). All in all, there seems to be a great built-up demand for it. Then we have the whole Web 2.0 and Identity 2.0 thing going at the same time, which also almost mandates that things like WSRP are available as enabling technologies.

    I am not well versed in other products support, or lack of support, for WSRP, but if people say that it sucks it is probably true. But what is the reason it sucks? Quite possibly it is because no one talks about it, or wants it. And why is that? Because everyone, it seems, thinks about these things as developers. Well, stop that. It is natural, but perhaps not very useful. You guys need to talk more to end-users, who most definitely are interested in these things (at least that is my experience).

    As but one recent example: the ONLY presentation I have heard talking about WSRP (apart from my own) was during a conference last week called "CIO Forum" in Oslo. Yeah, that's right, PHB's get this stuff! And YOU don't! Pretty scary, if you ask me.

    Just some thoughts on the subject...
  17. IF I SEE YET ANOTHER APPLICATION SPECIFIC USER DATABASE I AM GOING TO SCREAM. It is such a waste of time.

    Now mate, you may scream all the time, but the reality is, in a lot of large organization, an application specific user data base is the only way to go. Sad, but true. Various reasons:

    - Company policy does not allow for external users in their directory
    - Company directory does not allow for self service user creation/user deletion/profile edit/password change what have you
    - Company polices on password expiry are rigid and not tunable by the application
    - Company directory imposes other constraints that the application can not meet
    - Company directory does not meet application availability targets
    - Company directory to slow

    And on it goes.
  18. Now mate, you may scream all the time, but the reality is, in a lot of large organization, an application specific user data base is the only way to go. Sad, but true. Various reasons:
    - Company policy does not allow for external users in their directory
    Then use several directories, and/or NVDS.
    - Company directory does not allow for self service user creation/user deletion/profile edit/password change what have you
    Use a provisioning system then.
    - Company polices on password expiry are rigid and not tunable by the application
    If you have such policies, then what is the purpose of using application-specific user databases to circumvent them?
    - Company directory imposes other constraints that the application can not meet
    Such as?
    - Company directory does not meet application availability targets
    Then use a directory that can meet such targets (e.g. Novell eDirectory)
    - Company directory to slow
    Then use a directory that can scale to desired performance levels (e.g. Novell eDirectory).
    And on it goes.
    Sure, I hear you, but those are excuses, not reasons. The PAIN that companies and organizations have to go through because applications chose to introduce their own application identities is just not worth it.
  19. Sure, I hear you, but those are excuses, not reasons. The PAIN that companies and organizations have to go through because applications chose to introduce their own application identities is just not worth it.

    Rickard,

    the pain may be very well worth it, if it allows for provisioning of an application for customers that actually generate revenue for the customers!

    Sure it would be better if there would be a "corporate standard" usable in every project, across the corporation and I would really want to use it. The truth it, projects have constraints in terms of deadlines, skills available, ressource available and so on.

    Of course, something like WSRP is quite awkward if there are no corporate standards that are employed throughout your "portlet space". But even then you often end up with "federated security" where authentication is central, and authorization is somewhat distributed. I it may well be that "having everything in one but different places" is better manageable than "having some of it in one place and some in a different place".
  20. Great work![ Go to top ]

    Hi Rickard,

    You approached me earlier about helping develop an alternative to OpenWSRP, and even though my time is scarce (as everyone's is) I'm extremely excited that you're going thru with this and hope to follow your progress and help where I feel I can.

    I see WSRP as an excellent technology but what frustrates me the most is the lack of a halfway decent open source WSRP implementation. The author never even bothered to download the WSRP4J codebase he was talking about since if he did he would realize it doesn't build. That's right, I've been getting GUMP "nagging" announcements on the wsrp4j-dev mail list every day for 3 weeks straight and guess what? Nobody cares! I've charted the progression of the WSRP4J codebase with statcvs and it's a bloody flat line-- every now and then some poor unsuspecting fool asks a question on the wsrp4j mail list and guess what? Nobody responds. You would think if this is such hot technology a couple competent people could steer the project. The future of WSRP for open source projects may be in Rickard's hands here-- WSRP4J is such a #$%@ POS that I'm discounting WSRP completely unless a reasonable open source implementation with a real user community can rally behind it.

    Cheers, Jason
    (developer JSR-168 GridSphere portal www.gridsphere.org)
  21. Re: Great work![ Go to top ]

    Jason, Would you like to try open source WSRP implementation at java.net?
  22. True for anything[ Go to top ]

    (a) TEST YOUR PRODUCT'S WSRP support BEFORE counting on it.

    This is true for anything :)

    >> (b) WSRP support is still very immature in the average product.

    This varies from product to product. So, I would not make general statements about this without reviewing each and every piece.
  23. whats new in this article[ Go to top ]

    I could be short sighted but whats new in this article. The article merely repeats what is knows. I would have been interesting if the article had focussed on other aspects of portal development (THE PAIN).

    Though all the portal vendors theoretically subscribe to JSR 168 and WSRP there is very little advancement in this direction. JSR 168 (atleast in my opinion) is getting a raw deal. The specification is in its nascent stage and clearly the with proprietary extensions one can develop far more robust portals in a shorter time frame. I dont think anyone is seriously thinking about moving or porting their custom apis to the new specification.

    The only saving grace is that most platforms provide a way to expose their portlets to the outside world by means of WSRP. IMHO WSRP is the only hope for the portlet specification till it is significantly advanced to cater to the service integrators needs

    anand raman
  24. JSR168[ Go to top ]

    little advancement in this direction. JSR 168 (atleast in my > opinion) is getting a raw deal.

    Check for some issues I posted on this JSR.

    Perhaps someone from Sun or IBM (who were the co-spec leads for JSR168) should comment on this. AFAIK, a next version of this JSR will be started soon to fill some of the gaps in the current version, and also align it with the upcoming WSRP 2.0.

    In the mean time, as you rightly said, WSRP will make it easy for portals to consume portlets without worrying about all the proprietary details.
  25. WSRP 2.0 & Adoption[ Go to top ]

    Hi,

    Very good comments on the thread. I just wanted to share a few thoughts on adoption:

    - I have been working with enterprise customers with interest/focus on WSRP for almost 2 years. WSRP is a key standard and integral part of our Portal Federation features, here at BEA. So far, we have found that while we get over 75% of what is needed from WSRP 1.0, there are other 10-20% requirements that are needed before an enterprise customer can really bring WSRP in house. In the past 14 months we have added additional 10-15% of these requirements in the product, extending WSRP 1.0 in our Portal with good results - and yes you can turn all the extensions off if you want. In parallel, we have been working closely with the OASIS team to get these items into WSRP 2.0, a lot of it went in. We are very happy with the progress there. WSRP 2.0 rocks! The market is ready for it.

    - In addition to WSRP 2.0, I believe there is more awareness on the market related to what WSRP is, and what can and can not do. In the early days folks just assumed that you could expose portlets as services and everything worked just fine. As we know, things are not quite like that in real life. There is some work involved when you deal with more advanced features. So the point here is that not only the standard will get more mature with WSRP 2.0, but the users are also better informed what are the capabilities and limitation.

    - Finally, I see WSRP as very nice spec to promote SOA. It is a very nice alternative for customers take existing apps and service enable them. This can help old systems take part in SOA faster.

    Any other thoughts on adoption?

    Cheers,

    --alex

    Alex Toussaint
    BEA Systems, Inc.