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
- Portlet Services provide a clear service layer within the portal that is fully defined and accessible by all your portlets though the use of a JNDI look-up. The InfoCenter specifically states that portlet services are only available to portlets, however in the past I have accessed a portlet service from themes also. Since you find a service using JNDI I am not sure why this would not still be the case, but it is possible that something might have changed in the most recent implementation.
- This approach is self documenting, i.e., it is all there in the Portal InfoCenter so you can save time in getting a standard in place, BEFORE you start your project.
- Owners of back-end data sources can easily provide services within their organization and ensure that portlet developers access data in a manner that they can control.
- Deployment becomes a no-brainer, so your operations folks will love you (or at least not hate you). : ) Trust me when I say that trying to deploy a portal where no standards are in place can quickly become a very big problem.
- The service framwork is supported if you have problems, where a custom approach would not be.
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!