Re: Intermediary Discussion

Gudge,

Comments inline:

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Martin Gudgin
> Sent: Tuesday, February 06, 2001 2:17 PM
> To: XML Protocol Comments
> Subject: INT: Re: Intermediary Discussion
> 
> 
> OK, there has been *some* discussion of this topic [1-2]. The 
> Abstract Model
> Group have also been thinking about intermediaries[4-5]. Mark 
> Nottingham has
> posted a document discussing intermediaries[3].
> 
> After reading these posts I think we are still some way from 
> consensus on
> *exactly* what an XP intermediary is but we do seem to have 
> broad agreement
> that;
> 
> 1.    XP Intermediaries sit between the sender of a request 
> and the ultimate
> recipient of that request.
> 
> 2.    XP Intermediaries perform some processing of the 
> request message.
> 
> 3.    Exactly what processing occurs at an intermediary is defined by
> extension blocks.
> 
> 4.    There needs to be a way of addressing intermediaries 
> from within an XP
> message.
> 
> 5.    There may be multiple intermediaries between the sender and the
> receiver.
> 
> 
> Open questions/issues...
> 
> Do XP Intermediaries also sit between the sender of the 
> response and the
> ultimate receiver of that response? And hence also process 
> the response
> message assuming one exists.
> 
> If the answer to the above question is 'Yes' is the set of 
> intermediaries
> the same for both the request and response message?
> 

Food for thought:

In my own work on this I've identified several plausible interaction
patterns involving intermediaries.  These are identified below:

(this is not intended to be a complete list)

Key: S = Sender, P = Processor/Responder, I = Intermediary, + = cardinality
"one or more"

[1]
Name:    One-Way Direct
Pattern: S -> P

[2]
Name:    One-Way Intermediated
Pattern: S -> I+ -> P

[3]
Name:    Request/Response Direct
Pattern: S -> P
         S <- P
[4]
Name:    Request/Response Intermediated
Pattern: S -> I+ -> P
         S <- I+ <- P

Patterns [1], [2], and [3] are fairly simple.  Pattern [4] on the other hand
opens up several interesting scenarios.  These are identified below.

[4a]
Name:    Stack
Pattern: S -> I1
              I1 -> I2
                    I2 -> P
                    I2 <- P
              I1 <- I2
         S <- I1

[4b]
Name:    Loop
Pattern: S -> I1
              I1 -> I2
                    I2 -> P
         S <------------- P

Pattern: S -> I1
              I1 -> I2
                    I2 -> P
                    I3 <- P
              I4 <- I3
         S <- I4

[4c]
Name:    Partial Loop
         S -> I1 
              I1 -> I2
                    I2 -> P
              I1 <------- P
         S <- I1

[4d]
Name:    Mixed
         S -> I1
              I1 -> I2
                    I2 -> P
                    I3 <- P
              I1 <- I3
         S <- I1                    

> If a given intermediary is the 'target' for more than one 
> extension block in
> an XP message does a processing order need to be defined and 
> is so how do we
> define it?
> 

Yes, a processing order needs to be defined. As to how to go about doing
that, right now I have no suggestions.

> In terms of addressing intermediaries it's my feeling that we need to
> address ( ahem ) the following cases;
> 
>       a) absolute addressing ( must go to machine A )
>       b) by group ( must go to one of machine X, Y or Z )
>       c) by class ( must go to a machine running Windinux )
> 
> 

I feel consideration also needs to be given to the definition of the Message
Path itself.  In other words:  Will the message path for an XP message be
determined solely by the contents of the message (intermediaries identified
in the block) or will the Message Path have to be predetermined by the
application service.  If the former, then the message must contain a defined
message routing path that includes absolute addressing of all processors
(intermediaries and final destination).  If the latter, then the message
must contain ID's that the application service can use to identify the
blocks intended for particular processors.  

> So, coming to the purpose of this discussion which was to 
> provide a new
> definition for XP intermediary here are few possibilities;
> 
> 1.    Taken from Hugo's mail ( thanks Hugo! )
> 
>   An XML Protocol intermediary is an application which processes a
>   defined set of blocks in an XML Protocol message along an XML
>   Protocol message path. It acts both as an XML Protocol receiver and
>   an XML Protocol sender in order to forward the XML Protocol message
>   towards the ultimate XML Protocol destination.
> 
> 2.    Slight amendment to the above to add notion of addressability
> 
>   An XML Protocol intermediary is an application, addressable from
>   within an XML Protocol message, which processes a defined set of
>   blocks in an XML Protocol message along an XML Protocol 
> message path.
>   It acts both as an XML Protocol receiver and an XML Protocol sender
>   in order to forward the XML Protocol message towards the ultimate
>   XML Protocol destination.
> 
> 
> 3.   Slight amendent to 3 to make the possibility of multiple 
> intermediaries
> more explicit
> 
>   An XML Protocol intermediary is an application, addressable from
>   within an XML Protocol message, which processes a defined set of
>   blocks in an XML Protocol message along an XML Protocol 
> message path.
>   It acts both as an XML Protocol receiver and an XML Protocol sender
>   in order to forward the XML Protocol message to the next recipient
>   in the message path which may be another XML Protocol intermediary
>   or the ultimate XML Protocol destination.
> 
> 
> Thoughts, comments, flames etc. all welcome...
> 
> Gudge
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0006.html
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0011.html
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0026.html
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0021.html
> [5] http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0023.html
> 
> 
> 
>

Received on Wednesday, 7 February 2001 11:47:58 UTC