Re: attributes & WSDL (was: Re: attributes in CORBA IDL)

Sanjiva Weerawarana wrote:

>OK, so this discussion is interesting, but I'm not sure whether
>there's a hint of agreement or not. Let me try summarizing:
>
>- add an "attribute" construct to wsdl:interface with semantics
>  as in OMG IDL's attributes
>- leave out specific functions like findAttributes() and queryAttrs()
>  as out of scope for WSDL
>- grid guys can define those functions in their base interface
>
>Is that an accurate statement of where this discussion seems to
>be saying?
>  
>
Not quite. I think you are summarizing Savas' point of view, not 
necessarily the rest of the task force's thinking or discussion up to 
this point for those points 2 and 3 above.

We have discussed exploring a verbal contract and/or a binding contract 
for the attributes in order for the client to be able to get/set those 
values so that there may be a way of not defining the functions (2) in 
the interface, but there is a clear way of
accessing the values using the binding. We have not explored how this 
can be done in detail yet, but our feeling, (this is my understanding) 
has been to explore this contract part of the WSDL regardless of whether 
functions are within the interface or not.
After all, the contract for the client must be well defined to access 
these values.

--umit

>Sanjiva.
>
>----- Original Message -----
>From: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
>To: "Jeff Mischkinsky" <jeff.mischkinsky@oracle.com>; "Philippe Le Hegaret"
><plh@w3.org>; "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
>Cc: <public-ws-desc-state@w3.org>; "Steve Graham" <sggraham@us.ibm.com>
>Sent: Tuesday, July 01, 2003 10:20 PM
>Subject: RE: attributes in CORBA IDL
>
>
>  
>
>>Jeff,
>>[snip]
>>
>>    
>>
>>>I don't if this is relevant, but there IS a set of mandated operations
>>>      
>>>
>>on
>>    
>>
>>>all CORBA objects, those that are inherited from the base
>>>      
>>>
>>CORBA::Object
>>    
>>
>>>type. (Technically although the signatures are expressed in IDL, each
>>>language mapping defines how they are materialized in that language.)
>>>
>>>interface Object {
>>>      InterfaceDef get_interface ();
>>>      boolean is_nil();
>>>      Object duplicate ();
>>>      void release ();
>>>      boolean is_a ( in RepositoryId logical_type_id );
>>>      boolean non_existent();
>>>      boolean is_equivalent ( in Object other_object );
>>>      unsigned long hash( in unsigned long maximum );
>>>      void create_request ( .... [ parms snipped ] );
>>>      Policy get_policy ( in PolicyType policy_type );
>>>      DomainManagersList get_domain_managers ();
>>>      Object set_policy_overrides(
>>>          in PolicyList policies,
>>>          in SetOverrideType set_add
>>>          ) raises (InvalidPolicies);
>>>      Policy get_client_policy( in PolicyType type );
>>>      PolicyList get_policy_overrides( in PolicyTypeSeq types );
>>>      boolean validate_connection( out PolicyList
>>>      
>>>
>>inconsistent_policies );
>>    
>>
>>>      Object get_component ();
>>>     };
>>>};
>>>
>>>   So for example you can invoke a get_interface() operation which
>>>      
>>>
>>returns
>>    
>>
>>>the metadata describing the inteface on all object references.
>>>      
>>>
>>I agree that this is the case. However, this is part of the CORBA
>>specification and NOT of the IDL specification. It has been my case all
>>along in this mailing list that interface and behavioural
>>requirements/semantics should be defined by other specifications and NOT
>>by the WSDL specification. The WSDL specification should just provide
>>you with the means to write such specifications.
>>
>>WSDL is not the specification to define an object-based component model.
>>That's the responsibility of the CORBA and DCOM specifications. It seems
>>that the OGSI people want to define a similar component model for web
>>services. Despite the fact that I disagree with the approach taken by
>>OGSI, I am confident that WSDL is not the place to do that.
>>
>>.savas.
>>
>>    
>>
>
>  
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com