Portlets and JEE

[Piotr Nowicki]

Howdy Ashish!

I'm really new in the Portlets world, so excuse me if it's an obvious question :-)

I am just thinking - if Portlets are built on top of Servlets (and runs in Portlets Container, right?), then is it a part of JEE 6?

If not (I can't see it here: http://www.oracle.com/technetwork/java/javaee/tech/index.html), than should I understand that either the Web Profile or the Full Profile of JEE6 Application Server doesn't have to implement PortletContainer, and it's just the good-will of Application Server provider to support Portlets?
If I understand it correctly, this technology was made for web-tier, and doesn't seem to be too young to be a port of the JEE spec, as the JSR 286 (FR) has 3 years, so why it is so?

Cheers!

[Ashish Sarin]

hi Pedro,

I think that portlets deserve a place in the Java EE stack. Oracle hasn't published any plans for next Portlet specification, but I do think that sooner or later Oracle will align portlet specification with Java EE stack, so that portlets can also take the complete advantage of application server infrastructure. For now, portlet container implementation is a nice-to-have feature for application server vendors.

Java portlet technology is mature which makes me feel that may be we'll possibly see portlets as part of Java EE stack soon, and it'll become mandatory for application server vendors to provide a portlet container implementation.

regards
ashish

[Piotr Nowicki]

Thanks for fast answer Ashish :-)

So, basically, if in an enterprise, you use multiple information systems like Accounts System, Financial System, Document Management System, etc. than the Portlets would be the technology to use in order to provide information aggregation, right?
So this aggregation is only on web-tier it's only a visual integration - it is not any close to the Enterprise Integration Services?

Do you think that in the light-frameworks age, age of GWT (and SmartGWT, GWT-Ext, ...) the Portlets does have a bright future?
Or rather they would be too cumbersome for small projects and therefore, would be used only by large companies developing Enterprise Software?

Cheers!

[Ashish Sarin]

Yes, your understanding is correct about aggregation of content. I think the word content doesn't only mean showing information, a content also refers to a service. A portlet in a way not only shows you information but it is also a window to a service. Let's assume that you have a "Customer Account" portlet, which interfaces with a "Customer" information system. The portal page also has "Loans" and "Credit Card" portlets, which show information from "Loans System" and "Credit Card System", respectively. Now, when you select a customer account from "Customer Account" portlet, you can use inter-portlet communication mechanism to pass the selected account information to "Loans" and "Credit Card" portlets. The "Loans" and "Credit Card" portlets make use of the customer account information to displays the loans and credit cards issued to the customer. This indicates that you can integrate services from different systems in the web layer. This is a loosely-coupled integration and can go a long way towards achieving service-oriented architecture. Portlets are well-suited for medium or high complexity portal projects, and may not be a value add for small projects.

regards
ashish

[Piotr Nowicki]

The idea of integrating services in the web layer with Portlets sounds quite interesting...
I'd need to consider this a bit deeper.

Thanks Ashish! :-)