Re: Some requirements

Savas Parastatidis wrote:

>><KS>
>>	This is that specification ! If we define the serviceData
>>concept here and expect another specification to explain the
>>    
>>
>operations
>  
>
>>on them, it will just add the proliferation of more WS-*
>>    
>>
>specifications.
>  
>
>>We already have too many :o(. Our goal should *not* be to develop max
>>number of specifications, but a few cohesive and coherent
>>specifications.
>>
>>    
>>
>
>As you probably know by now, I disagree with this statement :-)
>
>Suggesting that the WSDL specification should talk about required or
>optional operations is like saying that the C++ language specification
>dictates the use of commit() and abort() methods because some
>applications require transactional behaviour. 
>
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?

>
>  
>
>>	Point well taken on the independence from underlying
>>implementations - may they be languages, OS platforms and such. But,
>>    
>>
>we
>  
>
>>still need to define the interfaces of the common operations. The
>>platforms and languages are free to implement them as they wish,
>>leveraging their own idiosyncrasies.
>>
>>    
>>
>
>If a set of common interfaces/operations is required for any kind of
>functionality, the W3C WSA and WS-Interoperability groups are
>responsible for adopting them or not.
>  
>
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.

>  
>
>>	IMHO, as we are into the realm of stateful services (with state
>>visibility thru the sericeData mechanism), we should *completely*
>>    
>>
>define
>  
>
>>what that means. In this regard we need to touch upon security as well
>>    
>>
>-
>  
>
>>I am thinking of visibility and access control of the
>>serviceDataelements - how they can be expresses, exchanged,
>>    
>>
>queried,....
>  
>
>
>I thought that attributes were about exposing access to state and not
>about stateful web services. I see a subtle difference. The web
>services-oriented architecture is stateless. Attributes could provide
>the syntax for exposing state but the semantics of stateful services
>should not be part of a WSDL specification (that's my personal view
>anyway).
>  
>
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?

Regards,

--umit


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