Portlets have been around for a few years now and after JSR 168 have matured as a technology.Easy plugability, interoperability (of Portlets) with various Portal Servers (post JSR 168) and the rich user interfaces possible in Portlets have made them a popular choice in the J2EE development world. The main purpose of this post is to briefly explain the difference between a Portlet and a Servlet (technically and functionally).
Portlet as a technology borrows heavily from the traditional Servlet model. While both, Portlets and Servlets are Java components that have to be hosted within a Java container (JVM), there are some essential differences.
Portlets as compared to Serlvets are relatively specialised components. They give the developer a chance to focus on capturing some essential function without worrying about the 'other' things that go with making the function available to the real world. Further, unlike Servlets, Portlets cannot be invoked via a URL. This is hardly a limitation as they aren't meant to be invoked in such a manner. Portlets are realized and invoked via Portals. Thus browsers (web-clients) communicate with Portlets via Portals.
A Portal defined in layman terms is a 'web-site' but in essence it is a collection of Portlets. It includes a theme other user interface features that define the look and feel of the Portal. Cameron McKenzie explains it well when he says that Portals build upon existing J2EE functionality and simply management of several diverse applications. Content management is a good example of simplified Portal functionality that is considerably simplified. I experienced this first hand when I installed and ran JBOSS Portal Server 2.6.5.
While Servlets are hosted by an Application Server (such as JBOSS application server, Bea's Weblogic), Portlets require Portal servers. Examples of popular Portal servers are JBOSS Portal Server 2.6.5 and IBM's Portal Server 6.1. Portal servers are super sets of Application servers in the sense that they extend their capabilities and provide specialised functions which make single-sign on, customisable security, one-look applications and rich user interfaces possible in Portlets.
To summarise Portlets are specialised Java components.They can be persisted, configured, manipulated via the addition of buttons and while they aren't allowed to generate general HTML code, the iFrame tag can be used with caution. Nifty??? eh??
Portlet as a technology borrows heavily from the traditional Servlet model. While both, Portlets and Servlets are Java components that have to be hosted within a Java container (JVM), there are some essential differences.
Portlets as compared to Serlvets are relatively specialised components. They give the developer a chance to focus on capturing some essential function without worrying about the 'other' things that go with making the function available to the real world. Further, unlike Servlets, Portlets cannot be invoked via a URL. This is hardly a limitation as they aren't meant to be invoked in such a manner. Portlets are realized and invoked via Portals. Thus browsers (web-clients) communicate with Portlets via Portals.
A Portal defined in layman terms is a 'web-site' but in essence it is a collection of Portlets. It includes a theme other user interface features that define the look and feel of the Portal. Cameron McKenzie explains it well when he says that Portals build upon existing J2EE functionality and simply management of several diverse applications. Content management is a good example of simplified Portal functionality that is considerably simplified. I experienced this first hand when I installed and ran JBOSS Portal Server 2.6.5.
While Servlets are hosted by an Application Server (such as JBOSS application server, Bea's Weblogic), Portlets require Portal servers. Examples of popular Portal servers are JBOSS Portal Server 2.6.5 and IBM's Portal Server 6.1. Portal servers are super sets of Application servers in the sense that they extend their capabilities and provide specialised functions which make single-sign on, customisable security, one-look applications and rich user interfaces possible in Portlets.
To summarise Portlets are specialised Java components.They can be persisted, configured, manipulated via the addition of buttons and while they aren't allowed to generate general HTML code, the iFrame tag can be used with caution. Nifty??? eh??
No comments:
Post a Comment