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.

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

so, i agree with you that it is a shrinking packaged apps market,

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

Good old Roy! Good to see you haven't lost your enthusiasm.

http://manidoraisamy.blogspot.com/2008/06/jsr-286-now-posted-so-what.html

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 a classic situation where 2 big headed companies, got in the way of technology, and in the end everyone suffers, including the actual technology. 3 years ago, companies would of implemented this... today with the advent of the numerous Javascript based technologies which allow for portlets to send events to each other on the client side (no server post back), JSR286, is outdated before its released. I needed this stuff nearly 3 years ago, since then we have developed our own portal server, loosely based on JSR168 but added 2 big features. 1 is the event exchange system, which uses a Javascript system to handle the communication between the portlets. From an IT perspective it is a little loose, however there is no lag from a user's standpoint (no server postback), and the benefits far outweigh the drawbacks of using a client side messaging system. When we went beta with the portal, we could barely keep up with the demand from our customers to implement the technology. Sorry but IBM and Sun really screwed the community here, by delaying this spec far too long. This is still a 100% server based technology, where users are now demanding instant response times, which require much more processing on the client.

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 as -does not provide any kind of coordination between applications -security is weak -limited support for CSS and Javascript

sometimes useful but has drawbacks such as

-does not provide any kind of coordination between applications

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

-security is weak

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

-limited support for CSS and Javascript

In the cases I have been involved with the backend apps were made with the portal in mind, so they simply referenced the portal CSS, which they then could update as they saw fit. Worked quite well. We also did some fixes to support AJAX-style applications. So, so far I must say that the proxy method has worked surprisingly well, even though it is "crude" in a sense. But with a little ingenuity you can get around most of the obvious problems.

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.

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.

It sure wouldn't work with all usecases, but I've been amazed just how often it *does* work. Customers of SiteVision has quite often used the proxy method to integrate apps which definitely weren't made for it, with quite good results. Since it is a proxy-technique it is possible to do content-filtering before presenting it, and our solution uses XSLT on the HTML that allows you to tweak the HTML to look ok in the portal. Usually one removes headers and footers of the proxied application, and sometimes you add or replace the CSS so that it fits the other graphical design. If the underlying app uses the JSR168 CSS styles it works out of the box, of course. The main cases I have seen it not working is if there's a lot of custom JavaScript that assumes that the app owns the whole browser. Some .Net-apps do funky stuff with session management, which is also hard to emulate. But again, it is amazing how often this technique actually does work, and whenever someone writes a new portal app from scratch I recommend them to do it this way (i.e. any way they want), instead of using portlets. One of the most recent cases is the Swedish pension fund website (ppm.nu), which use SiteVision in the front end and Spring apps in the backend. To the user this is all transparent. In these kinds of cases, where you want to combine strong CMS features with your own custom functionality, a product like SiteVision will make it soooo much easier than to roll your own for everything.

I take a positive view of this specification release. Yes, it is well overdue, but I don't think it is "too" late. To comment on some of the previous posts ... most of the app servers have proprietory stuff to support these The whole point of this is specification is to provide a standard component interface. Certainly if this release had come earlier it would have saved the portal server vendors from having to develop proprietary solutions to the shortcomings of JSR 168 (Portlet Spec. 1.0), but now the standard solution is specified I expect every portal vendor will implement it, relegating their proprietary solution to legacy. and most of the companies who used portal in the first place are moving out of it Any evidence to back up that claim? The reports I've read indicate the opposite trend. The practical benefits of a portal server (often just called a portal) are realised by website administrators who need to deliver a website containing multiple applications (also often referred to as portal). Portlet applications are deployed into the portal server which provides secure single sign on and overall site navigation (between applications) amongst other things. There are other ways of integrating multiple applications into a single cohesive website, but nothing else as clean and simple as the portal/portlet concept. Portlets provide little benefit to developers. They remove the need to provide authentication but that's about it. So far, they can even be quite frustrating to develop as they have severly limited your choice of web framework, javascript libraries and web ui libraries. Portlet 1.0 even limited the functionality you could provide. The important thing about this Portlet 2.0 specification is that it removes the functional limitations. It will be a little while before web frameworks and Javascript libraries support the spec but I've no doubt that support will come, thus removing the other source of frustration. Springframework have it scheduled for the next major release. Portlet support is currently the most requested enhancement for Grails. The only feature feature I've noticed missing from the spec so far is a "loadOnStartup" option. This is trivial as it doesn't prevent portlet containers providing it as a deployment option anyway. today with the advent of the numerous Javascript based technologies which allow for portlets to send events to each other on the client side (no server post back), JSR286, is outdated before its released. Why would JSR-286 need to specify this? It doesn't preclude you from implementing this any which way you want at the client and still remaining JSR-286 compliant. The "advent of the numerous Javascript based technologies" is a good reason why it is right not to have specified this. You will be able to evolve your own solution over time following developments in the client (e.g. localStorage) without having to wait for the Portlet spec to catch up. One feature I'm hoping to see from JSR-286 compliant Portal Servers is a way to use the Event facility for Portlet -> Portal communication, enabling navigation from within one portlet to another. Any vendors out there planning for that? Cheers, Derek

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 portals

