Making Sense of SharePoint Portal Server Architecture

Microsoft SharePoint PortalServer builds on WindowsSharePoint Services' abilityto create team sites by letting you construct a central portal that comprisesseveral different types of sites, linksthe individual team sites, and letsusers share information across them.If you're responsible for implementingand administering your organization'sSharePoint Portal Server project, toensure the project's success you'llneed to be familiar with SharePointessentials: the basic architecture of aSharePoint portal, SharePoint portalarea permissions, portal listings, WebParts, and how to manage the information that's shared through the portal. I'll start here by explaining keyaspects of SharePoint's portal architecture—in particular, portal listingsand how you can use them to flattenyour SharePoint site's navigationstructure and aggregate and displayinformation consistently across portalareas. Then, in the upcoming part twoof this article, I'll delve into moredetail about the visual elements ofSharePoint, such as Web Parts, andhow to use them to build a SharePointsite's UI. (If you're just beginning theplanning phase of your portal, see thesidebar "Planning Your SharePointPortal," for some planningguidelines.)

SharePoint Architecture
If you're new to SharePoint PortalServer portal design, you'll need toknow the following key terms.

Site. A SharePoint site is a Web sitethat's enabled by SharePoint WebParts and Windows ASP.NET–basedcomponents and contains collaborative content (e.g., documents, discussion groups) for a team. (For more information about SharePoint sites,see the sidebar "Types of SharePointSites" in "Making Sense of SharePointSearch," September 2006, InstantDocID 50623.)

Portal area. A portal area is generally a special type of one-page, self-contained site that SharePoint PortalServer controls. Multiple portal areascomprise a site. Portal areas are created in a manner that will produce ahierarchical navigation structure (i.e.,by using a taxonomy). Generally, administrators and subject matter expertscreate portal areas. So, for example,the administrator might create a top-level portal area for the HR department, then permit a named individualin HR to create subareas such as Compensation, Vacation, and Procedures.

Each portal area contains variousinformation containers, such as document libraries, lists, and portal listings, which are geared toward theusers of that portal area. An individualportal area can maintain only oneportal-listing list. (I discuss lists andlistings in more detail in the PortalListings section.) You can target a portal area to specific audiences (an audience is a custom group who can viewspecific content targeted to thatgroup) who will view the content inthat area and set permissions to limitportal-area access to certain users.You can also designate a portal area ashidden from navigation (regardless ofthe permission settings for that area)as well as whether or not it—and itscontent—are searchable.

In addition to serving as a site thatincludes the information containersmentioned earlier, a SharePoint PortalServer portal area can itself be aninformation container. By placing aContent Editor Web Part on a portalarea, you enable that area to becomean information container. (I'll discussWeb Parts and other visual elementsin SharePoint in part two of this article.)

Document libraries and lists. Ifyou've worked with Windows SharePoint Services, you should be familiarwith document libraries and lists.Document libraries and lists are thefoundation for maintaining information, such as Microsoft Office files, links,contacts, events, issues, and tasks, ona SharePoint site. A document librarycontains a collection of documentsshared with SharePoint site members.A list is an element of a SharePoint sitethat contains a collection of items thataren't documents, such as contacts ortasks. (For more information aboutdocument libraries, see "Office 2003 andSharePoint: Better Together," December 2004, InstantDoc ID 44156.) Listsare a powerful component of SharePoint and include many features formaintaining fields in a list, such astext, Rich Text Format (RTF), drop-down lists, lookups from other lists,and calculations (e.g., sum, total).

Portal-Area Permissions
Permissions for SharePoint PortalServer and its associated content areless granular than permissions in Windows SharePoint Services. The granularity of permissions derives from themanner in which Microsoft designedeach product to be used. WindowsSharePoint Services is designed as asecure collaborative environment formanaging "work in progress." SharePoint Portal Server is designed tomanage published content and providea single UI containing a holistic viewof aggregate information specific tothe current user's need—that is, aportal. Portal users have an unlimitedview of and access to the portal area,whereas on a Windows SharePointServices team site, only team members can access the site.

In SharePoint Portal Server, youdefine portal-area permissions for theportal area itself, and all content associated with that area assumes thesame permissions. You set portal-areapermissions via the standard ManageUsers option that's available for anyadministrator of a team site or portalarea. You can't set specific permissionson a document library or list as youcan in Windows SharePoint Services.

Permissions are an important consideration when designing your information structures and determiningwhere they will be physically located.Because permissions are at the portal-area level, you need to be carefulwhen deciding what content goes intowhat portal area, since anyone whohas write access to the portal area willhave write access to all content in thatportal area. Therefore, you might wantto look at your content and group ittogether by access permission—forexample, a portal area for all contentthat's readable and a portal area forcontent that's writeable.

You might be tempted to try to circumvent SharePoint Portal Serverpermissions. For example, some SharePoint administrators have used anunsupported technique published onthe Internet that lets you manage thepermissions of a specific documentlibrary or list within a portal area—that is, it lets you give a list a different set of permissions than those of theportal area. I strongly recommendthat you avoid such unorthodox solutions because they can have unpredictable results and Microsoft doesn'tsupport them.

Portal Listings
Portal listings are available only inSharePoint Portal Server, so you mightnot be familiar with them if you'renew to the product. A portal listing issimply a special type of list that'savailable only on a portal area. Portallistings are a vehicle for displayinginformation inside a portal area, suchas a piece of news. Listings are at thecore of information aggregation; theyreduce data-entry duplications andprovide a consistent presentationlayer for your users. Portal listingsinclude the following features:

As I mentioned, portal listings let youtarget a specific audience for eachitem in a listing. When you add a newportal listing to the portal area, you needto choose the audience(s) to target. Beaware that an audience's main purpose is to filter items only; an audienceisn't equivalent to security permissions.

For each portal-listing item thatyou create, you can either referencean existing document reference (i.e.,by a URL pointing to the document'slocation) or enter the RTF document itself. SharePoint Portal Server searchwill index only the portal-listing information, not any document reference.(For in-depth information aboutSharePoint's search capabilities, see"Making Sense of SharePoint Search,"September 2006, InstantDoc ID50623.) When you add a new portal-listing item to the portal area and yourintent is to reference a document, it'sa good practice to enter a descriptionof that reference. Note that searchresults don't honor audiences.

Unfortunately, portal-listing itemsare more difficult to remove from aportal area than to add to it. Forexample, when you create a new Windows SharePoint Services site, youhave the option to create any numberof portal-listing items in any portalarea you have permissions to. If theWindows SharePoint Services sitecontaining these portal-listing items isdeleted, the portal listings aren't automatically removed; you need to deletethem manually. This situation appliesto all portal-listing items that use areference. If the reference is no longervalid, the portal listing item isn't automatically removed.

Moving On
As you've seen, SharePoint PortalServer incorporates the basic elements of Windows SharePoint Services within the larger framework of aportal area. Becoming familiar withthe concepts of portal areas, portalpermissions, and portal listings willhelp you take your first steps in planning and putting together a SharePoint portal for your organization.You'll also need to get a handle onSharePoint Portal Server visual elements, such as Web Parts, and theessentials of developing a navigationalstructure—which I'll cover in my nextarticle.