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 DLLs which is 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 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 and 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 Studio already provides a set of generic contracts that can be used to represent a variety of sensors and actuators ranging 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 that implements 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).

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. This has the advantage 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 case, 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 case where a generic contract provides basic functionality that can be consumed broadly 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.

Finally, a service can be implemented as a 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 otherwise 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 as 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 and one service representing the actual data flowing in and out of the database.