Dave Minter

Originally posted by Glen Cai:
If I had three web app that were based on portlets according to the
JSR-168 specification and I were asked to develop a new web app
that would need a little bit from the three existing apps,
could the portlets from different web apps be easily integrated
within the new app? The three portlet apps were developed independently,
but may share some common data.

If you want them to merely exist as functionality available to the user of the portal - no problem. If you want them to communicate with the new app, then no more or less so than a conventional servlet.

Dave.

Originally posted by Nicholas Cheung:
So, will there any further specifications on how the portlets be communicated even they are developed by different vendors?

I don't entirely follow what you're asking - what are you looking for here above and beyond what one could already do with two servlet applications?

Dave.

Originally posted by Glen Cai:
Are you saying that you can integrate cnn.com and yahoo.com using portal
without any code changes on cnn and yahoo?

There is a big difference between a "Portal" and a "JSR 168 Compliant Portal".

The latter guarantees support for JSR 168 compilant Portlets. If CNN and Yahoo were JSR168 Compliant Portals composed entirely of JSR168 Compliant Portlets, then yes, you would be able to integrate them without any code changes.

In practice, of course, they ain't so it ain't that simple.

Dave.

Originally posted by Nicholas Cheung:
I still have some more questions about portal applications wanna discuss with you, will you still be here this week?

Sure, I'll try to keep half an eye on the Web Application Frameworks forums from now on for any other portlet related questions that crop up.

Dave.

Originally posted by Dirk Schreckmann:
The correct winner was "David Ulicny" not the author, "Dave Minter".

"Dave" ... "David" ... Same thing, right?

Ah, well, in view of that, perhaps Nick could drop me an email, and I'll arrange to send him a copy instead.

Dave.

Originally posted by Nicholas Cheung:
Congratulations to all winners, and thanks for Jeff and Dave to be with us for a week.

However, Dirk, seems that one of the winners Dave Minter is the author of the book!

Nick

Hurrah, and a fine prize it is too... although I do still have five copies in a box on my desk.

In view of which, Dirk, perhaps you could pass "my" copy on to Nick here, who's asked some interesting questions in the last week.

Unless Jeff's short of a copy...? ;-)

Dave.

Originally posted by Glen Cai:
Comparing to Struts, JSF, and other frameworks, what does portal
provide better than others? What portal has, but other do not have?
What is the trend in web application framework?

A portal isn't a framework. You can build a portal using Struts, JSF or any other framework you care to shake a stick at.

A JSR168 portal is no exception, but provides a very specific set of services to portlets, which are in some respects more limited (they don't have "ownership" of the page), but provide services to allow them to co-exist with other inhabitants of the portal.

Dave.
[ November 15, 2004: Message edited by: Dave Minter ]

Originally posted by Nicholas Cheung:
Dear Jeff and Dave,

I would like to clarify on my understanding of session mgt of portlets.

For a single page, in case it contains, say, 3 portlets, then there should be 3 portlet sessions, isnt it?

However, as they are based on the same HTTP session, thus, the 3 portlet sessions in fact is based on that HTTP session, and data can be shared by the 3 portlets via the HTTP session, am I correct?

Thanks.

Nick

Yes, three portlets running on the same application server will have mutual access to the application-scoped contents of the HttpSession and vice versa servlets on the same application server will have access to the application-scoped contents of all of the PortletSession.

So yes, you can share data in this way, but if you don't control the environment your portlets are running in, you have to bear in mind that the deployer may choose to have only one portlet running, or to serve the portlets from different servers into a WSRP container. So you need to be very explicit about what dependancies exist between your portlets.

Dave.

Ah, actually I think I misunderstood your last question; you're speaking of (for instance) entering form data on four distinct portlets, aren't you?

Portlets can't share forms, so yes, in this case you'll lose changes.

There are various work-arounds for that; probably the best is to only allow form-changes to be made on one portlet at a time. You could also "force" submit any changes to a field once focus is lost.

This problem is not fundamentally different to the usual situation when you have two forms with distinct action urls on one page.

Dave.

We have tried before but with no luck for this at all, when page refreshes, except the portlet that triggers the newly retrieved data, the data in the rest 3 portlets lost.

When the page refreshes all portlets receive a render request. This is their opportunity to reflect any changes in underlying data. It doesn't matter which portlet received the action that caused the refresh.

Dave.

Originally posted by Nicholas Cheung:

For example, the "screen" contains 4 portlets, one for wheel, one for body, one for the inner structure, and one for color. If, say, I choose a wheel, a body, a type of structure, and color in grey, and then click submit, what should happen? All 4 portlets have been updated accordingly, or only one of them being updated, and the rest 3 data lost?

Only one of them will have been updated, and the rest will be left as-is. Unless you choose to have them behave differently; if they all communicate with a common back-end of information, they will all get the opportunity to update their output in response to the change.

But the general case is that actions carried out on one portlet do not affect other portlets.

Dave.

Originally posted by Nicholas Cheung:
Thanks David.

However, what I needed is not just the confidentality. For example, a user goes to my page, which might forward him to a page contains stock code, a buy-sell screen, a/c balance, etc. However, the remote portlet requires a checking on authorization to see whether the user can do certain actions (query or update), so, SSL does not help in this case.

As we might need to use WSRP, thus, we are also thinking of using SAML as the security checking means. As far, I just wanna know whether there are other *natural* means for evaluation.

Nick

This is the sort of scenario where SSO comes into play. I would be inclined to do this with Kerberos if presented with a clean slate, but in practice you will usually have to work with whatever the existing infrastructure dictates as the "standard" authentication environment.

Working with Kerberos, you login to the web server, which in turn authenticates you and presents your credentials to the portlet. The portlet then has everything it needs to establish a secure context on the remote system (assuming they both have access to the Kerberos domain).

Chapter 13 includes a detailed example of using JAAS and JGSS-API to do exactly that.

In the end portlets don't present you with any new security problems or solutions over and above servlets - but they make some of the existing problems such as SSO rather more prominent.

Dave.

Originally posted by Nicholas Cheung:
Dear Jeff and David,

Do you think, in upcoming versions for JSR 168 or supplementary JSR, they will introduce Global context, so that each portal application could be communicate with each other using this context?

Nick

My feeling is that this probably isn't that useful a thing to want to do; it's perfectly possible to build a portlet which defers the content-building operations to a servlet(s), where that sort of thing is easy, and even if you don't want to do that, J2EE is already replete with communications APIs. Most portlets will be running in an environment where the full resources of J2EE are available!

Don't forget that your portlets will often be a very thin layer of logic talking to some application on the back end. For example, you might have a pair of email portlets, one of which was a "biff" style mail notification portlet, the other of which was a "mailbox summary". They don't need to talk to each other to figure out what to display - they just talk to the mail server!

Dave.

Hi,

I'll be doing my best to help Jeff out and answer any thing he misses on our chosen specialised subject. Hope you've all tried out one of the JSR168 compliant portals and are just burning to know more !

Dave.
[ November 11, 2004: Message edited by: Dave Minter ]

Originally posted by David Ulicny:
How to migrate existing web application to portal server?
Is it possible?

It's certainly possible. It can be moderately painful, depending on how well structured your originating application is.

We actually provide a concrete (but necessarily brief) example in Chapter 13, where we take an open source forum application and convert it into a portlet.

Most of the pain comes from simple things - you don't own the page, so you can't set content headers, or necessarily govern the CSS styles which are available to you (a subset is dictated by the JSR168 standard). Also, the handling of URLs is unexpectedly complicated since they must be permitted to contain arbitrary container specific information in addition to the relative paths and attributes associated with your portlet.

Dave.