RE: Draft Alternate Section 3.

Hi Krishna,

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: 26 March 2001 08:18
> To: Williams, Stuart; Henrik Frystyk Nielsen (E-mail); Jean-Jacques
> Moreau (E-mail); John Ibbotson (E-mail); Lynne Thompson (E-mail); Marc
> Hadley (E-mail); Mark A. Jones (E-mail); Martin Gudgin (E-mail); Nick
> Smilonich (E-mail); Oisin Hurley (E-mail); Scott Isaacson 
> (E-mail); Yves
> Lafon (E-mail)
> Cc: xml-dist-app@w3.org
> Subject: RE: Draft Alternate Section 3.
> 
> 
> Hi,
> 
> 	Overall looks excellent. I have a few preliminary 
> observations. May be they
> are already discussed.
> 
> 	1.	"Conceptually and from the point-of-view of 
> message correlation, each XMLP_UnitData operation causes 
> the transmission of a different message even if the message 
> has the same value as a previous message. "
> 
> 		If so, how would we handle reliable messaging, 
> retries et al. Are we leaving it to the protocol layer ?

There has been some discussion somewhere of how reliable is reliable. The
XMLP_UnitData operation is cast as being best-effort ie. messages can be
silently lost.

If you think of TCP, when you do multiple send's on the same buffer, you are
sending the same 'value' twice - you are sending two 'messages' that have
the same value. Under the hood with TCP if IP datagrams go astray,
mechanisms in TCP spot the missing pieces and cause the missing byte-ranges
to be resent. These missing pieces are assembled into NEW IP datagrams - ie.
(you'll find that at the IP level the Identification field carries a
different value - it's a different message which may happen to carry the
same content).

So there are two answers to your question:

1) It may be the case that we design mechanism that operates within the XMLP
layer to improve the reliablity of message delivery. If this is the case
then the multiplicity of underlying protocol messages that may flow to
transfer the XML protocol message should not be evident at the XMLP layer
interface. From the XMLP service interface point-of-view we are sending a
single message (possibly causally dependent on a message that was received
earlier).

2) It may be the case that we define extension one or more modules that
operate within the context of an XMLP application (AM usage) that provide
common application oriented mechanisms to improve the applications (rather
than the XMLP layer's) ability to detect and recover from lost and
mis-ordered data. If this is the case then the application may re-transmit
message as part of its recovery strategy, however it is highly likely that
the application will want to distinctively mark copies. In any case, from
the point-of-view of the XMLP service interface, it is again dealing with
single distinct messages (that may be causally dependent on earlier
messages).

> 	2.	What about sequencing ? Why not add the
Correlation.MsgSequence now
> itself while we can do it ? From my practical experience, this would help
a
> lot of B2B issues.

I'd be happy to give it some further thought. In the first instance I wanted
enough functionality in the abstract interface to enable simple
request/response correlation on one-way messages. The earlier draft had both
a one-way and a request/response operations. Some have been unhappy about
the inclusion of request/response and I tried to focus on why I was
reluctant to remove it. For me, the removal of request/response lead to an
inablity to express a correlation/causality between response and request in
the service interface. The changes proposed add enough functionality into
the UnitData operation to recover the correlation/causality lost by the
removal of request/response.

Certainly, adding in Correlation.MsgSequence in would be useful in that it
would then provide pretty direct expression of request/multi-response,
although you might want something more to denote last message of a
multi-response.

The semantics that I'd be looking for here is that the
Correlation.MsgSequence value indexed through a sequence of messages (from
the same source - to cover multicast variants) that arise as a direct
consequence of the SAME eariler message. It would not be sequence numbering
of messages in a long running exchange of messages.

An interesting effect of just Correlation.MessageRef is that it could be
used to thread a sequence of messages together which goes beyond the current
capability of SOAP over HTTP today. In the basic SOAP/HTTP case a SOAP
sender bound to an HTTP client is unable to mark (except through possible
extension modules) that a message it sends is causally dependent on an
earlier message from a SOAP sender bound to an HTTP server. However, with a
little more thought it might be possible to abstract the use of Cookies
through into the correlation parameter (a binding issue perhaps).

The possible reason to 'hold off' on MsgSequence right now is to think it
through a bit more.

> 	3.	Was there any logic behind leaving faults out of status ?
faults could
> be a good source of more information, especially for a status of .failure.
> (You had (faults) in many of your messages).

Yes... there was a good reason. Faults are carried in envelopes and
therefore look like messages that happen to have faults carried with header
and/or body elements. If they are messages, it seems much tidier to treat
them as messages and deliver them in UnitData.receive.

The other stylistic difficulty having collapsed headers, bodies and
attachments into Message with sub-fields which might carry a fault within or
instead of a body, it seemed ugly to have a separate Fault only parameter
just for .status. .status really is about the success or failure of the
underlying protocols to deliver a message in as much as it is possible to
determine either.

> 	4.	On a related note, why isn't .failure a status 
> disposition ?

Might be a bug... I'll take a closer look at what I've written.

> 	5.	I couldn't make out, if in your mind, correlation could be a
unique id
> for the message and possibly a GUID or UUID. (I do agree that the
mechanism
> would not be specified by the AM but at the binding level.)

In my mind the Correlation.MessageRef is locally significant only and
abstract. The mechanisms that use/derive MessageRef may be part of the XML
Protocol design; they may be part of the binding to an underlying protocol;
they may be the exploitation of intrinsic properties of the underlying
protocol.

So GUIDs or UUIDs would certainly do, but they have much stronger properties
than were intended, indeed the references I had in mind to cover the HTTP
case may not be explicitly present in any message, they just arise because
of the natural behaviour of the underlying protocol.

> 	6.	I assume we define a Message = (Message.Headers, [Faults],
> Message.Bodies, [Message.Attachments])

Yes... although it might be:

Message = (Message.Headers, (Message.Faults | Message.Bodies),
[Message.Attachments])

I'd be interested in hearing discussion on whether we should allow both
Faults and Bodies, or indeed whether a Fault is just a special kind of Body.

> 
> 	7.	Why can't status contain a Message as well ? 
> That way the sender can get more information as needed

Because that would make it a two-way exchange and I was trying to see what
could be done in the context of one-way messages with correlation only.

> 	8.	Because the status doesn't have the [Correlation], do we
assume a
> request/response pattern ? i.e. a send waits for a status and on time out
> assumes an error.

I need to think about this a little more. I think that you actually always
get status (which you can ignore). At a minimum the status reports that the
message was successfully sent. Depending on the chain of underlying
protocols it may also be possible to report that the message has been
delivered to it's endpoint. The other 'strong' thing that status can say is
that the message was NOT send or NOT delivered if the mechanisms exist in
the underlying protocol chain to make that determination.

For request/response, the response is a separate message so it would look
something like:

[Hopefully this wiil not be destroyed by line-wrapping]

  .send(Message=MsgA)
  ------------------->|     |
                      |     |
  .status(status=sent)|     |.receive(Message=MsgA)
  <-------------------|     |----------------------->
                      |     |
                      |     |.send(Message=MsgB,
                      |     |      Correl.MsgRef=&MsgA)
                      |     |<-----------------------
 .receive(Message=MsgB|     |
  Correl.Msgref=&MsgA)|     |.status(status=sent)
  <-------------------|     |----------------------->
                      |     |
NB, the &MsgA references are locally only.
> 
> 	9.	"This operation may be implemented over HTTP, HTTPS,
SSL/TCP, TCP and
> SMTP" : Why not RMI, COM+ et al ? The point is do we *need to*
> assume/specify any protocol/transport ? Of course, we would have the
> bindings and hopefully we could specify bindings to these as well.

That's fine, the assertion can go and was certainly not intended to imply a
closed list.

> 
> cheers

Thanks,

Stuart
<snip/>

Received on Monday, 26 March 2001 05:10:07 UTC