I did mention that there were other ways of doing it.

why couldn't a user/customer use SSO

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

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.

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.

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

------------------

Abacus

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

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.

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.

If you have a portal server, that works for your company's needs, which many companies now have or are in the process of implementing. Why on earth would you want to use something that is obviously 2 steps back in terms of advancement in technology. Because it's standard? Server based standards, no longer have the pull they used to have. Users want applications today, and they want them to be responsive, and feel like desktop applications. We are moving away from server based applications (old school servlet based apps), and moving back into a realm of client-server applications (JavaScript + Servlet based apps). This server side specification, is 2 years too late. At this point you are asking well over 50% of major corporations to do a change so they can adopt a new portal technology, even through their existing one, already implements all this functionality in another way, still allowing you to plug in "portlets" as individual modules. Don't forget vendors still need to implement this... we'll be well into 2009 before a decent, scalable, portal which implements JSR 286 is available.

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. I will not comment about the differences with pure mashup solutions because it is another debate (whether you should have everything in the web tiers with a solution like RichFaces or you should have Javascript in your applications that does tons of stuff that you will have to maintain years, etc...). We can agree that today nobody use anymore servlet+JSP but rather a web framework. People first chose a web framework and then decide how to consume the application: as a standalone or aggregated in a portal. That's why the debate is not relevant and what is relevant is whether or not the web framework you are using will be able to be adapted through a bridge in order to be consumed in a portal environment. If you consider that then the JSR286 is *nothing more* than the standardized technology that allows a bridge developer to create a portable bridge for the target web framework. The expert group spent lot of time improving the spec for bridge developers. For instance, JSF applications and Seam/JSF/RichFaces applications can today be natively deployed in JBoss Portal or in the JBoss Portlet Container because a huge effort of standardization is currently being made by JSR301 and we do provide an implementation of the spec as the JBoss Portlet Bridge. More than that, today Seam provides advanced functionnalities such as events and page parameters that can be mapped to Portlet 2.0 coordination features. Similarly technologies such as Wicket also has a bridge that provides a runtime for Wicket based applications in a portal supporing JSR286.

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.

I will not comment about the differences with pure mashup solutions because it is another debate (whether you should have everything in the web tiers with a solution like RichFaces or you should have Javascript in your applications that does tons of stuff that you will have to maintain years, etc...).

