b) clarification of "operational model"

ATFers:

Now, what does this /interface/attribute thing mean anyway?  What is the
conceptual model?  How do designers/tools interpret the appearance of an
/interface/attribute element in a WSDL interface?

So, a requestor examines a WSDL interface and determines that there is an
attribute element in it.  How does this observation inform the requestor
what operations are now legal to send and how can the requestor determine
what the proper input and output messages could look like?

This is an area that is not clearly described in any of the emails I have
seen posted to the ATF list.  Maybe I missed something on vacation.  Some
of the discussion in [1] had a summary from Sanjiva and subsequent
discussion, but we need to be more concrete.

We need to discuss more details regarding the “operational” model as
suggested in [1] could look like CORBA IDL’s treatment of attributes.
Therein, there is an “implicit” operation (or get/set pair of operations)
defined for each attribute defined in the interface.

I see several possible approaches:
a) CORBA IDL-like convention
b) similar to a) but single operation, no strong typing
c) JavaBeans pattern
d) a “base” Web services interface that defines the attribute operations.

a) CORBA-IDL like convention

Consider the following PT:
<wsdl:interface name=”somePT” …>
  <attribute name=”sd1” type=”tns:sd1Container”>
  <attribute name=”sd2” type=”tns:foo” readonly=”false”>
…
</wsdl:interface>

What can the requestor conclude about how to read/write values of sd1 or
sd2?  A CORBA IDL like approach would suggest that the requestor could
invoke operation(s):

- getsd1(), with no input message and that would return a message
containing a single sd1Container element.
- getsd2(), with no input message and that would return a message
containing a single sd2 tns:foo element.
- setsd2(), with an input message with a single tns:foo element and that
returns an output message that is empty.

This is nice, but where is this defined?  There is no wsdl:operation
definition defined for these operations.

Furthermore, how is the binding specified?  Do the operations “magically”
appear in the binding?  Sanjiva [2] indicates that adding operations to the
binding is not the way to go.

We could add an “attribute” element to the binding, as Savas suggests, but
this could end up being a lot of repetitive work, to define a binding level
attribute element for each attribute element found in the interface.

We need to resolve how this works.  Are we ok with the appearance of the
get/set operations to be by convention (ie not explicitly modeled in the
WSDL)?  How can a service designer declare which bindings these “implicit”
operations can be associated with?

b) one operation, weakly typed.

If we go with an implicit operation approach, I don’t see why we should be
bound to a strongly typed get/set pair.  An alternative on this would be a
single get() and single set() operation that takes the qname of the
attribute as parameter (only parm in get() and the first of two parms in
the set()). The get returns xsd:any and the set still returns empty
message, but its second input parm is also an xsd:any.  This is something
like:

xsd:any get(qname)
void set(qname, xsd:any)

This way the binding does not have to specify separate construct for each
attribute, but rather, there needs to be a single binding for a single
implicit get operation and a single implicit set operation.

This also gives tooling the freedom to *choose* if it wants to generate a
type strong getXXX and setXXX method at the language level or *choose* to
accept the weakly typed get() and set() operation.  There is enough
information in the interface’s attribute elements to define the strongly
typed operations, if the tooling chooses to do so.  Languages like
Smalltalk don’t need no stinkin’ strong typing. :-)

This model will also allow OGSI to extend the concept for findServicedata
and setServiceData more conveniently.

Note: with this proposal, we assume that attributes are inherited within an
interface extends hierarchy in a fashion similar to operations, with all
the grotty name and namespace acrobatics we require because the WSD WG did
not allow operation overloading.

c) JavaBeans like pattern
If we go with a CORBA IDL like approach, we are challenged to answer the
question, why define attributes at all, just do getXXX and setXXX and
therein imply that an attribute called XXX exists and infer the type from
the input and output messages.

This argument was raised on the list and addressed quite deftly by Sanjiva
[2].

Note also that attribute inheritance is a little trickier, because the name
of the attribute needs to be derived from the operation name and the
namespace of the operation name.

d) a base or root “Web services” interface
We should still consider and argue whether we should propose a “root” web
services interface that suggests how to meet all the requirements.
However, there appears to be non-trivial opposition to this approach within
W3C.

For the purposes of analysis we will use the OGSI serviceData concept as a
PROXY for a concrete proposal of this sort.

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

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

Received on Saturday, 19 July 2003 13:22:37 UTC