Exploiting the WebSphere Portal V5.1.0.1 programming model: Part 1: Introducing the model

This is the first in a series of five articles which can help portal developers and administrators to apply the IBM® WebSphere® Portal V5.1.0.1 programming model to your company's portal. This article introduces the various parts of the model, provides a short overview of portal technology, and describes how portals relate to the service-oriented architecture (SOA). You learn about the model artifacts--such as portlets, themes, skins, and portlet services—and how you can influence a process called aggregation, in which the different pieces come together to create the portal page. Then, you see how two general concepts, security and virtual portals, relate to the programming model. Finally, you can download and experiment with a portlet application which illustrates the concepts introduced in this first part, and which will be used in future parts of the series.


Stefan Hepper, WebSphere Portal Programming Model Architect, EMC

Author photoStefan Hepper is the architect responsible for the WebSphere Portal programming model and public APIs. He was co-leader of the Java Portlet Specification JSR 168. He also started the Pluto project at Apache, which provides the reference implementation of JSR 168. Stefan has delivered a number of lectures at international conferences, such as JavaOne, published various papers, and is co-author of the book Pervasive Computing (Addison-Wesley 2001). His research interests are component-based software architectures, pervasive infrastructures, and, of course, portals and portlets. Stefan received a Diploma of Computer Science from the University of Karlsruhe, Germany, and in 1998 he joined the IBM Böblingen Development Laboratory.

developerWorks Professional author

Stefan Liesche, WebSphere Portal and Workplace Foundation Lead Architect, EMC

Author photoStefan Liesche is a Certified Senior IT Architect in the IBM Development Laboratory in Boeblingen, Germany. He has 11 years of experience in the software development field. He holds a master of science degree in computer science from University of Hildesheim, Germany. He joined IBM in 1998 as part of the services group where his speciality was designing large-scale end-to-end e-business solutions for complex environments. Stefan has been working with IBM WebSphere Portal for years. He first worked on the construction of large-scale portal solutions before joining the WebSphere Portal development architecture team. He is the Lead Architect of Workplace and Portal Foundation.

14 December 2005

Also available in Japanese


The WebSphere Portal programming model is an extension of the J2EE programming model. You use it to implement Web applications that leverage the rich set of WebSphere Portal platform capabilities. These include aggregation and integration of components into page hierarchies, flexible navigation, content and application aggregation, branding, customization, personalization, content management, document management, search, and so on. Figure 1 shows how a portal works in principle.

Figure 1. The portal principle: Application integration at the glass
Figure 1. The portal principle: Application integration at the glass

The user interacts with the portal, and the portal interacts with various backend applications, aggregating them all for the user into a single browser window, the portal page. WebSphere Portal also helps you integrate these components within a context, a capability which is often called integration on the glass. Again, all of a user's applications are integrated by the portal and displayed in a single window, so that the end user gets a consistent view of many disparate systems within a context which has meaning to that user. This powerful capability enables companies to provide users with an integrated, consistent means of working with a complex network of applications within a widely fractured IT infrastructure. Instead of dealing with different IT systems with different user interfaces, users only need to deal with one IT system, the portal, with a single user interface.

The WebSphere Portal programming model consists of various APIs, SPIs, JSP Taglibs, and descriptors that let you customize the aggregation steps at different levels. The intent of this document is to give you an overview of which parts of the portal can be customized and extended using the this model.

Examining the parts of the model

The portal page consists of different markup fragments that are produced by portlets. The process of collecting all the portlet fragments and creating a single page that can be sent back to the client is called aggregation, which is depicted in Figure 2.

Figure 2: Aggregation of portal pages
Figure 2: Aggregation of portal pages

Aggregation flows like this:

  1. The client sends a request to the portal. The portal servlet examines the request header and determines which device and which user is requesting a page.
  2. The portal determines the portlets on this page, and checks the user's access rights to these portlets. Here a the first plug point where you can customize. You can tailor the login and logout behavior. We will give you more detailed information on how to achieve this customization in a later article in this series.
  3. The layout system is called, which consists of themes and skins that render the look-and-feel. Themes and skins are a major plug point in the portal system, in which you can influence the complete portal page look-and-feel. We discuss theme and skins in more detail in a later section of this article Artifacts: Themes and skins.
  4. User actions are forwarded from the portal to the portlet container for the corresponding portlet. This container provides the runtime environment for portlets, and it interacts with the portlets through the Portlet API. The portlet container issues a process action call to the portlet, and the portlet processes the action and changes its state accordingly.
  5. Finally, rendering is started by the layout system, and the portal calls the portlet container for each portlet on the page. The portlet container calls the render method of the requested portlet, and the portlet renders its markup fragment into the output stream. After all portlets are processed the complete page is returned to the client.

Portals and SOA

Service-oriented architecture (SOA) is an approach for building distributed systems that deliver application functionality as services either to end-user applications or to other services. SOA provides mechanisms to integrate and manage these different services.

How does a portal fit into the SOA picture? Portals provide first-class user interface (UI) support in an SOA. Portlets--the building blocks of portals-- let developers focus on unique aspects of their applications, while the middleware handles common functions of the lifecycle, such as per-user customization, aggregation, and integration with other components.

Portals provide the ability to aggregate and integrate the UI similar to the way SOA runtimes combine and integrate services. Component UIs are aggregated into larger, higher value UIs, giving users a single view of IT services with a single UI to master. Applications which were originally designed separately can be integrated together to enable new function. You can use inter-portlet communication to integrate components. For example, an email portlet could communicate with a collaboration portlet to filter the in-box and display received email only when the sender is online and available for a chat; this capability not available in either of the original applications.

A surprising consequence of the portal model is improved agility for on-demand businesses. Administrators can become application integrators who create new applications without programming: by defining new pages, adding portlets to them, wiring the portlets together, and setting entitlements. A self-service portal lets users adapt their work environment to their unique needs. So, the portal architecture frees up application developers to concentrate on building new business value.

The service interface and protocol for a local portlet is defined by the Java Portlet Specification. Web Services Remote Portlet (WSRP) is the standard for remote rendering of portlets, enabling a portal to aggregate content from multiple remote sources. WSRP extends the integration capabilities of Web services to presentation-oriented components and exposes the view layer to sharing across platforms, implementation languages, and vendors. Content and application provider services can be discovered and plugged into standards-compliant applications, without any extra programming effort.

Artifacts: Portlets

Portlets are the basic building blocks of portlet applications. This article does not describe the Java Portlet API or programming model; rather, it focuses on WebSphere Portal specific extensions. See Resources for more information on the Portlet API.

Tag libraries

JSR 168 defines a tag library for the most common portlet specific functionality, such as create actions or render URLs. JSP™ Standard Template Library (JSTL) provides additional common functionality for JSPs such as iterations, formatting, and internationalization. WebSphere Portal provides an additional tag library for portlets that allows them to use other internationalization extensions.

You should include an application specific tag library in a portlet application only in the case when the standard tag libraries are not sufficient.

Brokered portlet interaction

The current Java Portlet Specification provides limited support for portlets to share data with other each other. Portlets can only use the portlet session to share data with other portlets in the same Web application.

WebSphere Portal introduces the notion of a brokered inter-portlet interaction mechanism. All portlets register their interaction capabilities with a broker, and the broker then facilitates the interactions among the portlets. The broker operates on the principle of portlets being producers and consumers of typed properties; therefore, it is called the Property Broker. Portlets can either directly register interest in producing and consuming properties, or can do so indirectly by registering actions that consume and produce properties. Using the typed information associated with properties, the Property Broker determines compatibility between properties belonging to different portlets. This enables loosely-coupled, highly interactive applications. Portal administrators can define wires between the portlets so that they are integrated at runtime.

The programming model for inter-portlet communication uses the existing JSR portlet API method processAction for notifying portlets of property changes. Therefore, these portlets can also run in environments that do not support the IBM extension. The special Property Broker actions are never triggered in the non-IBM environment.

To take advantage of basic brokered cooperation mechanisms, portlet application developers are usually not required to do additional programming (beyond normal portlet development). Instead, they are required to declare the properties and actions to the broker in a WSDL file. In WebSphere Portal V5.1.0.1 the property broker mechanism is limited to portlets on the same page or to portlets on two different pages only.

Portlet frameworks

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 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.

Artifacts: Themes and skins

The J2EE JSP model provides the base for separating the programming role from the design role when building Web applications. WebSphere Portal takes this a step further by providing a framework for greater separation and a lot more flexibility. WebSphere Portal themes and skins isolate branding and look-and-feel aspects of the user experience with a well-defined set of artifacts, including JSPs and CSS classes. You can easily change the branding and overall look-and-feel of the user experience by simply replacing the implementations of the themes and skins referenced in the Topology model. WebSphere Portal 5.1.x defines a directory structure to which themes and skins must adhere so that they can be deployed in WebSphere Portal.

Themes control the look-and-feel (including branding) aspects of pages. Skins expose portlet controls. In order to make themes and skins work smoothly, portlet programmers use globally defined standardized CSS style classes, such as those defined in JSR 168 and WSRP, within their implementations. Then, independently developed portlets come together on the same page and look like they were developed by a single team.

Figure 3 depicts some of the default WebSphere Portal 5.1 themes. Any of these can be chosen as a theme for a page or these themes can be taken as a template for creating custom themes.

Figure 3: Subset of the WebSphere Portal 5.1 default themes
Figure 3: Subset of the WebSphere Portal 5.1 default themes

Figure 4 shows some of the WebSphere Portal 5.1 default skins that render the portlet windows. Similar to the case of themes, you can customize skins, and use the default skins as samples to build your own.

Figure 4: Subset of the WebSphere Portal 5.1 default skins
Figure 4: Subset of the WebSphere Portal 5.1 default skins

You can retrieve information about themes and skins programmatically through the Theme List model and through the Skin List model. These models expose theme and skin objects, respectively. They can be used to obtain information on a specific theme or skin.

Artifacts: Portlet services

Portlet services are, as you might expect from the name, services that can be used by portlets. There are two types of services: the default portlet services that ship with WP 5.1, and custom portlet services.

The portlet services programming model defines a framework for providing functionality to portlets that is not specified in the portlet API. The portlet can retrieve such a service through a standard JDNI lookup. A portlet service is not restricted at all in the definition of interfaces. Typically, portlet services take objects from the portlet API (such as the portlet request) as input parameters. Some (IBM-specific) portlet services are provided as part of WebSphere-Portal, but you can also allow add custom services to a portal.

There are two aspects of portlet services that are mostly independent:

  • The service access (client view) describes how interfaces of portlet services are defined, and how portlets can obtain an implementation of the service.
  • The service provider (server view) describes how a service is implemented and registered.

The portlet service programming model is singleton-based, which means that there is no portlet entity specific instance of a portlet service. Therefore the suggested programming practice is to look up the service in the init method of the portlet and store it in an instance variable.

WebSphere Portal V5.1.0.1 provides the following portlet services. These services are APIs intended for general usage.

  • Content access service.

    Lets a portlet access the Internet and enables the portal administrator to manage this access centrally (for example, set proxy servers and exclude specific Web sites).

  • Credential vault.

    Stores user IDs and passwords for backend systems to facilitate providing a single sign-on experience for the portal user. This service will be explained in detail in the security and user management part of this article series.

  • Dynamic UI manager.

    Launches dynamic portlets and pages. See the next section (LINK) for more details.

  • Task manager service .
    com.ibm.portal.portlet.service.taskmanager.TaskManagerDelegateFactoryService and

    Enables portlets to participate in BPEL-related workflows.

The following services are System Programming Interfaces (SPIs), which are more complex and intended for advanced use cases.

  • Puma user management.

    Provides access to the profiles of a portal user or group. You can find, create, modify, and delete users and groups. This service will be explained in more detail in the Security and user management article of this series.

  • Credential Vault encryption exit.

    Lets you provide an encryption of the stored user IDs and passwords.

  • Portal model SPI.

    Gives read access to the current navigation and content model of the portal. You can write portlets which provide navigation links to other portlets and pages. This programming interface will be explained in detail in the article about dynamic and context sensitive portlets.

Assembling the pieces: Portal aggregation

Aggregation is the process of assembling all the different markup fragments produced by the portlets on a page, with the entire additional markup produced by the themes and skins, into one page that is sent back to the client.

You can customize the look-and-feel of the aggregated page through themes and skins (see Artifacts: Themes and skins), and add support for new markups by providing the corresponding themes and skins for these markups.

Another point of customization is determining which portlets contribute markup to the current page. This can be done either statically by the portal administrator, or the portal end user who can create pages and put portlets on these pages. Alternatively, it can be done dynamically through the dynamic UI manager explained in the next section. The portal administrator can delegate access permission to customize a page to other portal administrators or to portal end users.

In order to render a page for a user, aggregation needs to determine the current page for the user, and which resources reside on this page. All this information is stored in the topology model of the portal. The topology model spans several kinds of portal resources. These resources are available through different kinds of models, including the Content Model, the Layout Model, the Navigation Model, and the Navigation Selection Model. All these are tree models, except for the Navigation Selection Model. The information is ordered in a tree hierarchy and the model can be explored with the usual tree model methods.

The elements of the Content Model can be pages, labels, or URLs. For each content node that represents a page, a model exists that represents the layout of that page (the Layout Model). This model holds layout nodes that describe the layout and contents of the page (containers and portlet windows, sometimes also called controls).

The Navigation Model represents elements that are used to build the navigation possibilities that are presented to a portal user. The elements of the Navigation Model are navigation nodes. Each such node can reference a content node.

When a user is navigating through the portal, the currently selected navigation node is needed to render the current page. The Navigation Selection Model reflects the current selection. It represents a list that defines a path through the navigation model, as illustrated in Figure 5.

Figure 5: Different models involved in the portal aggregation
Figure 5: Different models involved in the portal aggregation

Dynamic UI management

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.

The dynamic UIs management will be explained in detail in a later article.


To a large extent, WebSphere Portal security is based on security features provided by WebSphere Application Server. In some areas, WebSphere Portal provides some additional services to enable portal-specific security extensions.

WebSphere Portal security includes aspects of each of these facilities:

  • J2EE authorization

    The WebSphere Portal portlet container supports programmatic J2EE authorization according to the J2EE specification.

  • Portal Access Control

    Access control within the portal domain is not based on the J2EE authorization model, because it is not powerful enough to be a viable solution for the portal authorization domain. Instead it is based on the Portal Access Control. For more information about Portal Access Control and how to optimize your portal performance using it, see Resources.

  • Credential vault

    The Credential Vault is a component in WebSphere Portal which portlets use to safely store confidential information such as user name/password pairs. The Credential Vault exposes a corresponding portlet service which portlets use to read and write the confidential information, and a corresponding service provider interface that can be implemented to integrate with existing credential management systems.

  • Support for Java 2 Security

    Java 2 Platform Security is a security feature that was newly introduced by WebSphere Application Server V5. This feature enables protecting individual sensitive operations (such as file I/O or network access) such that code needs to be granted certain permissions in order to be allowed to actually execute those operations.

Further details on Security and how to customize the default portal behavior will be given in a future article of this series.

Virtual portals

WebSphere Portal is all about the integration of users and administration, a common look-and-feel, and a standardized application programming model. You can integrate various backend systems to a common user experience. However, there are cases in which you will have several independent user populations and you want to provide a very unique and distinguished look-and-feel to each of them. Each community wants to work with its own logical partition of WebSphere Portal, independently from others. You want to support these communities efficiently, without having to install complex hardware and software systems over and over again.

You can avoid the hassle of such time consuming installations by sharing hardware and/or software, and by enabling multiple logical portals called virtual portals. End users will not be able to distinguish if their request is served by a normal full WebSphere Portal installation, or by a logical portal which has been defined within a shared environment. Administration is simplified by reducing the number of parallel installations. Such sharing of hardware and/or software is extremely important in a hosting environment; for example, when service providers provide portal services for multiple tenants. Several characteristics of virtual portals have impact on the programming model, and these are explained below.

When exposing multiple virtual portals on a single WebSphere Portal installation, it is imperative that each logical portal expose its own look-and-feel. This is achieved by creating parallel root content nodes for each logical portal. Each content root and its child pages, can apply its individual themes and skins without impacting other content in parallel trees. An end user is not aware that two different content nodes actually reside on the same physical WebSphere Portal installation.

Figure 6 depicts this content hierarchy for three virtual portals. The content root of each virtual portal can be accessed through an individual URL. You can also provide virtual portal-specific login, error, logout, and self-enrollment "pages". For this purpose it intended to allow the usage of customized portlets instead of the current "screens".

Figure 6: Virtual Portal content hierarchy
Figure 6: Virtual Portal content hierarchy

When sending a request to portal, the URL needs to include which virtual portal should be accessed. For that purpose, friendly URL mappings are applied. Each virtual portal has one specific URL mapping referencing its content root. That mapping is defined and created during the initialization of a virtual portal. Such a friendly URL for a virtual portal can look like this:


You can create additional URL mappings to pages within the virtual portal at any time in exactly the same way as it would have been done in a "normal" 5.0 Portal installation. If no URL mapping is specified, the user is directed to a "default" virtual portal. That default portal is the one which was created during installation of WebSphere Portal. In the case that an invalid URL mapping had been used, the user is directed to that "default" virtual portal as well.

Based on the URL mapping that is used, WebSphere Portal sets an internal virtual portal context. All of a user's activity is executed within the context of that virtual portal. Depending on the current context, different content will be visible to the user.

The requirement to isolate the content of individual virtual portals, but still allow sharing of applications, has been addressed in WebSphere Portal 5.1 by a new concept. Depending on the type of a WebSphere Portal resource, it will scoped in one of the following ways.

  • Scoped to a particular virtual portal

    In order to use such a scoped resource, you must access the associated virtual portal. These resources are not visible or accessible from any other virtual portal and, therefore, cannot be shared among virtual portals. Pages, portlet entities, and search indexes are scoped resource types. The scoping of these resource types is enforced by WebSphere Portal.

  • Shared among all virtual portals of an installation

    Shared resources are available within the entire WebSphere Portal installation and can therefore be used by all virtual portals. Portlet definitions, portlet applications, Web modules, URL mappings, WSRP producers, themes, and skins are shared resource types. However, you can apply Portal access control and limit the usage of these shared resources to certain virtual portals. You can grant permissions for a shared resource to the only users of the virtual portal of choice.

Impact on the model

When developing applications, keep in mind that there is no real application isolation between virtual portals, since the entire installation shares a common portal. Fundamental J2EE concepts such as session or Web application are not aware of the notion of a virtual portal.

Portlet applications share the same session across virtual portals. From a portlet programming model point of view, this is not different than having the same portlet more than once on a page or on different pages. In the portlet section of this document, we explained the different customization levels of portlet definition, portlet entity, and portlet window. When storing data in the application scope of the session, the portlet needs to take into account that several instances of this portlet at the portlet definition and portlet entity level might exist, and these different instances would overwrite the data if no precautions are taken.

At the portlet definition level, the portlet can offer the portal administrator a preference setting that can be used to distinguish between these different definitions. The portlet can then use this preference attribute to namespace the session data per portlet definition. For example, a news portlet could offer such a session scoping key with the name newsPortletInstance and the administrator could set this value to "EuropeanNews" for the first portlet definition, which points to a European news provider, and then set the value to "USNews" for the second portlet definition, which points to an US news provider.

Portlet windows can be used to separate data in the shared application session. This allows each appearance of the portlet to have its own data stored in the application session scope, and not shared with other J2EE artifacts.

You can deploy a portlet multiple times as different Web applications. Although each deployed application is shared among all virtual portals, the portal administrator could apply access control to restrict each deployed instance to a particular virtual portal. Then, the virtual portal could use its own copy of the Web application and have a higher degree of isolation (such as separate session data).

Example portlet application

Now that we have covered the different aspects of the WebSphere Portal programming model it is time to get our hands dirty. We'll start with a calendar portlet application that is strictly standards-based in this part of the article series. We will extend this sample in future articles with WebSphere Portal extensions, such as inter-portlet communication.

The calendar portlet application consists of two portlets: a calendar portlet, which displays a specific month where the user can select a day, and a display portlet that renders the selected day's To-dos in the calendar portlet. The calendar portlet and the display portlet share the data through the portlet application session. The running sample is depicted in Figure 7.

Figure 7: Running calendar sample with a selected date (12/12), and todo's list in the todo portlet
Figure 7: Running calendar sample

The sample, which you can download, is explained in detail with the complete code in section 3.2. of Portlets and Apache Portals. See Resources for this reference and others which can guide you through creating portlets with Rational Application Developer and deploying them onto WebSphere Portal.


The WebSphere Portal programming model consists of several programming artifacts that provide different functions, such as portlets, themes and skins, and portlet services. WebSphere Portal offers many customization points that you can use to tailor and extend the portal to your specific needs. Future articles in this series will take you deeper into the use of new V5.1.0.1 APIs.

In the next part, you learn about portal URL generation and how you can leverage this capability in your theme. In another part, we'll show you how to make your portlets more dynamic and how to react to the current user context. Another article will make a deep dive into security and how you can customize the credential vault, the login/logout behavior, and achieve single sign on with your infrastructure. Finally, we'll tell you how you can create your own portlet services.


Code samplesCalendarPortlet.zip  ( HTTP | FTP )928 KB



Get products and technologies

  • Rational Application Developer V6: Download trial software from developerWorks. Includes the portal tools and a test runtime copy of portal that you can use to develop a prototype.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Exploiting the WebSphere Portal V5.1.0.1 programming model: Part 1: Introducing the model