News: JSR-286 Now Posted
The final JSR-286 (Java Portlet API version 2.0) spec has now been posted (see http://jcp.org/en/jsr/detail?id=286). According to a source close to the expert group, a holdup for about three months was a disagreement between IBM and Sun that has now been resolved. The major changes in version 2 of the Java Portlet API are: - Events - enabling a portlet to send and receive events and perform state changes or send further events as a result of processing an event. - Public render parameters - allowing portlets to share parameters with other portlets. - Resource serving - provides the ability for a portlet to serve a resource (including doing ajax calls). - Portlet filter - allowing on-the-fly transformations of information in both the request to and the response from a portlet.
- Re: JSR-286 Now Posted by shawn spencer on June 13 2008 19:22 EDT
- Re: no comparison by douglas dooley on June 14 2008 00:34 EDT
- Re: no comparison by Joseph Ottinger on June 14 2008 07:53 EDT
- Re: no comparison by Roy Russo on June 14 2008 09:14 EDT
- Re: JSR-286 Now Posted by Adam Clarricoates on June 14 2008 16:40 EDT
- 2 years too late by Pierre Tessier on June 14 2008 18:21 EDT
- "Late in the game"? by Tor Iver Wilhelmsen on June 17 2008 07:09 EDT
- Re: no comparison by douglas dooley on June 14 2008 00:34 EDT
- Other ways by Rickard Oberg on June 14 2008 11:02 EDT
- Re: JSR-286 Now Posted by Derek Alexander on June 16 2008 06:12 EDT
- Re: Portlets and such by douglas dooley on June 16 2008 06:49 EDT
- Re: Portlets and such by Derek Alexander on June 16 2008 08:08 EDT
Re: Portlets and such by Roy Russo on June 16 2008 09:48 EDT
- Re: Portal Servers by douglas dooley on June 17 2008 12:30 EDT
- Re: Portlets and such by Karl Banke on June 17 2008 05:46 EDT
- Re: Portlets and such by Michael Quinn on June 17 2008 06:31 EDT
- change management - doesn't like change by Pierre Tessier on June 16 2008 07:20 EDT
- Re: Portlets and such by douglas dooley on June 16 2008 06:49 EDT
- Re: JSR-286 Now Posted by Julien Viet on June 16 2008 13:26 EDT
- JSR-286 Now Posted by Walter Paul on December 25 2010 16:49 EST
- JSR-286 Now Posted by George Kaerfsseldne on January 10 2011 22:27 EST
- Long wait by Graveri Atom on March 24 2011 21:17 EDT
- JSR-286 Now Posted by Harrie Hines on April 08 2011 00:42 EDT
- JSR-286 Now Posted by Bethany Badgley on June 03 2011 07:22 EDT
- agree that this is far too by Passion Lab on June 22 2011 06:00 EDT
- Public render parameter by chetan kapoor on December 22 2011 03:01 EST
- JSR-286 Now Posted by Rizo Albert on May 21 2012 17:03 EDT
- Thank you by vipin raj on June 10 2012 07:07 EDT
- Mickael by clint eastwood on August 15 2012 14:37 EDT
- hey by club stork on April 18 2013 04:35 EDT
- day by Matt Coleman on April 19 2013 02:24 EDT
- Re: JSR-286 Now Posted by shawn spencer on June 13 2008 19:22 EDT
this is so late in the game .. most of the app servers have proprietory stuff to support these and most of the companies who used portal in the first place are moving out of it. this is like the ejb dejavu.
EJB is a cross-platform component model that has been adopted by every single vendor except SpringSource and Microsoft, with millions of downloads, and thousands of deployments worldwide: how does a portlet spec. compare? because it will 1 day be like EJB, adopted and legacy and all...i kind of doubt it... i really don't know what a portal does anyway, is there anything beyond Liferay and proprietary tier-1 vendor implementations that have a life-span beyond three years... so, i agree with you that it is a shrinking packaged apps market, but my prediction is that there will be more emphasis on standardizing business logic than presentation logic, and unless u believe spring has a shot at ubiquity, EJB will be part of that conversation... (i really cant believe how anti-conventional wisdom this pro-EJB position has become) also, i feel like putting in an Apache-like-JCP statement at the end of all of my entries protesting the appointment of a .Net Editor for TSS, something like: "Though I would typically support this post, while feeling it is an inadequate debate, I am waiting for someone with Java experience to assist in the leadership of TSS, so that we could move to a more in-depth level of analysis than re-hashed product announcements."
"Though I would typically support this post, while feeling it is an inadequate debate, I am waiting for someone with Java experience to assist in the leadership of TSS, so that we could move to a more in-depth level of analysis than re-hashed product announcements."Doug... have you actually looked at Peter's qualifications? He's worked on a primarily .Net publication *recently*. That doesn't mean he has no Java experience. He was editor for JavaPro - a well-respected magazine - and a valuable contributor to it. Personally, I think that kinda... counts... as Java experience.
I was a little over-excited about my jab at Apache's (and for that matter IBM, Intel, Red Hat, etc, though only Apache votes no purely in protest...) JCP tactics that I decided to make up my own disclaimer, so i understand u went through a thorough vetting process, and i acknowledge i forgot from a previous thread the JavaPro experience, so my apologies... So i guess i wont get 2 far along in my argument since this is just week 2 in the transition, but the point being that TSS is basically the central point and a unique 1 for presenting ideas as well as product announcements or spec. releases, more than just news of the day but analysis, so i encourage you, Peter, to accept my apology and ask people to think and react, not just peruse... As for the portlet spec, the topic of this thread, I am confused, Roy, what do portal vendors outside of the apparent ineptitude of Sun and IBM do that is so special, other than offer vagaries around "framework" as opposed to "application"...i understand it is apparently a run-time for developers to now standardize the portlet development process, if that ever happens... but what exactly are developers going to build? do u remember Compoze Software, i think in Philly, that did MS Exhcnage links, but also 'components' for calendaring, e-mail, to-do lists, etc...not sure if they are still around, but it was never clear to me why if server-side components did not initially catch-on, why would client-facing components: so that everyone would have the same look-and-feel? Portals are like SOA, another way to sell software, they don't actually have technical merit in the standardization process, yet, and perhaps that is why this announcement is good, but outside of selling a group of customizable widgets and JSF tags, what r customers going 2 do with them? I admire Liferay for giving it a shot, i would just like some clarity on the business model, and the pain points that are being solved, with so-called portals... (did i completely discredit myself?)
...is there anything beyond Liferay and proprietary tier-1 vendor implementations that have a life-span beyond three years...The power of the portal, is not in packaged apps, its in its ability to aggregate information from different data sources and allow personalization to the user at the same time. You don't deploy a portal because it has a better calendar portlet. You deploy the portal to solve a business problem. Consider the portal a framework... not an application. I do agree with the first post... it took 2 years to finish this one iteration of the spec, and by then everyone had their own proprietary workarounds. And this was because of some disagreement between IBM and Sun that we don't know about? Sun has a crappy portal, and IBM sells consulting. Next time, kick them both out of the spec, and let them fight like little girls on the sideline, while the process moves forward. Roy Russo http://www.loopfuse.com
so, i agree with you that it is a shrinking packaged apps market,
Good old Roy! Good to see you haven't lost your enthusiasm.
I have to agree that this is far too late in the game and the rate of progress of this API is glacial. To see what could have been done here, contrast Portlets to .NET's WebParts. To see the business demand, consider that WebParts forms the foundation to SharePoint - sure IT folk may have mixed feelings, but users love being able to customise their pages with components to aggregate data from a variety of sources. Anyone know of a decent open source Java API in this space?
this is so late in the game .. most of the app servers have proprietory stuff to support these and most of the companies who used portal in the first place are moving out of it. this is like the ejb dejavu.Well, why did we ever start using servlets? At the time servlets were introduced, people used CGI and SSI written in C or Perl or whatever. So servlets were "late in the game" - the only reason to use servlets was that you got to write in the new, fancy Java language. Other example: Should not Sun have made JNI just because Microsoft and Netscape already had made their own interpretations of "native"? J/Direct was way easier to use, though it only worked on Windows. Was Sun "late in the game"? You seem to draw the wrong conclusion as well: The proprietary portals like Oracle's are being abandoned - but that is because they are moving to standards instead of proprietary solutions. So, yes: Portal vendors - including Sun - added their proprietary "extensions" to JSR-168, but now there is a spec. This spec changes JSR-168 (Portlet 1.0) into something useful. I, for one, having fought with weird proprietary portlet technologies, am grateful for that. The problem now is to get vendors to actually implement the specs correctly.
I built a JSR168 container that is now part of the SiteVision product (CMS+portal in one). While it was very useful for internal purposes to have the Portlet API, if I look at the bulk of major projects that have been done with it, most chose to do it using web clipping instead, similar to what is described at portletbridge.org. Essentially, the functionality is implemented in a separate server, using typically either Java or PHP, but could be anything, and then webclipping is used to get it into the portal content. That has proven to be a very useful model, since the web app can have total control over JVM versions, servlet container versions, and other needed things, plus being able to easily restart without cycling the entire portal. And the app only has to implement regular HTML, without bothering with either JSR168 or WSRP specs. Pretty nice!
sometimes useful but has drawbacks such asDepends on what you mean by that. I have yet to come across a situation where many applications from different vendors needed to be coordinated. If you mean coordination between "views" of applications by the same vendor (or custom apps written by the customer), this actually is not so hard to do. Mostly a matter of sending request parameters from the portal container to the backend system, and you can do all sorts of stuff with just that.
-does not provide any kind of coordination between applications
-security is weakActually security has been one of the main reasons for using the scraping proxy method. The portal container is usually in the DMZ, but you don't want to put your applications there, or the application databases, so by placing the apps on the inside, and then only having port 80 communication from DMZ to the custom apps, it is much more secure than if you "export" all your logic to the portal. As for authentication, this can be trivially passed from the portal to the backend application, and we have even had cases where the portal accesses the apps through a reverse proxy security product to ensure strong authentication all the way. What kind of security were you thinking about btw, is there anything in particular with the proxy method that is weak securitywise?
Hi Rickard, I think that what you are describing makes sense (even though it is hackish and has limitations) because you have the a good degree of control over the applications you aggregate in your portal. It could not work with all use cases.
I think that what you are describing makes sense (even though it is hackish and has limitations) because you have the a good degree of control over the applications you aggregate in your portal. It could not work with all use cases.
Derek, You said that: "Portlet applications are deployed into the portal server which provides secure single sign on and overall site navigation (between applications) amongst other things." why would this be a unique feature of portals, why couldn't a user/customer use SSO and BPM to do the same thing? is it the integration (and potentially proprietary implementation) of these two features which make portals better associated with administration and ease-of-use... I am thinking of this same concept from the server-side perspective, and still am confused to what a portal's discerning value proposition is, and then u mention this: "Portlets provide little benefit to developers." I am not completely sure what you mean by this, but am i 2 assume that developers don't really benefit from writing front-end apps targeted at portals?...is the supposed standardization process incomplete?...are there better functionality options with web frameworks, such as Seam and Spring, that writing portlets is not a recommended approach?... Look, I am all 4 the spec., and i expect that Liferay would b able to come on here and give their side of the story, that would influence me of the value of portals, but frankly, after your post, I am less convinced, apologies all around...
why would this be a unique feature of portalsI did mention that there were other ways of doing it.
why couldn't a user/customer use SSOFirst up all their applications would need to be compatible with their SSO system. Even if they are compatible this will still usually require a little bit of configuration for each. Not all SSO is equal. That's why I mentioned *secure* SSO. A decent portal will also provide single sign off either explicitly by user or implicitly on idle timeout. A decent portal will also allow you to include remote portlets, extending this SSO to them.
and BPM to do the same thing?Not sure how BPM would help here. I was referring to how a portal server would provide a menu system on the web page and that by simply deploying a portlet and specifying the groups it should be available to, the portal server would ensure it appeared on the menu of relevant users.
Is it the integration (and potentially proprietary implementation) of these two features which make portals better associated with administration and ease-of-use...Yes, that's pretty much it.
"Portlets provide little benefit to developers." I am not completely sure what you mean by this,I suppose it depends where you draw the line on a developers responsibilities. What I meant, is that for a web developer, developing a single application, they don't help you do anything that isn't doable (and usually easier) by other means - except of course target a compliant Portlet container. The benefits are elsewhere (beyond what I see as the developer role). When you come to create a website aggregating multiple applications. When you know you will want to extend that website by adding additional applications later, potentially from third-parties. Perhaps you know your intended market already has Portal Servers widely deployed. Don't get me wrong, there are good reasons to develop portlets! Sometimes though I've seen portal servers and portlets pushed as a development platform, the web equivalent to Net Beans Rich Client Platform perhaps. This technology may well reach that level eventually but it is still some way off.
but frankly, after your post, I am less convinced,Darn, I didn't intend to come across negative about portals at all. To put it another way: If you need to deliver a cohesive website aggregating many applications then Portals/Portlets are the way to go (assuming you can, depending if your suppliers can/will deliver apps as Portlets). If you are developing an application, unless you expect it to be deployed into a Portal Server then the Portlet spec isn't the easiest way to do it. What would really make Portlet 2.0 take off would be widescale adoption of Portal Servers. If a hosting service were to provide affordable hosted portal servers for the small to medium enterprise then perhaos that could happen. What might encourage that? Some high quality OSS portlet applications for webmail, blog, wiki, calendar client, forum ...
What would really make Portlet 2.0 take off would be widescale adoption of Portal Servers. If a hosting service were to provide affordable hosted portal servers for the small to medium enterprise then perhaos that could happen. What might encourage that? Some high quality OSS portlet applications for webmail, blog, wiki, calendar client, forum ...Nah. That's been done; when people posted about it various portlet collections on TSS (example from JBoss) .. they went nowhere. Of course, none of this takes place in a vacuum; it could have been that the timing just wasn't right. But the portlets are already there, so it's not the portal market catching up - if it was, then portals would be on fire right now, because the portal vendors have been ready.
That's been done; when people posted about it various portlet collections on TSS (example from JBoss) .. they went nowhere.The problem is that in real-world deployments, chat, calendar, and calculator portlets don't provide much business value. While at JBoss, the portal was most often deployed at large corporation wishing to tie information together from disparate sources. This often meant SFDC, Exchange, and even some green-screen legacy apps all being combined in to a portal. Those are often niche applications in their own right, and so there doesn't exist the demand to OSS or even sell them.
Of course, none of this takes place in a vacuum; it could have been that the timing just wasn't right. But the portlets are already there, so it's not the portal market catching up - if it was, then portals would be on fire right now, because the portal vendors have been ready.
Doug, (Can I call you "Doug?") ;-)
I am not completely sure what you mean by this, but am i 2 assume that developers don't really benefit from writing front-end apps targeted at portals?...is the supposed standardization process incomplete?So your pointy-haired boss walks in the door and says, "We need an interface for our 300 world-wide partners that shows them order information, sales data, and keeps them up-to-date on partner news. You can run off and build this all yourself, but you most likely already have these systems in place - order management, news, etc... In this instance, a portal buys you not having to worry about user management, personalization, SSO, or any of the underpinnings of the main "site". Instead, you focus on developing the individual portlets, using the framework of your choice (JSF, Seam, Spring). Your point-haired boss likes you now: 1/ You saved him money, in not re-writing all the systems from scratch 2/ You gave him coice: You can move your portlets to JBoss, Liferay, IBM and they should work regardless. 3/ You didn't waste time building out the tedious bits that are inherent to every portal. Its done for you. Whenever I had (not at JBoss anymore) a customer want to develop his own portal for his own business need, he ended up a few years later with some useless legacy app that no one wanted to maintain. I'm sure we've all experienced this. Roy Russo http://www.loopfuse.com
Roy, Most people call me Doug, i just use the Douglas moniker because Jonathan calls himself by his full-name, so i thought: why not, lets try it for on-line correspondence...basically, i think it is ridiculous, but not as ridiculous as trying to b like engineers via appearances, such as PTB... As 4 Portals, u r right, i don't want to re-invent anything that is already built, so thanks for that bare-bones analysis of portals and portlet-interoperability...i understand that you can customize look-and-feel, and still get app portability as well as some built-in functionality... my only professional experience is trying to work with iPlanet Portal Server, which never ran on the application server from Sun, and was just thinking that Sun PS ripped-out their home-grown code and started shipping it to customers, and so it left a bad-taste in my mouth... i have a sibling that worked for Plumtree, and understand that it did it better, and have high hopes for Liferay on Glassfish, and 4 u, as well, in this market, if that is what u r doing...i am all 4 standardization of portlets, i just needed to vent a bit on what role they actually play in middleware decisions... carry on, Roy, i am with ya...
I have read your article, it is very informative and helpful for me.I admire the valuable information you offer in your articles. Thanks for posting it..
In this instance, a portal buys you not having to worry about user management, personalization, SSO, or any of the underpinnings of the main "site". Instead, you focus on developing the individual portlets, using the framework of your choice (JSF, Seam, Spring).In my experience, a scenario like the described does happen - but not that often. I have however witnessed quite the contrary rather often: You use some portal product, but the constraints of the product lock you out of decently using JSF, AJAX, your existing security infrastructure, third party vendors, your proven inter-application communication models etc. On top of that, you may find out that moving your infrastructure from one vendor to another will not work as easily (or not all), because to get any meaningful result you had to cut corners and use some vendor propriatry stuff, that was just not available somewhere else. All of these scenarios happened *a lot* and are the precise reason we now have this new specification...yet: too little, too late. On top of this, Portal Servers impose a certain interaction paradigm that works a lot along the lines of "portlets" and "pages" that quite often turn out to be the wrong kind of abstraction to your actual business problem anyway.
Your point-haired boss likes you now:
1/ You saved him money, in not re-writing all the systems from scratch
2/ You gave him coice: You can move your portlets to JBoss, Liferay, IBM and they should work regardless.
3/ You didn't waste time building out the tedious bits that are inherent to every portal. Its done for you.
Whenever I had (not at JBoss anymore) a customer want to develop his own portal for his own business need, he ended up a few years later with some useless legacy app that no one wanted to maintain. I'm sure we've all experienced this.
One pointy haired boss (boss A) tells you we need supply management, location tracking and customer self managment, in an integrated "application", and he doesn't really know or care about "minor" implementation details. Another pointy haired boss (boss B) says we need to get our costs down and so, we need to engage external "partners" to supply us with packaged solutions. All cool so far You say, we need a standards based approach which will significantly simplify our authentication/authorisation model, unified presentation tier, provide extensibility and flexibilty and ability to perform "component based development" (SOA etc...) maybe portlets ??? So, in come the "vendors" - call them boss C and boss D. So boss C says , we have a fantastic tracking system, just what you need. So boss D says, we have a fantasic supply management system, just what you need. And then in 2 part harmony, boss C and boss D say, " oh, sorry, while we have an excellent SOA architecture, all nicely partitioned, with first class decoupled implementation etc..., we just dont have portlets on our radar. Our existing customer base are just not interested, and in fact, you are the first ones to ask us to implement a portlet based front end !!!" And then even louder!!! " But, sure, we'll implement a portal solution for you, it will cost !!!$%%$@! dollars extra" And yes, I know there a lots of ways to implement portal integration (Iframe, clippers, etc...), but all are comprimises and result in lost functionality. To me this is the fundamental issue
Alot of the discussion here seems to be pondering over why portals and this portlet specification just don't seem to take off. I surmise the answer to this question doesn't lie in any significant flaws in the spec or with portals in general so much as in the general nature of the Internet, where there are simply so many ways to do things that no one method can take hold unless it represents such a breakthrough as to make all other methods obsolete. Portals and portlets do not at the moment represent enough advantage or present a compelling enough option over other methods of creating web sites to become a leading paradigm.
About the debate is JSR286 not too late or should I use whatever technology to build a portal and not use JSR286, I think that the debate is just wrong.Well, that depends on your overall point of view. If you want to look at the idea of a portal as a concept, and not the current J2EE centric idea of it as a marketable product, I think there are some openings. Google is a portal. Ebay is a portal. MSDN is a portal for that matter. So if you are going to have that debate, it seems only proper that you would examine those who have gone their own way versus those who embraced the "standards" and see exactly how much that disregard actually cost them in the end. Not to put out an answer, but I don't think it's any forgone conclusion.
We can agree that today nobody use anymore servlet+JSP but rather a web framework.
I do agree with the first post... it took 2 years to finish this one iteration of the spec, and by then everyone had their own proprietary workarounds.
To summarize, here are the major working areas for JSR 286 -
- Coordination (Events support, Sharing session beyond portlet application, Sharing render parameters across portlets)
- WSRP 2.0 alignment
- Better support for Web Frameworks (JSF, Struts, Spring, WebWork)
- AJAX Support
Three months was quite a while. At least the disagreement was already settled. Anyways, would these changes in Java API make the it even more powerful? Regardless, these are features worth waiting for.
Are these the only major changes in version 2 of the Java Portlet API?
- enabling a portlet to send and receive events and perform state changes or send further events as a result of processing an event.
- Public render parameters - allowing portlets to share parameters with other portlets.
- Resource serving
to say these facts are something that would help those learning about JSR
I have to agree that this is far too late in the game and the rate of progress of this API is glacial. To see what could have been done here, contrast Portlets to .NET's WebParts. To see the business demand, consider that WebParts forms the foundation to SharePoint <a href="http://www.mql-programming.com">MQL Programming</a> - sure IT folk may have mixed feelings, but users love being able to customise their pages with components to aggregate data from a variety of sources. Anyone know of a decent open source Java API in this space?
Can we share PRP beyond page level?
if yes then how we navigae?
Well this kind of information is really worth searching for, good information for readers and a value for you as will definitely show the quality of the writer. It’s good to have these kinds of articles around to keep the information flow steady. Helping those who really can make things right in the future, good work!logo design Toronto
Do you have any news about this please ?
JSR-286 is simply awesome golden age of hollywood actresses
thanks for posting this buffalo brochure design