RE: comments on 30/3/2001 AM draft

Hi Chris,

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 02 April 2001 20:09
> To: 'xml-dist-app@w3.org'
> Subject: comments on 30/3/2001 AM draft
> 
> 
> Stuart/AM team,
> 
> Some comments on the 30/3/2001 draft [1] follow.
> 
> Cheers,
> 
> Chris
> 
> [1] 
> http://www.w3.org/2000/xp/Group/1/03/30/XMLProtocolAbstractModel.html
> 
> 1) Section 1 cites 3 operations, the intro to Section 3 cites two, yet the
> primitive 'forward' seems to have been migrated to the UnitData operation,
> which would seem to suggest that there is but one "operation", UnitData
> with 4 primitives (send, receive, forward, and status) as defined in
> section 3.1. These inconsistencies need to be addressed.

Your conclusion is correct, ie one operation with 4 primitives. The
inconsistencies are my fault and I believe we have caught and corrected them
in our working copy.

Apologies.

> 
> 2) In section 3.1.1, the last paragraph states:
> 	
> "Failures that arise during message processing at the recipient or
>  at intermediary XML protocol applications may result in the 
>  generation of fault messages directed toward the originator of the
>  message whose processing gave rise to the fault. Such fault 
>  messages are a direct consequence of the faulted message and 
>  this should be indicated through the use of the Correlation parameter."
> 
> However, as an intermediary may add blocks to the message, the fault may
not
> necessarily lie with the originator of the message, but in the
intermediary
> that appends the block(s) that caused the problem. Should the 
> fault be communicated to the intermediary that produced the 
> block(s) at fault? Should the fault be also propogated back to 
> the originator of the message?

These are good questions and I would encourage further discussion of these.

Message path and message processing models remain significant areas of open
discussion as noted in Issues 2 and 3 at the beginning of the document. It
would seem reasonable that if a block that gives rise to a fault was
introduced my an intermediary then (where possible) is it should be made
aware of the fault. It would also seem reasonable that the original sender
of the message, who has the expectation of that message being delivered to
some ultimate recipient, also be informed of the fault. The AM document uses
the phrase "...directed toward the originator..." which is a little oblique
and certainly was not intended to preculde a fault message being passed back
along some reverse path that may include some or all of the intermediaries
visited by the failed message.

> 3) In section 3.1.3, the assertion that the Correlation  parameter
references
> a message previously forwarded seems to eliminate the possibility that
> a message might be related to another that takes an alternate path between
> source and destination. e.g. 
> 	a->b->c and c->d->a
> 
> Does this mean that if a pair/set of correlated messages travels different
paths
> that the Correlation parameter might not apply to all nodes receiving
> a message? Is the correlation applied only to messages for 
> which there is a local correlary?

The Correlation.MessageRef parameter is defined as being locally significant
only. It is *not* intended to imply the existence of any particular
mechanism for determining the correlation or causality of messages.

Consider say, SOAP bound to HTTP. There is no general
CorrelationID/MessageID parameter expressed however, any message returned in
an HTTP POST response is causally dependent on the message sent in the
corresponding HTTP POST request. This correlation would be indicated to the
recipent of the message in the POST response by through the
Correlation.MessageRef parameter carrying a (local) reference to the
previously sent message.

Likewise, at an intermdiary, the local significance of
Correlation.MessageRef would only be meaningful in the context of messages
that that intermediary had itself forwarded.

It may be the case that an underlying mechanism gets designed into XMLP that
does give rise to some syntactic element within the message that serves as a
more global means of message referencing - and that could play into this
abstract notion of a locally significant message reference.

So I think the short answer to both your questions (if I have understood
them) is yes - because the message reference in the Correlation parameter is
a local reference to a message that the node in question has already seen.

> 4) Section 4.2 #6 says:
> 
> "SOAP:  Header entries can be referenced via links from other headers.  If
they have no actor
>  (targeted at the final destination), they will not be removed by any
intermediaries.  Using
>  that mechanism, headers can be effectively shared among modules, even at
different
>  nodes.  The actor-less headers are interpreted as relevant to the final
processor, even
>  though they may not be.  The body can only be processed by the ultimate
recipient."
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> No where in the SOAP specification is this claim established. It is also
unclear as
> to what the term "processed" means. Certainly, as has been stated, the
elements
> of the Body element as well as the rest of the Message (or Message Package

> as defined in SMwA) are made available to a handler along with the
block(s?)
> that it is registered to "process".

I'll defer to Henrik and/or Mark Jones to comment here.

