Introduction to WebLogic Portal

WebLogic Portal is the outward-facing component of Oracle WebLogic Platform that lets you provide a user interface to integrate your applications. WebLogic Portal lets you surface application data and functionality from heterogeneous environments into an integrated, dynamic, and customizable Web-based portal user interface that can simultaneously support your customers, partners, and employees on multiple devices. WebLogic Portal handles the infrastructure so that you can focus your development efforts on what is most important — your applications.

In addition to a powerful portal framework and its J2EE security foundation, WebLogic Portal provides many business services, such as content management, communities, personalization, search, and user management.

WebLogic Portal provides a virtual content repository that lets you federate external content management systems into a single management interface. You can then build portals using content in those external resource. WebLogic Portal also provides a WLP content repository for creating and managing content.

This guide is the starting point for understanding and developing applications with WebLogic Portal. This chapter introduces portal concepts, describes the WebLogic Portal infrastructure framework and business services, and describes the portal life cycle, from architecture through development, staging, and production. The remaining chapters in this guide describe each phase of the life cycle in detail and provide a starting point for using WebLogic Portal.

Portal Concepts

Portals let you combine discrete processes and pieces of functionality into a single Web interface. Before portals, Web users could visit only one page at a time. They could, for example, search for airline flights in a browser window, but if they wanted to see their personal calendars or view their organization’s travel policies, they would have to open a new window and probably log in more than once. Chances are that each site would also look and feel differently than the other sites. With portals, users are able to view all of those sites, and many more, in a single browser window with single sign-on and a common look and feel.

Portals accomplish this unified view with individual windows called portlets. Each portlet can contain a process flow, functionality, or content, and multiple portlets can be displayed in a single browser window. In some portals, portlets can even communicate with each other. Portlets are grouped onto a page. A page is a viewable area represented by a clickable link often in the form of a tab. Pages can further be grouped into a book for organization. Books are also represented by navigation links or tabs. In all, a portal can contain multiple books, each with multiple pages that display multiple portlets on each page.

Another characteristic of a portal is a common look and feel shared among books, pages, and portlets. In some cases users can “re-skin” a portal by changing the look and feel from a drop-down field or with some other control.

A portal often uses a single security framework for authentication and authorization, even when a portal accesses external data (such as RSS news feeds), external business processes (Web Services), and external portlets (Web Services for Remote Portlets [WSRP]).

Figure 2-1 shows a page that contains a number of portlets and other functionality. For example, the desktop header could display a campaign, one portlet could encompass a complex process flow and communicate with another portlet, and another portlet could come from a remote portal.

Technically speaking, portals are collections of resources in an enterprise application that can be displayed in customizable, personalized, and audience-specific views called desktops. For example, a portal might contain business logic, process flows, and content for internal employees as well as for partners. Portal administrators could create an employee desktop and a partner desktop that surfaces the appropriate flows and content for each audience. With a unified security framework, such as that provided by Java 2 Enterprise Edition (J2EE) and WebLogic Server, along with a flexible entitlements engine (WebLogic Portal), a single desktop can also contain all resources and dynamically display only the resources for which an authenticated user is entitled. For example, a desktop could contain pages and portlets for both employees and partners, but a partner who logs in does not see the employee pages and portlets, and vice versa.

Reuse is also a key portal concept. For example, a single process flow in a portal can be reused in multiple portlets in multiple desktops.

WebLogic Portal Framework

A portal desktop, when viewed in a browser, is simply HTML code (along with browser-supported resources such as graphics, animations, cascading style sheets, and JavaScript). The key to the dynamic nature and functional power of a portal is the behind-the-scenes processing that occurs at each click or selection.

Traditional behind-the-scenes processing (in the Java world) has included client-side functionality such as applets, and server-side functionality such as JSPs, servlets, EJBs, and other J2EE features. All of these features perform their processing whether or not a portal is involved. WebLogic Portal provides a framework that dynamically constructs your portal user interface on each request using standards-based components (such as XML, JSPs, JavaScript, cascading style sheets, and GIFs).

The WebLogic Portal framework lets you easily customize and reuse your portal user interfaces for multiple types of devices simultaneously. With your portal user interface in place, you can surface your application functionality in an integrated view. For example, you can create a portal look and feel that displays your portal application a specific way in a desktop browser, and you can create a sub-look and feel that displays the portal and its content automatically in a completely different way when accessed by a handheld device.

The WebLogic Portal framework uses the WSRP standard to handle federated portals, letting you produce books, pages, and portlets that can be consumed by remote portals, and consume books, pages, and portlets that are hosted by remote portals.

WebLogic Portal also provides a framework that lets users create their own community portals, where they can assemble the portlets they need to work together interactively in groups. Communities let users create their own secure portal desktops that group members use to communicate with each other, create and share content, invite new users to join, and manage their own community. WebLogic Portal provides a community-building template for project teams called GroupSpace that provides portlets for e-mail, calendar, contacts, tasks, discussion forums, content maintenance, search, creating bookmark links, maintaining issues lists, making announcements, viewing RSS news feeds, and editing portlet content with rich text controls.

