RE: attributes in CORBA IDL

At 10:47 AM 6/30/2003, Savas Parastatidis wrote:
>
> > In IDL, if you say "attribute string foo" its simply another way
> > of saying "string getFoo ()" and "void setFoo (string)".
> >
>
>I think there is a misunderstanding here. In IDL, saying "attribute
>string foo" DOES NOT mean "string getFoo()". The CORBA IDL binding to
>JAVA says that.

Actually it does, in a logical sense. The IDL says there will be a 
method/function/procedure in the target programming language that will have 
one output parameter that is that programming language's mapping of the 
type IDL string. And there will be another method/functionc/procedure in 
the target programming language that will have one input parameter whose 
type will be that programming language's mapping of the type IDL string.

The actual name and signature is defined by the rules for the programming 
language. The language mapping designer's picked method/function/procedure 
names and types that seemed natural for the target programming language and 
which met the other rules language binding rules. E.g. the 
method/function/procedure name(s) had to be guaranteed not to collide with 
any other mapped name for user-defined IDL operation names or other names 
generated by the language mapping.




>In IDL, when you say "attribute string foo" all you have suggested is
>that there is an attribute called foo as part of the interface.

And that there will be 2 methods, one of which gets the value of foo, and 
one of which allows for the setting of foo. What the implementations of 
those methods do, is completely upto the designer of the interface and the 
implementation code.

I believe this discussion about stubs/skeletons is a complete red herring. 
If you are using DII, there are no stubs and skeletons, but the semantics 
are still the same -- none.

The implementations of the getter/setter can do whatever they would like. 
There is no more (or less) requirement that in Java that void foo(int l) do 
anything particular, then void bar(int l) which was generated from IDL that 
looks like
   interface xface { void bar(long l); attribute long l};
(assuming i've got my idl syntactic details correct ;-)


>  The IDL
>specification gives you the means to write interfaces that contain
>attributes.

which is just a shorthand for getter/setter IDL operations.

In fact one is guaranteed better consistency in the language mappings by 
explicitly defining the getter/setter operations in IDL rather than using 
the attribute keyword. This is because the use of getter/setter IDL 
operations means the operation names follow the regular IDL name mapping 
rules, rather than the special ones which are defined for mapping attribute 
names.

jeff

>  That is exactly what WSDL should do as well.
>
>In WSDL, saying
>
><interface ...>
>    <attribute ...>
>...
></interface>
>
>should only mean that there is an attribute as part of the interface.

whatever that means. This is the tricky part: defining the semantics of 
what it means for something to be an attribute of a WSDL interface. If we 
were to follow the CORBA IDL model, it would be exactly equivalent to 
defining operations with the right signatures.

jeff



> > Without such an approach, there's no way to implement a stub
> > so that it knows what to do when someone wants to read the attribute.
> >
>
>How an implementation creates stubs from a WSDL interface should be
>irrelevant to the WSDL specification.
>
> > WSDL as the IDL for Web services should presumably support the same
> > model for attributes: an attribute x in WSDL means that the service
> > offers getx() and maybe setx() (if the attr is readonly).
> >
>
>Do you mean getx() and setx() WSDL operations? If that is the case, then
>you don't need attributes. If you mean that there should be a way to
>get/set the values of attributes, then yes... that's the responsibility
>of the binding specification. In one of my previous messages I suggested
>just that.
>
> > Are you now agreeing this is the right way to go? IIRC you disagreed
> > earlier; my apologies if I misunderstood you.
> >
>
>No, I have not changed my position. It's the same. I thought you agreed
>with what I was saying. Sorry for the misunderstanding.
>
>.savas.

Received on Monday, 30 June 2003 22:18:10 UTC