Putting the .NET Portal Together

Clearly, a full-featured portal provides a wide range of functionality to its users. What is not as obvious is the complexity of the underlying solution. Microsoft has not attempted to pack all the tools you may need into a single product. Based on the results of the portal solution requirements table, we can determine which Microsoft Server components are needed for our portal, as shown in Table 2.4. I omitted .NET, Visual Studio, and Windows Server from this table because they are required for all the portal solutions discussed in this book.

Table 2.4. Portal Elements and Microsoft Server Products

	CMS	SQL Server	SPS	WSS	Commerce	BizTalk	Active Directory
Look-and-feel	X	X
Security		X					X
User profile		X					X
Personalization		X			X		X
Taxonomy and dynamic navigation	X
Application integration						X
Database repository		X
Support for transactions		X				X
Collaboration tools			X	X
Multichannel support	X	X
Search engine			X

The priorities you assign to these portal elements are up to you. My clients have pointed toward common priorities for external and enterprise portals. The external portal places the highest priority on managing a large volume of HTML web content and creating a consistent and pleasing look-and-feel. Anonymous users are the most important customers, and solutions must be simple to use and support low bandwidth and multiple browser versions. Content management is therefore the top goal, which makes Microsoft Content Management Server the center of the portal effort. A taxonomy and search engine are also requirements for this type of portal.

The next priority for a public portal is usually a commerce system. For a retailer, this means an electronic storefront with a catalog, shopping cart, and order fulfillment. For an association, the electronic store might also offer free publications and registration for public events. Government agencies would use the e-commerce capability to support transactions such as tax payments, parking tickets, and permit applications.

The low priorities for the public portal are collaborative tools, such as virtual communities, document management, knowledge management, and line-of-business application integration, as well as support for multiple hardware platforms. All these may ultimately make it into the portal to some extent, but they are usually reserved for subsequent versions.

The priorities for an enterprise portal are quite different. The infrastructure for an enterprise portal is known; you may be able to assume standard hardware and software for each user, high bandwidth, and solid connectivity. You can interview users in person and grill them on their needs, as well as observe how they work.

The enterprise portal starts at the desktop of the knowledge worker. You will not shy from the expense or the training burden of a sophisticated new solution if it will produce return on investment from your employees . This equation is in stark contrast to the least-common-denominator approach you must take with anonymous web users.

The highest priorities are usually integration of line-of-business applications and collaboration. SharePoint Portal Server is a key part of the enterprise portal, although MCMS may be just as important. SharePoint provides document management, threaded discussions, and the advanced search engine for knowledge management solutions. The .NET platform provides a host of tools to make application integration easier. Chapter 4 explains how web services work, and they are the key to application integration, along with standardization on XML for all applications.

To understand how technologies and products fit the portal roadmap, we need to take a broader view of the Microsoft .NET portal platform (see Chapter 3). Then we will take each of the portal elements one at a time and show how it is implemented with .NET and the Microsoft platform. Along the way I will offer suggestions on successful approaches to portal development and share best practices.