As we grow our skills as professional developers and architects, we tend to forget that our profession is constantly churning with new people, ideas, and technology. This churn, and the knowledge that Software Engineering is not like any other type of engineering is why we continue to build poor applications time and time again. What is a poor application? A poor application is any application that does not live up to its design, in terms of performance, security, usability, or function. It should not be that hard for any of us to think back on a project we have worked on, or led, that meets this criterion.The science of software engineering should be composed of the same rigorous set of rules and standards that other sciences have to live by. No other engineered product is released to the general public without inspection, yet in software inspections take place a small fraction of the time, and at that are often cursory and incomplete.
I bring it up because I'm in the middle of a project where we are trying to track down a elusive memory leak. This isn't necessarily bad code, in fact most of it looks pretty good. But a few extra steps might have saved some trouble.
We are finishing up the final draft of my new book Application Architecture for WebSphere. It is not due out until the fall, but it takes that long to get it production ready. Interesting how the publishing phases match up with the phases we go through in our portal projects. But one thing that publishers do not skimp on is editing and reviews. An area where we in the IT world often take shortcuts. I devote an entire chapter in the new book on standards, logging, and code review process with examples and best practices to help new project teams avoid these problems. Of course we never expect to have problems.
I wrote this book because I continued to see problems in the way that customers designed and built WebSphere and WebSphere Portal applications. I was convinced that by writing some of my concerns down many of these problems would magically disappear. Well perhaps it is not that easy, but hopefully reading this text and considering some of its suggestions will help you on your way to obtaining software excellence.
- Keep having fun![Read More]
Portal in Action
7:00 A.M comes too early after a late night of discussion with colleagues, but I dragged myself out of bed this morning to have breakfast with members of my team. OK, it wasn't that late, but I'm not really a morning person. Richard G, who I mentioned yesterday, Tony Higham, Ken Polleck (my boss), Ken Krause, and some other folks, met with our executives for a morning discussion. All of these folks are considered experts in various portal topics, so it is always interesting in these discussions when we talk about strategy. Many times we agree to disagree, but I always come away having learned something from our interaction. To me that is one of the best reasons I enjoy my job, coming up with ideas, being challenged, and challenging others to continue to grow and improve our skills, which allows us to better help our customers.
Ken Polleck, mentioned an issue he discovered with a customers public portal site. As he described the problem, I realized that I had the solution outlined in a presentation I had given at the Portal Technical Conference a few years ago. How's that for collaboration? The problem was directing users to different pages on the portal, and can be solved by using rewrite rules within the IBM HTTP Server. This is really an Apache module, and happens to be one of my favorite tricks for various URL issues. I'm sure jw@IBM will enjoy the fact that I was able to mention rewrite rules again. :)
My first session this morning was given by Mustansir Banatwala, a Lotus Quickr Architect. The presentation was Lotus Quickr Overview, Architecture and Roadmap. OK, this was another 101 type of session, but I actually needed to learn the basics on this one. Lotus Quickr is IBM's new Web 2.0 collaboration product, enabling teams as well as larger communities to collaborate efficiently around documents, content, and places.
For me the interesting part of Quickr is the availability of content and document sharing, through wiki's, blog's, and document repositories. Making it easy to use these shared spaces and actually making it harder, not to use the collaboration tools is one of the key concepts of Quickr. I think this will help keep documents out of email, and off of local c drives and put them in a place where they can be shared and reused. The key for me is performance. Teamspaces, Lotus Notes databases, whatever, if it's slow, then it is unusable, and I am unlikely to return. Mostly I would like to believe that performance of OOB type applications like Quickr is a direct result of the investment in underlying infrastructure, with server capacity and network bandwidth being at a premium.
The Connectors aspect of Quickr looks very compelling. The ability to access or update content within other applications or from within Windows Explorer sounds like it will make collaboration much easier. The part I don't like about this type of collaboration is people finder, or expert location. This is where you can see if document authors or subject matter experts are on-line and available for a Sametime discussion. Not that I don't want to be found, but since you want to help people, sometimes it get's to be a little overwhelming[Read More]
It's actually surprising to me how many questions are getting answered for customers and fellow portal practitioners. I guess that is the point of this type of event, but folks come armed with questions and issues and are ready for in-depth discussion. Hey, where else can you get a free hour or two from one of Portals key architects, or someone with years of field experience? It is only the first day, but you got to start early to be sure you get the information you need. Several people have asked me questions that I wasn't readily able to answer, but as fate would have it, the right person was within a few steps. A quick introduction to explain the situation and I'm moving on to the next conversation.
One of the interesting features of this conference is the topic tables that are setup during lunch. It's an additional twist to the 'birds of a feather' that are so common at these types of conferences. I've always felt that one evening of BOF sessions was not enough, so luckily here they have setup two days dedicated to BOF sessions in the evening. This is in addition to the lunchtime topic tables. I sat at the "Portal Governance" table at lunch today with my colleague Richard Gornitsky. Richard is co-author of the book Mastering IBM WebSphere Portal and a veteran of large portal projects. We didn't talk much about governance; I guess people couldn't find our table. : ) Rumor has it that the performance table was hopping, so I think I'm going to hang out there for lunch tomorrow.
Stefan Liesche's talk on Portal 6 Operational Architectures and Procedures this afternoon was also apparently a sell out. I was on my way there when I was told it was standing room only, except fire codes wouldn't allow anymore standers in the room. Only slightly disappointing since I would prefer a customer get the seat I would have taken. But maybe next time I won't spend as much time talking in the hall between classes.
I was able to spend a little time over the last few weekends reviewing the WSRR-Portal Tech Preview. Pretty sad isn't it, this is what I do with my free time? This is an area of integration that we nagging at me, and I really want to try and stay ahead of the curve on the latest portal advances with SOA integration.
I was disappointed in some areas and excited with others. First I guess I'll talk about my disappointment. Really this is not the fault of any of the tools or development efforts, but rather my own bias toward improving portal management and governance. What I really think we need is some type of tool that allows us to provide meta-data around portlets themselves in some sort of catalog fashion. Some of this meta-data would include the purpose and owner of the portlet as well as any input or output parameters that the portlet may use with messaging. This would allow new composite applications to be created more easily by allowing administrators and business owners to look up portlets and see how they might communicate with one another. It would also help enforce some sort of standard approach to messaging allowing developers to adhere to published formal or informal standards. In other words, a developer can look at what parameters other portlets are using and attempt to build their portlet in a complimentary fashion. Up to now, I think the best way to accomplish this type of catalog may be a wiki that will allow cross domain teams to collaborate and maintain the information on different components. Our goal should be to help define a set of meta elements or development standards that can be used as a template to accomplish this goal. I'll try and come up with a template for a sample portlet catalog entry on Portal Patterns.org.
As for the exciting news, the WSRR tech preview really is impressive in terms of the integration with WSRR for portlet that utilize or provide services. There are two main parts to the integration.
With WSRP producers, after a portal is registered as a producer, other portals can then look up available producers and search for WSRP services any given producer offers. This is directly inline with most of the WSRP producer patterns that have been put forward. This includes either standalone producers or producers that also provide a standard interface to end users. I'll have to enumerate some of the common WSRP patterns that are available in a different posting. WSRP has been a little slow in being full adopted, but the vision has been constant, and the standard is continuously being improved upon. It is only a matter of time before it becomes better adopted within portal environments.
The second integration point is the ability to register portlets which consume services that are defined within WSRR. This provides a nice catalog of portlets which are really the front end for services available within the enterprise. Additionally, the capability to modify the service that the portlet uses is provided with some replacement of some of the administration capability within WebSphere Portal. This is an interesting capability that allows portlets to consume updated services that may become available over time.
From a portal perspective I think WSRR is still a challenge and I would not recommend embracing this approach, unless you already were embarking upon an SOA strategy within your organization. If this is the case then WSRR is probably going to be a player within your infrastructure and you are building the skills within your enterprise to manager this type of environment. For the average portal administrator (including myself) there is still a bit of a curve to climb to become truly proficient with and taking best advantage of WSRR within your SOA environment.
This integration is still a tech preview, so there were a few bumps in getting everything to work correctly, however the initial results were pretty impressive and I expect these things to become much cleaner as it becomes a fully integrated part of the product set.
For those of you paying attention, I have taken a short (read several months) break from posting while we finished work on the 2nd edition of our book, "Programming Portlets II". I have no idea if that is really going to be the title, I'm just happy that it is finished. We were able to bring on a bunch of new authors this time and really expanded the books content. Our goal was originally to bring the focus around to JSR 168, but we were able to expand that and add information on JSF, the Portlet Factory, and WorkPlace Forms. We were able to bring a bunch of new authors onto the team, many of whom are "the" experts in their respective areas.
With the draft finally shipped off to the editors, it gives me some time to breath and maybe work on other deadlines. Article 6 of our Project Portal Series needs to be started, and of course the PortalPatterns.org website has be left to languish. I added a new section to that site focusing on development standards. I'm hoping that someday others will join in and help me define a set of industry wide development standards around portal development. This is something that is desperately needed for many development teams. I added this new section as a result of an article recently published for the WebSphere Developers Technical Journal, where the editor asked me to pick a topic for his comment lines article series. Really, it was a chance to talk about any topic that I wanted, which is kind of what I do here! Hopefully, I was able to hit a wider audience then just the portal geeks.
Anyway, I'm glad folks are still reading, and I look forward to starting my Saturday morning posting sessions again and talking about all the new things we will learn with Portal V6.
I wanted to do a quick post just to update folks who stop by. I have to offer sincere apologies for not keeping up with things, but I promise I have some great excuses. I had started to get in the habit of spending a few hours on Saturday morning while my kids were in German language school to work on new postings. Since most of you know my postings tend to be longer discussions then quick hit information that I find too hard to keep up with. I'll let the marketing folks keep up with that type of stuff.
My excuse list is pretty long. First off we are toward the end of finishing the second edition of our book, Programming Portlets II. I am very excited about this. We have added a bunch of great new authors, who really are experts in the field. This book should be maybe twice as big as the initial volume with great coverage of the basics and all the great new features of WebSphere Portal 6. The focus of this book is JSR 168, but we are adding lots of chapters on JSF, the Portlet Factory, Workplace Forms, SOA, Process Portals, etc., etc. Look for this in December I hope!
Additionally I'm trying to put together some new material for the portal conference in
There is other stuff to that is taking my attention. Article 6 of our Portal Project series is still hanging over our heads and we hope to get working on that soon. As well as a bunch of new work on Process Portals and Portals in SOA. Specifically I'm trying to make sense of all the different products we have available and provide some recommendations and guidelines on when customers might choose one direction over another.
Oh, and then I actually have my day job helping customers deliver world class portals.
I hope you will forgive my indulgences as I climb out of this hole I have dug myself into. It seems that there is a light at the end of the tunnel somewhere, but it is still pretty faint. The upside is that if you can wait a little longer, I have a ton of new material and ideas to discuss with everyone.
Welcome to 2006! I hope everyone is fully recovered from the Holidays. I just have a short post this time to help me get back into the swing of things.
I recently was working with a group of architects during a portal workshop. During the course of the discussion I brought up the idea of defining a service layer for portlets to help ensure that developers did not arbitrarily create portlets that go directly against the data source. In addition, having a standard way of creating services ensures that everyone does it the same way, and you do not end up with a hodgepodge of ad hoc jars and properties files that are spread all across your directory structure. In the past my standing recommendation has been that I do not have a strong preference, as long as some standard is defined and everyone adheres to the same approach.
Many teams turn to using the Singleton pattern or use a shared class with static methods. There are different opinions on whether this is considered good or bad programming. Do a quick search on Google and you will see comments from folks who think Singletons are the best thing since sliced bread, as well as from those who think they are truly evil. In discussions with my colleagues we have not discovered any truly technical or performance reasons why you should use one or the other. JNDI look-ups on the services could become expensive if there are too many, but caching the look-up result will remove that issue. So the issue then becomes one of standards and design. Here are some of the benefits that I can see for using Portlet Services
The next questions is, "Would I use a Portlet Service in every case on my projects?" Probably not. There are too many design decisions to be made and each application has different requirements and different technical challenges. However I would probably make those exception cases and ensure that they are clearly documented in their approach.
One strong argument against the use of portlet services is that the API is defined and supported only by IBM and WebSphere Portal. Many architects want to define an agnostic layer that can be reused on different platforms. This is fine as long as the effort is made up front, to fully define your approach along with any configuration, deployment, and usage by different clients. This may include defining a common factory to handle serving the service objects up to your portlets. Remember your desire to keep things simple and use what is out of the box as much as possible. Truly this is one of the reasons you use WebSphere and WebSphere Portal in the first place is that is provides the framework pieces you need to concentrate on the business logic of your code. Even if that does not convince you, be aware of the fact that the most of the methods in your service will be your own and can be refactored pretty easily into a stand-alone object or moved to a different platform with minimal effort.
For some more technical facts around what Portlet Services are and how they are created try the Portal InfoCenter. I do have more thoughts in this area around defining what might be considered more agnostic service layers, or using a framwork such as the Spring Application Framework. Hopefully we can better answer some of these fundamental challanges during the course of this year![Read More]
When is your portal performance, good enough? What I mean by this is
1. You have squeezed 80% of the performance out of the machine, you think that might be enough and getting the additional 20% might take weeks to tweak and fine tuning code and options.
2. Your system is crashing or bogged down with only a small load, and you are not sure what steps to take next?
So before we get too deep, I do not consider myself a great performance expert, IBM has some great performance folks and I find myself going to them for help with many questions. Not surprisingly however I do spend a lot of time helping customers with performance tuning and problems. One of the most common questions asked of performance engineers is, "What kind of performance should I be getting?" Unfortunately the all too common answer ends up being, "it depends".
Yes, I know this sounds vague, but it is not a trick or an attempt to be evasive. One of the main reasons for this misunderstanding is that performance is very much tied into the application, and since every (yes every) application is different; performance will vary. I have had customers mention that IBM should provide a base application to perform portal testing, but I tend to disagree. The reason being that even in what you might call a base system or an "out of the box" portal, there can be variations. Different databases and customer repositories, hardware variations, network latency, lots of different things can contribute to performance issues. So often the numbers can become a bit fuzzy within each organization. In a previous blog I talked a little about this subject,
What about testing the infrastructure, and how you might get started with the testing process. Before we get too far into what steps you might take, I will try and dispel a few misunderstandings around performance tuning that often confuse new portal teams.
Usually targeting performance numbers begins at the sizing stage. IBM has a group called TechLine that offers assistance in sizing your system based on your expected user load and your application parameters. The drawback here is that you need to know in advance, the number of users and the rate at which they might access the system, and information about the design of your portlets that will be deployed to the system. Usually this is measured in terms of Low, Medium, and High complexity portlets. I've talked with TechLine folks about this and some of this is subjective. There are some guidelines that I will provide in a later entry. Your best bet to take advantage of TechLine is to work with your sales support team to get the questionnaire filled out and submitted to the TechLine team correctly.
I talked with a TechLine rep earlier this year to see if there was any feedback from portal projects where they had provided estimates. Unfortunately that data is not regularly collected but it would be interesting data. I would encourage anyone out there who has results to begin this feedback cycle with their sales reps, or even send comments directly to me. I will gladly feed this data back to technline to see if it can be used to help improve future estimates. Of particular interest is how your original sizing estimates were in comparison to what the application actually looks like live and how that might have affected your estimates.
OK, back on point, usually there becomes a point when one of several things happen. I'll try and look at each of these situations in turn and see if in my humble experience I can offer some thoughts on how you might approach each issue.
1. Performance is poor and you need to dig in and see where the bottleneck is occurring
2. Performance appears to be "good enough" and continued testing just confirms your results. Continued tuning can be done, but given time and cost constraints there might not be enough runway in your project plan to fine tune the system to the nth degree.
3. Performance is good, but you need it to be better before you turn the system loose on your real users. How much better often varies, but most of the time you are pretty close, but not what you were expecting.
With the first situation, where performance is just plain bad and you are not even close to the numbers you need to reach, there are several things you might try. First read my previous blog (mentioned above) for ideas on how to narrow down the problem areas, but sometimes you just have to dig in and look for the bottle neck. Thread dumps are really my favorite tool for seeing where activity is hanging up in the JVM. Thread Analyzer can be downloaded from the IBM site to connect with your portal and initiate a dump. There are otherwise to initiate a dump that you can learn by checking out the WAS InfoCenter.
Some people are afraid of thread dumps, and I agree they can be hard to read, but many times the problem can just jump out at you. If you see every thread seems to be waiting on the LDAP or a database connection for example, then it is a pretty good bet that you have an expensive query, or maybe some indexing could be done. Likewise, if the threads are waiting on a single object or service, then you might have a caching or syncronization problem with that service. Some issues are harder to read, maybe they are WAS related, and may require assistance from IBM support. Additionally, thread dumps are snapshots in time, so several such snapshots may need to be taken to see how activity is moving around in the system as the load progresses on your system.
OK, I'm going to stop here and continue this conversation in my next blog. Sometimes I get going and forget where to stop. : ) 'till next time.[Read More]
A few months ago I wrote an entry about development frameworks and things to consider when making a framework decision called
Development Requirements and Business Value.
This discussion has been an ongoing struggle with me as I continue to learn, and discuss with others their experiences with difference approaches and different frameworks. A lot of my previous experience is from leading development teams through projects on consultant engagements, so I am aware of the struggles that team members and development leads go through in making these decisions. I don't believe that a project manager or "hands off" architect can make an arbitrary decision to use a framework without understanding the massive impact it may have on team members. Many things must be taken into account, skill level, training, project requirements and the time line for a project delivery.
Before going to far, I'll mention a few of my colleagues Skyler Thomas, Brad Bouldin, Tim Hanis, Svetlana Petrova , and my manager Ken Polleck. All of whom have spent time recently discussing this topic with me ad nauseam, helping me define some of the thoughts below.
Most folks agree that in some cases the portal API can be a bit limiting, especially with the move toward JSR 168. Many developers who come from a Struts background want to continue with some of the features such as validation and page navigation that Struts made so easy to handle. JSF continues with that good stuff and adds more in terms of reusable interface components that can be used to quickly build up an interface and bind data to back-end methods. As more development teams become familiar with JSF they become enamored with the idea of making developers more productive by allowing them to use the tooling, specifically in Rational Application Developer to quickly build up portlets that can do all sorts of cool things.
The obvious thing to say is that JSF is great and everyone should move to this framework, however I'm always a bit cautious about new things that are supposed to revolutionize the way we do things. I am devoting and will continue to devote some of my time to ensuring that JSF is used in a correct manner and not just because it is a new great thing.
Don't get me wrong. It's pretty cool and I expect that more and more folks will grow into these frameworks as they evolve more with WebSphere Portal. With that, I've come up with two rules around using JSF that have to be kept in mind as you move forward with your project. Actually as Tim Hanis pointed out to me, these rules are not specific to portal or even JSF in many ways. They can apply to any framework.
Rule 1: JSF allows you to quickly build portlets within a framework and using the components. BUT, using JSF implies restrictions. Mostly that you use the components as they are designed.
If you need new functionality, then you have the option of changing the component to include the additional functionality, or letting a developer figure out a work around. Both of these require more expertise, skill, and time. Sometimes more then if you did not use JSF in the first place. (IMHO) This also requires that your advanced developers need more training and are working on these enhancements.
Rule 2: The Tooling for JSF is not intelligent enough to always build a well designed application. Using this tooling to build a portlet may result in problems within your production environment if the design is not evaluated by more experienced folks.
Corollary to Rule 2: Tooling can't help a poor design. For example if you store data that a component uses (like a list box) in the session instead of taking another design approach. Less experienced developers may not even know there are other design approaches.
My favorite example of this is when folks build a portlet that uses the web services client. Inexperienced folks will not worry about the fact that this portlet will access the service for every user. In some cases this may be OK, but in many cases it could overtax your portal and may lead to performance issues.
JSF is pretty still pretty new and so the jury is still out in the portal world as to how effective and worthwhile it has been. One of my favorite questions to development teams is, "how did using Struts (now JSF) improve your effort"? and "Do you think you could have been more productive without it, using a plain portlet API?". The results are often interesting.
I (and I'm sure others) would love to hear and learn from your comments about which framework you are using, why you choose it, and what the outcome has been?[Read More]
Recently someone asked me a question about using SSL with WebSphere Portal. The question was how to switch back and forth between HTTP and HTTPS for different parts of their portal. This is a pretty common question, and my answer has usually been the obvious one, that it is not possible. But really, that is not the whole story.
The portal is setup to be protocol, and actually can be configured to be domain agnostic. This means that whatever protocol, and/or domain, you use to make the portal request, that is what the portal will use to create all return and navigation URLs. The common scenario for many portals has been to use HTTP for the public pages and then do an HTTPS redirect during log-on to provide a secure submission of the user credentials. At this point the entire protected portion of the portal, the wps/myportal part, is accessed using HTTPS. The portal provides this redirect ability out of the box by allowing you to configure the log-on command with the ssl=true attribute.
The WebSphere Portal InfoCenter has a whole section on setting up SSL with WebSphere Portal, what commands and configuration changes are possible, and why this is important.
Sometimes for various reasons the requirement is to only use SSL for more limited sections of the portal. While this is possible, the main problem is that once you are using a specific protocol, your somewhat "trapped", and it is problematic to switch back to the original protocol. There is some speculation that by using mapped URLs and HTTP Server rewrite rules, you could come up with some techniques to switch back and forth. Adding some hard coded tabs into your navigation or maybe a judicious use of virtual portals could also enhance your possibilities.
A better option would be the ability to tag each URL within the portal to provide a link that is either secure, not secure, or follows the current security protocol. Unfortunately, this capability is not currently available within the portal.
There is hope on the horizon, * I think *, the JSR 168 specification provides an optional attribute (secSecure) for the PortalURL object that has just this ability. While it wouldn't handle every link in the portal, like navigational links, it would offer a more programmatic way for developers to provide this switching ability.
After playing with the setting for awhile and not getting it to work, I took another trip through the InfoCenter and found the following tidbit:
Portlet URL security
The setsecure() method of the PortletURL interface is not supported. The portlet URL will always be the same security level of the current request. Likewise, the secure attribute of the
While this is a bit frustrating, it does show there is some thinking in the right direction. The attributes seem to be available within the portlet API and tag libraries, so in time this capability should become a reality. Since this is currently optional within the spec, the portal is still very much in compliance with the specification.
For now, where there is a will, there is a way, and if the requirement is being forced on your portal, then budget for the extra design and development effort to make it a reality, perhaps using some of the techniques I mentioned above. If cost and speed to delivery is a driving factor for your portal, then plan on an all SSL or nothing approach for the near future. There are good arguments that using SSL within your entire portal is the more secure approach for all of your traffic.[Read More]
IBM has just announced a new partnership with Amazon Web Services to deliver IBM products via Cloud Computing. You can check out some of the details at http://www.ibm.com/ibm/cloud/. Included in this offer are WebSphere Portal and Lotus Web Content Management, as well as WebSphere sMash. I think this will be a big help for those who want to build new cloud applications, or for organizations who want to move applications into the cloud but need more private environments.
Additionally there is a new Cloud Computing Space at developerWorks Spaces.
You can also learn more from the developerWorks Cloud Product Page around Portal and WCM. Or Websphere sMash.
be sure to check it out![Read More]
I'm off tomorrow for the Lotus Collaboration and Portal Technical University in Sydney. It should be a lot of fun. I am giving part of the keynote address to kick off the conference, and then I will be running around doing some of the training over the next few days.
I have several labs and presentations that have been built around my new book; Application Architecture for WebSphere. As much as you can do in a couple of hours. I hope to be giving away some copies at the conference. They are not officially in the warehouse until the 18th, but I am waiting for a couple of advanced copies to show up at my door to take with me.
Hope to see everyone there![Read More]
I've been messing around with Drupal lately which I use on my personal site at Bernal.Net. We used this site to host the sample code from the 2nd edition of our programming portlets book. Mostly because we didn't know where else to put it. I have had lots of trouble with spammers on this site and have been working on ways to keep the site open, but not get a bunch of nasty links in all the comment fields. I think I have it figured out mostly so we'll see.
One thing I have been learning is how nice it is to plug in modules into Drupal. The procedure is pretty easy, extract and activate, and the module is ready to go. It is sometimes a bit of a challange to figure out the module after that, but hey, I'm not complaining. - OK, maybe a little. ; )
This got me thinking about plugability of portlets a little bit. I have been hearing a lot about using SpringMVC as portlets lately, especially with development on the Spring Portlet MVC option. On initial glance I am a little hesitant on this for many of our customers. Since people take me at my word when I recommend options, I would not want to lead them down a dark path, if there were issues with taking an unsupported approach. The general goal is to make the portal open to all types of portlets including things like Adobe Flex2 and SpringMVC. And I like to help guide customers in making their own decisions about frameworks, languages, etc., but from a consulting perspective I can only keep up with so many options, and if there are problems then support is going to have more trouble then if you were using JSF, the Portlet Factory, or even the plain old Java Portlet API (JSR 168). Just my 2 cents on this today, and even that is subject to change, as I know a lot of smart people are working on this approach. I think Spring fits a nice role in portal development as a local service layer, but it is also interesting what Spring is becoming. How a nice IoC framework is growing into an all encompassing giant is confusing.
What I really wanted to mention was that I setup a New Poll on my site, titled, "What language do you use to develop portlets?" I'm very interested hearing what folks use, so please if you get a few minutes go to the site and choose your poison. And I'm sure we are all curious what choices others have made for their development options. I've listed all the main options, but if your language is not there, then leave me a comment. I could add another option, like Spring Portlet MVC if we think it is necessary.
I hosted a call this week with the editors of The Sphere Journal and members of my team, IBM Software Services for Lotus (probably better known as Portal Lab Services). I sometimes think of The Sphere as this small underground journal, but it has quietly been building up a wealth of articles and content that cannot be ignored. Looking through the list of articles on line, I found at least a dozen that would be of interested to me in different aspects of projects I'm currently working on.
The key to The Sphere is that there are no advertisements. They make money off of the subscription costs, so it cost more then some of the other trade magazines. The upside is that it is all hardcore content, no fluff, no marketing! I actually don't have a subscription myself, but I get a copy every once in a while from different sources. Hopefully you can convince your company that a subscription is worth the added productivity. If not, it is probably worth buying it yourself. I'm actually thinking about buying a subscription myself and trying to deduct it from my taxes as a work related expense. I'm actually not sure if I can do that, so I'll have to check that out. Either way, in my line of work it's probably worth it to have another library of proven and complete solutions available to help solve customer problems.
The editors Celeste Frey and Lauren Bonneau are always actively seeking the best content for their subscribers. Looking at the payment structure for published articles, I can tell any potential authors that is it one of the best I have seen in the industry. If you have some WebSphere or WebSphere Portal expertise you might consider contacting them about an article idea.
Anyway, check it out and let me know if you subscribe, some of your favorite articles, and how you have benefited from some of the content?