Excel Services - Architecture

Excel Services is built on the SharePoint products and technologies platform. There are three core components of Excel Services:

1. Excel Calculation Service
2. Excel Web Access
3. Excel Web Service

Here is what each of these components do.

• Excel Web Access – This is a web-part in SharePoint that performs the “rendering” (development team speak for “creating the HTML”) of Excel Workbooks on a web page. This is perhaps the most visible component for the end user. For those of you familiar with SharePoint, you can use it like any other web part in SharePoint to create a wide range of web pages.

• Excel Web Services – This component provides the programmatic access that I talked about yesterday. It is a web service hosted in SharePoint. You can use methods in this web service to develop applications that incorporate calculations done by Excel Services and to automate the update of Excel spreadsheets.

• Excel Calculation Service – This is the component that loads the spreadsheets, calculates them, refreshes external data, and maintains session state for interactivity. This is the heart of Excel Services.

Additionally, there is also a proxy that is used internally to handle the communication between the components on the web front end and the application server in multiple-server configurations. It also handles the load balancing in case there are multiple application servers in your installation.

These three components are divided in two major groups – those that live on a front-end server (which we refer to as a “web front end”), and those that live on a back-end application server. In the simplest of the configurations, all these components could be running on the same machine (we call this a “single box” installation). In a typical production environment with significant number of users, the components on the web front end and the application server would be on different machines. It is possible to scale (up or out) these components independently.

Security

Excel Services leverages the security infrastructure provided by SharePoint. Excel services uses SharePoint for authentication (who can log into the server) as well as authorization (who has access to which spreadsheet and the type of access; read, write, view only etc.). This provides a robust security environment for protecting your spreadsheets.

Performance and Scalability

Excel Services are optimized for scenarios in which multiple users access the same spreadsheets. We have done a lot of work to optimize for this scenario – for example, caching at multiple levels so that collective performance for a group of users is improved by caching spreadsheets as well as external data queried by the spreadsheets. All this is transparent to the end user except for the good response time. (Anticipating a question, we only share cached results between users that have the same rights.)

Excel Services can be scaled up by adding additional CPUs or memory to the server it runs on. It will take full advantage of multiple CPUs to handle multiple requests concurrently. It also supports 64bit CPUs. And it is possible to scale out the web front end and application server components independently, so you can adjust either based on server load and performance requirements. For example, if there is a bottleneck in rendering spreadsheets with Excel Web Access, then you can add more web front ends, and if there is a bottleneck is in calculations, then you can add more application servers to the farm. A lot will depend on the type, size of the workbooks and external data connections in the workbooks you are planning to use with Excel Services. For large deployments, some planning will need to go into the number of users as well as the anticipated workbook mix for the installation. The architecture is designed to meet the needs of a spectrum of deployments from a departmental to enterprise. The multi-tiered approach also allows for better security and isolation of services, for example in extranet scenarios.