Relation between WebSphere Portal Server and WebSphere Application Server?

Both WebSphere Portal Server and WebSphere Application Server are commonly used terms in Portal world. Following are some of key points that helps you understand the difference between the two commonly used terms.

 WebSphere Portal Server 

• It is nothing but an preloaded enterprise application (wps.ear) in integrated WAS.
• This application is dependent on database for storing application related information.
• It provides the all the features of portal i.e. personalization, customization, security etc.
• It's configuration and other personalization data is stored in form of database, XML and property files.
• It supports authorization of users.
• Performance measurement about pages / portlets is not measured in WebSphere Portal server.
• It only supports deployment of .war files.
• Only portlet applications can be deployed on WebSphere Portal server.

WAS(WebSphere Application Server) 

• It provides platform for WebSphere Portal Server.
• It doesn't depends on any database.
• Personalization is limited to each application deployed on the server.
• Configuration and related data is stored in form of XML and property files.
• Portal authentication is done in WAS.
• Performance measurement about pages / portlets can be measured in WAS.
• It supports deployment of both types of files (.war and .ear).
• One can develop either basic / advanced J2EE applications or using portlet container in WAS, one  can also develop and deploy portlet applications.

Why do we need Portal server ?

Below are some of the key points that helps you understand why do we need portal server and why it is more preferable option over other technologies.

• Portal handles the presentation layer.
• Its cheaper than coding all this ourselves and has faster time to market.
• It allows the business to develop and deploy their own content.
• Portal handles security, it allows us to control what people see based on role and/or custom attributes.
• It separates content from applications.
• Can reuse code, a portlet can be dropped into any page.
• Can present to a number of different device types.
• It fits in with an SOA world.
• Ability to use 3rd party Portlets (e.g, People-soft). 

What does Portal Sever give us ?

• Ability to target content and applications, based on attributes or roles.
• Integrates with security components (i.e. WMM for users and groups).
• Common Themes/Skins.
• Adheres to JSR168 / JSR286 Portlet standards.
• Provides Web 2.0 functionality (AJAX, JSON, REST, etc).
• WSRP 2.0 (Web Services Remote Portlets).
• Search – can integrate with other search engines / seed lists (e.g., Google Appliances). 

What's new in WebSphere Portal V8 ?

WebSphere Portal 8 was released by IBM some time back. Below are some of the useful links for those who have just started working on WebSphere Portal 8.

Click Here to view the complete list of features that are introduced as part of WebSphere Portal 8.

Click Here for complete list of features comparison of different versions of WebSphere Portal.

Perfected Steps to Installing IBM WebSphere Portal v8

How to implement friendly URLs in IBM WebSphere Portal 8-based WCM rendering

This article showcases the new feature in version 8 of IBM WebSphere Portal / IBM Web Content Manager (WCM) with which you can implement a clean-navigation, stateless URL in Portal-based WCM delivery. Also referred to as friendly URLs or human readable URLs.

What is not changed from JSR 168 to JSR 286 portlet specification?

Although JSR 286 specification provides some advanced features to the portal developers but there are some key features of JSR 168 that still remains the same in new API.

• Portlet Modes
• Window States
• Portlet Preferences
• Portlet Security
• User Information 

What are the Key features of JSR 286 portlet specification?

JSR 286 comes with lots of new features that were missing in JSR168 API and badly required by portal developers. Few of them are

• Resource serving- provides the ability for a portlet to serve a resource.
• Events – enabling a portlet to send and receive events and perform state changes or send further events as a result of processing an event. 
• Public render parameters – allowing portlets to share parameters with other portlets.
• Portlet filters
• Invoking a Portlet directly (but still through the Portal) 
• PORTLET_SCOPED session for Servlets.
• Java 5 annotation support in GenericPortlet.
• Access to the Portlet Window ID.
• PortletURL generation callback listeners.
• “private” PortletModes and setting nextPossiblePortletModes.
• Action scoped request attributes (still under FINAL work).

API:
MimeResponse.createResourceURL()
ResourceServingPortlet.serveResource(ResourceRequest, ResourceResponse)

• Extends the render phase, NOT a new life-cycle phase
• POST, PUT, DELETE supported
• Should not change shared portlet state
• Additional URL parameters are specific for the request
• Full control over request and response headers
• Can be used for binary data or “readonly” AJAX (cannot change navigational state)

Extended Cache

Allow public cached content for multiple users

<portlet>
..
<expirationcache>
<expirationtime>300</expirationtime>
<scope>public</scope>
</expirationcache>
</portlet>

Support validation based caching using ETag API:

response.getCacheControl()
.getExpirationTime(), .setExpirationTime().isPublicScope(), .setPublicScope(boolean)
.getETag(), .setETag(String).useCachedContent(), .setUseCachedContent(boolean)

Better Web Platform support

• Allow servlet dispatching, including using forwards, from:
• processAction
• processEvent
• render
• serveResource
• Optionally providing a PORTLET_SCOPEd session to Servlets
• Extended JSP tag library using new taglib uri "http://java.sun.com/portlet_2_0"
• Bridging and native integration underway for JSF (JSR-301) and Apache Wicket (1.3+)

Portlet Coordination – Portlet Events

• Events must be defined in portlet.xml
• After event definition, each portlet must declare what events it will publish or receive
• Portal-defined events do not have to be defined in portlet.xml
• Event naming:
• Must use the W3C Q Name standard.
• Receiving events can end with a * wildcard
• Can declare default-event-namespace in portlet.xml and just use local names
• A portlet declares the events it wants to receive or send in portlet.xml using Qnames or by using a default namespace:

<defaultnamespace>
http://acme.com/events</defaultnamespace>
<eventdefinition>
<name>foo</name>
<javaclass> java.lang.String</javaclass>
</eventdefinition>
<portlet>
<portletname>PortletA</portletname>
...
<supportedprocessingevent>
<qname xmlns:x=”http://acme.com/events”>x:foo</qname>
</supportedprocessingevent>
<supportedpublishingevent>
<name>foo</name>
</supportedpublishingevent>
</portlet>

Sending non-declared events at run time is allowed too

• Allows wiring of portlets at runtime
• The portal / portlet container will act as broker
• The portal or portlet container can also send events
• Formally not 100% reliable, i.e. no guarantee of delivery (mainly for WSRP, “local” portals are less limited)
• New 3rd life cycle phase: before rendering

API:

EventPortlet.processEvent(EventRequest req, EventResponse res)
StateAwareResponse.setEvent(QName name, Serializable value)
StateAwareResponse.setEvent(String name, Serializable value)

Portlet Filters

• Modeled after Servlet Filters
• Modify request data by wrapping request
• Modify response data by wrapping response
• Intercept invocation of a portlet before and after it is called
• Filters may be chained
• Defined in portlet.xml

<filter>
<filter-name>Event Filter</filter-name>
<filter-class>com.acme.EventFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Event Filter</filter-name>
<portlet-name>SamplePortlet</portlet-name>
<lifecycle>EVENT</lifecycle>
</filter-mapping>

• Must implement javax.portlet.Filter interface
• Must provide a public no-arg constructor
• init() method will be called on all Filters before being called on any Portlets
• destroy() will be called if Filter is removed from service
• doFilter() method called if processAction(), processEvent(), render(), or serveResource() would be called on Filtered Portlet 

Difference between Friendly URL’s and URL mappings

In this article, I am going to talk about friendly URLs, URL mappings and difference between them.

Friendly URLs

Friendly URLs are human readable URL prefixes generated based on the content node hierarchy. The URL prefix for content sub node will contain the prefix assigned to the super and all other nodes above it. Friendly URLs are added to a page through page properties in Admin UI or we can add them through XML access too.



By default, Friendly URLs are disabled in websphere portal, to enable them

1. Open WAS admin console.
2. Navigate to Resources -> Resource environment -> Resource environment providers.
3. Search WP_ConfigService and click custom properties.
4. Click “NEW” and add “friendly.enabled” in name and “true ” for the value.
5. If it already exists change “friendly.enabled” to true

The URL assigned is stored in the page level metadata as com.ibm.portal.friendly.name.

URL Mappings

URL mappings are used to define the human readable URL prefixes to the content in the portal which will serve as entry points onto the portal. However, these URL mappings will not be preserved upon navigating to other content node. We can define URL mappings through Admin UI and XML access. Portal does not provide any API to construct URL mappings programatically. URL mappings are preferred when we need a URL to link up between two different portals. This will allow us to maintain a constant URL even with change in content node.



Few Important Points

1. We need to maintain URL mappings for each entry point and they will not be valid for the next navigation state.
2. We need to define friendly URLs for all the pages or nodes in the hierarchy before assigning it to sub pages. It cannot resolve a friendly URL unless and until all pages are properly defined with respective URLs.
3. For friendly URLs, URl assigned is stored in page level metadata as com.ibm.portal.friendly.name.

What is the best way to deploy portlets within Portal environment?

This article lists down different ways of deploying portlets within Portal environment listing advantages and disadvantages of each.

Portlet Deployment

One Portlet per war

In this approach, each portlet is bundled as one war file.

Advantages:

• Abstraction to the lowest level
• Independent development and testing of portlets
• Change to single portlet will not impact other portlets within portal

Disadvantages:

• Messy deployment as the number of portlets grow
• Sharing of portlet session is an issue

All portlets in a single War file

In this approach, we pack all the portlets in one war file.

Advantages:

• Clean deployment, easy to manage
• Easy to share portlet session

Disadvantages:

• Parallel development is a challenge
• The size of the deploying war becomes extremely large and takes a long time to deploy
• Single change in one portlet will cause a redeploy of all portlets, adding re-testing overheads and making portal unavailable

Grouping portlets in one war

This approach refer to portlets grouped together based on function/ same functionality into single WAR files. 

Advantages:

• Small changes to a functionality will not affect the overall portal
• Clean and easy to manage
• Portlets which need to share session will be grouped into one
• Parallel development at functionality level is possible

Disadvantages: 

• Maintenance at individual Portlet level might affect other packaged portlet of the application

Shared library management in ext of Portal server

Shared library in ext of Portlets

Shared Libraries

Apart from portlet applications, there are certain shared libraries used by most of the portlet applications (WAR's). This lead to challenge of how to deploy these shared applications. Here are few options:

Single Portlet application and shared libraries packed into one EAR 
This approach suggests having single portlet application, along with shared libraries and resource files, packed as one EAR file.

Advantages:

• Each EAR will be truly independent
• Common functionality could be extended based on the need of the portlet application
• Changes to shared libraries will not impact all the other independent EAR's

Disadvantages: 

• Each EAR would be large and will take longer deployment time
• Each individual EAR would contain copy of the framework classes and maintainability of different versions of framework classes in different columns will be a challenge
• More complex deployment process
• Changes to shared libraries will require redeployment of all the EARs
• Complex deployment
• Class loading strategy of the application server would have to be restricted to PARENT LAST

Multiple Portlet applications and shared libraries packed into one EAR file 

This approach suggests that multiple portlet applications along with shared libraries and resources files, such as properties, packed into one single EAR.

Advantages:

• All portlet applications share same common libraries

Disadvantages:

• Big size and will take a long time for deployment
• Change to single portlet application will require redeployment of whole EAR and thus unavailability of the application
• Complex deployment

Shared library in ext of Portal server

This approach suggests that the shared library to be placed within the ext library directory of the portal server. This approach is suggested when there is are framework libraries which need to be shared across the organization (Organization level frameworks for logging/exception handling etc.) and each application hosted in the environment should follow those standards.

Advantages:

• One of the most common way of sharing the files among the multiple applications
• In portal world, all the common files pertaining to theme, portlets and third party application are stored in shared library
• No need to use Dyna Cache or JSR 286 events to  save and share values across portlets
• Library would be available across applications
• Individual applications would be lighter since they won’t contain the code for framework classes

Disadvantages:

• Change management for the shared libraries would be very risky

Steps for Creating a Shared library on Portal Server

• Logon to Websphere Application server console
• Navigate to Environment -> Shared Libraries
• Click apply and save it

Assigning to a server 

• Go to servers -> Application servers -> websphere portal -> Java and Process management -> classloader.
• Click Shared library references
• Add the library that you want to share
• Save the configuration and restart the Portal server.

Note: Restart of server is mandatory for the class loader to load all the newly added class files. Now, you can add the shared jars to build path for proper compilation and deployment.