RE: Some requirements

[snip]

 

Perhaps the analogy is not to a C++ language specification, but to a
component model. It is not the language specification that dictates the
usage of some interfaces or methods, but the definition of these models.
For example, EJB 2.0 CMP model defines both attributes that describe
state in its abstract model and also well defined syntax to access these
attributes via get/set methods. Without defining how the access should
happen in a uniform and well understood way, just defining a set of
attributes may not be that useful. 

What I am not clear about is your position actually. I have been trying
to follow your postings. Are you suggesting that a set of  attributes
that describe state is not a useful concept or are you suggesting that
providing an agreed convention for accessing them (perhaps via a set of
operation conventions) should not be targeted by the WSD wg? 



 
Apologies if my postings have not been clear :-(
 
I will try to clarify my position...
 
I can see the reason we need attributes. Attributes can be used to
expose state in a standard way. However, I believe that the WSD
specification should only define the syntax of attributes and how they
relate to messages. For example... (please note that this should be used
as an example and not as a proposal)
 
<attribute name="myAttribute" message="tns:messageName" readonly="true">
   <!--other attribute-related elements or XML attributes--> 
</attribute>
 
<interface>
   <attribute name="tns:myAttribute"/>
   <operation name="tns:myOperation"/>
</interface>
 
I do not believe that the WSD specification should define a number of
specific operations, like the ones specified by OGSI: get, set, find,
subscribe, etc. If such operations was seen as necessary, another
specification should be introduced that talks about them and their
relation to the WSDL attributes. Please, note that since the attribute
of the example above specifies a relationship with a wsdl:message, there
would probably not be a need for get/set operations. But then again,
that attribute is part of the interface while OGSI allows attributes
(serviceData) to appear at runtime, which is the reason get/set
operations are required.
 
As for the analogy with C++, or Java for that matter... The EJB
component model is built on top of a language specification (Java
language). The Java language does not specify any operations. Perhaps I
should have used the IDL specification instead of C++. IDL is used to
describe OO interfaces and not to define the behavioural semantics of a
component model. It is my understanding that WSDL is used to define the
interface of web services and how that interface maps to operations and
messages (no?). Nothing is said so far in WSDL about specific operations
that must be supported (like get/set). I believe that such specific
operations should not be part of a WSDL specification.
 
The mapping of attributes to messages, though, is probably required (see
example above).
 
  

I am not clear about your comment. Are you suggesting WS-I should be
responsible for defining common interfaces? Since I did not understand
the previous comment well, it may be speculation on my part. 



 
No no. I am not suggesting that WS-I should be responsible for that.
Part of WS-I's role is to create profiles of Web Service specifications.
If a specification that included specific attributes-related operations
was deemed necessary, then WS-I would be responsible for adopting it and
including in its profile of standards, thus ensuring interoperability.
 
We can not say that the web services oriented architecture is stateless
or stateful. At best, the assertion we can make is that there is no well
defined mechanism for defining explicitly what external state is, or how
internal state is exposed.  If I were to provide a counter method on a
service which returned the next integer to the client, would this
service be stateless or would its state be undefined with respect to
WSDL today? 

 

I would say that in the current SOA the state of the service is
undefined. It is obvious that in order for a counter service to provide
a useful functionality, some state has to be maintained. However, the
SOA says nothing about that state, how it is maintained and how it is
exposed.

 

IMHO, I don't believe that attributes would provide a solution to this.
Instead of having a getCounterValue operation, now we will have a
counterValue attribute (granted, with some more information attached to
it). Still, nothing is said about the state that is maintained but,
rather, just the type of the counter's value and the wsdl:message that
will be returned.

 

 

Please, do forgive me if I haven't been clear. Let me know if
clarification on any of the above is necessary.

 

Again, all these are just my personal views and I may be very very
wrong. I hope I am not causing problems or delaying progress by
supporting them.

 

Best regards,

.savas.