Article Preview
TopIntroduction
Attempting to define a portal these days can be a risky exercise for they have come a long way from what they were meant to be. But it would not be too incorrect to term portals as web sites that act as a one-stop or single point of access to a host of information, applications and services, with the scope being either the internet or the intranet. However, for the sake of this article, we would be examining and treating the portal as an application platform. One of the key components or building blocks of a portal is a portlet. Most of what we talk about portal is usually synonymous with portlet behavior. For example, several individual portlets together on a portal page help achieve the objective a portal is created for, hence the name building blocks for them. Like servlets, portlets process user requests to generate dynamic content like partial page markups. In fact, one can draw a lot of parallels between servlets and portlets. Just as servlets run inside a servlet container, portlets are managed by a portlet container. The basis of portlet containers are the portlet specifications. The portlet specifications have had a long and interesting history. Earliest portlets were programmed to proprietary specifications that forced and tied down portlets to specific portlet containers thereby killing inter-operability and openness. It was then that JSR168 or Java Portlet Specification V1.0 was standardized in 2003, co-led by IBM and Oracle. As a result, the popularity of portlets underwent a meteoric rise since multiple vendors could support the specification, leading to a quick and widespread acceptance.
In spite of being a major step forward, JSR168 lacked in a few features, the most prominent being coordination between portlets. This is when JSR286 or Java Portlet Specification V2.0 was standardized. It introduced key inter-communication capabilities for portlets like eventing, shared render parameters etc.
A key feature of a portal is application integration. There is a considerable scope for synergy between portal and applications based on popular Java EE frameworks. The swelling popularity and openness of portal and portlet standards is manifesting this collaboration in a number of portal applications getting coupled with Java EE applications. However, such applications based on different Java EE frameworks have their own dynamics and the way they inter-operate with other actors in the system. On the other hand, design principles on which portals work are also different from traditional application integration systems. As an application platform paradigm, a portal is a different ball game altogether with its own idiosyncrasies and considerations. For an increasingly large Java EE community coming in to the portal landscape, it means that portal application development needs some facilitation for achieving best output in terms of returns on investments for businesses. This is precisely where a portal tooling can play a role in bridging the gaps between the two landscapes. A well oiled and efficient tooling can not only make the developer’s job easier but also ensure smooth functioning of individual components and systems in the overall complex integrated application. As already mentioned, tooling is that cog that can keep both the actors together and maintain smooth inter-operability. It is best placed to solve all development challenges and act as a broker in bringing the two together for best possible combination by taking care of most key decisions and considerations.