New Article: "Portal Standards" posted on TheServerSide


News: New Article: "Portal Standards" posted on TheServerSide

  1. In TheServerSide exclusive, JSR 168 (Java Portlet API) specification Lead Stefan Hepper and Portal Architect Thomas Schaek present an article on the need for the Java Portlet API and Web Services for Remote Portals (WSRP) standards. With these standards in place, application providers or portal customers can write portlets, or visual, user-facing web services independent of a specific enterprise portal product.

    Read article here
  2. Or a J2EE client to a not so portable and powerful .Net server.

  3. So, where do WSUI (Web Services UI from Epicentric) and IBM's (can't remember the name but like XForms I think) fit into this JSR? Seems like they manage how to render UIs for portals that can talk to and aggregate various web services into portals... Anyone know?
  4. just to get things formally right: the specification leads of JSR 168, according to the JCP website, are Alejandro Abdelnur (Sun) and Stefan Hepper (IBM).
    The 2 authors of the above article used to be the leads of the 162 spec, which was launched by IBM. That spec was later withdrawn and combined with another Portal API which had been submitted by several other vendors (including Sun).

  5. Great article!!

    A few comments:

    1. "The Portlet API will define interfaces for portlets and tags for JSPs called by portlets..."

    I don't see the logic of having new tags for portlets.
    I feel it would be better to rely on upcoming
    standard tag libraries so we don't further
    fragment portlet developers from the servlet/jsp
    developers. I could see some new tags for Page templates, but not for portlets...or am I missing something?

    2. "... standard way of storing and retrieving persistent per-user/per-instance data..."

    This sounds like an API design challenge to me. Some may want to use EJB's or their custom code against
    own database (e.g. stored procedures on Oracle), object
    databases, even LDAP, etc. I think
    it would be best if the spec leaves plenty of room
    for a container provider here. It would be even
    better if persistence implementation classes
    are "plug-in-able" (or event listener style interfaces) so a portal developer can use their own implementation
    classes for per-instance / per-user persistence
    if they have special needs.
    Other issues come to mind as well.
    For example how do you define
    the "user" identity that would work in all persistance
    mechanisms for all environments?
    (a social security number may work for
    some, a integer key for some, a GUID for some, LDAP
    naming, a first name + last name for others...). I hope this
    is well thought out and "plug-in-able" (or at least
    listener style interfaces) so we don't
    have to store and maintain a huge map of our app's
    (or LDAP) user identities to the portal API's user identities. I would like to suggest that you let
    the portal developer supply the object/data that
    represents user identity instead of inventing some
    data type and value they will have to map to later.

    3. There is reference to the WSRP. I think there may be
    some differences in how WSRP handles requests vs. how
    you would do this in a Java API. For example, last I looked the WSUI didn't deal with HTML form input
    validation or HTML mappings in a practical way.
    How does the SOAP container know
    about your per-user/per-instance data? How does the
    SOAP container get the user identity? How does the
    SOAP container get/set SESSION data so it's consistent
    with the portal tier's session data?
    Ideally, the Portlet API should
    be compatible. However, I hope this doesn't translate
    to "the lowest common denominator" and the api process
    doesn't become as slow as molasses (umm I mean
    as slow as oasis). :) I would envision
    perhaps portlet classes, the WSRP one having slightly
    different functionality? Can we get the Java one

    4. The SOAP/WSRP/WSUI stuff is very cool. Seems
    like the way to go if your portlet code is hosted
    elsewhere or with different technology.
    For those of us that host our own portlets,
    I think many of the same architectural benefits
    could be achieved if portlet business logic could
    be implemented as EJB stateless session beans in
    a fashion similar to the SOAP/WSRP architecture described
    in your article.
    I think this would be an interesting deployment
    alternative. Like WSRP, one could deploy the portlet non-view-rendering code in a stateless session
    EJB which could be versioned, clustered,
    and upgraded without disturbing the portal tier.
    For a heavyweight processing
    portlets, it would sure be nice if we could just add
    some extra "session bean portlets" to our cluster
    whenever scalability requirements dictate. Often we
    have a few "clunker portlets" that require extra horsepower.
    Of course you can always have your portlets hard-code
    calls to an EJB, but for that matter you could always
    hard-code a portlet to invoke a SOAP call too.

    5. The article doesn't mention what happens
    when you have sluggish portlets. If a portlet takes too
    long to render, you don't want the user left hanging
    forever waiting for that sluggish portlet. This is
    one of the key features that separates the toys
    from the better portals. I hope this behaviour
    is well specified by this document. At a minimum,
    a "max wait timeout" and some default behavior
    would be useful.

    6. I think that role-based navigation is crucial
    to a portal. The user should never be presented anything
    (embedded links or content) they are not entitled to see.
    Is this to be included in this API?

    7. Most portlet api's have been very weak on the
    "non-default views". Often these are embedded in semi-
    unmaintainable way in the portlet code. It would be
    nice if the Portlet API provides first class recognition
    for the portlets that have extra views (in addition
    the standard ones: default view, edit, configure, help).

    8. It would be nice if static content is easily supported
    by the portlet api/container. There are many cases where a web designer just needs a portlet to put some graphics and
    text (this site for example). Ideally this shouldn't
    require a Java programmer just to add new static content

    9. Deploying portals and managing them can be complex.
    The servlet specification discusses lots of information
    on the web container and how servlets are deployed. This
    wasn't always the case. After struggling with several
    vendors due to a lack of container spec details,
    it was refreshing when servlet specs finally discussed
    the container in enough detail so servlets were
    actually portable.
    I hope the portlet API follows the servlet API's
    hard won experiences and defines the portal
    container services and portlet container deployment
    with enough detail so portlets are
    actually portable and deployable across vendors.


  6. Answer to posting by B mcginnis 2002-02-20 04:11:44.0.

    1. Certain tags will be most likely required to allow to generate URIs pointing back to a particular portlet instance so that portlets don't have to know any portal URLs but can operate solely with relative URLs to be prefixed automatically with the portal URL prefixes by the tags. Also, some tags to access user data, portlet instance data, etc would be useful in JSPs called by portlets.

    2. Probably "standard *interface* for storing ..." would have been the better wording - of course the idea is that an interface - part of the Portlet API - would be the way to store such data. The actual storage mechanisms may be very different in different portal implementations.

    3. While SOAP is a session/stateless protocol, things like transferring user information, session IDs, may be layered on top of it. One option to address the issued in 3 is to transfer the user information - depending on a portals privacy settings - in the SOAP messages and by contract allow services to return a session handle in a SOAP response if they need a session and force the portal to use that session handle in subsequent requests on behalf of the same client. There are also other options.

    The main requirement to allow WSRP services to wrap Portlets and conversely Portlets to wrap WSRP services is that the incovation interfaces must be defined so that they can be mapped to each other. As long as this is the case, it should work.

    4. Not sure what you mean with running portlets as EJBs. Portlets are much closer to servlets than to EJBs.

    5. Those are important issues, but they are mainly implementation decisions to be made by portal implementers. I'd expect that better portals would feature concurrent invocation of portlets combined with timeout mechanisms, probably combined with admin UIs that allow portal administrators to set a per-portlet timeout if desired. A specification will probably be designed so that this is possible, but not mandate that implementations must be done so that they actually employ these features since they are not required to run portlets. While not so desirable, it would also work to invoke portlets one after the other.

    6. This sounds more like a function for portal frameworks / portal applications that run portlets rather than portlets themselves.

    8. Typically this is done by simple generic portlets for displaying static markup or JSPs or through more sophisticated clipping portlets. The advanced portals have admin UIs where instances of these generic portlets can be created and parameterized with the respurces to display by the administrator without any programming.

    9. That's indeed one of the core requirements.
  7. HI,
      i would like to add my 2 cents: do we need a Portlet API when the concept discussed have been around since two years (JSP Model2 architecture + jsptags)???

  8. Response to

    "Posted By: marco none on February 26, 2002 in response to this message.
      i would like to add my 2 cents: do we need a Portlet API when the concept discussed have been around since two years (JSP Model2 architecture + jsptags)???


    The Portlet API's core concept is not that portlets *may* internally use the model 2 architecture and JSPs, the important thing about the Portlet API is that it defines Portlets as entities that can be deployed, managed and run in compliant portal servers and plug & play with portals' aggregation/editing/administration functions.

    Portlets will plug&play with Portlet API compliant portal servers - that's not the case for JSP model 2 apps.
  9. Thomas, Thanks for the response.

    Any response to question 7, API support for
    multi-view portlets such that this isn't embedded
    in the portlet code in a wierd manner??

    I must admit my perspective on portlets is unique. Let
    me explain why I think an EJB style portlet would be
    beneficial to add to the mix:

    One of the main benefits of WSRP/WSUI is that
    you can upgrade the portlets without redeploying or rewriting any Java code in the portal tier. Also,
    the portal functions as a "controller" and "viewport" onto external web services instead of the portal acting as the application hosting platform itself. (I thought that what an enterprise portal is supposedly really about anyway?)

    Using Servlets to invoke EJB's is
    flexible and powerful. Conversely, I believe that it would be useful if we had some benefits like WSRP/WSUI does when it comes time to upgrade/version portlets. When you embed EJB method invocation code and related objects in your servlet/portlet code, you now need to change both your servlet/portlet tier code PLUS the EJB tier code whenever there's a portlet change. That makes portal administration and deployment difficult when you have hundreds of portlets and hundreds of EJB's.

    The proposed portlet API seems to presume that the portal functions primarily as the portlet hosting platform. The thing I like about the WSRP/WSUI approach is that the portlet code runs elsewhere (another tier, another machine) and the portal is used mainly for integration purposes only.
    This isn't to say that having portlets run like servlet isn't a useful or good, just that this shouldn't be the only
    way to run a portlet.

    Using WSRP, in theory, one can replace or upgrade portlets in the portal without ever rewriting or redeploying any Java code on the portal tier itself. That makes it a lot easier to administer and maintain a portal. Do you agree?? Used in this fashion, the portal becomes the controller and viewport onto external web services - instead of being the execution environment for the web services.

    Isn't there be some way to get the some of the advantages
    of WSRP/WSUI using off the shelf J2EE technology without forcing a people to use SOAP??

    I was thinking that adding an EJB portlet style would have many of the same advantages that WSRP/WSUI portlets have. We could get benefits of upgrading
    a portlet without having to rewrite any portlet Java code and without having to redeploy a bunch of Java classes to the portal.
  10. I need this stuff now! Keep up the good work and please do it quickly, guys!