In A short introduction to Web Services we saw that one of the important parts of the Web Services architecture is service discovery, which allows us to find out the URI of a Web Service which meets our requirements. We mentioned one example: we might need a Web Service that is capable of giving us the temperature in US cities. We saw that a UDDI registry would help us find those Web Services, but there was something we didn't mention: How exactly does a Web Service advertise what kind of services it offers? Your first guess might be WSDL, since it is the description language of the Web Services architecture. However, WSDL is too 'technical'. It is concerned with details such as method invocation, protocols, etc. We need something which is easier to classify and index. This is what we can achieve with Service Data. Although Service Data can be handled in different ways in standard Web Services, in this section we will only see the solution proposed in the OGSI specification (i.e. in Grid Services).
Service Data is a structured collection of information that is associated to a Grid Service. This information must be easy to query, so Grid Services can be classified and indexed according to their characteristics. For example, we might have a client that needs to use a MathService to perform a mind-boggling calculation. We might have many different MathServices in our organization, and the client needs to know which one can satisfy its needs.
The client can choose thanks to the Service Data associated to each MathService. If the client needs the most powerful service, without any consideration to how much it will cost, then it will probably choose the mainframe. If the decisive factor is cost, then Server A will probably be the best choice. However, if the client wants to do some sort of statistic analysis, then Server C is the best bet. Of course, this is an over-simplification: usually the client won't implement some complicated algorithm to query Service Data and choose a service. It will probably delegate that task on an index service, which will make the decision based on multiple criteria: speed, cost, availability, etc. The criteria are usually specific to each particular problem; in the 'US city temperature' example, the criteria might be 'number of cities available', 'availability of temperature, humidity, pressure, etc.', 'frequency of updates', etc.
Summing up, Service Data is an essential part of service discovery. However, we will also see in the next section that Service Data and notifications are closely related.