Saturday, 22 October 2011

Similarities and Differences between Portlets and Servlets..

This post is about to understand the differences and similarities of portlet and servlet. 

The differences between the portlet and servlet are:
1. Servlets can provide the content to complete web pages, whereas portlets only provide fragments. And these fragments are then aggregated to form a complete web page by the portal.
2. The user cannot access a portlet directly using a URL in the way that a servlet is accessed. Instead, the URL points to the page containing all of the portlets on single page.
3. Portlets aren’t allowed to generated HTML code that contains tags such as base, body, frame, frameset, head, title or html . Note: Here the iframe tag can be used with caution.
4. The communication between the web client and the portlets is performed through the portal.
5. Portlet allows to manipulate the portlets’ window states or portlet modes by providing the buttons or controls.
6. Portlets support two scopes within the session; application scope and portlet scope but servlets not.

The similarities between the servlet and portlet:
1. Servlets and portlets are web based components that utilize Java for their implementation.
2. Portlets are managed by a portlet container similar to a servlet container.
3. Both of these components generate content, which can be static or dynamic.
4. Both portlets and servlets have a lifecycle that is controlled by the container.
5. The client/server model is used for both servlets and portlets.
6. The packaging and deployment are essentially the same.
7. The manner in which the classes are loaded and the class loaders that perform the work are also the same.
8. Lifecycle management is similar.
9. The Request and Response semantics are also similar.

There are several things that servlets are allowed to do, but portlets are not allowed. These are:
1. Portlet aren’t allowed to set the character set encoding of the response.
2. Portlet also aren’t allowed to set the HTTP headers on the response.
3. Portlet cannot manipulate the URL of the client request to the portal.

Enjoy:)

XMLAccess to deregister the web modules from WebSphere Portal Server.

This is an add-on of previous post 'How to deploy an EAR file on WebSphere Portal Server?' The same way we can write XMLAccess script to deregister the portlets/web modules (.war file) from WebSphere Portal Server. Following is a sample xml file for doing the same:

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
type="update" create-oids="true">
<portal action="locate">
<web-app action="delete" uid="<Pur here correct Web Module id>"/>
portal>
request>

Note: 1. you can add multiple tags to remove the web modules (.war files) from portal server. For each web  module it will be a separate tag. 

          2. Put ‘delete’ as a value of action attribute of tag.



Wednesday, 19 October 2011

How to deploy an EAR file on WebSphere Portal Server?

How to deploy an EAR file on WebSphere Portal Server?

The IBM WebSphere portal server does not allow deploying the EAR file directly in Portal Server. If you are planning to put all your web modules (war files) in an EAR file then you need to deploy the EAR file in WAS server and then later need to register your web modules/portlets to Portal server.

Following are the steps for doing the same using XMLaccess: 

Step1. Deploy your EAR on WAS server: Using Integrated Solutions Console you can deploy your ear.

For example here we have deployed a SamplePortalEAR.ear file in below screen:

 
Step2. Create XMLAccess script for portlet registration on Portal server:
Below is the sample XMLAccess script to register the web modules/portlets on Portal server: This XMLAccess script is created for SamplePortalEAR.ear file, which have two web modules (war files) that we need to register on portal server. 

xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.xsd"
type="update" create-oids="true">
<portal action="locate">
<web-app action="update" uid="com.ibm.faces.portlet.FacesPortlet.9c5fe31133.webmod" active="true" predeployed="true">
<url>file://C:\IBM\WebSphere\wp_profile\installedApps\hecha\SamplePortalEAR.ear\testPortlet1.warurl>
<context-root>.testPortletcontext-root>
<display-name>testPortletdisplay-name>
<portlet-app action="update" active="true" uid="com.ibm.faces.portlet.FacesPortlet.9c5fe31133">
<portlet action="update" active="true" name="testPortlet" uniquename="">
<access-control externalized="false" owner="all authenticated portal users" private="false">
<role actionset="User" update="set">
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set" />
role>
access-control>
portlet>
portlet-app>
web-app>
<web-app action="update" uid="com.ibm.faces.portlet.FacesPortlet.dc81041133.webmod" active="true" predeployed="true">
<url>file://C:\ibm\WebSphere\wp_profile\installedApps\hecha\SamplePortalEAR.ear\testPortlet2.warurl>
<context-root>.testPortlet2context-root>
<display-name>testPortlet2display-name>
<portlet-app action="update" active="true" uid="com.ibm.faces.portlet.FacesPortlet.dc81041133">
<portlet action="update" active="true" name="testPortlet2" uniquename="">
<access-control externalized="false" owner="all authenticated portal users" private="false">
<role actionset="User" update="set">
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set" />
role>
access-control>
portlet>
portlet-app>
web-app>
portal>
request>
 
Mandatory tags and their values:
  • The tag is about to web module (WAR file) in your EAR file. If we have more then one web module in our EAR file then for each module It will be a separate tag.
Note: The uid attribute of must be the correct web module id with.webmod
suffix.
  • The tag holds the installed location of your web module.
  • The tag should be the correct context path of your web module other wise script will not run successfully.
  • The tag has an uid attribute it holds the web module id.
Step3. Import XMLAccess: Once we are ready with our XMLAccess, now open Portal administration then goto left hand navigation and choose Import XML option under the Portal Settings.  
Import XML file: Provide the location of XML file by clicking the browse button then click Import button: Once it will import successfully it will show an success message just above the same screen. (Below is the screen shot)
 
Registered: Now following web modules of SamplePortalEAR.ear file has been registered on portal server:
 
Registered Portlets: Now the following portlets of registered web modules are available on portal:
  • testPortlet2
  • testPortlet

Enjoy :)