On several occasions I have come across instances where people have mistakenly called the interface that a Service implements, the Service itself. The truth of the matter is that the Service can be formed by a number of interfaces (referred to as Service Contracts), each of which contain various methods (referred to as Operation Contracts) returning or receiving simple or complex data (referred to as Data Contracts). Consider the following example:
Example WeatherService
From a “traditional sense” it represents a class that implements two interfaces – now hold that thought.
Consider the same example from a Service point of view through the convention used by Thomas Erl:
Thomas Erl style Service Diagram
Two Service Contracts (ITemperature and IRainfall) are defined as follows:
///
/// ServiceContract that provides temperature information.
///
[ServiceContract]
public interface ITemperature
{
///
/// Retrieves the temperature for a specified location given the Latitude and Longitude
///
/// <param name="location">Location information for retrieving Temperature.</param>
/// Temperature of location.
[OperationContract]
double GetTemperature(Location location);
}
///
/// ServiceContract that provides rainfall information.
///
[ServiceContract]
public interface IRainfall
{
///
/// Retrieves the rainfall for a specified location given the Latitude and Longitude
///
/// <param name="location">Location for retrieving Rainfall.</param>
/// Rainfall of the given location.
[OperationContract]
double GetRainfall(Location location);
}
Where Location is the DataContract defined as:
///
/// DataContract that represents a location specified by its Latitude and Longitude.
///
[DataContract]
public class Location
{
///
/// Gets / sets the Latitude of the location.
///
[DataMember(IsRequired = true)]
public double Latitude { get; set; }
///
/// Gets / sets the Longitude of the location.
///
[DataMember(IsRequired = true)]
public double Longitude { get; set; }
}
The class that implements them, WeatherService, is defined as:
///
/// ServiceContract implementation class
///
public class WeatherService : IRainfall, ITemperature
{
///
/// Retrieves the rainfall for a specified location given the Latitude and Longitude
///
/// <param name="location">Location specific information for retrieving Rainfall.</param>
/// Rainfall of the given location.
public double GetRainfall(Location location)
{
return _GetRainfall(location.Latitude, location.Longitude);
}
///
/// Retrieves the temperature for a specified location given the Latitude and Longitude
///
/// <param name="location">Location specific information for retrieving Temperature.</param>
/// Temperature of location.
public double GetTemperature(Location location)
{
return _GetTemperature(location.Latitude, location.Longitude);
}
private double _GetTemperature(double latitude, double longitude)
{
return new Random().NextDouble();
}
private double _GetRainfall(double latitude, double longitude)
{
return new Random().NextDouble();
}
}
So now when we refer to a Service we are talking about the implementation of one or more ServiceContracts (as in the case of the Weather Service). One developer may be working on a single ServiceContract that the Service implements (such as ITemperature) but it does not necessarily mean that they are working on the whole of the Service.
