W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

RE: Spec draft

From: Damodaran, Suresh <Suresh_Damodaran@stercomm.com>
Date: Fri, 4 Oct 2002 17:04:06 -0500
Message-ID: <23AB6ECCD0FD064BAD472FA37FF80A781F4B0C@scidalmsg01.csg.stercomm.com>
To: "'Newcomer, Eric'" <Eric.Newcomer@iona.com>
Cc: www-ws-arch@w3.org
Eric,
 
Thanks for writing this excellent document - it certainly helped me to
understand
where the WG is on "what are Web Services," having been away for a while.
In particular, allowing a deployed component to take any of the three
described Roles is
an excellent idea.
 
I don't have any major disagreements, though I do have some comments. Hope
these are helpful.
 
1. Sec. 1.2, para 2"
"Valid implementations include subsets or parts of the stack, but must at
least provide the components within the basic architecture." 
I do hear your desire to inject some responsibility into those who would use
this architecture.
I, however, would prefer to delete this statement, since WSAWG is not in the
business of specifying what is a valid implementation or not. It is perhaps
best not to make any reference to "validity" of implementations, compliance,
etc in the architecture description. 
 
2. Sec 1.2,  Para 5:
"The service provider defines a service description for the web service and
publishes it to a requestor or service discovery agency."
 
I agree the current usage is "publish," which is a "push" pattern. It would
be of broader applicability if we also include the "pull" pattern, i.e., the
descriptions are available with the service provider, and the service
discovery agency (to be precise, whomsoever plays that role) pulls it out of
the service provider. To this end,
I would prefer to replace "publishes it to a requestor or service discovery
agency" with
"makes it available to a requestor directly, or through a service discovery
agency" - I would like to see this change made throughout the document. I
understand that a debate may precede this change:-)
 
3. Sec 1.2, Para 6:
"A service description is hosted by a discovery service"
is inconsistent with later discussions where the role of service discovery
agency can be played by the service provider.
 
4. Sec 1.2, Para 3 before figure 2:
"... an XML message may have one or more content models associated with it:
one for each header, and one for the data."
Please provide examples of what a content model is. Also, are you using the
word "data" in this sentence as a plural of datum? I would like to think you
are. If so, please make it explicit. If not, I would disagree with you that
there will be only one piece of data (datum), or there will be only one
content model for all the data.  I would like to think it is likely there
will be multiple content models for the various pieces of data. 
 
5. Sec 1.2, Para 2 after Figure 2:
"The request/response pattern is also often called the remote procedure call
(RPC) oriented interaction style."
 
Since the request/response pair doesn't have to be synchronous (more on the
need to define what is synchronous below), this classification is unfair.
 
6. In section "Operations in a Web Service Architecture"
In "Interact"
"The interaction can be single message one way, broadcast from requester to
many services, a multi message conversation, or a business process."
 
"or a business process" => "or result from the execution of a business
process"
Also, we do not want to exclude other ways of interacting (as an aside, UMM
prescribes at least 6 patterns for business transactions). Please make
appropriate changes.
 
7. In section "Operations in a Web Service Architecture" 
In "Interact"
"Any of these types of interactions can be synchronous or asynchronous"
 
These terms (synchronous, asynchronous) need definitions. The definitions I
have found useful in the context of  such interactions are below.
 
"An entity A communicates with entity B synchronously over a communication
channel if A requires a response back from B, and A does not initiate
another communication to B using the same communication channel before it
receives that response. 

In the Web Services  messaging context, the response could be a response to
a request, an acknowledgement, error, or a combination of these. A may
optionally wait for the response from B before doing further processing
(traditionally called a synchronous wait or block on receiving).  We define
asynchronous communication as follows.

When A communicates with B asynchronously, A does not always require a
response back from B. Irrespective of whether A requires a response or not,
A may initiate another communication to B. 

Certainly, A is not required to wait until it receives that response before
initiating another communication to B. A fire-and-forget model of
communication in which no response is expected is obviously asynchronous.

"

8. Para 2 below Figure 1
"Intermediaries, where present, cannot interfere with the MEP.
Intermediaries may processes certain functions associated with the message
such as routing, security, management, or other operations."
 
Are we excluding intermediaries that can change the data in a message? It is
not clear here. I think "what is an intermediary" needs some careful
thought.
 
9. Typos:
 Look for "patters" "Stck"
 
Best regards,

-Suresh 
Sterling Commerce (on loan to RosettaNet) 
Received on Friday, 4 October 2002 18:05:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT