All this stuff about SDEs and structured data might seem a bit confusing, so let's take a look at a simple example. We could define two SDEs in our MathService:

An SDE can, in turn, have any number of values. Don't worry if this concept of 'value of an SDE' (or, rather, values of an SDE) is a bit confusing. We'll clear it up by looking into the two SDEs we've just defined: SystemInfo and LastResults.

The SystemInfo SDE could be used to store information about the system where MathService is running. Without looking at the exact mechanism with which we can define the structure of the SDE, we can say that the datatype of the SystemInfo SDE is a structure with the following fields:

Of course, it only makes sense to have one (and only one) of these SDEs attached to our service. Therefore, we can specify (in the GWSDL file) that this particular SDE will have a cardinality of 1..1 (minimum quantity of one, maximum quantity of one).

The LastResults SDE, on the other hand, could be used to store the last N internal values that have been stored in MathService. Since the internal value is an integer, we could simply define the datatype of the LastResults SDE as 'integer'. If we wanted to keep (for example) the last 10 values, we would define the cardinality of LastResults as 0..10 (minimum quantity of zero, maximum quantity of ten). Of course, we could've also chosen to define the datatype as 'array[10] of integer' and set the SDEs cardinality as 1..1. That would also be a possible solution, but let's stick with the 0..10 cardinality since it shows how an SDE can have more than on value.

Summing up, our MathService could look like this at a given point in its lifetime:

Notice how SystemInfo has one value (and how that single value is a complex datatype: it has three attributes) and how LastResults has four values (which is perfectly valid since the cardinality is 0..10), all with the same datatype (integer).

Finally, remember from the What is a Grid Service? page that service data generally falls into two categories: state information (operation results, intermediate results, runtime information, etc.) and service metadata (system data, supported interfaces, cost of using the service, etc.). The SystemInfo SDE would fall into the 'service metadata' category, while the LastResults SDE would fall into the 'state information' category.

Looking back at the diagram shown in the previous page (the diagram with the client that had to choose one of three servers), we could represent the information each server exposed as SDEs like this:

In this diagram, we have three MathServices. The first two services each have one MathData SDE. Notice how both SDEs contain the same type of information (MathDataType, containing speed, cost, and statistics). The third service has two SDEs: a MathData and a StatisticsData one. Notice how the StatisticsData SDE has a different type of information (StatisticsDataType, containing software version and supported clients)

Imagine our client needed a MathService to perform a calculation, and that it is imperative to perform it as quickly as possible. The client would ask each MathService for its MathData SDE, then it would look at the speed property, and then choose the service with the highest speed. If our client needed to perform statistical analysis, it would choose the third instance (the only one with the "statistics" property set to true). Then, it would ask for the StatisticsData SDE to make sure details like the software version and the supported clients are acceptable.

Again, remember that a client usually doesn't have to mess around with these kind of algorithms to decide what service is better. This task is usually handled by an index service.

Ok, you'll agree that Service Data is definitely a good idea. However, how exactly do we implement Service Data? For example, should we simply add 'speed', 'cost', and 'statistics' attributes to the MathService implementation and expose them through get/set methods? Well, this could be a way to expose data about our service, but it's not a very elegant solution. What about having more than one SDE? What about not having any SDEs?

The solution is in the GWSDL. As we'll see in the next page, another of the extensions introduced by GWSDL (with respect to WSDL) is that we can associate SDEs to a portType, specifying the cardinality of each SDE along with other properties. The datatype of each SDE is specified in XML Schema, a language originally intended to describe the structure and vocabulary of XML documents. However, it can also be used to define other types of structures (including databases, objects, etc.)

For example, let's take the LastResults SDE, which has an integer datatype (a fundamental datatype). For this SDE we would we simply have to specify (in GWSDL) that its datatype is xsd:int.

The SystemInfo SDE, on the other hand, has a complex datatype. In other words, it is a structure with a set of attributes (or fields). To specify that we want that SDE to be of that datatype, we must first define that custom structure. This is also done in XML Schema, either directly in the <types> element of the GWSDL files or in a separate XML Schema file (XSD extension) which is imported into the GWSDL file. In fact, in the example we're going to implement we'll take the latter approach.

In the case of SDEs with complex datatypes, a Java Bean is created so we can interact with that SDE from Java.

	This code is not 100% correct...it has been shortened for simplicity.

Accessing the SDEs, as we'll see in the next page, is very easy. The standard GridService portType includes a method which allows us to tell the service "Hey, you, give me the SDE called FOOBAR!". First of all, if the SDE is multivalued (like the LastResults SDE), we'll receive an array of SDEs (otherwise, we'd receive an individual SDE). Then, if the SDE has a fundamental datatype (integer, float, string, etc.) we'll get that fundamental datatype directly when we access the value of the SDE. If the SDE has a complex datatype, we'll receive an 'SDE Java Bean' which we can use to access the individual fields of the SDE.