Re: Message Recipient 2.2.26 & Sender 2.2.27 text

A couple of comments on this; I hope that they are treated as friendly 
amendments.


I am not certain that we need to incorporate all of SOAP's gorp in our 
architecture for a couple of reasons: 1. If something is worked out in 
SOAP-land then we do not necessarily need to re-explain it in the 
architecture, 2. the architecture's role is surely to put all the 
different pieces together into a coherent framework; and 3. not 
everything in SOAP (or WSDL for that matter) needs to fit in with our 
view of the picture.

In the light of this, I wonder aloud about intermediaries : what is 
their purpose in the architecture?

If an intermediary can be expected to `consume' a message, and 'spit it 
out' again, possibly modified some, to another agent, how is that 
different from a larger-scale choreography? I.e., is the SOAP concept 
of intermediary really a poor-man's choreography?

IMO, if that is the full intent of XMLP, then I strongly urge us not to 
follow that route.

On the other hand, if the role of intermediaries are what may be called 
transport-assistants (i.e., the slightly generalized equivalents of 
fire-wall routers), then this is strictly SOAP-land stuff and we do not 
(again IMO) need to bake this into the architecture itself; we simply 
state that SOAP is a way of structuring messages and specifying their 
handling.

There is a third possibility; the one that I believed was the truth, 
that an intermediary may have *partial* access to a message and that it 
is fundamentally *transparent* to the parties in a message exchange; 
but that its role is to represent the interests of the owners of the 
organizations the message goes through (applying security and other 
kinds of policies).


Frank


On Thursday, July 17, 2003, at 06:34  AM, Husband, Yin-Leng wrote:

>
> I am all for "limiting the scope of our work to WSDL and SOAP plus 
> other
> stuff that builds on their concepts" and building on top of concepts
> already in SOAP 1.2.  As I do not know the reason behind the original
> text not building on SOAP 1.2 concepts, I wasn't prepared to suggest
> drastic changes.
>
> However, if the editorial team is willing to entertain substantial
> changes from existing text, I agree with almost all of Chris'
> suggestions with some changes:
>
> message sender
> An agent that transmits a message.
>
> message receiver
> An agent that accepts a message.
>
> intermediary
> An intermediary is an agent that is both a message receiver and a
> message sender and is targetable from within a message. It may process
> whole or parts of the message, and acts to forward the message to the
> next message receiver towards the ultimate message receiver along the
> message path.
>
> Message path
> The set of agents through which a single message passes. This includes
> the
> initial message sender, zero or more intermediaries, and the ultimate
> message receiver.
>
> Initial message sender
> The message sender that originates a message at the starting point of a
> message path.
>
> Ultimate message receiver
> The message receiver that is (intended by the initial message sender to
> be) responsible for processing the body or payload of the message. In
> some
> circumstances, a message might not reach an ultimate message receiver,
> for
> example because of a problem at an intermediary. An ultimate message
> receiver cannot also be an intermediary for the same message.
>
> -------------------------------------------
> Cf. Chris proposed definition for
> Ultimate message receiver
> The message receiver that is a final destination of a message. It is
> responsible for processing the contents of the message. In some
> circumstances, a message might not reach an ultimate message receiver,
> for
> example because of a problem at an intermediary. An ultimate message
> receiver cannot also be an intermediary for the same message
>
> Cf. SOAP 1.2 definition for
> Ultimate SOAP receiver
> The SOAP receiver that is a final destination of a SOAP message. It is
> responsible for processing the contents of the SOAP body and any SOAP
> header blocks targeted at it. In some circumstances, a SOAP message
> might
> not reach an ultimate SOAP receiver, for example because of a problem 
> at
> a
> SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP
> intermediary for the same SOAP message (see 2. SOAP Processing Model).
>
> I think neither of the above definitions will work because as given in
> the above example where a (SOAP) message does not reach an ultimate
> (SOAP) receiver as a result of a problem at a (SOAP) intermediary, the
> (SOAP) intermediary then effectively becomes the final destination of
> the (SOAP) message.  In this situation, if the Ultimate (SOAP) receiver
> is defined to be
> "The (SOAP) message receiver that is a final destination of a (SOAP)
> message"
> the (SOAP) intermediary is also the ultimate (SOAP) receiver which is
> clearly contradictory to the last sentence of the respective
> definitions.
>
> We seem to have concepts of message header and message content, instead
> of message body.
> Had we concepts of message header and message body similar to SOAP
> header and SOAP body, then the ultimate message receiver (which IMO is
> what the current Message Recipient corresponds to) could be:
> The message receiver that is responsible for processing the message
> body.
>
> Without the concept of message body (as opposed to message header), IMO
> it is difficult to define responsibility for processing the body (or
> non-protocol related part) of the message without bringing intent by 
> the
> initial message sender.
>
> Yin Leng
>
>
>
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Friday, 11 July 2003 7:53 AM
> To: www-ws-arch@w3.org
> Subject: RE: Message Recipient 2.2.26 & Sender 2.2.27 text
>
>
> "Husband, Yin-Leng" <yin-leng.husband@hp.com> wrote on 07/10/2003
> 10:36:35
> AM:
>
>> Hi Shishir,
>>
>>  The original text in the 2003/07/01 version was:
>> "A message recipient is an agent that is intended - by the message's
> sender - to consume the message."
>> Your proposed change was:
>> "A message recipient is an agent that is intended - by a message
> sender
> - to consume the message."
>>
>> You effectively made two changes:
>> 1. from the definite article (i.e. "the") to the indefinite article
> ("a") which grammatically means
>> any message sender, not necessarily the sender of the message being
> consumed.
>> 2. from the article qualifying the gramm. object "message" to the
> article qualifying the gramm.
>> object "sender".  The orginal text relates the message (being
> consumed),
> not to any sender, but
>> specifically to the sender of the message (being consumed), whereas
> the
> proposed text does not
>> relate the message (being consumed) to its sender.
>
> I agree, I don't think that this language is very meaningful. However,
> it
> is unclear to me
> (appologies for not following this thread more closely!) why we would
> want
> or need to articulate
> intent at all. Specifically, there may be intermediaries along a 
> message
>
> path of which
> the message sender is oblivious. Does this mean that they aren't 
> message
>
> receivers? Not according
> to SOAP1.2[1]. Of course, SOAP1.2 uses the terms SOAP sender and SOAP
> receiver, but I fail to
> understand why we continue to be tempted to define a whole new set of
> terms that IMO will
> only serve to confuse matters considerably and may make it awkward at
> best
> for us to map
> the architecture to SOAP which even if we do not limit the scope of the
> architecture will be
> a necessity IMO.
>
> This gets to the crux of my continuing concern that we are not limiting
> the scope of our
> work to WSDL and SOAP plus other stuff that builds on their concepts.
>
> The terms/concepts that are being defined here are inconsistent with
> similar terms in
> SOAP1.2. For instance, the term "message receiver" is being defined in
> terms of intent of
> some (or the:-) "message sender". I for one think that this is
> misguided.
> Whether a
> message is received by some agent because it was intended or not is
> irrelevant, it was
> still received and the agent that received it should be somehow
> considered
> in our architecture
> or we can say nothing about it and make no constraints upon it.
>
> If we want to generalize terms because we still haven't come to 
> complete
>
> consensus
> as to whether we are scoping our architecture to WSDL and SOAP plus
> other
> goop, then
> why not look to SOAP1.2 first before simply making stuff up.
>
> SOAP1.2 defines SOAP sender, SOAP receiver and SOAP intermediary as:
>
> SOAP sender
> A SOAP node that transmits a SOAP message.
> SOAP receiver
> A SOAP node that accepts a SOAP message.
> SOAP intermediary
> A SOAP intermediary is both a SOAP receiver and a SOAP sender and is
> targetable from within a SOAP message. It processes the SOAP header
> blocks
> targeted at it and acts to forward a SOAP message towards an ultimate
> SOAP
> receiver.
>
> These terms could easily be generalized as:
>
> message sender
> An agent that transmits a message.
> message receiver
> An agent that accepts a message.
> intermediary
> An intermediary is an agent that is both a message receiver and a
> message
> sender. It may processes messages and acts to forward messages towards
> an
> ultimate message receiver along the message path.
>
> Then, of course we would need/want to define the other missing terms
> that
> are found in the SOAP1.2 spec:
>
> SOAP message path
> The set of SOAP nodes through which a single SOAP message passes. This
> includes the initial SOAP sender, zero or more SOAP intermediaries, and
> an
> ultimate SOAP receiver.
> Initial SOAP sender
> The SOAP sender that originates a SOAP message at the starting point of
> a
> SOAP message path.
> Ultimate SOAP receiver
> The SOAP receiver that is a final destination of a SOAP message. It is
> responsible for processing the contents of the SOAP body and any SOAP
> header blocks targeted at it. In some circumstances, a SOAP message
> might
> not reach an ultimate SOAP receiver, for example because of a problem 
> at
> a
> SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP
> intermediary for the same SOAP message (see 2. SOAP Processing Model).
>
> These could be generalized as:
>
> Message path
> The set of agents through which a single message passes. This includes
> the
> initial message sender, zero or more intermediaries, and an ultimate
> message receiver.
> Initial message sender
> The message sender that originates a message at the starting point of a
> message path.
> Ultimate message receiver
> The message receiver that is a final destination of a message. It is
> responsible for processing the contents of the message. In some
> circumstances, a message might not reach an ultimate message receiver,
> for
> example because of a problem at an intermediary. An ultimate message
> receiver cannot also be an intermediary for the same message
>
>>
>> Yin Leng
>>
>> -----Original Message-----
>> From: GARG Shishir / FTR&D / US
> [mailto:shishir.garg@rd.francetelecom.com]
>> Sent: Thursday, 10 July 2003 3:49 AM
>> To: Husband, Yin-Leng; 'www-ws-arch@w3.org'
>> Subject: RE: Message Recipient 2.2.26 & Sender 2.2.27 text
>>
>> hi, inline comments....
>> -----Original Message-----
>> From: Husband, Yin-Leng [mailto:yin-leng.husband@hp.com]
>> Sent: Thursday, July 03, 2003 9:14 PM
>> To: GARG Shishir / FTR&D / US; www-ws-arch@w3.org
>> Cc: Husband, Yin-Leng
>> Subject: RE: Message Recipient 2.2.26 & Sender 2.2.27 text
>> Hi Shishir,
>>
>> 2.2.26 Message recipient
>>
>> RE: 2.2.26.1 Summary
>> The proposed modification to 2.2.26.1 would lose some essential
> relationship information relating
>> the message being consumed to its message sender.  I suggest retaining
>
> the current text.
>>  The original text in the 2003/07/01 version was:
>> "A message recipient is an agent that is intended - by the message's
> sender - to consume the message."
>>
>> All I changed there was replaced "message's sender" with "message
> sender" in order to use the
>> concept of a message sender directly as defined in 2.2.27. I think
> this
> change emphasized the
>> definition of the relationships based on the concepts being defined.
> What info has been lost so I
>> can capture it?
>>
>> RE: 2.2.26.3 Description
>> I suggest that either the paragraph discussing intermediaries be
> dropped
> from this section or re-
>> worded in the context of message recipient.
>> Since "a message recipient is an agent", the text for this section
> (second sentence) should not be
>> "The message recipient of an agent ..."
>>
>> I was a little unsure of the original text, but thought the "of an
> agent" notion was meant to
>> capture the fact that an agent can be many things, and here we're
> discussing the message recipient
>> part of the agent... I am happy to drop the "of an agent" in both 26
> and
> 27.
>> In addition, I propose removing references to "anonymous" (which means
>
> unknown source) in this
>> section.  Propose the following modified text.
>> The message recipient is the agent that the sender intends the message
>
> to be consumed by.  The
>> message recipient may be identified by its agent identifier in a
> message
> envelope; however, the
>> agent identifier of the message recipient is not required to be
> supplied
> in the case of broadcast-
>> style interactions.
>> In general, a message may be intended for more than one recipient.
> Furthermore, in some cases, the
>> sending agent may not have direct knowledge of the identity of the
> message recipient (for example,
>> in multicast or broadcast situations).
>> Optionally,
>> Messages may also be passed through intermediaries that process
> aspects
> of the message; typically
>> by examining the message headers. The message recipient may or may not
>
> be aware of processing by
>> such intermediaries.
>> I agree with these changes, and don't mind not mentioning anonymous
> interactions, but at the same
>> time, it's probably useful to relate the "Message recipient" concept
> with the "Intermediary"
>> concept and then the anonymous interactions can be implied. So, I
> would
> suggest keeping the
>> optional text suggested by Yin-Leng.
>>
>> 2.2.27 Message sender
>>
>> RE: 2.2.27.3 Description
>>
>> I suggest that either the paragraph discussing intermediaries be
> dropped
> from this section or that
>> similar paragraphs be present in both  message recipient and message
> sender sections.
>>
>> As I just wrote above, lets add the intermediary text in for both
> sender
> and recipient.
>> Propose the following modified text consistent with proposed 2.2.26.3
> text.
>> A message sender is the agent that originally caused a new message to
> be
> created and sent to an
>> agent. The message sender may be identified by its agent identifier in
> a
> message envelope;
>> however, the agent identifier of the message sender may not be
> available
> in the case of anonymous
>> interactions.
>> Optionally,
>> Messages may also be passed through intermediaries that process
> aspects
> of the message; typically
>> by examining the message headers. The sending agent may or may not be
> aware of processing by such
>> intermediaries.
>> Yin Leng
>>
>>
>> -----Original Message-----
>> From: GARG Shishir / FTR&D / US
> [mailto:shishir.garg@rd.francetelecom.com]
>> Sent: Wednesday, 2 July 2003 4:08 PM
>> To: 'www-ws-arch@w3.org'
>> Subject: Message Recipient 2.2.26 & Sender 2.2.27 text
>>
>> hi, per the last concall, I have taken a look at the existing text for
>
> 2.2.26 and 2.2.27 and
>> propose only minor modifications to the original text as follows.
> Also,
> there is some text
>> regarding intermediaries that I think is more appropriate to associate
>
> with the sender's description:
>> 2.2.26 Message recipient
>> 2.2.26.1 Summary
>> A message recipient is an agent that is intended - by a message sender
> -
> to consume the message.
>> 2.2.26.2 Relationships to other elements
>> a message recipient is
>> an agent
>> 2.2.26.3 Description
>> The message recipient is the agent that the sender intends the message
>
> to be consumed by. The
>> message recipient of an agent may be represented as the agent's
> identifier in a message envelope;
>> however, in the case of anonymous or broadcast-style interactions, the
>
> recipient of a message may
>> not be available to the sender, and vice-versa.
>> In general, a message may be intended for more than one recipient.
> Furthermore, in some cases, the
>> sending agent may not have direct knowledge of the identity of the
> message recipient (for example,
>> in multi-case situations or in the case anonymous interactions with a
> service provider.)
>>
>
>> 2.2.27 Message sender
>> 2.2.27.1 Summary
>> A message sender is the agent that originates a message.
>> 2.2.27.2 Relationships to other elements
>> a message sender is
>> an agent
>> 2.2.27.3 Description
>> A message sender is the agent that originally caused a new message to
> be
> created and sent to an
>> agent. The message sender of an agent may be represented as the
> agent's
> identifier in a message
>> envelope; however, in the case of anonymous interactions the
> originator
> of a message may not be available.
>> Messages may also be passed through intermediaries that process
> aspects
> of the message; typically
>> by examining the message headers. The sending agent may or may not be
> aware of such intermediaries.
>> -#-#-#
>> Couple of additional comments:
>> * I would suggest the Intermediary text in 2.2.11.1 Summary read:
>> An intermediary is a message processing node that does not necessarily
>
> represent the message's
>> intended recipient; but which, none-the-less may process some aspect
> of
> the message.
>> * Does 2.2.26.3 need to mention intermediaries at all?
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624
>
>

Received on Thursday, 17 July 2003 13:12:38 UTC