d) mapping to OGSI serviceData concepts

ATFers:

ServiceData has the following information items:
- name
- type
- nillable
- minOccurs, maxOccurs
- mutability
- modifiability

@name and @type are the same in the attributes proposal and OGSI
serviceData.

@nillable could be an OGSI extension. That is, OGSI could add an ogsi
namespace

@minOccurs and @maxOccurs illuminates perhaps a conceptual gap in the
modeling approach. In OGSI the type of the SDE reflected the type of an
individual value.  The SDE itself could take multiple values. The analogy
was more along the line of an SDE being an xsd:element definition. With the
approach suggested here, the type of the WSDL 1.2 attribute would model an
outer “container”. Perhaps an example would be illuminating:

in OGSI I could specify:
<gwsdl:portType name=”somePT” …>
  <sd:serviceData
    name=”sd1” type=”xsd:integer”
    minOccurs=”1” maxOccurs=”5”/>
  <sd:serviceData name=”sd2” type=”tns:foo” minOccurs=”1” maxOccurs=”1” />

And this would imply that the service implementing the portType would have
state represented by a “logical” XML document that could look like:
<sd:serviceDataValues>
  <sd1>1</sd1>
  <sd1>2</sd1>
  <sd1>3</sd1>
  <sd1>4</sd1>
  <sd1>5</sd1>
  <sd2>
    <tns:foo>bar</tns:foo>
  </sd2>
</sd:serviceDataValues>
…
</gwsdl:portType>

The term “logical” is used because the actual SDE values did not have to be
stored in XML, but that the service implementation was obligated to be able
to support this notion.  It is particularly important to support XPath
queries against the entire state.

So the equivalent construct with the attributes proposal would look like:

<wsdl:interface name=”somePT” …>
  <attribute name=”sd1” type=”tns:sd1Container”>
  <attribute name=”sd2” type=”tns:foo>
…
</wsdl:interface>

where sd1Container would be defined as:

<xsd:element name="sd1Container">
  <xsd:complexType >
    <xsd:sequence>
      <xsd:element  name="sd1" type="xsd:integer"
                   minOccurs="1" maxOccurs="5"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

and sd2 can be modeled directly since it does not represent a repeating
group of values.

This has the additional burden of the designer defining the container
element for sd1. Furthermore, there is no notion of a “containment” element
for all the values of the state. It is somewhat harder, but as we will see,
not impossible to write XPath queries across state.

@mutability could be an OGSI extension.

@modifiability essentially maps to the @readonly.

Note: that we could define a child element of the attribute element to
support “default” values or static values.  We have a facility like this in
OGSI serviceData.  The point has been raised by Savas that properties and
features could be used [1].  However I personally would like to see an
example of this, and make sure that the “static” values have close affinity
to the declaration of the attribute.

Looking at the findServiceData and setServiceData operations in the
GridService portType, I would assert that these operations are much more
sophisticated than simple get/set. The operations act across individual
SDEs and would therefore be the subject of an OGSI-specific interface.  We
need to make sure we can define the conceptual model for attributes
properly that allows us to build the necessary conceptual model.

Note: there does not seem to be much support for “dynamic” serviceData
elements.

[1]
http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Jul/0035.html



++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++

Received on Saturday, 19 July 2003 13:25:47 UTC