IBM has posted JSR 162: The Portlet API specification. This new spec. defines an API for components being aggregated in web applications like portals. It includes portlets, portlet container behavior, portlet windows, events, persistent storage and portlet services.
Portlets are web components like servlets, but have additional, special properties that allow them to easily plug into and run in enclosing web applications like portals. Portlets are designed to be aggregatable in the larger context of composite pages, e.g. multiple instances of the same portlet parameterized with different per-user, per-instance portlet data can coexist on the same portal page. Usually, many portlets are invoked in the course of handling a single request to aggregate their respective produced markup fragments in a page of markup. The markup fragments generated by portlets often need to contain links to trigger actions in the portlet, therefore URL-rewriting methods are required that allow portlets to transparently create links within the markup fragments they output, without needing to know how URLs are structured in the particular web application.
READ MORE @ http://www.jcp.org/jsr/detail/162.jsp
What an absolutely terrible idea. Basing a JSR on a product that is generally misdesigned, and competes with a plethora of web frameworks, sounds like utter and complete stupidity.
It probably went something like this:
"Guys, our portal server isn't selling very well"
"Well... it sucks, so noone wants it"
"Hm.. what should we do?"
"Well... we could standardize it I guess. Then we can certify it and all that, and then people will buy it anyway. You know, the they-implemented-it-first-and-were-behind-the-spec kind of thing. Usually works"
"Oh. Right. Sure, why not"
Sorry, I usually don't get upset by stuff like this, but this sux badly. The JSR description itself hints that it's a rather schizofrenic JSR. "It's like servlets, but more than that, but at the same time they can't do things servlets can". geeeezz....
On a more calmer note (ehm), it would be interesting to hear how this compares with JSR 127 (Java Server Faces) and JSR 52 (Standard Taglib). Sounds like there's overlap between these and the Portlet API.
I agree. To me, JSF is much more interesting (and supported by many tool makers). I found it curious that IBM appeared to be the only member of this JSR, with BEA, etc nowhere to be found.
Oracle has a personalization server, so does BEA. It seems pretty lame that this even got through. I guess the combined powers of IBM and Apache pushed it through.
Faces is much more interesting, to see how the server side UI (i.e. the web) might get closer to having an event model like Swing. The web needs a richer (but still thin) GUI and so does Java if it's gonna compete with Microsoft.
In the meantime, people will still use portals, but I don't really see how this will keep anyone from using a portal product from another manufacturer. We still need the best-of-breed fight to go on before a standard is stamped.
Maybe this is just a first draft, and BEA and Oracle and others will get involved and make it an actual standard, instead of an almost-patent. <shrug>
I think this is a much needed API as there are several different java implementations of portals from companies like iPlanet, IBM, Apache, and BEA. Portal channels/portlets are not simply JSP's in a frame but are in fact managed objects. Often channels/portlets must be customized based on user, roles, and policy and need to have access to some kind of portal context to share information with other channels and the portal server. In iPlanet's and IBM/Jetspeeds implementations channels are seemingly deployed using configuration files. Currently all portal implementations have their own standard proprietary means of managing and developing channel/portlet content so a standard seems appropriate given that Java is all about standardization. Where I think this will really help is with elaborate web service clients that will be portable among the various commerical portal servers.
"I think this is a much needed API as there are several different java implementations of portals from companies like iPlanet, IBM, Apache, and BEA"
I guess the question is then how much input the other big portal players had, or is it just the regurgitated existing interfaces of the "sponsoring" company? When I think "portals", IBM isn't the first (or second or third ...) company that comes to mind. I think it's great that IBM is involved with the JSR process, and I can't criticize any aspect of the portlet JSR because I know so little about it (it could be a good JSR for all that I know). I just concerned because it seems that the JSR mechanism is just becoming a way to change "com.ibm" (or whatever) into "javax.portlet" (or whatever) -- for an example, read the Oracle caching JSR and I think you'll see what I mean.
Even though there is a need for a portlet API, I agree that if IBM is the only company that is going to support it then yeah this JSR is pointless. The whole purpose of the JCP is java standards, so if IBM is the only one using it then it isn't a standard. That said, just because IBM is the only one on the expert group doesn't mean more won't be added. Also, this is only a submission and doesn't mean this JCP will move forward without aid from other JCP members. In the end, the JCP will flush this JSR out if it is truely not needed or wanted.
What alternatives are available?
Pretty much all web frameworks, plus JSR 127 and JSR 52 combined.
Let's see.. we have (at least):
and a bunch more (sorry to those I forgot). IMHO it is much more interesting to get these to play nicely together (which most of them already do), than make a single API and say "this is the standard, forget the rest".
I repeat: this JSR is utter and complete stupidity. Period.
I'm getting a subtle feeling that you might have an opinion on this subject, but I just can't seem to figure out which side of the issue you stand on. Could you please clarify your position and quit submitting ambiguous posts! ;)
The fact is that the lack of "portlet" portability remains the number one complaint that we hear. I can't say that means that Plumtree and Epicentric, to take two examples, are poorly architected: they were solutions developed independently for commercial needs outside of a standard. That doesn't make them bad. The current portlet API is not the issue (I believe it's not the basis for the proposal in any case: there's a newer API under review in the Jetspeed project), the need for a standard is.
Now, let's consider your proposal:
"Let's see.. we have (at least):
* HyperQbs "
and a bunch more (sorry to those I forgot). IMHO it is much more interesting to get these to play nicely together"
I admit that this may be "more interesting" and purely from a developer perspective, it's appealing. The question isn't one of technical interest, it's of solving real business needs. From that perspective, a hodge-podge of open source technologies, some of which are in questionable state, is not a good solution. I can't think of a single large customer who would accept this. Whereas an open standard to normalize portal frameworks against seems very reasonable.
"The current portlet API is not the issue (I believe it's not the basis for the proposal in any case:"
How can the current Portlet API not be the issue? The foundation you start from is definitely the issue. It ultimately determines the building you can build.
"From that perspective, a hodge-podge of open source technologies, some of which are in questionable state, is not a good solution. I can't think of a single large customer who would accept this."
Accept what? There are already large customers using these technologies.
There are many "interesting" parts in your response, but I am particularly fascinated by this statement:
From that perspective, a hodge-podge of open source technologies, some of which are in questionable state, is not a good solution. I can't think of a single large customer who would accept this.
Right. Well, there ya go. I'll go tell Craig to ditch Struts, since, as you note, who in their right mind would use it?!?
Struts is only one of the projects you mentioned, and probably the most likely of the list to be well regarded as the basis for a serious application. Would I personally recommend and use Struts for a project? Yes.
Would I use it for a portal project? Most likely not. I'd probably use one of several commercial portal frameworks. I'd really like the choice to be about the quality of the framework implementation, not about how many PIM "portlets" are available for that particular framework's API and I'd really like the piece of mind to know that my decision doesn't lock me in to a vendor. To me, a familiar servlet-like model sounds appealing, but I could be convinced otherwise on that point.
Out of curiousity, do you see any merit to a portal framework per se?
I think you are missing the point. The issue is not "whether there should be a portlet API" which is a thread discussion in itself but "what should be the bases for this API and who should help shape it". There seems to be a strong feeling that basing this API on JetSpeed is not the right decision. It seems to me that there needs to be a more open debate about portlets in general before blindly going ahead and fast tracking a poor API that we are stuck with.
By the way it is "Rickard" not "Rikard". ;-)
Alright, let's talk about what a portal framework would be, per se, and see if what would be useful in such a framework.
To start off with, I don't see how it is necessary for a portlet API to include the application model itself, i.e. how you write code. Portlets is mostly about (IMHO) creating fragments of HTML code in a page, and managing those fragments configuration wise. The creation of these fragments could be done any way you want. It really doesn't matter what API you use, whether it's plain servlets, Perl CGI, Struts, WebWork, or static HTML. All you need to do is use an include mechanism to invoke it, e.g. a <jsp:include> tag. One of the important parts of configuring portlets is the ability to parameterize that include. In WebWork there are tags to do this, like so:
<webwork:param name="'user'" value="currentUser"/>
which will generate the proper URL (e.g. "horoscope.action?user=rickard"). This should be enough to include whatever content you want from any content provider you want. If you want this tag standardized, then look no further than JSR52, which has this.
For the actual content generation, as above, do it with whatever framework suits your fancy. As long as it can be included, it should be just fine. That said, you might want some Java API with standardized access to functionality, such as the user, his preferences, and stuff like that. *This* may need standardization, but I'm not convinced of that either. And I'm especially unconvinced that JetSpeed is the way to go for this.
Would you agree with the general problem assessment above? Are there any other areas you see as necessary to cover by a portal framework?
Rickard (sorry on the spelling):
If a portal was just about including HTML fragments in a JSP, you'd have no argument from me. But a decent portal framework provides a lot of functionality. Some of that should be managed as configuration (content cacheing and timeouts, for example), hopefully based on a portable deployment model. Generally, portlets need restrictions on what they can do and are likely to have explicit isolation requirements with respect to the framework and each other; it may be desireable to collect content asynchronously, which the framework should handle. Additionally, the context that you allude to is important since it's the basis for almost everything interesting that the portal is going to provide for portlet consumption, such as device information, location, etc. It would be useful to standardize this.
On the other hand, you do have an application model thrust at you that's going to be less than ideal for complicated apps. At which point, I assume you'd have to abandon the portlet model.
One of our first portal implementations was built almost exactly as you describe. I think it's generally easier to use a framework. I also think we've beat this horse to death.
This is just in. A new portlet specification has been posted on the JCP site. In fact it's so new that they haven't filled in the details for it yet. It certainely looks like that the JCP community is going through the same confusion, and disagreement with regards to a portlet API, as what is taking place here. Interestingly enough, Sun appears to be the main driver behind this last one.
No details but the description makes a lot better sense than JSR-162. Looks like someone was realizing that the foundation wasn't quite right.
Is this the point when someone walks up to you and says "Smile, you're on candid camera?".
Boy, they sure fooled me. Phew.
At least as far as I understand,
Jetspeed currently comes with Turbine,
but can use other frameworks as well.
Is this incorrect ?
Have you seen the JSR list lately? Holy f?????g whatever of whatever, bat-man!!!
The assertion stuff was bad enough ("we don't want to change the language or the JLS or the JVM or the compiler ... uh we're done now ... you will just have to change the language _and_ the JLS _and_ the JVM _and_ the compiler!").
Now every failed project at every big company is getting JSRd.
Oh man, how right you are. Soon there will be 1.2 billion JSRs! Why not spend time and energy on things that should be done right, and that need a standard.
I am thinking of starting a JSR on the fibonnaci equation
:) People keep doing this in different ways... we need a standard I tell you!
The JCP will die if it gets too bogged down, and people are overloaded with too many JSRS/APIs
I just took a look to JSR 162 and the only reference that I found was the jakarta Jet Speed project.
Which IBM product are you talking about in the dialog that you wrote ("It probably went something like this:")
Thank you very much.
IBM's portal server is based on JetSpeed.
Yes and No. IBM WPS 1.1 was based on Jetspeed 1.3a1 while WPS 1.2 and 2.1 are based on turbine, jetspeed portal ui and Portlet API as container. Portlet API WPS 2.1 uses is still different from JSR-162, but based on it.
IMO Portlet API is quite nice, architectured well and scalable. It is addresses to different needs than current frameworks, and thus it is urgently needed by corporate developers. I have studied it, tried it, and while I know that it doesn't suit for all purposes it is still suberb.
Portlet API lets you implement portal ui with any frameworks, just like IBM who uses turbine, while giving corporate developers ability to create portlets that can be transferred from portlet container to another like JSP's, Servlets and EJB's today work.
For corporate developers Portlet API gives easy interface, possibility to use standard JSP and freedom not to think most of navigation and administarion stuff.
I agree, given the volume of excellent frameworks that are appearing, it seems a little sudden to just grab one and say 'that's the new standard'.
It also seems that their is still a lot of flux in the realm of J2EE presentation layers and I think that until more developers have experience implementing such frameworks can a real standard soldify.
From what I can see, the Portlet API is synonomous with the Apache Jetspeed project:
One gripe we've heard repeatedly is the difficulty organizations have in merging portals during a consolidation. A standard API would go along way toward solving this problem. It would also allow communities of "portlet" providers to market their wares to a much broader set of end users, regardless of the portal framework. In both cases, this is a move in the right direction. I'll have to take exception and say this sounds like a great idea for the real-world.
It's bad news for independent portal vendors who have been doing ok until now, since it will eliminate a lot of room for differentiation in this space.
Any difficult organizations may have in merging portals during consolidation may point towards badly designed portals in the first place. Many of the issues with merging content generation providers will be solved through JSF and JSR-52 (standard taglibs, which will have very powerful include-tags).
Again, this would also compete with web frameworks like Struts or WebWork. Are you saying that we should scrap those in favor of the Portlet API? I'm skeptical, to put it mildly.
Regardless of any pro's and con's to have this JSR conceptually, the Portlet API from JetSpeed is not a very solid ground to base it on.
Exactly what's wrong with Portlet API/JetSpeed? Let's be more specific to be more objective.
can anyone tell me what's so wonderful with this Portlets?
Is it the main target only to develop portals that can be accessed by either Wap phones and/or browser?
can't a simple jsp tag do the same work??
I have done the same thing almost two years ago, using only jsp, servlets, jsptags and XSLT engines...
does the portlet add any feature to the things that i have just mentioned?
The Portlet API proposal is *not* synonymous with the JetSpeed Project nor bound to any product. The goal is that any portlet vendor can write portlets to the Portlet API and these portlets then can be deployed on any Portlet API compliant portal server.
In the JetSpeed project, an initial effort was made to define a new Portlet API to achieve interoperability between portal server/portal framework implementations on one side and portlets on the other side, therefore JetSpeed is referenced in the JSR. It is important to note that the referenced API is is not the API of the current JetSpeed 1.3 a 2 release, but the new Portlet API that has been proposed.
The Portlet API is important to many players in the portal space:
- Portlet vendors and application providers need it be able to develop portlets once for all J2EE based portal servers instead of once per portal server product
- Portal customers want it to protect their investment in portlet development and purchased portlets
- Portal vendors profit from it since a common API will result in a large set of installable portlets will become available over time
- A standard will enable building tools for portlet development
Alright, that sounds much better. The old JetSpeed, with its ties to ECS and Turbine, was terrible. This new stuff (I read the PDF) sounds much better, if you manage to make it so that it's easy to implement Portlets with any framework. It sounds feasible from the description, but it's hard to tell for sure without a concrete API to test against.
It'll be interesting to see what happens, no doubt. Thanks for clearing up this thread.
JSR162 & JSR167 are being merged into one JSR. Both of these have major relevance to the work that Oasis is doing in WSIA, and a soon to be formed TC to be known as WSRP. Both of these TC's are concerned with "How do you present UI's over webservices, in a generic fashion ?" So, for this work to proceed, the first step is to define a standard mechanism for local calls to these type of portal artifacts.
I see that both JSR 162 and 167 have now been marked as "Withdrawn". Does anybody know when the combined submission is expected to appear?
The new Portlet JSR is up: JSR 168.
I have to agree with Rickard here - this is a sad day for the JCP. I agree that portals are necessary and indeed good, however the first thing that needs to be defined is the definition of a portal and what it wants to achieve. Next, surely the standard should control the _interoperability_ between portals, rather than the layout and design of them.
There are any number of frameworks existing that can drop into any web server to produce the same result as this JSR (WebWork + SiteMesh is just one example that's actually more powerful together than this JSR purports to be).
My second beef with this is if you ARE going to decide to write a portlet API (ok, it's not _that_ bad an idea), then WHY PICK A BAD FRAMEWORK TO START FROM? This seems incredulous to me that they picked such a poorly architected, almost non-used framework - just because IBM picked it to use as their portal server to try to make up some marketing ground to BEA doesn't mean it's any good folks.
What a sad corruption of the JCP.
It just makes me wonder how important a reference implementation is to the JCP. Who's gonna write free, open-source Java code? Apache is the cheapest way for Sun to do this. Sun wouldn't want to actually hire some Java developers of their own to head up a JSR and write some actual code. ;-) Juuust kidding.
Now, they couldn't wait on Apache to do a J2EE reference implementation that ran EJBs, etc. since Tomcat was only a servlet/jsp container. In order for server-side Java to succeed, they needed to do it themselves.
So I think Apache probably pulls an inordinate amount of weight, if only for the reason code does exist and it is open source. I seriously doubt BEA or Oracle or whoever want to pony up (as free open source) their hard-won, effective portal solution when they can make so much money on it.
So it seems the JCP is stuck with a solution that may or may not be best-of-breed just because they need a reference. Which might explain why a spec of this sort would HAVE to be ambiguous and occasionally contradictory.
Not until the disparate implementors try their hand at implementing javax.portal.whatever will the spec tighten up.
Who knows. I'm guessing. <shrug> In the meantime, IBM is ahead in implementing their version. ;)
I don't know why everyone is so down on this. IBM has contributed to over 80% of the specifications that already exist.
J2C was submitted by IBM, it was called Common Connector Framework before.
The JMS P2P API has a lot of what the Java Base API had for MQSeries, The Entity Bean API has its root in VAP from Visual Age. IBM has been on a role as of late in the J2EE community and some people feel threatened by this. People should try the Portal product first before bashing it. The industry cannot afford to sit and decide what a Portal is by a committee. CORBA suffered with this and stayed behind the times.
"I don't know why everyone is so down on this. IBM has contributed to over 80% of the specifications that already exist."
And that is relevant in this context how? A crappy JSR is a crappy JSR, regardless of any other circumstances.
I agree with Rickard on this score. Just because they've supported/contributed 80%? That's like something you often hear in corporate world both technical and non-technical, "Well, we've always done it that way, so the right way is to continue doing it that way." That statement leads to static management (again technical or not), and can be the death-knell of a company or project.
I think there is too much over anlysing here. When IBM was behind in the standards, everyone complains. When they create standards everyone complains. The death of a project? If you don't like the standard, don't use it.
Please read the complaints will ya, *before* posting. This has not much to do with IBM as such. The core issue is whether this is a good idea or not, from a spec point of view.
Your assertion that "if you don't like the standard don't use it" is rather naive. If you were building a product and all of a sudden your competitors product is deemed "standard", for no good reason, then what does that do to free competition?
The Portlet API is probably the most important non-core API out there. Why? Portals are where the majority of new IT Java spending is going these days. Portals are something that is actually selling very well in this economy. Portals are the biggest class of web applications out there today. Everyone wants to build a B2C, B2E, or B2B portal. Why? Most folks think they actually give executives the fabled ROI. Now, I know we all have our own sacred cows... This may be mine.
Ok, if you buy the argument that portals are important. Why do we need this API. Someone lists Struts, Turbine, and a host of other technologies as open source portals. Well that's not really true. These are all Web Application frameworks. They can certainly be used to build a portal. I have built corporate portals with just the JSP Model-2 Architecture, a ton of JSP includes, and long hours. However, the portlet API proposed has very little to do with these frameworks. The portlet API is only about building an API so that portlets built for one framework will work in another. Turbine could care less about this. Struts could care less about this. They are not portals. However, this is very important to projects like JetSpeed that would like to share portlets with the Struts subproject tiles. However, for portlets to work in both these frameworks a number of portlet services must be implemented. Portlets are very similar to servlets. In fact, the are servlet subclasses with additional required methods for communication and complex lifecycle services.
The spec proposed is actually the newly accepted JetSpeed API. It's not the horrible one that is implemented today. It is the new model that will start being implemented when the JetSpeed framework is finished. Yes, IBM contributed 90% of this spec. The folks at JetSpeed want it though. (Read the archives) They want this spec standardized. The folks at Struts want this framework. The folks at IBM want it. The folks at most of the other vendors will probably want it too. If not, they are free to vote against it.
I just can't understand why this JSR would draw a reaction as irrelevant. It is one of the few relevant JSR's IMHO.
First. put a lot of money to define jsr and advertise it.
Say the other are not standard and they are bad even they can achieve the same functionalities.
JSR based implemenation become the defato standard.
Oh yeah, our product is better, customer come and get it.
Developers are then just talking about these products.
I still think ATG and broadvision portal server are better defined. But they don't know how to do business.
bea, oracle, Sun and IBM are late players and they need a way to pull the market share from them. First define the J2ee server, then get the attentions from developer and public. After all, use third parties application. Finally, build their app and sell it.
Anyway, let say good bye to many app providers that build their app on J2EE technology. Many of them will be gone soon.
So don't just blame Microsoft.