Clients (Analysis Services - Multidimensional Data)
Microsoft SQL Server Analysis Services supports a thin-client architecture. The Analysis Services calculation engine is entirely server-based, so all queries are resolved on the server. As a result, only a single round trip between the client and the server is required for each query, resulting in scalable performance as queries increase in complexity.
The native protocol for Analysis Services is XML for Analysis (XML/A). Analysis Services provides several data access interfaces for client applications, but all of these components communicate with an instance of Analysis Services using XML for Analysis.
Several different providers are provided with Analysis Services to support different programming languages. A provider communicates with an Analysis Services server by sending and receiving XML for Analysis in SOAP packets over TCP/IP or over HTTP through Internet Information Services (IIS). An HTTP connection uses a COM object instantiated by IIS, called a data pump, which acts as a conduit for Analysis Services data. The data pump does not examine the underlying data contained in the HTTP stream in any way, nor are any of the underlying data structures available to any of the code in the data library itself.
Win32 client applications can connect to an Analysis Services server using OLE DB for OLAP interfaces or the Microsoft® ActiveX® Data Objects (ADO) object model for Component Object Model (COM) automation languages, such as Microsoft Visual Basic®. Applications coded with .NET languages can connect to an Analysis Services server using ADOMD.NET.
Existing applications can communicate with Analysis Services without modification simply by using one of the Analysis Services providers.
Data Access Interface
OLE DB for OLAP
Visual Basic 6
Any language that supports SOAP
XML for Analysis
Analysis Services has a Web architecture with a fully scalable middle tier for deployment by both small and large organizations. Analysis Services provides broad middle tier support for Web services. ASP applications are supported by OLE DB for OLAP and ADO MD, ASP.NET applications are supported by ADOMD.NET. The middle tier, illustrated in the following figure, is scalable to many concurrent users.
Both client and middle tier applications can communicate directly with Analysis Services without using a provider. Client and middle tier applications may send XML for Analysis in SOAP packets over TCP/IP, HTTP, or HTTPS. The client may be coded using any language that supports SOAP. Communication in this case is most easily managed by Internet Information Services (IIS) using HTTP, although a direct connection to the server using TCP/IP may also be coded. This is the thinnest possible client solution for Analysis Services.
In SQL Server 2008 R2, the VertiPaq storage engine is used for in-memory multidimensional databases within Excel workbooks, including PowerPivot workbooks that have been published to a SharePoint site.
PowerPivot for Excel is the only client that is supported for creating and querying in-memory databases that use VertiPaq mode. The multidimensional database that you create by using the Excel and PowerPivot tools is contained within the Excel workbook, and is saved as part of the Excel .xlsx file.
You cannot access the VertiPaq storage engine by using traditional SSAS clients and tools.
However, a PowerPivot workbook can use data that is stored in a traditional cube if you import the cube data into the workbook. You can also import data from another PowerPivot workbook if it has been published to a SharePoint site.
When you use a cube as a data source for a PowerPivot workbook, the data that you get from the cube is defined as an MDX query; however, the data is imported as a flattened snapshot. You cannot interactively work with the data or refresh the data from the cube.
For more information about using an SSAS cube as a data source, see the PowerPivot for Excel.
Interfaces for PowerPivot Client
PowerPivot interacts with the VertiPaq storage engine within the workbook by using the established interfaces and languages for Analysis Services: AMO and ADOMD.NET, and MDX and XMLA. Within the add-in, measures are defined by using a formula language similar to Excel, Data Analysis Expressions (DAX). DAX expressions are embedded within the XMLA messages that are sent to the in-process server. For more information, see Data Analysis Expressions and MDX.
Communications between PowerPivot and Excel use the MSOLAP OLEDB provider (version 10.5). Within the MSOLAP provider, there are four different modules, or transports, that can be used for sending messages between the client and server.
TCP/IP Used for normal client-server connections.
HTTP Used for HTTP connections via the SSAS data pump service, or by a call to the SharePoint PowerPivot Web Service (WS) component.
INPROC Used for connections to the in-process engine.
CHANNEL Reserved for communications with the PowerPivot System Service in the SharePoint farm. For more information about the components needed to work with PowerPivot in a Sharepoint installation, see Planning and Architecture (PowerPivot for SharePoint).