Best Practices in Portlet Deployment
Has anyone seen any article on Best Practices in Porlet Deployment, or have opinions on the subject?
I'm specifically interested in weighing the relative merits of publishing/deploying all my portlets into a single war file versus publishing/deploying multiple war files with one or more portlets.
This assumes that I have resources on the server running by web container to adequately serve them.
This also assumes they are local to the container which is running the portal. In that case, I'd need to use WSRP, but I'd still need to decide whether it was more maintainable to publish them all in one war file or separate them into multiple war files.
I think I know the answer. It depends. :-)
I would however like to hear about what others have done: What's worked. What hasn't . What lessons have you learned in your production portal environments.
Thanks!
Byron Estes
SCEA
[945 byte] By [
ByronEstes] at [2007-11-25 20:33:33]
# 1
Wow. No opinions at all on this topic?
# 2
there are several opinions - I am sure
:-)
First of all: Is the portlet solution the right one or is it better to go for the native provider implementation and not for the portlet standard which only realizes a minimum functionality provided by several portal-jsr-168-compliant containers.
Secondly: Do you want to setup 1 webapp per portlet or run them all in several web-apps ?
/u
# 3
Thanks for replying, Ulf!
You're right there are a number of foundational questions that need to be asked (...or assumed).
For discussion purposes, my opinion is that JSR-168/WSRP is the way to go because I'd like to be able to share these things given the reality is that many companies have not one, but several portal servers.
As much as possible, for performance I believe I'd want to deploy them local to the portal server to avoid the SOAP/XML marshaling/unmarshaling with WSRP.
At a minimum I would think they should be grouped into "functions" and deployed in separate apps based upon those functional groups.
I was curious what real life experience managing deployment and re-deployment of portlets to a production environment (...and various development/test environments) has taught them about the best, easiest, most managable way to deal with them.
# 4
In hopes that eventually people start posting to this topic instead of just viewing it, I thought I'd add something else that I recently learned that impacts how you might want to package up portlets for delivery in portlet applications.
I probably should have realized this earlier, but it escaped me....
At a minimum those portlets that need to communicate with each other by SESSION, must reside in the same portlet application.
# 5
The JSR 168 Specification is based on the Servlet specification. Portlets are deployed as WAR files with each portlet essentially behaving like a Servlet. I think that the packaging strategy for Portlets should be similar to existing packaging strategies for Servlets. A development group could start with the idea that all portlets would be deployed together in a single WAR file. This way, all the portlets can share the session information.
This might become cumbersome due to different maintainence schedules of various portlets. You should also consider that if multiple development teams are creating portlets then perhaps each team would own its own WAR file. This might be the case if each business unit in an organization is responsible for maintaining and deploying their own content.
The pdeploy command must run separately for each WAR file as well. With many WAR files, this could create a long deployment time. If reducing the deployment time is a goal, then the fewer the WAR files the better.
Ultimately, I think the same problem exists today for servlet technology and I don't really see much of a difference for deploying portlets one way or the other.
- Jim
# 6
Jim,Thank for the input!It will be interesting to see what happens assuming portals become the "visual glue" to SOA's.
# 7
I found this useful article: http://www3.software.ibm.com/ibmdl/pub/software/dw/wes/pdf/PortletCodingGuideli nes.pdf
# 8
Okay, we've got a somewhat different approach.
First a question... when you guys are doing your daily builds to the integration server (everyone is at least integrating their code no more than on a daily basis right... something tells me Dave Thomas just flinched somewhere). What is the longest part of the deployment process? The pdeploy stage by far!
Yes, JSR-168 is the coolest thing and, yes, a standards-based approach is smart! But what if, rather than placing all this view/edit/help modes in your portlets, you placed that logic into the web container the portal server is running in (we call it portal services)? (One caveat here... we are only deploying to SunOne, or whatever we're calling it this week, Portal Server and it is for internal use only. So these comments are not directed towards portal logic integrators or portlet resellers) Then inside the portal container you place a URLScraper to portalServices. PortalServices then uses AJAX calls to the web container (yes, you have to consider security and pass appropriate information to it). What you get is application logic and flow within the context of that channel. No more full-page refreshes, no more full-page edit screens, and no more undeploying/deploying your JSR-168 portlet on every single server in your farm (my last contract will soon have eight of them) during a deployment . What if instead, you deploy a war file and load a URLScraper pointing to the app and simply use AJAX asynchronize calls to talk to it. Ohh and did I mention, it's just commidity servlet development, and there's no more pdeploy.
Sure if you must, deploy the initial View-Only with a JSR-168 portal get all the chrome you want, but let the portalservices war in the web container do the heavy lifting.
You wanted discussion...
# 9
Thanks for your thoughts wrreisz1!
I've been using AJAX too for the chattier more interactive portlets, but not for everything. I'll consider what you've said and think about if/how to apply it.
Thoughts: You still don't eliminate the pdeploy for the first release (...or those that might change the basic portlet code), although I personally tend to get around/limit that by adding a JSP for each of the modes whith can be configured for the instance of the portlet deployed on your desktop(s). In that way I can make many changes (...very significant changes) and never be forced to updeploy. I wimply redeploy the portlet war file again with the changes.It might be interesting to look at a service layer approach using AJAx to centralize/resuse some of the base code like security, logging, etc. to make sure it's consistently applied.
I do like the use of AJAX to improve performance. The idea of rendering and reassembling content from every portlet on the desktop each time, even with cacheing, just rubs me the wrong way. :-)
Thanks again. Discussion is good and those that challenge each of us to consider other ideas and alternatives is the best of all.
Byron at 2007-7-4 18:01:03 >
# 10
|| You still don't eliminate the pdeploy for the first release
Byron, sure you. Use a URLScraperProvider. Configure the channel in your desktop profile to point to the default action of your AJAX app. You've abstracted out this logic from the portal rendering logic. We've removed the pdeploy stage completely. If you need access to the identity server or logging (as you mention), we abstracted this out also into a shared commons.
# 11
Got it now.
In that case, haven't you made this particular implementation of it non-standard (i.e. not really JSR-168 compliant)? As long as any other portal server has a URLScraper like component I suppose you could still use it. I still kind of like the life cycle, the hooks and the inter portlet communication that comes with the standard.
Thanks for clarifying!
Byron at 2007-7-4 18:01:03 >
# 12
Byron... take a look at my original post. I accept the conclusion that it is non-JSR-168 standard. Although, as you pointed out before, you could always use a JSR168 portlet if you intend to deploy to multiple platforms.
