The System Center Platform in Service Manager Part 3: The System Center Data Access Service
This is a continuation of the ‘The System Center Platform in Service Manager’ series. Previous posts:
“What?”, you say. “I thought you were going to write about the “SDK Service” next!? What is this ‘Data Access Service’?”
I’m pleased to announce that we are finally renaming the “Operations Manager SDK Service” to the “System Center Data Access Service”. This is significant for two reasons:
1) You can see that the name has changed from ‘Operations Manager…’ to ‘System Center…’ indicating the shared nature of this part of the common platform across multiple System Center products including Service Manager now.
2) You can see that the name has changed from ‘… SDK Service’ to ‘… Data Access Service’ which is really a much more accurate name for what this service does. This service is not a ‘SDK’ in the sense most people are familiar with – see definition.
The other services in the common platform you may be familiar with have also changed names. Starting in Operations Manager 2007 R2, Essentials “v2”, and Service Manager 2010 you will see the following names for these Windows services:
· Operations Manager SDK –> System Center Data Access
· Operations Manager Configuration –> System Center Management Configuration
· Operations Manager Health –> System Center Management
The name change is significant, but it doesn’t change what the Data Access Service does, so let’s get into that.
At a high level, the Data Access Service is the “middle-tier” application server for the System Center common platform. Unlike typical line of business application middle-tier servers, there is not a lot of “business logic” in the Data Access Service because it is intended to be a platform that can be used in many different scenarios. The Data Access Service is a single point through which all interaction happens between clients (console, connectors, automated procedures, PowerShell, etc.) and a common platform model-based database such as the ServiceManager database.
As you may have guessed from the picture above, the Data Access Service is a Windows Service that has a Windows Communication Foundation (WCF) interface which exposes the programmatic web service APIs for the common platform. The Data Access Service is installed as one component of what we call a ‘Management Server’. We’ll get into more about the other component of the Management Server in future posts.
The security infrastructure is effectively a part of the Data Access Service. All interaction with a model-based database such as ServiceManager goes through the Data Access Service which authenticates and authorizes users using Authorization Manager.
The Data Access Service actually goes through another layer we call the ‘Data Access Layer’ (DAL) to get to the database itself. The Data Access Layer is really just a set of DLLs that are only internally used by the other components of the common platform and is not really interesting to take a look at from a customer/partner perspective.
The Data Access Service accesses the Service Manager database over ADO.Net (default port: 1433) using the security context the Data Access Service Windows service is configured to run as. For example, here the Data Access Service is configured to run as WOODGROVE\SvcMgrDataAccess.
This account must be added to the ServiceManager database in the sdk_users database role in SQL Server. This is the account you are prompted for in setup when it asks you for a service account. Setup will automatically take care of creating the Data Access Service and configuring it to use that account as well as grant that account the permissions necessary (sdk_users) on the database.
You can run the Data Access Service as Local System or a domain account. Using Local System gives you the advantage of not maintaining the password as it expires periodically. This is especially effective if your Data Access Service and ServiceManager database are on the same server. If the Data Access Service and the ServiceManager database are on different servers you will probably want to use a domain account. You can use LocalSystem when the Data Access Service and ServiceManager databases are on different servers, but if you do you will need to set a Service Principal Name (SPN )(see product documentation).
Now the architecture diagram begins to unfold. Here is where we are now:
Please see the following team member blogs for additional information on the Data Access Service:
Jakub Oleksy (Senior Developer Lead for Data Access Service)
Jim Truher (Senior Program Manager for Data Access Service)
Ready to try using the Data Access Service?