JSF Central - Scott O'Bryan chats about JSF, portlets, and the JSR 301 Portlet Bridge
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Scott O'Bryan chats about JSF, portlets, and the JSR 301 Portlet Bridge
by Kito D. Mann
20 Oct 2009 00:15 EDT

In this podcast, JSFCentral editor-in-chief Kito D. Mann talks with Scott O’Bryan about the JSR301 JSF Portlet Bridge. This interview was recorded in September of 2008 at JSFOne.


Podcast (MP3)
Welcome to the JSFCentral podcast # 17 for the week of October 5, 2009. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
Kito Hi, my name is Kito Mann. I am here at JSFOne 2008. We are now at day three. I am here with Scott O’Bryan, who works at Oracle, and works on ADF Faces and Trinidad, and also is involved in the JSR301 JSF Portlet Bridge. Scott, why don’t you start by telling us a little bit about your work and your background?
Scott Alright. As you mentioned I work for Oracle, in particular the ADF Faces team. We make a relatively rich render kit for JavaServer Faces, Ajax enabled and what not. One of the focuses of the work I do there is the portal integration between that render kit and portal container. I have about 12 years of experience in the computer industry. I was a consultant for quite a while and got a wide range of background. I got hired on to a permanent position at JD Edwards. At that time this was pre-JSR168.
Kito Which is the portlet spec.
Scott Yeah, I was one of their lead portal architects. I redesigned the whole system. I basically re-wrote their second generation portal for them. I did that for quite a while. When PeopleSoft bought JD Edwards it was thought that they really didn’t want to compete in the portal space, so I was instrumental in allowing the JD Edwards application suite to move to a standard JSR168 portal. At the time we were using IBM WebSphere. Then when Oracle bought us I got moved over to and Oracle project called ADF Faces. I did straight Faces work for a couple of years, until they realized they wanted to get these things to work in portal containers. It was their answer to how applications are going to be developed in the next version of Oracle applications. They looked around to see who knew anything about portals and they’re like, “hey, Scott used to be a portal architect,” so they kind of drafted me into doing that work. I then got involved in doing a lot of the spec work and those sorts of things, trying to really marry the JSF view technology and portal environments.
Kito Okay, so just for those listeners who aren’t really familiar, can you explain what a portal server is and how portlets fit into that?
Scott What a portal is…. The biggest consumer-facing type of portals would be something like MyYahoo or iGoogle. What they basically are is an aggregation technology that really takes a bunch of applications that can be from different sources, and tries to display them in a coherent fashion on the screen to the user. There is a lot more that portals do, but frontward facing, that is basically it. They have standards built around being able to consume web services so you can expose content through a web service from .Net or Java. There is no telling what actually gets put in the aggregation engine. In order to support that, you need your own kind of container. That is what JSR168, the portal 1.0 spec, specifies. There are a lot of challenges with that, especially dealing with Ajax applications or JSF applications. In Ajax applications there is a lot of complexity with dealing with the JavaScript because you have to play nicely with others on the page. Furthermore one of the caveats of this is you also have to play nicely with yourself on the page because you can have two copies of your own portlet. If you have IDs or JavaScripts that have common names or names that interfere with yourself, you can run into some issues. There are a lot of issues associated with portals and I think it has the illusion of being fairly straightforward, but once you dig into it you realize that programming for a portal environment is actually a very complex prospect.
Kito Part of the complexity is because you have what people normally see is a web page and you have all these little self-contained applications on it, right?
Scott Right, except they are not really self-contained. That’s the thing; the portal controls the outer page. Most web developers I know kind of thought, “I think of me owning the page.” The page is owned by a container, by the portal system. You just own a small portion of that page and you are not isolated from everything else on the page, which has both advantages and disadvantages. If you know what else is on the page, you can interact with it on, say, the client side. In general, you want to try to see if you can’t isolate yourself as much as possible. The isolation really catches a lot of people off guard. It may seem kind of an easy prospect to think about an application as owning the entire page, but then when all of a sudden you own a section of the page, you realize there are a lot of issues involved with that. On the back end, being able to work in that type of environment, having to be able to re-render your content without necessarily processing your entire application. With portals you always need the ability to refresh your GUI. That is something that a lot of servlet developers have taken for granted, that they can reprocess everything, but that’s not true in a portlet environment. So you know, it requires a little bit different way of thinking. Like I say, the solutions do get very complex.
Kito Right, okay so we have talked about these portlets and how there are all these issues involved. So when someone wants to write a portlet, it is essentially a variation of the web application, right?
Scott Correct.
Kito So can you talk a little bit about what’s different in writing the application than just writing a normal Java web application?
Scott Okay, number one, a portal has its own metadata set. Obviously in a web application, you have your web.xml. Portlets have a portlet.xml that exposes what portlets are available. The portlets are actually derived off of another class. It is taken from the portlet API versus the servlet API. They have generic portlets implementation as well as an interface that you can just implement, that specifies what a portlet is. One of the key differences to a portlet environment is that in a servlet environment – the standard web container – you can load a series of servlets just by changing the URL. With a portal you expose one portlet in a space and every request goes to that portlet. Furthermore, for each instance of a particular portlet on a page… in this case I am talking about portlet A and portlet B are kind of the same portlet so they can show maybe two sets of data side by side. In those cases you actually have two instances of that portlet. That way they run kind of in an isolated environment. That is one of the biggest topology differences that you find between a portal and servlet environment, in how you go about constructing your app. Underneath the covers, portals own the URLs that you generate. You are not making a post back to your web application. When you do, your web application can say “I want you to go to this page” or “I want you to call myself with these parameters.” In a portal your callbacks or URLs don’t actually go to you, they go to the portal server first. The portal server has to have information in that link, or that URL, to be able to realize that you are the portlet that is making the post, and then it knows from that how to get that information to you. That is kind of a big learning curve as well. The other major difference in portal development that I think is different from servlet development is the two-phase request cycle.
Kito Right, it has caused a lot of issues.
Scott The two-phase request cycle is brilliant from a portal architecture standpoint, but a lot of people have real trouble relating to it. How this basically works is there is an action request, a process action method on the portlet API, and it is responsible for doing the bulk of your work. It is the thing that – you understand that when you have an action request, your portlet is the one actually acting. In other words when a person clicks a button on a screen, they are only interacting with one particular portlet. That particular portlet is the only one that gets the action. The action runs business logic or whatnot. After that is done, a second request comes into your portlet to render your portlet out. On a typical portal, when you click a link and you do a form submission, it is going to do a full page refresh on your browser. All the other portlets on that page have to be able to re-render themselves back to the user just like they were before so you get expected results.
Kito Right and this is in the case of a normal full page refresh like we are used to in older web applications.
Scott Exactly. And in a portal system there are still a lot of use cases, even with the brand new specification, where it is expected you will make a full page refresh. Certainly portal vendors can have control to come up with some really inventive Ajax solutions on the portal side to enable you to not have to do full page refreshes. The spec is really written from a barebones standpoint of – for certain things, especially like an action request -- that these are going to be full page refreshes.
Kito Okay, so if we look at portlet development, we basically see that there is the issue of having several portlets on the same page or having the same portlet on the page multiple times. There is the issue of not having any control over the URL structure and that kind of stuff, and then there is also the separate render phase and the separate action phase as distinct things. So essentially what you are saying is that when you write a portlet there are obviously different issues that you have to worry about.
Scott Yes.
Kito And consequently, if you use a web framework to build your portlet – which you certainly can do – like JSF, there are different issues that need to be dealt with.
Scott Right. I am a big fan of consistent contracts. So to me a JSF developer is a JSF developer. They are not a portlet developer necessarily, or even a servlet developer. JSF is a model-view-controller framework. It implements a very complete controller. It implements a good view, and the model of course has the ability to bind a model into the whole picture, so what you end up with, with JSF developers, is they really kind of have their own development paradigm. They deal with things like managed beans. They deal with things like a JSP or a Facelet, and these are the technologies they are used to and they learn to think in those patterns.

