A service contract is a condensed description of a service that describes its behavior so that other services can compose and reuse services with a given contract. The contract of a service can be inspected using the DSS Contract Information Tool (DssInfo.exe).

Contracts are used to generate DSS proxy  Dynamic Link Library[ies] (DLLs). These are what service implementations link against rather than linking directly with other service implementations. This ensures that a service implementation can be modified without having to change other service implementations referencing the modified service. Provided of course, that the service contract remains the same.

Services should always link to the service proxy DLL generated based on the service contract rather than the service implementation DLL.

The ServiceDeclaration assembly level attribute, by default present in the AssemblyInfo source file in a service project, (see DSS Service Projects Overview) is used to indicate that an assembly contains one or more DSS services. It can also be used to control how a DSS proxy is generated based on that assembly.

Generic Service Contracts

Generic service contracts are service contracts that do not have an associated service implementation in the same assembly. Microsoft Robotics Developer Studio already provides a set of generic contracts that can be used to represent a variety of sensors and actuators. These range from analog sensors, batteries, sonars, encoders, and motors, to differential drive services.

Example: Service Tutorial 8 (C#) - Generic Service Declaration demonstrates how to define a generic service contract.

Service Contract Implementations

Service contract implementations contain the actual code implementing the behavior of a service. It typically contains initialization of the service state, operations port, and partners, as well as message handlers dealing with incoming messages. See Accessing DSS Services through a Web Browser and Accessing DSS Services through DSSP for more detail.

Example: Service Tutorial 1 (C#) - Creating a Service provides a very basic example of a service implementation.

Rather than defining their own service contracts in terms of service state and operations, service implementations can implement generic service contracts. The advantage is that consumers of generic contracts do not have to worry about the different service implementations as they all have the same service state and behavior as defined by the generic contract.

Example: Service Tutorial 9 (C#) - Implementing and Extending Service Contracts demonstrates how to implement a generic service contract.

In some cases, a service implementation may want to extend the definition of a generic service in order to provide additional functionality while still supporting the generic contract. This is particularly useful in cases where a generic contract provides basic functionality that can be broadly consumed, but services that want to take advantage of more complex functionality can use the extended service contract.

Example: Service Tutorial 9 (C#) - Implementing and Extending Service Contracts demonstrates how to extend a generic service contract.

A service can be implemented as if it contained multiple related but independent service instances operating completely side-by-side. Even though the services from the outside are completely independent they may both manage a shared resource or require a high degree of interconnectedness. When designing multi-headed services, it is always important to carefully evaluate whether a multi-headed service is better implemented as separate services. The consideration is whether it may provide more flexibility for future revisions.

Example: Service Tutorial 9 (C#) - Implementing and Extending Service Contracts demonstrates how to implement a multi-headed service.

Another example of a multi-headed service is the SQL sample, SQL: Storing, Retrieving, and Manipulating Data in a SQL server. which has one service representing the database in terms of connectivity and views. Plus one service representing the actual data flowing in and out of the database.