Communities Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Community Architecture

This chapter describes the concepts and features that make up the Community framework and describes the logic the portal framework uses to render a Community.

This chapter includes the following sections:


Community Concepts and Features

This section describes the concepts and features in the Community framework. See also Using the Community Framework API.

Community Templates

A Community template is the pre-packaged set of resources from which a Community can be built. A Community template resides in the database and allows business users to create Community applications without any coding.

The .community File

A .community file is identical to a .portal file in the development environment, but with a different file extension. A .community is a collection of books, pages, portlets, Look & Feel resources, and other components that eventually become a Community. Portal administrators can create Communities directly with a .community file rather than using a Community template.

Another difference between a .community and a .portal file is that the PortalServlet knows how to render a .portal file as a file-based portal. All Communities, however, must be rendered from the database rather than the file system, so the .community file cannot be rendered as a file. For this reason, the PortalServlet does not know how to render a .community file.

The .ctmeta File

The .ctmeta file is an XML file that lets Community developers preconfigure Community properties, such as the .community file that should be used to create the Community, the registration and error page that should be used, and the Community expiration date. The .ctmeta file makes it easy for portal administrators to create portal templates without having to know technical details about the Community configuration.

Community Membership

When a user joins a Community (becomes a member), information is stored in the database that associates the user with the Community. In addition, the member is assigned to a role, or capability, within the Community (such as owner, contributor, or viewer), which can be assigned to the member when the member is invited to join the Community.

Once part of a Community, members have a CommunityUserContext that lets developers set and get membership information about that user within the Community.


Registration is the process by which users join Communities and become members. Registration functionality, represented in a landing web page or portal, can include such operations as authentication, letting users create their Community usernames and passwords, and displaying the Communities the members can access.

When you run the WebLogic platform installer, it creates a domain in the WLPORTAL_HOME\samples\domains\portal directory.

Communities can be publicly accessible. They do not have to require registration, but a landing page is required when registration is not required.

Community Tools

The WebLogic Portal Visitor Tools, with which users can customize their views of portal desktops, also contain a set of Community tools. The Community tools provide Community management and creation functionality for use in portal applications.


Invitations are the means by which you tell users that they have been invited to join Communities. The Community framework provides the means to send invitations through e-mail using JavaMail, with the ability to extend invitations using formats such as instant messaging.


Notifications are the means by which users communicate with each other in a Community or are alerted to events that occur within a Community. The notification API lets you develop notification functionality in your Communities.

Notifications, which have a limited life span, may come from other users, web applications, or even the framework itself. When notifications are sent, the Community framework persists them in the database until they are consumed or they expire.

Community Context

Because Communities are designed to serve groups of users with common interests and goals, each Community is scoped to that set of users and has unique characteristics. Community context, represented in the Community framework API, is the collection of Community information, including membership information. Community developers can use Community context to create Community-specific features and functionality. For more information, see the Javadoc for CommunityContext.

Community User Context

Users (Community members) also have context within a Community, which can also be accessed and used by Community developers. The CommunityUserContext API lets you get and set member information and perform many types of Community management tasks.

Security: Capabilities vs. Roles

In Community development, you have the option of using capabilities or roles (or both) to control access to Community resources and functionality.


Communities provide a feature called capabilities. For example, the default capabilities for a Community are “creator,” “owner,” “contributor,” and “member.” A capability is a text label applied to a Community member and stored in the member’s record in the database. (A member can have a different capability in each Community.) The only default security functionality with capabilities is that a Community “creator” can delete a Community, and a Community “owner” can manage a Community. Aside from those two behaviors, capabilities are merely labels. To control access to Community resources and functionality with capabilities, you must get the capability for a member from the CommunityUserContext or ICommunityMemberManager, then set up your security logic on the return value.

For example, if you want to show a button on a page to those only in the Community “owner” role, you would get the current member’s capability from the CommunityUserContext or ICommunityMemberManager, followed by the conditional code that shows the button for “owner” and hides it for everyone else.


Roles are widely used in WebLogic Portal. They provide a mechanism for controlling user access to administration tools and portal resources. WebLogic Server lets you create global security roles, and WebLogic Portal lets you create visitor entitlement and delegated administration roles. For example, you can create a portal desktop and designate that it can be viewed only by users in the global “admin” role or the “manager” visitor entitlement role.

In addition, roles are open to auditing, and in your code you can simply use an isUserInRole method or JSP tag to restrict user access to content or actions.

For Communities, the Administration Console provides a bootstrapping mechanism that creates a default set of Community-specific roles. The default Community roles map to the Community capabilities defined in your application’s META-INF/communities-config.xml file. If you choose to secure your Community resources with these roles, you can simply use the isUserInRole method/JSP tag to secure Community resources.

If you do not want to use Community roles to secure Community resources, or if you want to use another mechanism as well, you can use capabilities.

For Community development, you must decide whether you want to use capabilities, roles, or both to control access to Community resources and functionality.


How a Community is Rendered

The following describes how the portal framework renders a Community. Error code constants are defined in com.bea.netuix.servlets.manager.communities.CommunityRedirectionHelper.

Is the Community public?
    Yes: Is the Community active?
         Yes: Render the Community.
         No: Redirect to error page with error               REDIRECTION_TYPE_COMMUNITY_DEACTIVATED
    No: Is a user logged in and do they have a membership 
in the Community?
        Yes: Is their Community member record active?
             Yes: Is their Community membership record active?
                  Yes: Is the Community active?
                       Yes: Render Community.
                       No: Redirect to error page with 
                   No: Redirect to error page with 
              No: Redirect to error page with error                    REDIRECTION_TYPE_MEMBERSHIP_DEACTIVATED
        No: Is public registration enabled?
            Yes: Is a user logged in and do they have a Community member record?
              Yes: Is the member record active?
                   Yes: Redirect to registration page.
                   No: Redirect to error page with 
              No: Redirect to registration page.
            No: Is a user logged in and do they have an invitation 
to this Community?
                Yes: Redirect to registration page.
                No: Redirect to error page with error                   REDIRECTION_TYPE_NO_PUBLIC_ACCESS

  Back to Top       Previous  Next