Project Server Architecture
Microsoft Office Project Server 2007 is a true multitiered system. The Project Server architecture includes Microsoft Office Project Professional 2007 and Project Web Access 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). The business objects, DAL, and primary databases are hidden from the clients.
Figure 1 shows a generalized view of the Project Server 2007 architecture. The front-end tier includes third-party applications as well as Project Professional and Project Web Access. Project Web Access uses Internet Explorer to display Microsoft ASP.NET 2.0 pages. The Project Web Access pages use standard Windows SharePoint Services 3.0 Web Parts that communicate with the PSI.
Figure 1 does not show workflow architecture, configuration, or integration with Microsoft Office SharePoint Server 2007 or other 2007 Microsoft Office system applications.
Client applications on separate computers call the PSI through proxies to the PSI Web services. Client applications and back-end components of line-of-business (LOB) Web applications use PSI proxies to make direct calls to the PSI Web services if they can access the Project Server computer. If applications do not have direct intranet access to Project Server, they can use a Project Web Access server in a perimeter network (see Project Web Access Server).
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, which can be located on separate servers.
The Project Server databases are factored into the following stores: Draft, Published, Archive, and Reporting.
The Project Web Access components of Project Server also use the Windows SharePoint Services configuration database for project site setup and the content database for project site content such as management settings, documents, and lists of issues, risks, and commitments. The Windows SharePoint Services configuration and content data stores support additional features for project management, such as Project templates and workspaces, workflow, team collaboration, and reporting.
Project Web Access Server
Figure 2 shows a simplified view of Project Server architecture, with the addition of a separate Project Web Access server. In Figure 2, the Project Web Access server is isolated in a perimeter network (also known as a "demilitarized zone" or DMZ) that can provide a secure and efficient interface to Project Server from the Internet or an extranet. A perimeter network provides an additional firewall and serves as a buffer between the intranet and the Internet.
You can also install one or more Project Web Access servers within a corporate intranet to allow load distribution for intranet clients.
When a client application uses a separate Project Web Access server, PSI calls are routed through a PSI Forwarder to the PSI Web services on the Project Server computer. The PSI Forwarder performs the following functions:
Optimizes calls to the PSI from remote clients.
Includes a server-based active cache that works with the client-side active cache in 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 Access is developed with ASP.NET 2.0. 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). The assemblies enable easier development with IntelliSense in Microsoft Visual Studio 2005, better debugging, reduced errors, and a common extensible platform that Microsoft can support.
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 2007, Project Web Access, line of business, 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 Web service calls by back-end LOB applications, or through a PSI proxy for client applications with a user interface.
PSI methods typically produce or consume typed DataSet objects as the means to exchange information with the business objects. The PSI reference includes DataSet documentation. For more information about PSI features, see Project Server Programmability. For information about using the PSI and DataSets, see Working with the PSI and DataSets.
The internal object model of Office 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 database schema and access to Project Server 2007 data is very different from the database schema and use in Project Server 2003.
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 Access does not show project data in the Draft database.
The Published database contains all of the published projects as well as enterprise resources, the enterprise global template, and other project templates. Published projects are visible in Project Web Access. The Published database also contains tables that are specific to Project Web Access (timesheets, models, views, and so on), and global data tables (outline codes, security, and metadata).
The Archive database saves backup and older versions of projects and other data.
The Reporting database 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 Reporting tables are optimized for read-only report generation; for example, the tables are denormalized to provide redundant data and reduce the number of relational tables.
In Project Server 2007, 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 IDs 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 2007 database schema to the Reporting database. If you add tables, fields (properties), and entities that are not defined in Project Server 2007 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, but we recommend that you do not modify the core Project Server databases.
Publishing and Server-side Updates
Project Server 2007 supports both manual and automated project schedule updates. Because Project Server 2003 does not include a scheduling engine only manual schedule updates are possible. Similarly to the process in Project 2003, updating projects manually is the default process in Project 2007. 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.
However, the scheduling engine in Project Server also enables automated project updates using the PSI. Project Server allows the published version of a project to be updated while a project manager is using the draft version, as follows.
Project Server applies updates and reschedules the published version automatically.
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.
If there is a conflict, the project manager must resolve it before the draft version can be published.
There are some limitations and differences between the Project Server scheduling engine and Project Professional. For information, see Project Scheduling on the Server in Project Server Programmability.