The question of using a Portal framework or not pops up quite often. Some are trying to fit anything as a portal while some others are avoiding portals at all cost including the cost of building their own monolithic infrastructure.
JSR-168 definition of a portal
“A portal is a web based application that –commonly- provides personalization, single sign on, content aggregation from different sources and hosts the presentation layer of Information Systems.”
Aggregation
A Portal is mostly about aggregation of content, it may not sound as a difficult task. Everybody used any template mechanism that is after all an aggregation of content. But using that kind of naive aggregation you would have encounter several issues.
The aggregated applications have to be build with the same technology. A JSF Portal would aggregate only JSF applications, a Struts portal would aggregate only Struts applications, and so on...
Portals bring more modularity to your architecture because you can put together several applications designed with different technologies: buy a portlet (a web application) made with Struts, create your own made with JSF, get a Portlet using regular JSP and portlet API from your partner and you can have them all living in the same portal with the possibility to have them on the same page of course. Add WSRP into the mix, and you can also aggregate content produced by another portal vendor and/or on another server. In the enterprise world soon or later we have to deal with multiple technologies, and the cost of rewriting legacy applications to that they can fit with the newly developed components is way too expensive in many cases.
Also we need to tell you that managing visual state of several portlets on a portal page is not a trivial task and portals are designed to efficiently and correctly aggregate markup of several applications on the same page.
WSRP
Web Services for remote portlets are often used by big corporations to share responsibilities transparently to the end-user.
One office in Toronto is in charge of the human resources related portlets and have their own servers, another in Paris is in charge of accountancy portlets and client of a third party server located in Sydney that will provide stock and weather portlets on a portal platform from a different vendor.
The end user could transparently split his page with a portlet coming from Toronto, another from Paris and two from Sydney, if the Sydney's server is out of order he would still have access to the other two portlets and will be happy to be able to ask for more vacation though the human resources portlet even though he would have to check another website to see the weather forecast for his vacation destination.
Benefit from an improving portal
While you can focus on the business part of your application, the portal framework you are working on will evolve. I don't see any portal vendor willing to stop supporting the JSR-168 and the coming JSR -286 as they evolve.
If you stick with the specification (it can be hard since the JSR-168 is lacking of some key features like the infamous inter-portlet communication) not only you will be able to change of portal vendor but even when sticking with one vendor, you would benefit from the new features of the portal. As an example, while one is building a portlet to provide his business, the JBoss portal team worked on drag and drop windows and partial refresh for windows.
Separation of responsibility
While a team works on designing portlets, another team can work on the portal itself, customizing a portal framework for their own needs.
The first team will work on the business portlet, make sure to implement all the actions and rendering methods for specific portlets.
The second team will make sure that the portal integrates well with their identity manager, that the page navigation is designed the way they require, that portlets/pages/portals can be secured the way they want.
JSR-168 also defines CSS styles to use, so a third team can also work on the graphic design independently.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment