Sun ONE logo     Previous     Contents     Index     Next     
Sun ONE Portal Server 6.0 Migration Guide



Chapter 9   Changes in Sun ONE Portal Server APIs that Affect Migration



Note All instances of Sun™ ONE Portal Server 3.0 refer to the products formerly known as iPlanet™ Portal Server 3.0, Service Pack 3a and iPlanet™ Portal Server 3.0, Service Pack 4.


This chapter provides information on the API changes between Sun ONE Portal Server 3.0 and Sun™ ONE Portal Server 6.0.

This chapter contains the following sections:

Changes From Sun ONE Portal Server 3.0 That Affect Application Development

The following changes to Sun ONE Portal Server 3.0 affect portal developers:

  • New data model - Sun ONE Portal Server 6.0 uses Sun™ ONE Directory Server as its storage mechanism. This replaces the Sun ONE Portal Server 3.0 internal role tree directory.

  • The Sun ONE Portal Server 3.0 APIs for session, profile, authentication, and so on, have been replaced by the iPlanet™ Directory Server Access Management Edition 5.1 APIs. See the Sun ONE Portal Server 6.0 Developer's Guide for more information.

  • If you migrate from Sun ONE Portal Server 3.0 to Sun ONE Portal Server 6.0, the migration process also includes modifying source code to use the new Sun ONE Portal Server APIs. See Appendix C "Public API Changes Between Sun ONE Portal Server 3.0 and Sun ONE Portal Server 6.0" for API mappings.

  • The Sun ONE Portal Server 3.0 Provider API (PAPI) has been updated as follows:

    • New ProviderContext interface.

    • New APIs for container hierarchy.

    • Compile compatibility for some providers.

    • Improved internationalization so that:

      • The display profile supports localized strings.

      • Character set encoding methods are determined using local setting and client type.

Migrating Sun ONE Portal Server 3.0 Session to iPlanet Directory Server Access Management Edition 5.1 SSOToken

For details on API changes needed for migrating Sun ONE Portal Server 3.0 session to iPlanet Directory Server Access Management Edition 5.1 SSOToken, see Table C-1 in Appendix C "Public API Changes Between Sun ONE Portal Server 3.0 and Sun ONE Portal Server 6.0."

Migrating the Sun ONE Portal Server 3.0 Profile to iPlanet Directory Server Access Management Edition 5.1 User Management Classes and Service Management Classes

For details on API changes needed for migrating Sun ONE Portal Server 3.0 profile to iPlanet Directory Server Access Management Edition 5.1 user management classes and service management classes, see Table C-2 in Appendix C "Public API Changes Between Sun ONE Portal Server 3.0 and Sun ONE Portal Server 6.0."

Migrating Sun ONE Portal Server 3.0 Logging to iPlanet Directory Server Access Management Edition 5.1 Logging APIs

For details on API changes needed for migrating Sun ONE Portal Server 3.0 logging to iPlanet Directory Server Access Management Edition 5.1 logging APIs, see Table C-3 in Appendix C "Public API Changes Between Sun ONE Portal Server 3.0 and Sun ONE Portal Server 6.0."

Migrating Sun ONE Portal Server 3.0 Debug to iPlanet Directory Server Access Management Edition 5.1 Debug APIs

For details on API changes needed for migrating Sun ONE Portal Server 3.0 debug to iPlanet Directory Server Access Management Edition 5.1 debug APIs, see Table C-4 in Appendix C "Public API Changes Between Sun ONE Portal Server 3.0 and Sun ONE Portal Server 6.0."

Migrating Sun ONE Portal Server 3.0 Provider APIs to Sun ONE Portal Server 6.0 Provider APIs

The Desktop SDK for Sun ONE Portal Server 3.0 included the following interfaces and classes:

  • Provider

  • ProviderAdapter

  • ProfileProviderAdapter

  • DesktopURL

  • InvalidEditFormDataException

  • AsciiFormInputException

  • LoadPropertiesException

  • ProfileProviderException

  • ProviderException

  • ProviderWrapperException

  • UnknownEditTypeException

This section outlines the Desktop API changes between Sun ONE Portal Server 3.0 and Sun ONE Portal Server 6.0. For the Sun ONE Portal Server 3.0 Desktop SDK classes and methods that have changed syntactically or semantically, see Table C-5 in Appendix C "Public API Changes Between Sun ONE Portal Server 3.0 and Sun ONE Portal Server 6.0."

By far, the largest changes are in the provider interface. These changes fall into two general categories:

  • Changes to facilitate the formalization of container channels

  • Changes to separate access to services out of the PAPI

In Sun ONE Portal Server 3.0, there is a single implicit container for all channels. This container cannot be modified or replaced. All leaf channels can assume a single container with a particular implementation. In Sun ONE Portal Server 6.0, the idea of a container channel is formalized. The Sun ONE Portal Server 6.0 Desktop consists of a number of container channels, all with different implementations and features. In the Sun ONE Portal Server 3.0 provider interface, there is a subset of methods that assume a single container. For example, the Sun ONE Portal Server 3.0 container called the Provider.isDetached() method on a leaf channel to determine if the provider should be displayed in a detached window. The information describing whether the channel is detached or not is logically connected to the channel. This does not scale to an environment in which the channel's detached status will be different for every container. Specifically, the detached flag is actually a property of the container channel, not the leaf channel.

Additionally, having an isDetached() method in the provider interface assumes that all containers support this functionality. This is not the case. A tab container, for example, would not support detachability.

It is useful to split channel properties into two categories:

  • Type 1- Properties that are the same regardless of the container in which the channel is displayed.

  • Type 2: Properties that describe a relationship between a container and leaf channel.

Provider.isDetached() is a type 2 property since it describes a relationship between a container and leaf channel rather than being the same regardless of the container in which the channel is displayed. In Sun ONE Portal Server 6.0, all type 2 properties are owned by the container channel. In other words, they are properties of the container channel. For example, if a container supports detachability for its leaf channels, it must store a property that is a mapping between leaf channel name and detached status, for every leaf channel it contains.

The methods to access type 2 properties are therefore removed from the provider interface.

In Sun ONE Portal Server 6.0, the underlying services layer changed from using the proprietary Sun ONE Portal Server 3.0 services to iPlanet Directory Server Access Management Edition 5.1. Because the Sun ONE Portal Server 3.0 provider interface is tightly integrated with the Sun ONE Portal Server 3.0 service APIs, migration is required in Sun ONE Portal Server 6.0. In an attempt to prevent this problem in the future, Sun ONE Portal Server 6.0 separates service access into an agnostic interface called ProviderContext. The idea is that provider developers access services through ProviderContext and are therefore immune to changes in the underlying services implementation.

There is a subset of methods in the provider interface that are specific to the syntax and semantics of the Sun ONE Portal Server 3.0 service APIs. These have been changed to use standard JDK or Portal Server APIs. An example of this is the Provider.init() method. In Sun ONE Portal Server 3.0, this method took a Sun ONE Portal Server 3.0 session object as an argument. In Sun ONE Portal Server 6.0, this method takes a servlet request object from the Servlets 2.2 SDK.

Table C-5 in Appendix C "Public API Changes Between Sun ONE Portal Server 3.0 and Sun ONE Portal Server 6.0" maps the Sun ONE Portal Server 3.0 classes and methods that have changed syntactically or semantically to the Sun ONE Portal Server 6.0 equivalents. Note that classes and methods where there is no syntactic or semantic change are excluded from the table.


Previous     Contents     Index     Next     
Copyright 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated September 25, 2002