One of the things that we were really pushing with the bridge project -- to be able to enable JSF on a portlet -- is to allow JSF developers to develop applications like JSF developers. We didn’t want them to have to worry about, or at least worry as little about the fact that they are running in a portal versus the fact that they are running in a servlet. One of the strengths of JSF is that it really does provide a good abstraction between the native objects such as the HttpServletRequest and servlet response versus the portlet objects – the render response and render request or action response and action request. So you have a lot of the building blocks to really be able to simplify development between portlets and servlets.

So the idea is that hopefully you will be able to take a person that has been developing JSF applications for their whole career, or for a portion of their career, and then somebody says we want you to write a portlet, and they can just do it. Then, as extensions to the base, we allow people to do the more intimate interaction with the portal, but that’s the primary goal. One of the things we have really done is we looked at how a bridge would react from several different skill sets. Those were an end application developer. We wanted them to take applications literally directly from the servlet and go into a portlet environment. Then we took a render kit developer. With render kit developers, they are a little bit more technical and intimate with how JSF works.

Kito Right.
Scott We wanted them to be able to allow their render kits to enable portlet functionality, but not necessarily always have to have portlet functionality deployed on your web server. For instance, Trinidad. If it has portal functionality built in to it, and the ability to handle some of these portal use cases, it is kind of a failure of the framework if that means that every environment they deploy into has to have the portlet API and the bridge. We wanted them to be able to deploy into a standard plain Jane servlet environment. So there was a lot of attention paid to being able to allow applications to run both inside a portal environment and outside a portal environment.
Kito Right, so the bridge is essentially the integration layer between JSF and the portal server?
Scott You can think about the bridge as being a replacement for the Faces servlet in the JSF implementation.
Kito What’s important… the reason there is a JSR for this is because there are lots of different portlet bridges for JSF.
Scott Yes. Some people may disagree with me, but I think to a large extent there was very little attention paid to portal use cases in the JSF environment. Obviously it was paid attention to. The API for the lifecycle, or the whole concept of an external context was really designed around being able to enable portlet-like technologies. But what really kind of failed in the spec is they didn’t take into… They took into account how an API would be exposed, but they didn’t really take into account how would a JSF developer use these particular APIs to do what they needed to do. What we found is that although the building blocks were really there, the complexities were not really appreciated in the JSF spec. What you ended up with is, as implementers started implementing bridges, they all came up with different designs for how they could be extended. Some had capabilities to support different portal views and others didn’t. Some had the ability to mix portlet content with JSF content, some didn’t. Some of them handled ambiguities in the spec differently. Most of those bridges were tested using local portals like Pluto, Liferay, some of those others.

