What's New in WebSphere Portal V18.104.22.168?
— The first thing that you said to yourself when you saw the title of this article is, Why am I reading an article about a point release? A fixpack update point release usually provides just technical fixes. Who cares?
Surprise! IBM® WebSphere® Portal V22.214.171.124 provides new and updated capabilities, as well as the typical set of adjustments and fixes to some components of the product. It also contains some long anticipated enhancements that did not quite make it into WebSphere V5.1.
This section gives a high level comparison between the new JSR 168 Portlet API and the IBM Portlet API. First, it covers the concepts that are similar; then, it explains some of the differences between the two.
The following features are very similar in JSR 168 and the IBM Portlet API.
|Portlet modes||Both support the basic portlet modes: Edit, Help, and View.||The config mode is optional in the JSR 168. The other optional JSR 168 modes (About, Edit_defaults, Preview, Print) are not supported by the IBM Portlet API.|
|Window states||These window states are supported: Maximized, Normal, and Minimized.||The Solo window state is only supported by the IBM Portlet API.|
|Portlet lifecycle||The lifecycle life cycle is the same: init, process requests, destroy.||none|
|Request processing||Request processing is divided into an action phase for processing user actions and a render phase for producing the markup.||none|
|URL encoding||Both support creating URLs pointing to the portlet or to a resource.||none|
|Include servlets/JSPs||Servlets and JSPs can be included in the portlet.||none|
|Portlet session||Portlets can store transient information that should span requests in a session.||none|
|Portlet application packaging|| Both package portlet applications as WAR files with an additional deployment descriptor called || The |
|Expiration-based caching||The portlet can support expiration based caching.||The APIs use different mechanisms to implement this functionality. The IBM Portlet API uses a polling mechanism where the portal queries the portlet for how long the markup will be valid, whereas in the JSR 168 the portlet can attach an expiration time to each created markup. Sharing the cache entry across users is only possible in the IBM Portlet API.|
JSR 168 and the IBM Portlet API differ in the following ways.
| Feature|| IBM Portlet API|| JSR 168|
|Portlet application entities|| Lets you define an abstract|
portlet application and different instance of this portlet application as
concrete portlet applications via the deployment descriptor. This allows
reusing settings of the abstract portlet application and only overwriting
the parts that are unique for each concrete portlet application.
The deployment descriptor follows the web.xml deploymentdescriptor
|Portlet entity|| There is one portlet object instance per portlet|
configuration in the Web deployment descriptor. There may be many
to the Flyweight pattern, provided on a per-request basis. Changes in the
of this concrete portlet. The user can also have personal views of concrete
portlets that are rendered using the
for customization of the output.
into one object called
|Request/Response objects|| The request/response object|
that the portlet receives in the render call is the same as the one received
in the action call.
| In the JSR 168 these are two|
Exclusive to JSR 168
These items are only available in the JSR 168.
|Feature|| Description |
|Render parameters|| Render parameters|
allow the portlet to store its navigational state.
Render parameters stay the same for subsequent render requests and only
change when the portlet receives a new action. This enables bookmarkability
and solves the browser back button problem.
|Global HttpSession scope|| Portlets can store data not|
only with the visibility of the portlet, but also with the visibility of
the whole Web application.
|Redirect|| Portlets can redirect to other|
Web resources in the action phase.
Exclusive to the IBM Portlet API/p>
The following concepts are only available in the IBM Portlet API.
|Eventing||Events can be sent between portlets.|
|Additional lifecycle listeners|| Lifecycle listeners besides|
action and render, (such as begin page) are not available in the first version
of the JSR 168.
|Portlet menus|| Lets the portlet contribute|
content to a menu bar to facilitate navigation through portal pages.
|Invalidation based caching|| Lets the portlet explicitly|
invalidate cached content.
1. Comparing the JSR 168 Java Portlet Specification with the IBM Portlet API by
By default, portlets do not share the Portlet Session object. So, if a page has 4-5 portlets, each portlet will have its own portlet session object. This can lead to a lot of overhead when rendering the page. To avoid this problem, portlets with common functionality should be packaged in one WAR file. Further the portlets packaged in the same WAR, share the same Portlet Session object, hence saving on the memory requirements, all leading to faster rendering of the page.
- Architecting, designing, building and management of Enterprise Business applications using COTS (Commercial Off The Shelf) packages as well as Custom Application development
- Wide experience in Requirements Gathering and Analysis, System Design, Use Case Modeling, Defining functional/technical specifications and creating Architectural views for applications
- Expert in estimation methodologies ( Function Point, WBS, Use Case Analysis), project planning ( RUP, Agile methodology) and monitoring/mentoring development team
- Wide Technical Expertise on IBM Product Stack, J2EE/Java centric technologies, Open Source products and tools, Web2.0/Enterprise2.0 tools and Cloud technologies
- Proven expertise in Technical Architecture/Solution Definitions and Roadmaps, Vendor Evaluation, RFP responses, Client Presentations, Whitepapers and SOWs
- Researching new technologies that can drive business innovation, provided Technical Solutions with proof of concept/ prototype in umpteen situations in multiple technologies
- Helping business solve problems in innovative and cost effective ways
- Thought Leadership
This excerpt covers some of the architectural challenges posed by Web Services, examines how to use (and not to use) Web Services, and describes some best practices in applying Web Services for solving tough architectural problems.
I hold a Masters degree in Computer Applications from Thapar Institute of Eng & Tech, Patiala, India and ePGDBM from SIBM, Pune.
ABOUT THIS SITE
The information in this weblog is provided "AS IS" with no warranties, and confers no rights.
This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion.
I can be reached at write2munish (at) gmail dot com