RE: [AMG] : PPT of diagram

Henrik,

I think that without intermediaries we're all happy with the event sequences
that cross the upper blue line between original sending and receiving XMLP
Applications (using XMLP Application to excapsulate a collection of XMLP
Handlers at a given node). Looking at just a single one-way message we have
a 'sending event' (XMLP_UnitData.request) between the sending application
and the layer. At the receiving application we have a 'receive event'
(XMLP_UnitData.indication) from the layer. We also received a
'status/confirm event' (XMLP_UnitData.confirm) at the sending end providing
information about the success or failure of the operation (XMLP_UnitData) as
a whole.

In particular the semantics of XMLP_UnitData.indication are about delivery
to a destination application nominated by the sender.

Now you can interpose an application intermediary in the path... it's
visible to the sender and addressed by the sender. That's what's happening
at Handler's T&U. However, this does not seem to be what you seem to be
wanting.

What you seem to be wanting is intermediaries that are between sending
application and receiving application that process targetted modules.
Delivery at these intermediate points is *different* from delivery at the
ultimate recipient. The message is passed up from Processor M to Handler S
which munges bits of the message and passes it back again to Processor M to
continue its journey. The semantics of these events are different from
delivery to the ultimate recipient. Think of them as an 'up-call' if you
like that takes inbound message as a parameter and returns the modified
messsage for onward transmission.

The diagram below are two diagrams that a UNITDATA operation through an
intermediary. The numbering shows the ordering of events:

  +---------+    +--------------+   +---------+
  | XMLP Ap |    | Intermediary |   | XMLP Ap |   
  |         |    | XMLP Ap      |   |         |
  +-+---+---+    +---+-------+--+   +----+----+
    |1  ^5           ^2      | 3         ^4
+---|---|------------|-------|-----------|------+
    V   |            |       V           |

One operation end-to-end:
1=Unidata.request, 4=UnitData.indication, 5=UnitData.confirm (5 may arise
any time after 1)
2=Intermediary.indication, 3=Intermediary.response



  +---------+    +--------------+   +---------+
  | XMLP Ap |    | Intermediary |   | XMLP Ap |   
  |         |    | XMLP Ap      |   |         |
  +-+---+---+    +-+-----+----^-+   +----+----+
    |1  ^6        ^2     |3   |5         ^4
+---|---|----------|-----|----|----------|------+
    V   |          |     V    |          |

Two chained Operations:
1=UnitData.request, 2=Unitdata.Indication, 6=UnitData.confirm (anytime after
1)
3=UnitData.request, 4=UnitData.indication, 5=UnitData.confirm (anytime after
3)

My understanding of our discussion is that you want something different from
2 two chained operations, you want (I think) a single operation with
intermediaries. If that's what you want I think that the events (sequence
and semantics) that pass across the layer boundary between the layer and the
handlers that constitututed the intermediary application are different.
That's what I'm trying to accomodate with the notion of an 'Intermediary'
operation with .indication and .response primitives (events).

Slide 3 [1] that we were pretty much agreed on on Tuesday, basically only
did the chained operation. You elaborated your thoughts on the 'Messaging'
intermediary in that slide. In that slide, the "Messaging Intermediary" was
purely a 'helper' to relay messages between different underlying protocol
bindings. This sprouted "Processor M" and "Handler T" in [2].

So... two questions:

1) Are chained operations enough for you? From our discussions I think not.

2) If you want a single operation, through intermediaries, which I think you
do, do you have a problem with the notion of a distinct event to pass the
message 'up' to the XP handlers (encapsulated as an Intermediary
Application) and a second distinct event to pass them down again?

3) If not.... do we just have a problem over the names of these events?



> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
> Sent: 09 February 2001 16:02
> To: Williams, Stuart; Jean-Jacques Moreau (E-mail); John Ibbotson
> (E-mail); Krishna Sankar (E-mail); Lynne Thompson (E-mail); 
> Marc Hadley
> (E-mail); Mark Baker (E-mail); Martin Gudgin (E-mail); Nick Smilonich;
> Oisin Hurley (E-mail); Scott Isaacson (E-mail); Yves Lafon (E-mail)
> Cc: xml-dist-app@w3.org
> Subject: RE: [AMG] : PPT of diagram
> 
> 
> >Using Martins version of the diagram [1,2], the difficulty I'm
> >having is not
> >so much the processor N thing that Martin introduced, its the
> >nature of the
> >exchange that takes place between Processor M and Handler T
> >(particlarly if
> >there are a collection of handlers). I think it has different
> >semantics that
> >those of the UnitData and Data operations.
> 
> An intermedediary *is* special in that it defines both the 
> sending side and
> the receiving side - otherwise it can't be an intermediary. 
> Given that we have
> a definition of an intermediary that supports both an XML 
> Protocol sender AND
> an XML Protocol receiver then I can't see the difference:
> 
>     On the sending side between (Processor M, Handler T)and
>     (Processor L, Handler S)
> 
> and
> 
>     On the receiving side between (Processor M, Handler T) and
>     (Processor O, Handler V)
> 
> I can't think of any example where there would be a difference?
> 
> >I think we can resolve all of it by introducing an operation to
> explicitly
> >support intermediaries. Something like:
> >
> >
> >XMLP Application                  XMLP Application     XMLP 
> Application
> >(encap of                         (encap of            (encap of
> >Handlers Q&R)                      Handlers @ T)        Handlers U&V)
> >
> >XMLP_UnitData.    |             |                    |
> >request       |             |                    |
> >----------------->|             |XMLP_Intermediary.  |
> >                  |             |indication          |
> >                  |             |------>             |
> >                  |             |<-----              |
> >                  |             |XMLP_Intermediary.  |XMLP_UnitData.
> >XMLP_UnitData.    |             |response            |indication
> >confirm           |             |                    |------>
> ><-----------------|             |                    |
> >                  |             |                    |
> 
> I am somewhat confused about why we would want to describe this as a
> request/response interaction?
> 
> Henrik
> 
>

Received on Friday, 9 February 2001 12:08:32 UTC