Condividi tramite

Project Server 2010 Architecture

  • Articolo

Applies to: Office 2010 | Project 2010 | Project Server 2010 | SharePoint Server 2010

Microsoft Project Server 2010 is a true multitiered system that extends the architecture introduced in Microsoft Office Project Server 2007. The Project Server architecture includes Microsoft Project Professional 2010 and Project Web App clients in the front-end tier. The front-end applications communicate with the middle tier only through the Project Server Interface (PSI) Web services, which in turn communicate with the business object layer. Business objects use the databases through the data access layer (DAL). Client applications do not directly access the primary databases; Project Server hides business objects and the DAL from clients.

This topic includes the following sections:

  • General Architecture

  • Project Web App Server

  • Business Objects

  • Data Access Layer and Databases

  • Publishing and Server-Side Scheduling

General Architecture

The major differences between Project Server 2010 and Office Project Server 2007 are the following:

  • Project Server 2010 requires Microsoft SharePoint Server 2010 Enterprise version to be installed on the computer running Project Server and on all Project Web App servers within a SharePoint farm.

  • The PSI includes both the Windows Communication Foundation (WCF) interface and the ASMX interface for Web services.

  • The Project Server workflow platform is integrated in the PSI, business object layer, and DAL, and built on Windows Workflow Foundation (WF) in the SharePoint platform.

  • Project Server task, assignment, and assignment status data is integrated with Microsoft Exchange Server (not shown in Figure 1), instead of with a Microsoft Outlook add-in.

Figure 1 shows a generalized view of the Project Server 2010 architecture, including an optional Project Web App front-end server and a Project Web App instance on Project Server. As in Project Server 2007, there can be multiple instances of Project Web App running on one server.

Figure 1. General Project Server architecture

Project Server architecture

Note

  • In Project Server 2010, you can use the WCF or the ASMX interface of the PSI. The Project Web App and Project Professional 2010 clients both use the WCF interface.

  • The PSI Forwarder in Figure 1 consists of two components, a WCF Forwarder and a Web Service Forwarder. Clients that use the ASMX interface call the PSI through the Web Service Forwarder. Clients that use the WCF interface call the PSI through the WCF Forwarder.

  • Figure 1 does not show that a Project Web App server can be isolated by an additional firewall in a perimeter network (also known as a "demilitarized zone" or DMZ).

  • The SharePoint Web Services site is part of SharePoint Server 2010 and is not shown in Figure 1. The SharePoint Web Services site includes the Project Service Application with the PSI virtual directory for the ASMX and WCF services. The Project Service Application in Project Server 2010 replaces the Shared Services Application in Project Server 2007.

The front-end tier includes third-party applications, Project Professional, and Project Web App. Project Web App uses Internet Explorer to display Microsoft ASP.NET 3.5 pages. The Project Web App pages use Project Server Web Parts that communicate with the PSI and also use standard SharePoint Server 2010 Web Parts.

Client applications on separate computers call the PSI through service proxies. External clients that use the WCF interface access the PSI through https://ServerName/ProjectServerName/_vti_bin/psi/ProjectServer.svc. Clients that use the ASMX Web service interface use one of the Project Web App URLs, such as http://server1/pwa/_vti_bin/psi/project.asmx. If applications do not have intranet access to Project Server, they can use a Project Web App server in a perimeter network (not shown in Figure 1).

If they can directly access the Project Server computer, client applications and back-end components of line-of-business (LOB) Web applications can use PSI proxies that use the Project Server service application URL for the PSI Web services, such as http://server1:32843/ProjectServiceApplication/project.asmx. Port 32843 is the default port for the SharePoint Web Services application in SharePoint Server 2010. Direct access to the Project Service Application virtual directory should be used only when an application needs to use impersonation or run with elevated permissions.

The middle tier includes the PSI and the business logic layer, which consists of logical business objects that represent Project Server business entities. Business objects include Project, Task, Resource, Assignment, and so forth. The PSI and the business logic tier are tightly coupled and are located on the same server. A client application calls the PSI Web services, and the PSI invokes business objects in the business logic tier.

The DAL provides communication between the middle tier and the database. All Project Server data is stored in Microsoft SQL Server databases. The Project Server databases are factored into the following stores: Draft, Published, Archive, and Reporting. Client applications can read the Reporting database for project data. Clients should use only the PSI to access the Draft, Published, or Archive databases. The Reporting Data Service (RDS, which is not shown in Figure 1) updates the Reporting database from published data in nearly real time. In Project Server 2010, all of the Project Server databases can be located on separate servers.

The Project Web App components of Project Server also use the SharePoint Foundation 2010 configuration database for project site setup and the content database for project site content such as custom pages, workflows, management settings, documents, and lists of issues, risks, and commitments. The SharePoint configuration and content databases support additional features for project management, such as project templates and workspaces, custom lists for team collaboration, and reports.

Project Web App Server

You can install one or more Project Web App servers within a corporate intranet to allow load distribution for intranet clients. When a client application uses a separate Project Web App server, PSI calls are routed through a PSI Forwarder to the PSI Web services on the Project Server computer. The PSI Forwarder (either the WCF Forwarder or the Web Service Forwarder) performs the following functions:

  • Optimizes calls to the PSI from remote clients.

  • Includes a server-based cache that works with the client-side active cache in Project Professional to reduce roundtrip calls to Project Server.

After a user receives an authentication cookie from Project Server, the PSI Forwarder transparently sends requests to the PSI Web services on the Project Server computer. The PSI Forwarder improves performance and reliability over both the LAN and a WAN.

Project Web App is developed with ASP.NET 3.5. The visual elements in .aspx files (HTML, server controls, and static text) are separate from the programming logic in code-behind classes that are in compiled assemblies (.dll files). Site pages in Project Web App, such as the top-level page, Project Center, and Report Center, can be customized by using Web Parts. Application pages that do not have an Edit Page option in the Site Actions menu cannot be edited, such as the Server Settings page and Review Timesheet page.

Project Server Interface

The PSI is the API of Project Server. The PSI object model exposes Project Server functionality to all external applications. Project Professional 2010, Project Web App, LOB, and other third-party applications use the PSI to access Project Server data in the Draft, Published, and Archive databases. The PSI is available through WCF services and through ASMX Web service calls by back-end LOB applications, or through a PSI proxy.

Web methods in the PSI typically produce or consume typed DataSet objects as the means to exchange information with the business objects. The PSI reference includes DataSet documentation.

Business Objects

The internal object model of Project Server includes the business objects. Client applications access business objects only through the PSI, and only business objects can call the DAL.

Business objects are logical entities that can be classified into three types:

  • Core entities are objects such as projects, tasks, assignments, resources, and calendars. The core entities include basic business logic such as permissions and naming rules.

  • Business entities are objects such as timesheets, portfolios, and models. Business entities include additional business logic and usually are built from a combination of the core entities.

  • Support entities are objects such as security and validation.

Developers need not be directly concerned with business objects. The PSI handles mapping of the API to business objects.

Data Access Layer and Databases

The DAL is internal to Project Server and is not exposed to external applications. The DAL translates between the logical business entity representation of the data and the physical database tables. Each logical entity is stored in a number of different tables. The DAL encapsulates the work required to manage connections, execute queries, and begin/commit/roll back transactions.

Project Server data is partitioned into four databases in SQL Server.

  • The Draft database contains tables for saving unpublished projects from Project Professional and other applications. Project Web App does not show project data in the Draft database.

  • The Published database contains all of the published projects and enterprise resources, the enterprise global template, and other project templates. Published projects are visible in Project Web App. The Published database also contains tables that are specific to Project Web App (timesheets, models, views, and so on), and global data tables (custom fields, lookup tables, security, and metadata).

  • The Archive database saves backup versions of projects and other data.

  • The Reporting database (RDB) is the staging area for generating reports and OLAP cubes. Data in the Reporting database is comprehensive and is updated nearly in real time. The tables and views are optimized for read-only report generation; for example, the RDB tables are denormalized to provide redundant data and reduce the number of relational tables.

Entities such as Resource or Project can span multiple tables, and all tables for a particular entity have the same primary key. The primary key is a single column that uniquely identifies one instance of a particular entity. Unique identifiers are GUIDs.

Only the Reporting database schema is documented. You should access the Draft, Published, and Archive databases only through the PSI. You can add data tables, fields (properties), and entities that are not defined in the Project Server 2010 database schema to the Reporting database. If you add tables to the core databases, you must also provide the full stack of a custom assembly, Web service, business objects, and data access. You can easily modify the Reporting database; we recommend that you do not modify the core Project Server databases.

Publishing and Server-Side Scheduling

Project Server 2010 supports both manual and automated project schedule updates. The default process is to update projects manually. That is, the project manager opens the project in Project Professional, applies the changes, and then saves and publishes the project to make the changes available to everyone. The scheduling engine in Project Professional calculates scheduling changes for manual updates.

The scheduling engine in Project Server enables automated project updates by using the PSI. Project Server allows the published version of a project to be updated while a project manager is using the draft version, using the following steps:

  1. Project Server applies updates and reschedules the published version automatically.

  2. Project Server saves the update to apply to the draft version when either of the following events occur:

    • Project Professional opens the project.

    • Project Professional tries to publish the project.

  3. If there is a conflict, the project manager must resolve it before the draft version can be published.

Note

There are some limitations and differences between the Project Server scheduling engine and the Project Professional scheduling engine. For example, Project Server does not schedule subprojects or links to other projects, and does not calculate earned value fields. For more information, see the Project Scheduling on the Server section in Project Server Programmability.

See Also

Concepts

Project Server Programmability

What the PSI Does and Does Not Do

Overview of WCF and the PSI

Other Resources

Project 2010 Overview for Developers