- From: Tim Banks <tim_banks@uk.ibm.com>
- Date: Mon, 21 Jul 2003 12:52:26 +0100
- To: <public-ws-desc-state@w3.org>
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