Re: new editor's draft of WSA available

Chris,

Wow! that was quick! Responses inline.

Jean-Jacques.

Christopher B Ferris wrote:
>  > <moderate>
>  > More imporantly, the terminology used used in the paragraph cited
>  > above is at odds with that of SOAP (and possibly that of WSDL).
>  > For example, "content model" vs. "module", "endpoint" vs. "node",
>  > "provider" vs. "ultimate receiver". This is likely to create
>  > confusion.
>  > </moderate>
> 
> moot

I didn't see "moot" in the glossary; it is just an unresponsive 
SOAP intermediary?  ;-)

>  > <moderate>
>  > The following sentence gives the impression that, to access a
>  > service, you always need to be a provider as well: "that function
>  > as both requesters and providers".
>  > </moderate>
> 
> Actually, its more screwed up than that. I REALLY don't like
> requestor and provider as roles. Request implies response and
> some messaging is purely oneway. I don't have time to redo the
> whole section, and given that I haven't spoken up before, and DaveH
> has asked us to hold our tongues w/r/t the terms used, versus the
> definitions I'm going to leave this as is... too hard to deal with.
> 
> IMO, we should have been consistent with the terms used in SOAP1.2
> 
> (SOAP) sender
> (SOAP) receiver
> 
> but, I digress:)

Would a quick, short term solution be to replace:
   "that function as both requesters and providers"

with:
    "that function as either resquester and providers,
     or possibly as both"

>  > <important>
>  > I disagree with the following sentence, both from a WSDL and SOAP
>  > perspective:
>  >    "The request/response pattern [should be MEP] is also often
>  >     called the remote procedure call (RPC)."
>  > Document exchanges work with request-response as well.
>  > </important>
> 
> I believe that this was removed in a previous round of edits.

There's still a remnant in section 6 "The Bottom Up View of the 
Architecture", paragraph starting with: "Figure 2 illustrates a 
common message exchange pattern: request/response."

>  > <moderate>
>  > "Here is a partial list of features:"
>  > Why a partial list? Why a list at all?
>  > </moderate>
> 
> Well, its only partial 'cuz we're still noodling on it:)
> I think that it is fair to leave this as is. No harm, no foul.
> As we unwrap this onion, we'll probably expose what we believe to
> be a comprehensive, yet non-exclusive, list which is still
> technically only a partial list.

Understood. My concern essentially came from the fact that the 
tone and style in this section were very different and much less 
polished that the rest of the document. Maybe an ednote to 
indicate this is work in progress?

>  > <minor>
>  > The appearance of the acronym "SOA" first comes as a shock: where
>  > did the "P" disappear? It might be worth changing the acronym to
>  > something less akin to "SOAP".
>  > </minor>
> 
> SOA == Service Oriented Architecture... has been around for a while.
> Yes, it is possibly too easily perceived as SOAP sans P.

My concern is that the acronym is never formally introduced. 
There is no prior indication in the text that "SOA=Service 
Oriented Architecture", only in drawings.

Received on Friday, 25 October 2002 07:08:45 UTC