RE: Some requirements

Savas:
Ok, things are getting more clear, but I still do not see your point.

In your example, how do I as a requestor know how to get/set the value of
myAttribute?  how can I query whether the state of the service has
myAttribute="someValue" and anotherAttribute > 12 and ...?

If one somehow associates attributes with messages, does the requestor
somehow have to figure out which operations somehow use those messages as
input and output?

I guess I still don't understand the approach you are suggesting, nor do I
completely understand your concerns with the OGSI service data approach.

sgg

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++



                                                                                                                                               
                      "Savas Parastatidis"                                                                                                     
                      <Savas.Parastatidis@newca        To:       "Umit Yalcinalp" <umit.yalcinalp@oracle.com>                                  
                      stle.ac.uk>                      cc:       <ksankar@cisco.com>, Steve Graham/Raleigh/IBM@IBMUS, "David Snelling"         
                                                        <d.snelling@fle.fujitsu.com>, "Jim Webber" <jim.webber@arjuna.com>, "Paul Watson"      
                      06/16/2003 06:59 PM               <Paul.Watson@newcastle.ac.uk>, <public-ws-desc-state@w3c.org>, "Steve Tuecke"          
                                                        <tuecke@mcs.anl.gov>                                                                   
                                                       Subject:  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.

Received on Monday, 16 June 2003 19:34:56 UTC