Accessibility is the practice of ensuring that people with disabilities have meaningful access to the information and function provided by computer and information technology. An accessible portal page is one that meets accessibility guidelines, including:

* Lets users navigate by using only the keyboard
* Lets users select font sizes, colors and color contrast combinations
* Supports assistive technologies, such as screen readers and closed captioning

Incorporating accessibility for people with disabilities into portlet development need not be difficult or costly. This article will get you started.

"Eclipse Review" has been launched. All the fans out there, who think that Eclipse is the best thing that ever happened to Java IDE, then do check out the magazine at
www.eclipsereview.com

Portal Search has undergone significant changes in the WPS V5.1

Search Portlets
There is a new Portal Search Box and Search Center portlets that presents a search box on every portal page. When the users enter a search string and click Search, the portal takes them to the new Search Center portlet and applies the search criteria and shows them the search results.

Catalog
Another, new development is the Portal Search can be assigned to external/internal web sites. Portal Search allows crawling and indexing portal pages. The crawler can fetch and index all pages with portlets to which it has access rights. This way you can enable users to search those pages. You can define which portlets on which pages you want to make searchable. You can do this by granting the required access permissions to the crawler user.

Security
Another feature is limiting the search results based on the user privileges. Each individual search collection is now a separate portal resource. You can give users access permissions on them and thereby make different search sources available to different users or user groups. This applies to all search collections. For example, in the Search Center users see only the tabs for those search collections to which they have access.


Some of the drawbacks, I encoutered is the lack of availability of search features for anonymous users. Also, settings up the search with results in mulitple languages is very tedious. The whole crawlong and cataloging of the pages and documents takes too long.

Filed in: WPS

The logout can be initiated by a URI that is explicitly selected when the user clicks on the logout button (which has been added by the aggregation engine to every page banner). Alternatively, the logout can be initiated implicitly through a session timeout that occurs after a specified time of inactivity.

The portal logout performs the following actions:

1. Suspend User Session. The user’s portal session (the portal’s navigational state) is persisted. The HTTP session is invalidated.

2. Portlet user logout. The portlets are notified of the event user logged out to give them the opportunity to finalize (trans-)actions that need to be terminated.

The following steps are performed only when the logout is initiated by an explicit user action. They are not performed when the logout is a consequence of a timeout.

3. WebSphere Application Server logout. The user’s credential token is marked as invalid, and a respective cookie invalidation command is added to the response.

4. Browser redirect (302). The browser is redirected to render the post-logout target.

HTTP Basic Authentication has the following known disadvantage. The browser caches the user ID and password and sends them with every request to the same target. Because there is no standardized mechanism through which the browser is notified of a user-initiated logout, the browser continues to implicitly log in the user, as soon as the same target is accessed again.

In the case of an authentication proxy, WebSphere Portal needs to be set up to redirect after logout to the authentication proxy’s logout page. This way the authentication proxy is also notified of the logout. If a user does not logout explicitly, the proxy cannot be notified of the portal session timeout and the proxy session will time out eventually as well.

Filed in: WPS

WebSphere Portal lets you customize the portal login and logout procedures at various places. The following modifications are possible:

* Specifying the post-login and the post-logout redirection policy and targets.

* Adding custom JAAS login modules that are used to authenticate a user and/or populate the portals user JAAS Subject with principals or credentials.

* Securing the login interactions and/or the personalized portal pages using SSL.

* Extending the portal login and logout action classes.

Filed in: WPS

Dynamic UI management deals with a special use case of the dynamic addition and removal of dynamic pages and portlets (called dynamic user interfaces or dynamic UI) based on user interactions. The layout of a dynamic page is defined by a page definition, which is a static portal page acting as the master copy. Because of their dynamic nature, pages and portlets are not persisted in the portal database, and have a maximum lifetime of the user's session with the portal. They can also be closed prior to the end of the session, either programmatically or by the user.

You can use dynamic UI management to:

* Increase usability by keeping the number of pages in a portal, and number of portlets on a page, to a minimum.
Based on user interaction, you can pages and portlets to be displayed at the moment they are required, and removed when they become obsolete.

* Facilitate reuse of components.
Single pages and portlets can be parameterized with the current application context so that they seamlessly integrate with the calling application.

* Support multi-page applications.
An application can use multiple pages; for example, to implement a wizard dialog.

Closely related to dynamic UI management is the concept of page and portlet context passing. You can use this mechanism to dynamically launch pages or portlet that are parameterized with the current application context; therefore, a seamless integration with the portlet that created the dynamic UI can be achieved. The dynamic portlets will receive this dynamic UI context through property broker events when the dynamic page is launched. The dynamic UI programming model is closely aligned with the property broker model.

More details about the Dynamic UI model can be found in the infocenter.

When programming for WebSphere Portal V5.1.X, and programmers coming from the traditional Web application world face the challenge: how to create Uniform Resource Locators (URLs). The portal environment poses special requirements on components that need to create URLs; therefore, URL generation in the portal environment is a bit more involved. The article delves into how portal components can generate URLs using WebSphere Portal Version 5.1.0.1 System Programming Interfaces (SPIs) that go beyond what the portal JSP tags. Finally, you see how to use these SPIs in an example which implements a navigation breadcrumb trail.

Filed in: WPS

There are several use cases when a portlet needs to obtain the object ID used to uniquely identify a portlet or a page. For example, the object ID of a page definition is required for a portlet to launch a dynamic instance of that page. You can use the lookup() method of the JNDI Context class to obtain the object ID for a portlet or a page, passing the unique name of the page or portlet. As an alternative for portlets, you can obtain the object ID by using JNDI lookup() and passing a combination of the portlet application ID and the portlet name.
• For JSR 168 compliant portlets, the portlet application ID is the value of the ID attribute of the element in the portlet.xml. However, this attribute is not required by the Java Portlet Specification. If the ID attribute is not set, the portlet WAR file name is used as the portlet application ID.
• For IBM portlets, the portlet application ID is the UID attribute of the element. This attribute is required.
The following example shows both ways to find an object ID.
************************************************************
// initialization
Context ctx = new InitialContext();

// portal:uniquename prefix is required for unique name lookup
Name uniqueName = new CompositeName("portal:uniquename");

// portal:config/ prefix required for portlet definition lookup
Name portletName = new CompositeName("portal:config/portletdefinition");

// the unique name assigned to the page is example.org.page
uniqueName.add(org.example.page);

ObjectID oidForName = (ObjectID) ctx.lookup(uniqueName);

// appID and portletName have already been set programmatically
portletName.add(appID);
portletName.add(portletName);

ObjectID portletDefOID = (ObjectID) ctx.lookup(portletName);
************************************************************
The Name used for the lookup() method is created from a CompositeName, which is prepopulated with the required portal prefixes enclosed in quotes. This technique is used to avoid having to escape special characters in the prefix.

To create more complex portlet applications, using frameworks can save a lot of development effort and assure that these portlet applications are well-designed and maintainable. WebSphere Portal supports three different frameworks: Struts, Java Server Faces, and the JSF Widget Library.

Struts

Struts is one of the oldest Web development frameworks, and it has a very large developer community and very good tools support. Struts is an open source project at Apache [Struts] and was created to provide servlet and JSP programmers with a multi-page, Model-View-Controller (MVC) framework. Because Struts was developed for servlets, it does not work out-of-the-box with portlets; portlets have the MVC patterns strictly built into the interface, with an action and a render phase. In addition, the portlet and servlet request/response are different and must be adapted. WebSphere Portal provides a special version of the Struts V1.1 library that was modified to support JSR 168 portlets on WebSphere Portal.

Java Server Faces (JSF)

Java Server Faces is a UI framework for Java Web applications which was standardized through the Java Community Process. Because it is quite new, it took portlets into account and can work with portlets and servlets out-of-the-box. In addition to the UI components, JSF also provides infrastructure support for state handling, validation, and event processing for these components. It is a very powerful and flexible framework that works well with portlets.

WebSphere Portal supports JSF by including the JSF library so that themes and skins can utilize this UI framework. Rational Application Developer provides tooling support. You can create JSF-based portlets using a wizard, and you can use additional JSF UI widgets that portlets might use.

JSF Widget Library (JWL)

JWL is provided by Rational Application Developer and enables portal and portlet programmers to use an additional widgets based on JSF. A noteworthy feature of this library is that these widgets have client capabilities. The widgets can perform processing on the client in order to update their views, which saves round trips to the server, dramatically improving the user experience because the response time is shortened by orders of magnitude. You can deploy WebSphere Portal portlets which use these widgets just like any other portlets.

Filed in: WPS

Last time, I talked about the Release process for WPS using XMLAccess as the tool, here. Now, I going for more details on the XMLAccess to help gain an indepth understanding of the tool.

Why use XMLAccess
The major benefit of XMLAccess is its ability to update pages and portlets without losing user customization. If you perform your updates via XMLAccess, any user customization to a page or a portlet is retained because the object IDs are retained.

For example, the organization may have deployed a stock portlet that the user can customize to monitor certain stocks by adding just those stocks to the portlet. If you update this portlet, you do not want the user customization to be lost. The XMLAccess tool allows you to maintain the user’s customization. When exporting and importing via the XMLAccess tool, the object IDs of the portlet application are maintained. When a user customizes a portlet or a page, these customizations are stored in your back-end database. All these customizations are stored relative to the actual portlet application. The key that ties all of these customized versions of a portlet or page back to its parent is the object ID.

How XMLAccess works
The XMLAccess command line client is a small separate program that connects to the server using an HTTP connection, which allows you to configure the Portal remotely. The XMLAccess command is located in the wp root/bin directory of the Portal server and is xmlaccess.bat (on Windows) or xmlaccess.sh.

The syntax for the command is as follows:

xmlaccess -user wpsadmin -pwd itso -in file.xml -out result.xml -url myhost:9082/wps/config

In the command line, use the following file names:

* file.xml: The name of a file containing the XML request (configuration export or update) that should be processed.

* result.xml: The name of the result file containing the XML output (configuration export). You can later use that file to re-import the exported configuration.

* url: The URL to access the Portal configuration servlet. This URL consists of the Portal host name, the base Uniform Resource Identifier for the Portal, as specified during installation (for example /wps), and the servlet extension /config.

You can use the XMLAccess tool to transfer a complete configuration, including:
* Portlets
* Access Control List
* Portal Web application configurations (portlet applications)
* Portal skin definitions
* Portal theme definitions
* Portal portlet configurations
* Portal site map (pages, labels, and links)
* Portal URL mappings

With the XMLAccess tool, you can also:
* Load the WebSphere Portal default portlets configuration during the initial install and transfer parts of Portal configuration.
* Create and modify existing Portal artifacts incremental releases.
* Delete Portal artifacts. However, you must manually add delete commands to the input file. Keep in mind, although the XMLAccess tool is a bulk transfer utility, the command does not know history. It only knows the Portal configuration at specific point in time.

Filed in: WPS

Although there is no automated method to move Portal applications from one environment to another, there are two options:

* Completely replace the old release with a new release. The drawbacks of this option is that any data that was customized by the user is lost. While this option works, it is not the recommended way.

* Use the XMLAccess tool to load incremental or differential release

The XML configuration interface

The XML configuration interface is more commonly referred to as the XMLAccess tool, because xmlaccess is the command that is executed. The tool provides a batch processing interface for Portal configuration updates and allows you to export an entire Portal configuration or parts of a configuration. For example, you can process and export specific pages to an XML file. You can then re-create the exported configuration from a file on another Portal.

While XMLAccess is as simplified bulk transfer utility, there is no magic button that automatically moves all the components of your Portal to the next environment. The XMLAccess tool is best for the initial loading of Portal application and for doing incremental releases. However, it is increasingly being used as a command line Portal administration tool.

I will talk more about XMLAccess next time.

Filed in: WPS

Last time, I blogged about when not to use portals. This time, I am blogging about when portlets make sense. So,now if your goal is to bring together your Web applications and information into one convenient place, portlets are the obvious choice. If your development goals are somewhat different, consider these other portlet and portal server features that you might want to take advantage of:

* Portlets can be extended to work on many client devices. The users can move from computer to computer, and mobile device to mobile device, and still use the infomation and applications they need.

* Portlets allow you to easily customize their content for different user groups, and individual users can rearrange and tailor them to their needs.

* One can make the portlets have a unified look, and change their appearance quickly, using Cascading Style Sheets along with themes and skins that the portal server provides. You can create your own themes and skins as well, to better reflect your company's image and style.

* Portlets can be published as Web services, so that companies outside of your portal server's environment can easily write programs to use them.

* The IBM WPS provides excellent support for internationalization, beyond what the Web Application server provides. It is straightforward to develop portlets that will display correctly for international users, even in double-byte or bidirectional languages like Chinese and Arabic.

* Portlets help divide complex applications into tasks: in general, one group of closely related tasks equals one portlet. WPS's administration portlets are a good example: like the administration tasks can be broken down into categories (Portlets, Portal Settings, etc.), groups of related tasks (Manage Users, Manage User Groups), and single tasks (Search for users, Create new user).

* Portlets make it easy to add features to your applications later. If the new feature is large, one can create a new portlet. For small updates, you can update the existing portlets without losing users' individual preferences.

* Portlets, like other Web applications, play well with firewalls. They use standard Web protocols to receive and display information.

* You only need to install and configure portlets once for all of your users, which is much easier than working with stand-alone applications on each computer. This logic applies to the other Web applications as well.

* The portal server works with the Web application server to provide security, installation support, reliability, and availability for many users, so you don't need to spend a large part of your development effort working on these features.

* Once you do invest in a portal server, you may find its advanced features useful: content management, transcoding, voice support, and offline browsing, among others, useful for integrating into your application

Filed in: WPS

Portlets are not the solution to every design challenge. Here are a few things that portlets do not do well:

* Complex user interfaces do not translate well to portlets. The markup languages like HTML and WML simply cannot describe some interfaces. Try to imagine implementing an integrated development environment (IDE) like Eclipse or Visual Basic in HTML and you'll have the idea. Native applications and Java applications work better for this. (If you have a complex user interface and still want to take advantage of the benefits of portlets, WebSphere Portal does support Struts, which can be very helpful.)

* User interfaces with data that must be constantly updated are also not portlet material. When you update one portlet, all portlets on the entire page must be re-drawn, so it is generally not a good practice to have your portlets automatically reload themselves with new data. On the other hand, you can have "refresh" option in the portlet so your users can choose when to reload the page. You cannot be sure how often users will choose to refresh the page, so if your data must not be out-of-date, use a native application or a Java application instead of a Web application.

* Highly interactive user interfaces do not translate well to Web applications in general, or portlets in particular. If you want your interface to change automatically when a user takes some action, like selecting an entry in a drop-down list, you can either submit the form and reload the entire page (annoying), or use a scripting language to re-draw the portlet (very difficult). If you use a scripting language, you will need to make sure it works for all of the devices you want to support, and you will also need to make sure your portlet still works if scripts are disabled by some of your users. For mobile devices, you will probably need to have alternate JSP pages that do not use scripts. Native applications or Java applications are easier to make highly interactive than are Web applications.

* Portlets need to live "within their box." Be careful if you have a link in a portlet that takes you to a Web page outside of the portal server environment, because it is difficult to get back to the portal after that. Frames are not allowed (Internal frames are allowed, but only Microsoft Internet Explorer users can see them). Pop-up windows and scripts usually cannot be used for mobile devices. If you can't make your application fit into the portal framework, don't make it into a poorly-behaved portlet.

* If you will want to provide services to other applications, consider writing a Web service first. Once you implement a Web service, you can write a portlet to use it, and you can publish the Web service to share it with other applications. The stock portlet is a good example: the stock quote service should be a Web service that the stock quote portlet and other applications can use. In this case, you might also write a program that automatically sends users a text pager message when a stock reaches a certain price.

* If the company does not have a portal server yet, and does not plan to invest in one immediately, one can go ahead and implement the application as a servlet using JSP pages for the output. One can always convert it to a portlet later.

Filed in: WPS

If you offer more than a few portlets within your portal, then you need to think about how people will navigate between and among them. While it is tempting to just let users click the back button until they make it back to the portlet page, this is a highly inefficient method. When you have complete control over the development of the application that the portlet accesses, you should include breadcrumb navigation trails, links to the main sections of the portal site, and links to related portlets.

Information architecture has to be designed for a portal and its application just as in the development of any other Web application. A good navigation scheme within a portal should allow the user to answer each of the following seven questions from anywhere within the portal or its applications.

Seven questions to determine a good navigation scheme:

1. Am I still in the portal?
2. How do I get to the main page of the portal?
3. What are the major areas of this portal?
4. Where am I in relation to the main page of the portal and the other applications I have visited?
5. Where can I go from here?
6. How can I go back to where I came from?
7. When I leave this screen, will I be able to get back to it?

Filed in: WPS

Walk through a sample IBM WebSphere® Portal problem scenario to get a step-by-step guide to the Automated Problem Determination (AutoPD) tool. In this article, the first in a series, learn how the AutoPD tool can help you diagnose problems related to WebSphere Portal. Use the tool in the same manner with other IBM software products, including WebSphere Application Server. And find out about the general design of the tool and how you can use it to diagnose a WebSphere Portal login problem.

Filed in: WPS

Whenever, we are travelling, we are always checking are mails to make sure we do not miss out on any important communications. Now, if we could set up some kind of notification service, where we can communicate to the user's phone and send him/her some kind of notification on the important mails.

Then is it time to explore the concepts behind the Mail and Calendar Services (MCS), a component of the Intelligent Notification Services used to access mail files, monitor for new e-mail messages, and to provide events based on these new e-mails to users' preferred delivery channels.
Check out the basic details here.