Re: new editor's draft of WSA available

Jean-Jacques,

Please see below.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

"Jean-Jacques Moreau" <moreau@crf.canon.fr> wrote on 10/25/2002 07:09:20 
AM:

> 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?  ;-)

lol!

> 
> >  > <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"

Actually, with the request/response MEP, both agents/nodes operate
in both roles. The original requestor/sender sends a message and receives
and processes a message. The original service provider both receives and
processes a message and sends a response.

> 
> >  > <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."

this section is anachronsitic. It is intended that it be fully harvested
and ultimately removed in a subsequent draft.

> 
> >  > <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?

okay, that would work.

> 
> >  > <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.

Okay, that makes sense.

> 
> 
> 
> 
>