> I think that there needs to be a clear definition as to what is meant by
"to process"
> and that there needs to be a much clearer definition of terms  (handler,
block, module,
> message) and what the relationships are in the abstract model.

I hope that that concern is captured in Issues 2 and 3 at the beginning of
the document.

> 5) Section 4.2 #7 says:
> 
> "The processing of a block may result in a fault or a  successful
evaluation.  A fault
>  terminates processing and causes a return message containing the fault to
be generated if
>  a return path is available.  It is possible for a module that processes a
block to have status
>  information, non-fatal errors, or other results incorporated into the
return value generated
>  by the ultimate recipient.  It can accomplish this by inserting blocks
which are targeted to
>  http://.../final."
> 
> The phrase "terminates processing" needs to be qualified. Is it the
processing
> of the block? the module?, the message? In addition, the use of the phrase
> "incorporated into the return value generated by the ultimate recipient"
seems
> to imply that there will be a response.

Again I will defer to others on this one.

> 6) Section 5 references alternative bindings to HTTP and 
> indicates that 
> 	"It is anticipated that others will create bindings to  SMTP, TCP,
SSL, 
> 				^^^^^^
> 	BEEP and others."
> 
> *who" others? Granted, this is outside of the scope of the AMG, but unless
there
> are standardized bindings to alternate protocols, they will  be fairly
useless
> as regards to interoperability. At the very least, some attempt at
establishing
> a body that has authority to sanction standard bindings is needed IMHO.

I think that your point is well taken. I think there is a sensitivity on the
part of the WG as to the particular commitments it has made to the
development of protocol bindings beyond the definition of a binding to HTTP.



> 7) Section 5 doesn't have a section defining/declaring the three binding
> "operations" (OP, MSG and ERR). In addition, the disgram in section 5.1.1
> only contains reference to OP and MSG (ERR is omitted). That same diagram
> also refers to OP and MSG as primitives, when in fact they are Binding
Operations
> in the lexicon of the AM.

I think we can work to improved the consistency. Thank you for picking up
the glitches.


> 8) Section 5.3 still references the obsolete XMLP_Data operation

Thanks. This has been corrected in the working copy.

> 9) Something that isn't clear to me is whether the correlation discussed
in section
> 5 is the same as correlation discussed in section 3. In fact, I believe
that 
> there may need to be a separation of concerns w/r/t correlation as it
applies
> to individual message exchange and a protocol binding which may support
the
> notion of session. A session may span multiple correlated message
exchanges
> or "conversations".

I think you are correct here. I think this is something that needs to be
worked on some more as section 5 develops. Section 5 is marked as a work in
progress and at most the result of this process will be a W3C WD (ie. a
snapshot of a work in progress).

> 10) The other point that isn't covered adequately is the nesting of
bindings, and what, if any
> abstract interface exists between each of the nested bindings as well as 
> that between them and the XMLP Processor Layer (e.g. to stipulate the
nesting).

These were a late introduction into section 5 and I think also fall under
the heading of need more work.

> 11) Finally, I think that there needs to be some discussion/exploration as
regards
> the ability for one node to communicate to another(s) what MEP (message
exchange pattern)
> is to be employed. In this regard, processing of a one-way messasge may be
very different than
> that used for a request/response pattern (e.g. RPC) carried over a
synchronous 
> communications protocol such as HTTP.

Earlier versions of the document did have an explicit correlated
request/repsonse operation which personally I was not unhappy with although
others were. This lead to the thinking (ironcally on my part) reported in
[1] which lead to the major changes in section 3.

> In fact, at the abstract layer, I do think that it is worthwhile calling
out the distinction
> between oneway and request/response and this needs to be (somehow) able to
be
> communicated through the whole stack (e.g. from the sending application
through to the
> receiving application). While it is quite true that one can construct the
equivalent
> of request/response with oneway messaging, there seems to me  to be quite
a bit of
> information that needs to be communicated through the stack to ensure that
the
> pattern is correctly satisfied by the layers of software supporting the
exchange.

This probaly is angels on a pinhead stuff, but I actually don't believe that
you can do request/response ontop of pure one-way messaging without
introducing (possibly standardised) 'application' specific syntactic
elements into the message that explicitly enable such correlation - ie. you
have to apply some semantics to the payload.

Thank you again for your full and thorough review of the AM document.
Unfortunately (depending on your POV) I'm taking some vacation, so I won't
be able to persue much further discussion until late April.

Best regards

Stuart 

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0216.html

Received on Tuesday, 3 April 2001 08:14:54 UTC