And you won't have to maintain the JSF/Portlet/Seam solution? Or it just won't do tons of stuff? Not to be cheeky or anything, but I think you are in the proverbial glass house throwing stones. I've been watching and reading a lot by the portal vendors who are jumping on this Ajax bandwagon. And it's because RIA front ends are neat. More like the Windows apps that everyone wanted to begin with, and Web developers could never really do. But you still have the issue that this aggregation of portlets is linked to a server side structural representation that must remain consistent. I saw a BEA presentation where they are preaching this same thing of "Oh you can have Ajax, but you still need a portal server. You just have to now execute all this nifty utility code that we give you with the product to keep all these little disjointed UI's in sync. None of which I see mentioned in the spec, btw, so hmmm, what's the chance that one vendor's will match another. I mean the cross portlet communication piece is there, but as far as implementation, where it really matters. I see the Tower of Babel, part two. Oh, and let's not forget that you keep tossing in RichFaces (Part of the JBoss product brand, conveniently enough - when you make hammers it all looks like nails, it seems). Let's see what we have here so far. For adhering to "standards", I get not one, but two, cumbersome, memory heavy, and often slow and cumbersome server side rendering models to facilitate my responsive, client side interface. And simply tossing out additional hardware as a solution seems to be losing the attractiveness it once had, at least in the circles I move in. Lot of talk here about all the benefits that a portal server brings to the table, and I am not necessarily going to disagree completely there. But all this stuff is usually available without having to run a portal. It's just another server side technology. It reminds me of the old Lotus Notes/Domino days where they bundled a mediocre word processor, email, database and web server and tried to sell it as the successor to peanut butter and chocolate in the great ideas sweepstakes. Trouble is, there's really nothing explicit about single sign on in the spec. Or personalization management. Or repositories (separate spec). It's all about portlets. The spec just talks about portlets. Which aren't, in and of themselves, portals. Portals are a concept, portlets are just kind of a kludgey implementation of a way to do them with dashes of other J2EE technologies tossed in for flavoring. These are all features that vendors will implement in their own fashion, with their own little quirks and ways of seducing you into locking them in so I am unsure where in these areas all this so-called standardization really benefits you. And let's even examine whether that is really a benefit. In practice I see people mucking around with site look and feel/authorization/and content via developers and administrative drones working live against the production sites on some GUI tool. That is just sooo twentieth century. And it's really what all the J2EE community used to hammer Microsoft about as well, since that's really their model. Don't control what's going on. Use the the GUI tool. Point and click your way to an early grave. Guess it's in the eye of the beholder.

We can agree that today nobody use anymore servlet+JSP but rather a web framework.

I think you should get out more :) There is a lot of homegrown application space out there, and you of anyone should be aware of just how resistant most enterprises are to ever getting rid of anything. And that includes apps like those. Especially apps like those. In reality, corporate pointy headed bosses never tell you you have to rewrite a whole app in 30 days or whatever. They tell you they want 10 more screens and X more functionality and it has to be added to the current one, which has a mix of other web technologies, half of which aren't supported any more. And it keeps coming around to my main issue with the whole portal vs. portlet thing. It's not a spec about designing portals. It's about designing portlets, which are just the community's latest attempt to make yet another simple task as complex as possible while all the ROR and PHP people snicker. And in this case, I can't much blame them. All I ever hear about is how now you can go out and consume all these portlets that some imaginary portlet provider is writing for you. Yeah, right. Like that's going to happen. Really took off, didn't it. Just like no one was going to write full applications any more anymore, we would just be buying functionality as EJB's and assembling the components. Does any of this sound familiar? No one does it. No one is going to do it. It's just another case of building functionality that with absolutely no prior demand. A local radio station here once had an imaginary company called Brute Force Cybernetics - We create the need, and then fill it. That sounds a lot like what seems to be going on here. I don't say it's necessarily a good thing to write security and personalization, repository functionality yourself. But the key is how easy it really is to integrate and swap parts around. I think there are much better ways to do those things than specify what is basically a UI technology first and work everything backwards from there to make it fit. Which is just the way I see it. Sorry. Now I won't, like some, say I won't use this stuff. Matter of fact I am going to dig in heavy duty. Because as soon as all these pointy headed managers dig in here, get 100 feet over their heads, and have to call someone to really READ what is in that spec and why all this stuff they produced that was just supposed to work out of the box is going belly up(just like all those Applet/Servlet/EJB/JSF apps) while the lights go dim I'm going to be ready. And so is JBoss consulting and support I would venture a guess. But let's be realistic about what this is. It is commerce. Not problem solving. Not innovation. It's a way of tacking more stuff on what you've already invested in so you can sell some more of it. If you were solving the real problem it would be with functionality that doesn't require a portlet.

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.

Three Economic Systems

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

 

Cheers,

George

 

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

Thanks ATH-M50

 

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

Great.

http://9xtec.com/

Do you have any news about this please ?

 

Livre dor mariage

JSR-286 is simply awesome golden age of hollywood actresses

thanks for posting this buffalo brochure design