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

Or a J2EE client to a not so portable and powerful .Net server.

Billy

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?

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).

Christian

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
sooner?

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
portlets.

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.


-brian

 

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.

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)???

regards
 marco

Response to

"Posted By: marco none on February 26, 2002 in response to this message.
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)???

regards
 marco
"

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.

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.

I need this stuff now! Keep up the good work and please do it quickly, guys!