Attributes, yes. Set/Get operations, no.

On 19/07/2003 18:20 Steve Graham wrote:

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


Three points to make here:

Point 1)  I don't see much advantage to defining get/set operation syntax;
get/set aren't a very powerful language for describing what a service does.
Of course, operations which access attributes shouldn't be restricted to
get/set, so it's worth considering what would be lost if we just defined
attributes and left out the get and set operations.

For example,  If I define a JobQueue as an attribute for a service, I can
define operations like JoinQueue, PurgeHead, PurgeQueue, PurgeByOwner etc
etc. Set and Get aren't always desirable. Obviously, the binding is not the
right place to define these operations, so I don't see it as the place for
get/set either, if those were the operations that were needed.

So, my vote amongst a) - d) is e) - None of the above. Let's keep it simple
and just define the attributes, leaving the definition of their
manipulation to the operations defined by an interface which includes the
attributes.  What's the point of the attributes?  They provide a way for
describing the semantics of the service. Operations on a stateful service
leave some effect on the state at their completion, and the attributes help
describe that effect.   In OGSI, they are also used for introspection; Get
is a major use. However, I think, this is a requirement that needs to be
treated as a special case.

Point 2)

What are the semantics of the proposed Get and Set?  There are two ways to
go: the OGSI way, where the value of a Set may not show up in the value
retrieved by a subsequent Get for some time  after the Set completes. Or
there's the more instinctive way where the Set is immediately reflected in
the real attribute state and a Get can get is right away. (Who can tell me
what happens in CORBA IDL?)   I think the way out of this awkwardness is to
let the interface define the semantics.

Point 3)

It is a requirement, I think, to define the way the semantics of an
interface may change/be preserved when an interface is extended. Suppose
interface A is extended by B; can B modify the semantics of the attributes
defined by A?


Regards, Tim Banks
IBM TP Architecture & Technology. Hursley, UK.
Phone: External +44 1962 815639, Internal 245639

Received on Monday, 21 July 2003 07:54:12 UTC