There does exist another set of portals out there and they really make life difficult. They are WSRP portals that are exposed through web services. In those types of environments there is a lot in the portlet spec that is left to interpretation. Whereas you may be able to expect something from a Pluto -- a prime example is between action and render -- your request parameters are generally preserved in local portals. They are not preserved in WSRP portals. Between action and render, your request scope gets cleared. If you are defining request scope beans in your JSF, you are not thinking that those things are going to go away and you’re reinitialized during the render. That can cause some real problems in an app. The purpose of the 301 expert group was to really delve into a lot of these issues and try to figure out how rich render kits like Trinidad might be able to really, really leverage portals and make the application developer’s life easy. We tried to tackle what we saw were some of the major shortcomings of the bridge spec. We got a lot of support from the Apache community and the Java community. There were a bunch of portal people on the expert group and a lot of people from the various render kits or other portals out there that really took and tried out the stuff, gave us some really good feedback, and I think we have really hit most of the major points.

Kito Yeah and I have to say, I am on the expert group too but not totally active. I have actually worked… I have been using the bridge and it works pretty well.
Scott Martin from Apache had put together a demo of the Portlet Bridge using a full blown rich application. I think he used Trinidad for that, I am not positive. And he used Orchestra to do some of the stuff Orchestra does, and it was a fully functional app and he showed it working under one of the alpha versions of the bridge.
Kito Nice.
Scott It was just sort of a demonstration to see if we really got this right. At this point we have had a number of people that have taken some of the early releases and adapted some of their applications. We are getting positive feedback on what we have done with the bridge.
Kito Excellent.
Scott To me that’s the really winning use case. Render kit developers -- you get a lot of innovation in those areas and sometimes those people can kind of do… and I am one of those, so when I say “you people” I mean me. Sometimes they are willing to go that extra mile to get that little bit of extra richness in their GUI or a little bit of extra capabilities. But an application developer doesn’t want to have to do a lot of that. They want their toolset to provide that for them, their render kits. To me the real success stories are: can a render kit do what it needs to do, to be rich and do all these things? And in the end, can you take an application developer who uses JSF and has only ever used it in a servlet environment, and have them immediately turn around and run an application or convert an application to work in a portlet?
Kito Exactly.
Scott I think we have got a pretty compelling solution to be able to say that.
Kito So if I am a JSF developer and I have written my app, and then my boss says “hey, this needs to run in a portal server,” and let’s say I decide to use the JSR301 Portlet Bridge, which is actually part of MyFaces right now, the reference implementation. What do I have to do?
Scott There is going to be some more documentation on the project, but obviously it starts with downloading the Portlet Bridge. Ideally all you really have to do is specify a portlet.xml which says to run the 301 generic Faces portlet for your portlet. The idea is that you can basically just then load that into a portal and try running it, with no real modification. There are a couple of things that you have to pay attention to. Right now they are outlined in the spec and hopefully soon there will be a how-to guide for some of these things. I touched on a lot of them during the presentation I did at JSFOne. There are a few caveats but really when those come into play are when people step outside of the JSF framework. The bridge does a lot through the JSF framework to really try to make things work consistently. The minute you start going outside of that framework, we can’t really do a lot of support there. If you use managed beans like you are supposed to, you have an application developed that has all of its navigation rules specified through the metadata, and even a little bit of things where maybe you are using some links, maybe to go to a new JSF view or you are running a couple of external web content, the bridge will probably do most of what you expect it to do, most of what you need.

