RE: b) clarification of "operational model"

[snip]

> 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?
> 

Why do you make the assumption that operations must exist? Why can't we
just say that the existence of an attribute element in an interface
suggests a message exchange pattern? A get attribute suggests that a
request message has to be sent requesting a message to be returned whose
structure is determined by the type of the attribute. A set attribute
suggests an one-way message whose structure is determined by the type of
the attribute.


[snip]

> 
> 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.
> 

This has been the discussion in many messages so far. It is my position
and I think Jeff's messages agreed with this position that the semantics
of CORBA IDL suggest that appropriate accessor operations exist. These
operations do not have to be get/set operations as it is the case with
the CORBA IDL binding to Java.

Why can't we say that the semantics of the WSDL attributes map to the
exchange of messages? The way attributes are mapped to different wire
protocols is specified by the binding part of the WSDL specification.

> 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.
> 

I don't understand why this is seen as repetitive work. You have to do
it for operations, why should attributes be treated any differently?

> 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?
> 

For what it matters, my vote is "no" to (a).


> b) one operation, weakly typed.
> 

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.
> 

Definitely not my preferred way to go. Unlike you, I like typing and
especially in the world of Web Services where interoperability is
important we can't have non-typing behaviour as the norm. It's going to
cause an interoperability nightmare.

> 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.
> 

I see conventions on operation names as application domain specific and
not a general solution that should be adopted by WSDL. 

> 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.
> 

Again, I don't think that specifying a base interface for ALL Web
Services is what the WSDL specification addresses. The WSDL
specification defines the means to describe such an interface.


Hmmm... I seem to disagree with all four suggestions. My position is
that the semantics of the /definitions/interface/attribute are that a
message is sent in case of a set operation and a request and a response
are exchanged in case of a get operation.

Something needs to be said about faults.

.savas.

Received on Sunday, 20 July 2003 17:58:11 UTC