In addition to enhancing collaboration with communities, WebLogic Portal also lets you rebrand the tools in the WebLogic Portal Administration Console for use in your own custom applications. WebLogic Portal lets you surface pieces of management functionality and combine them with other application functionality to create many types of applications, including executive dashboards, collaboration communities, ASP affiliate applications, ISV-branded applications, self-service applications, and OA&M applications.

The services provided by the WebLogic Portal framework let you develop and manage your applications easily and more rapidly, increasing productivity and return on investment while enhancing the user experience.

WebLogic Portal Business Services

In addition to a powerful framework for portal user interface development and application integration, WebLogic Portal provides the following services that can make your applications more powerful and personalized.

Access Control – You can provide dynamic access control to portal components and administration tools.

With visitor entitlements, you can determine which users can access specific desktops, books, pages, portlets, and look and feels. For example, in an HR desktop, you can entitle only managers to see manager-specific portlets; or you can entitle a desktop so that only partners can access it.

With delegated administration, you can determine which administrative users can access specific WebLogic Portal Administration Console tools and set different levels of administrative rights on those tools. For example, you can grant an administrator access to a single content repository folder and restrict administrative rights to only publishing content (not editing or deleting content).

Content Management – WebLogic Portal’s virtual content repository lets you federate multiple compatible content management systems into a single interface, where you can centrally manage content and provide dynamic access to it in your portal applications. WebLogic Portal also provides its own content repository.
Search – The Autonomy search engine is integrated into WebLogic Portal to help visitors find the information they need by delivering accurate and meaningful search results.
User Management – In addition to an LDAP user store and authentication provider provided by Oracle, you can use third-party user stores with WebLogic Platform for authentication or retrieval of user properties. WebLogic Portal’s unified user profile framework lets you create and maintain user profile properties that are attached to users regardless of which user store their user accounts reside in. User profile properties are key components in features such as personalization and access control.
Interaction Management – WebLogic Portal provides an interaction management framework that lets you build personalization and campaigns, track user interactions with your portals, and trigger custom actions when specific events occur. Interaction management lets you improve the visitor experience, increase adoption and loyalty, and achieve business goals with visitor interactions.
Communities – Communities are WebLogic Portal desktops that let users with common goals and interests work together in—and administer—a web-based environment. Whether for specific events, work groups, partners, or for any other groups that need to share information, communities provide a dedicated, secure, self-managed place to collaborate.
Production Operations – Because portals are typically developed in a team development environment, WebLogic Portal supports production operations with tools that allow you to manage the portal life cycle, including portal development, staging, and production environments.
Federation – WebLogic Portal supports federated portals. A federated portal is a portal that includes remotely distributed resources, including remote portlets, books, and pages. These remote resources are collected and brought together at runtime to a portal application called a consumer, which presents the federated portal to end users. Unlike a non-federated, entirely local portal, in most cases, the individual remote parts of a federated portal can be maintained, updated, and released independently without redeploying the consumer portal in which they are surfaced.
Commerce – WebLogic Portal’s commerce framework lets you increase portal value and return on investment by adding commerce functionality to your portal applications.
Client-Side Development – Disc (Dynamic Interface SCripting) is a client-side JavaScript framework that handles the asynchronous updating of portlets, portlet events, and the retrieval of portal context objects. WebLogic Portal provides a set of web-based, REST-style APIs for retrieving, modifying, creating and updating portal data dynamically from the client.
Portlet Publishing – Portlet Publishing makes portlets available to any web application over HTTP and allows portlets to be surfaced in any web page. With Portlet Publishing, for example, you can render portlets within a Struts or Spring application, or any other non-portal web page.

The Portal Life Cycle

Creation of a portal application with WebLogic Portal and other WebLogic Platform components follows an iterative life cycle through different environments: you design the portal application and build its foundation J2EE resources, develop the application functionality and user interface, perform runtime configuration and testing in a staging environment, deploy the application, and manage the application in a production environment.

Figure 2-2 shows the environments in which the portal life cycle occurs: architecture, development, staging, and production.

Architecture

In most cases, the architecture phase occurs once. In the architecture phase, you make fundamental application design decisions and create a starting set of J2EE resources that serve as the foundation of your development efforts.

Resources you create at this phase may include a basic portal enterprise application and basic Web applications, custom EJBs and servlets (business logic), custom SQL scripts for pre-populating data in the development environment, shared development domain (config.xml) with string substitution variables, custom domain, enterprise application, and Web application templates, and custom look and feel resources. The architecture phase is where you set up your team development environment.

Application-level decisions you might make at this phase include the authentication and authorization providers you want to use, whether you will store user properties externally or use WebLogic Portal’s user profile functionality to store user properties in WebLogic Server’s default LDAP store (or both), which database you will use, your cluster configuration in staging and production, your source control strategy and conventions for concurrent application development, your process for moving application code and data between environments, whether or not there are remote books, pages, and portlets you want to consume in your portal application, and your content management strategy, especially if you are using a compatible third-party system in conjunction with WebLogic Portal’s content repository.

