Share via

  • Article

Project Server 2010 architecture

 

Applies to: Project Server 2010

Topic Last Modified: 2011-08-05

Microsoft Project Server 2010 is a true multi-tiered system that extends the architecture introduced in Microsoft Office Project Server 2007. The Project Server architecture includes Microsoft Project Professional 2010 and Microsoft 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 article contains the following sections:

  • General architecture

  • Web servers

  • Project Server Interface (PSI)

  • Business objects

  • Data Access Layer and databases

  • Publishing and server-side scheduling

General architecture

The main differences in general architecture between Project Server 2010 and Office Project Server 2007 are as follows:

  • Project Server 2010 requires Microsoft SharePoint Server 2010 Enterprise as an installation requirement. Similar to Microsoft Office Project Server 2007 farm deployment, when you are deploying Project Server 2010 to a farm, Project Server 2010 has to be installed on all application servers and all Web servers within the 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, instead of with a Microsoft Outlook add-in.

The figure that follows shows a generalized view of the Project Server 2010 architecture. It includes a Web server and a Project Web App instance on Project Server. As in Office Project Server 2007, there can be multiple instances of Project Web App running on one server.

Project Server 2010 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 the architecture graphic 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.

  • The architecture graphic does not show that the Web 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 (not shown in the architecture graphic). 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 Office Project Server 2007.

The front-end tier includes third-party applications, Microsoft 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 the architecture graphic).

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 SharePoint shared service URL to 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 has 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 on. 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 almost 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 Microsoft 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.

Web servers

You can install one or more Web servers within a corporate intranet to allow load distribution for intranet clients. When a client application uses a separate Web 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 Microsoft Project Professional to reduce round-trip 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 (PSI)

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 way 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.

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 several different tables. The DAL encapsulates the work that is 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 Microsoft 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 almost in real time. The tables and views are optimized for read-only report generation; for example, the RDB tables are de-normalized 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 Microsoft Project Professional, applies the changes, and then saves and publishes the project to make the changes available to everyone. The scheduling engine in Microsoft 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, by 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 occurs:

    1. Microsoft Project Professional opens the project.

    2. Microsoft 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.

Warning

There are some limitations and differences between the Project Server scheduling engine and the Microsoft 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 (https://go.microsoft.com/fwlink/p/?LinkId=191606) in the MSDN Library Online.