Web Part Architecture Design

Designing Web Parts for business applications is similar to designing other distributed enterprise applications. A popular architecture for enterprise applications is the 3-tier, or n-tier, architecture. The 3-tier architecture splits services into Presentation, Business, and Data tiers. The classic 3-tier architecture is a good architecture to start with when building Web Parts for business applications that use SharePoint Portal Server. The following figure describes the three tiers.

Figure 19.1. Classic 3-tier architecture

The Presentation Tier

Web Parts render in a digital dashboard and require a Web browser on the client computer. Currently, SharePoint Portal Server supports browsers that are HTML 3.2 compliant. Web Parts are, at the risk of oversimplification, like small Web pages. Therefore, developers must address the same issues that are inherent with cross-browser compatibility, including deciding whether to use DHTML, XML, and other client-side technologies in the Web Part.

Developers should be skilled in the variety of technologies associated with traditional Web-based application design. These technologies include HTML, Microsoft JScript, and Visual Basic Scripting Edition (VBScript). To maintain a consistent look and feel among Web Parts, the digital dashboard should use common style sheets created by the user interface developer. At this stage of development, traditional tools such as Microsoft FrontPage^® and Microsoft Visual Interdev^® can assist HTML and script development.

The digital dashboard also provides a rich set of services that aid in communication and state management. Developers should plan how to take advantage of these services in order to create unique digital dashboard applications that are more than simply the sum of the individual Web Parts. The digital dashboard provides the client-side services through the Digital Dashboard Services Component (DDSC). The presentation tier developer should fully understand the DDSC to create good Web Parts that can communicate with each other.

The Digital Dashboard Services Component (DDSC)

The DDSC is a client-side component that is included in every digital dashboard page as a hidden object. Figure 19.2 illustrates the presentation tier with the DDSC component. This component makes Web Parts reusable and easier to build by providing a standard infrastructure for the following services:

• Part Discovery. Allows Web Parts to discover other Web Parts on a digital dashboard.
• Notification. Allows Web Parts to respond to external events that occur at the digital dashboard or Web Part level.
• Session state management. Allows Web Parts to interchange information and objects within a browser session.
• State management. Allows digital dashboards and Web Parts to maintain global state and to persist in this state between activations.
• Item Retrieval. Allows Web Parts to retrieve and maintain the state of items in the store module.

Figure 19.2. Presentation tier with DDSC

For more information about the DDSC and digital dashboard factory, see Appendix B.

The Business Tier

You can separate the business tier into two more logical tiers: the user-centric tier, which manages the delivery of HTML that renders in a client's browser, and the data-centric tier, which handles the complexities of accessing resources in the data tier.

Web Part properties determine how the digital dashboard renders the Web Part.

User-centric Tier

The digital dashboard factory is a code engine, implemented as an ASP page, or compiled code on the Web server. This server assembles the Web Parts into a layout suitable for rendering Web Parts in a digital dashboard. Web Parts can contain embedded content, including HTML, scripts, Microsoft ActiveX^® controls, or XML. They can also contain links pointing to any type of Web-based content in any location.

The factory also exposes a programming object model and a scripting host on the server. Services exposed by this object model include server-side object creation, querying of standard IIS server variables, and querying of factory inspection variables that expose information about the type of factory and environment in which the current part is running. Developers can use the scripting host to build rich Web Part content. Web Parts are defined as an open specification and are meant to run in a platform-independent fashion. Because of this, Web Part authors must use the factory object from the scripting host to ensure portability of the Web Parts.

In an enterprise environment with multiple browsers and devices in the field, the Web Part must detect what type of browser is requesting the data and then send the appropriate Web content for that particular platform. You can accomplish this by using script in a Web Part that queries the factory object for the type of client and then sends the appropriate content.

An effective method for dynamically formatting raw data into Web content is to use XSLT. This technique, coupled with determining the digital dashboard factory browser, allows the developer to take raw XML data, delivered from the data-centric tier, and format it into Web content that can best be viewed in the user's particular environment. By using the scripting host provided by the factory, the developer supplies the Web content by implementing a function called GetContent(). The following figure illustrates the user-centric tier.

Figure 19.3. User-centric business tier

Data-centric Tier

Using XML is the most effective technique for passing data from the data-centric tier to the user-centric tier. This gives the user-centric developer the flexibility to format the data into the appropriate Web content.

The first step for the data-centric developer is to build an XML Generator. This is a component wrapper around the application programming interface (API) for the business application. The component wrapper retrieves data and formats it into XML.

The data-centric developer may include an interface for the component that allows the Web Part builder to supply constraints to the information. Filtering and sorting the information from the business application are two examples of such constraints.

Although the work for data-centric developers appears to be relatively straightforward, they have the difficult task of programmatically accessing the data from the business application. This crucial exercise requires extensive knowledge of the business application.

Business applications are inherently intricate. Usually, the data in such applications are contained in data stores whose schema is complex. For example, a full instance of SAP R/3, with all the modules, requires a database that contains over 10,000 tables.

Given the complexity of data stores for business applications, the fact that schemas frequently change, and the fact that most of the data is locked behind a fortress-like application layer, many business application vendors provide published APIs or input/output (I/O) mechanisms for accessing the data. Because Microsoft Windows^® is prevalent in most enterprises, many of the application vendors have COM components that expose these APIs. When building Web Parts for the digital dashboard, use of these COM components is the preferred method for accessing business application data.

Because most business and legacy applications are important, the developer must have deep knowledge of the application and the API or I/O mechanism used to access the application to obtain data appropriate for the Web Part. If this is not the case, the development team should consult with experts who have such knowledge.

Figure 19.4. Data-centric business tier