In addition to application-level decisions, you must also make architecture and design decisions for each WebLogic Portal feature you will use. For example, if you want to use campaigns in your application, what are the conditions that will trigger campaigns (such as date/time or user profile properties)? And when the campaigns run, what content characteristics to you want to use to display the content? Do you need a “season” property with values of “spring”, “summer”, “winter”, and “fall”, so that content added in the production environment with one of those values is picked up by campaigns automatically? There are many feature-level architectural decisions to make.

Development

In the development phase, developers use the set of resources created in the architecture phase to create programmatic portal application functionality. Multiple developers create application functionality using source control in this phase.

Resources you create at this phase may include JSPs, page flows, Web Services, portals, books, pages, portlets, campaigns, content selectors, placeholders, property sets, XML files, graphics, JavaScript, HTML, and Java code. These resources you create in the development phase are file based, and when you reach the production phase these resources are most likely deployed in an enterprise archive (.ear) file. The primary tools used in this phase are source control, Workshop for WebLogic and other editors of choice, and the WebLogic Portal production operations tools to move database and LDAP data between staging and development.

Because development code and resources are often dependent on server and database data, such as content, users, and security roles, development occurs in parallel with staging, where server and database data are populated.

Staging

In the staging phase, you assemble, configure, test, and deploy the portal application you want to go live with. With the testing aspect of the staging phase, there is tight iteration between staging and development until the application is ready to be released.

Tasks at this phase may include creating content and content types, creating desktops, modifying cache settings, creating administrative users, modifying interaction management rules, creating delegated administration roles and applying them to resources, creating visitor entitlement roles, connecting WebLogic Portal to external security and content providers, configuring services such as behavior tracking and the campaign e-mail, and modifying cache settings for performance. These tasks write data to the LDAP server and the database.

The primary tools used in this phase are the WebLogic Portal Administration Console, the WebLogic Portal production operations tools to move database and LDAP data between staging, development, and production, and any third-party content, authentication, or authorization providers you are using.

Production

In the production phase, you manage and fine tune your live portal application. Many tasks at this phase, such as user management, are identical to tasks you may perform in staging, such as adding users. But staging tasks are for the purpose of simply getting your public portals in place, and production is for true runtime application management.

Tasks you perform at this phase may include user management, applying of delegated administration and visitor entitlement roles to resources, creating desktops, adding content, and resetting/modifying interaction management rules. Visitors can also create communities, as well as customize their portal environments using the WebLogic Portal visitor tools. These tasks write data to the LDAP server and the database. The primary tools used in this phase are the WebLogic Portal Administration Console, the WebLogic Portal production operations tools to move database and LDAP data between production and staging, and any third-party content, authentication, or authorization providers you are using.

When you are in production and you want to update the application functionality or user interface—create a new release of the application—you return to the development and staging phases until your updated application is ready to be released.

For ease of iterative development and application updates, WebLogic Portal provides production operation tools that let you move LDAP and database data between environments. For example, you can move portal desktops and communities from production to staging or production to development to test new application functionality against a live simulation of your production application.

Each feature area in WebLogic Portal follows the portal life cycle. Table 2-1 shows examples of how different features move through the portal life cycle.

Table 2-1 Examples of Feature Tasks in the Life Cycle Phases
	Portals	Interaction Management	Security
Architecture	Design a custom portal look and feel and define the types of portals you want to build.	Determine the type of personalization you want to provide.	Develop a strategy for user access to your application.
Development	Create user interface graphics, cascading style sheets, JavaScript functions, skeleton JSP files, layouts, and portal, portlet, book, and page files; configure WSRP producer capabilities.	Create property sets with default values, campaigns, placeholders, content selectors; develop JSPs and Page Flows that implement campaigns, placeholders, and content selectors.	Configure declarative security in deployment descriptors to control access to EJBs, URLs, and file-based resources (such as JSPs); create property sets to support expression-based visitor entitlement and delegated administration roles.
Staging	Create portal desktops and community templates. Consume remote portlets.	Modify default user profile property set values and campaign, placeholder, and content selector definitions.	Create visitor entitlement and delegated administration roles, and apply those roles to portal resources for visitor and administrative access; create administrative users.
Staging	Deploy the application to production
Production	Fine tune desktops and portal components. Users create communities.	Fine tune campaign, placeholder, and content selector definitions.	Fine tune role definitions and their application to portal resources; create administrative users and fine tune access rights for existing administrators.

Even though individual features follow the portal life cycle, development of the entire portal application and its features does not have to happen simultaneously. For example, you can move through the life cycle to create a complete portal application, then continue with additional portlet development that follows its own life cycle to update the entire portal application.

The remaining chapters in this guide discuss each phase of the portal life cycle in more detail and provide guidance on getting started with portal development:

Overview