The one thing that I tell people to do is take that application and try running it as is. Your issue should become very apparent. Because this stuff is still kind of in its infancy, the expert group and the developers are really active – especially on the MyFaces list -- and our turnaround time on questions posted to the expert group through the JCP is pretty quick. It is definitely possible that we forgot about something. The spec is in its final review. Now is definitely the time, if people want to try out their applications, to point out some shortcomings that we have, and really give us some good feedback so that when we do make this a final release, it really is a compelling solution for JSF developers. The only way we can do that is to really get input from the community. Getting the bridge to work is fairly easy: it’s portlet.xml, you add a couple of jars to your class path and Faces should just run.

Kito Okay, so do we have a release trajectory for the spec?
Scott The JSR itself won’t be closed for a little while because the JSR is actually going to produce two specifications. The first spec is the one that is in final review. It is for Portlet 1.0 and JSF 1.2. The bridge is going to probably have to have a new version for each version of JSF and each version of the portlet. Now they are backward compatible, and of course you can run the Portlet 1.0 Bridge on the Portlet 2.0 portal but you don’t get all of the extra advantages of using our framework. The one I am really excited for is one we haven’t even started scoping yet, and that is the JSF 2.0 and the Portlet 2.0 Bridge. Portal 2.0 solves a lot of issues that we had, especially concerning Ajax and some of this rich UI stuff that we had with the Portal 1.0 spec. Then JSF 2.0… we have a guy that is part of this project that is on that expert group. I think you are too but you are not acting more as a bridge, you’re acting more as a JSF.
Kito Michael Freedman.
Scott Yeah. He is really trying to get some of the real “gotchas” that we had in implementing the bridge with JSF RI. He is trying to get more elegant things speced into 2.0, for us being able to support them. That I think is where you are really going to start seeing these technologies, at least as far as the bridge, really kind of come into their own. Definitely the bridges today are useable because a lot of the hacks that had to be put in place to get this stuff to work together are in the bridge. They are not expected to be in an application. Going forward I think there are going to be some really exciting things and I think that you will be able to, in a general fashion, deliver applications that are as rich as what you see in a servlet environment.
Kito Okay, well, I think those are all the questions I have. Anything else you want to add Scott?
Scott No.
Kito Thanks a lot for coming and speaking at the conference. I appreciate it. I know you weren’t sure if you would be able to come at first, so I am glad you made it out here. Hopefully we will get to see you next year. And we’re looking forward to seeing the final version of the bridge.
Scott Sounds like a winner. Thank you.
Announcer That’s it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann.


RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.