A legacy portal assembles information from several places into one user experience. To understand a Sun ONE implementation, trace each visible channel back to its provider, source content, identity rules and presentation configuration. That map reveals what a replacement must preserve.
Place FatWire and Sun ONE in their period
In April 2003, FatWire Spark pCM was offered as a portal content-management integration for Sun ONE Portal Server. The period’s licensing and download offers belong to that announcement, while the useful architectural distinction remains: content creation and approval supply material that a portal selects and presents.
The Sun ONE Portal Server 6.0 deployment overview, preserved by Oracle, describes an identity-enabled portal and separates provider business logic from JSP or template-based presentation. It also identifies FatWire among content-management integrations. The concepts here are scoped to that 6.0 documentation; inspect the installed release and extensions before using later manuals.
For a transition, treat historical manuals as a vocabulary and dependency-discovery aid. Choose current operational, security and support requirements independently for the destination system.
Read the components as a dependency map
| Component | Role in the historical model | What to inventory |
|---|---|---|
| Channel | A configured unit of portal content associated with a provider. | Visible title, source, audience and the task it serves. |
| Provider | Produces the content delivered through a channel. | Code/configuration, upstream service and error behavior. |
| Display profile | Stores provider and channel configuration used by the Desktop. | Channel arrangement, inherited settings and customizations. |
| Desktop and presentation | Assembles the user-facing portal view. | Templates/JSPs, navigation, layout and links. |
| Identity and directory services | Supply user and service context for the portal. | Groups, role mappings and authorization dependencies. |
The Sun ONE 6.0 glossary explains channels, providers and the Desktop/display-profile relationship. Retain the distinction between a source application’s data and the portal’s configuration for displaying it.
- Content source or CMS: authors, approves and stores the material.
- Provider and channel configuration: select and retrieve the needed content.
- Identity context: determines the relevant user and permitted experience.
- Desktop presentation: assembles the selected channels and navigation.
- Reader task: follows a link, reads information or enters a connected application.
Trace each channel to an accountable owner
Begin with representative user roles and capture the channels each can see. For every channel, identify whether it shows copied content, retrieves live content, embeds an application or simply links elsewhere. Find the upstream owner and record how freshness, errors and access are handled.
Inventory source IDs, content formats, templates, images, links, provider code, configuration and search indexing rules. Record the identity mapping separately from the content mapping. A replacement must preserve required access behavior even when the destination uses a different group or role vocabulary.
Use the portal dependency and transition worksheet (plain text). It includes one record per channel, an owner map, representative role tests and an explicit retain, rebuild, redirect or retire decision.
Work through a fictional employee portal
Three channels, three different transitions
An employee portal shows a policy bulletin from a CMS, a project-status panel from an application and a link to an external benefits service. The bulletin needs content and approval-history mapping. The project panel needs a documented data interface and role tests. The benefits link needs an owner-verified destination and a clear sign-in route.
The team selects three representative roles: a general employee, a project member and a content editor. It records both expected access and expected denials. Copying the visible portal page would preserve a view while leaving the source updates and role behavior unresolved.
For the bulletin, test a source edit through publication, portal display and search. For the project panel, test permitted data, restricted data and an upstream outage. For the external link, verify navigation and current service guidance without treating portal authentication as proof of access to the other service.
Accept the replacement by task and evidence
- Preserve a recoverable copy of the relevant content and configuration before transformation.
- Map each required reader task to a destination route and a named owner.
- Reconcile content identifiers, fields, relationships and required history with the exported package.
- Test roles, search results, direct links, stale content and source-system failures.
- Record the cutover decision, redirects, support ownership and evidence for retiring each dependency.
A channel’s appearance may change substantially while its task remains useful. Make that task and its acceptance criteria explicit. Keep unresolved source ownership, inaccessible evidence and unknown custom code visible in the transition plan rather than inferring them from a product name.