Re: new editor's draft of WSA available

Jean-Jacques,

Thanks again for the careful review/feedback. 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 wrote on 10/25/2002 04:24:49 AM:

> 
> Chris et al,
> 
> Some further comments on the draft.
> 
> Jean-Jacques.
> 
> ==============
> 
> Section 1.1 The Need for an Architecture
> -----------------------------------------
> 
> <minor>
> For consistency with:
>    "extensible message framework (SOAP)"
> I suggest adding "(WSDL)" to:
>    "interface definition language"
> i.e.:
>    "interface definition language (WSDL)"
> </minor>

done

> 
> 
> Section 3.1 Basic Architecture
> ------------------------------
> 
> <minor>
> MEPs are defined at least three times:
>    "Requester and providers interact using one or more
>     message exchange pattern (MEPs)."
> and:
>    "message exchange patterns (MEP)s that
>     group basic messages into higher-level interactions"
> and again:
>    "Service requesters and providers interact by
>     exchaging messages, which may be aggregated to form
>     message exchange patterns (MEPs)."
> </minor>

got it.

> 
> <minor>
> Similarly, the extended Web services architecture is defined at 
> least twice:
>    "details how messages may carry context to support
>     security, transactions, orchestration"
> and:
>    "may be extended to include features that
>     ensure privacy, coordinate transactions, orchestrate"
> </minor>

okie dokie

> 
> <important>
> More importantly, the two sentences give above give the 
> impression that the extended architecture is provided only 
> through specialized MEPs; other types of features (modules) are 
> completely left out.
> </important>

Not sure I agree. I left in the first one which was more comprehensive.
I did tweak a bit, but don't think it leaves that impression.

> 
> <minor>
> I don't think the paragraph starting with the following sentence 
> is very clear: "For example, an XML message may have or more 
> content models associated with it"
> </minor>

agreed, gone

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

> 
> <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:)

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

> 
> 
> Section 3.2.1 Features
> ----------------------
> 
> <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.

> 
> <minor>
> The description of list items is very terse.
> </minor>

agreed, these need to be fleshed out as I am sure they will
be in a subsequent draft. definitions/descriptions are always 
welcomed by the editors:)

> 
> 
> Section 3.3 Web Services Stacks
> --------------------------------
> 
> <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. 

>