Beta 1 kept us quite busy last week so it ended up being a slow blog week. With the weather back to normal in Seattle (cloudy, wet, cool) and Beta 1 almost ready, I have a bit of time to talk about one of the biggest changes in P12 = the Project Cache.
A short detour into history: Project introduced the ability to save to database way back in Project 98. Project used ODBC to handle read/write to db. Lots of folks leveraged this functionality to build EPM solutions. In 2000, we opted to leverage this functionality to build the Project 2002 EPM solution. Project Professional called a set of web services on Project Server to authenticate the user and create a connection (and a set of SQL views) between Project Pro and SQL Server. Once this connection was established, Project Pro 2002 communicated with SQL Server in largely the same way that Project 98 communicated to SQL Server.
This design works fine in a LAN where latency is minimal (generally in the 5 - 10ms range), pipes are big (10Mb and up) and connections are reliable. In WAN scenarios, conditions change. Latency can be indeterminate; for example, if you are using a VPN across the Internet. Even on leased lines, WAN latency is often above 50ms. Pipes range from small to OK (256K - 5Mb). Connections can be sketchy. As many of you know, customers have typically deploying Windows Terminal Services to support Project Pro users who need to connect to Project Server over a WAN.
With P12, we wanted to enable project managers to have a great rich client experience from any location. This required us to rethink how Project Pro interacted with Project Server. We assumed the following: (1) network connections drop and the I/O between Pro and Server needed to be resilient to drops in connections, (2) WAN pipes have lots of latency and limited bandwidth so I/O needed to be as efficient as possible, and (3) users should be able to largely ignore the state of their network connection = things should just work w/o user intervention.
Project 12 introduces a new client-side cache and caching service. Project Pro interacts directly with the local cache for opens and saves. The caching service then handles moving the changes between the client and Project Server. Project Pro 12 never communicates directly with SQL Server. The caching service interacts with the Project Server using SOAP calls made to the Project Server Interface (PSI) web service = calls are made only through port 80. The PSI then serializes the data to SQL Server.
The caching service works based on differences and is asynchronous. When a project manager makes a change to a project and closes Project Pro, the project is saved to the local file system and a set of messages are created for the caching service based on the differences made to the project. These messages are then sent to Project Server. The project manager does not need to wait for the messages to be sent before moving onto other work. The caching service works in the background.
The caching service works closely with the Project Server queue. A project save may result in several messages being sent to Project Server. A "valid" project save requires all of these correlated messages/jobs to be successfully processed. The Project Server queue tracks the processing of the correlated jobs. Once all of the jobs in the same correlation are successfully processed, Project Server communicates with the client which allows the caching service to release the messages. By transacting the cache messages and saving projects 1st to a local cache, Project Pro I/O is highly resilient to low quality network connections.
These services also work with centralized data. For example, changes to custom field look-up tables or enterprise resources are moved from the server to the client in the background. Users can now boot Project Pro and connect to Project Server and get started working immediately. Updates are sent to the client in the background.
The user experience is simple, especially once you have opened projects once. Users interact with their local cache for opens and saves. Their cache is refreshed from the server whenever they are able to connect to Project Server. Projects save quicky to the local cache and project managers can control when to push the updates to Project Server. Project is only locked while it saves a project to the local file system.
The IT Professional experience is equally simple. Terminal Services are no longer needed to support remote Pro users. Pro I/O is transacted and highly reliable (= no lost plans based on someone accidentally closing their laptop in the middle of a save).
In our early performance testing, Project Pro 12 I/O is significantly faster than Project 2003 EVEN when Pro is opening a project for the 1st time. Perceived performance is then as fast as saving to the local file system.
We think that the Project Cache (final naming is TBD) changes the rules of the game. It allows users to have a rich client user experience + the "mobility" advantages of saving to a local file system (try that with a thin client!) with the relatively light network footprint of a web application. Customers no longer need to choose between a great user experience and a low network footprint. You can have both with P12.