W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2001

RE: Thoughts about path and intermediaries

From: Satish Thatte <satisht@microsoft.com>
Date: Thu, 15 Feb 2001 09:30:37 -0800
Message-ID: <EC67B042372C27429014D4FB06AC9FAF2D7417@red-msg-29.redmond.corp.microsoft.com>
To: "'Noah_Mendelsohn@lotus.com'" <Noah_Mendelsohn@lotus.com>, Martin Gudgin <marting@develop.com>
Cc: Frystyk <frystyk@microsoft.com>, XML Protocol Comments <xml-dist-app@w3.org>
I haven't followed this whole thread, but another related point occurs to me
that may not have been raised.

An intermediary is a "stop" on my path.  An actor is a service or functional
unit of some kind.  There is no a priori reason to assume a one-to-one
relationship between the two.  In particular, an intermediary may provide
several "actors", e.g., both a logging and a store-and-forward service.

Just a thought.


-----Original Message-----
From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
Sent: Thursday, February 15, 2001 8:46 AM
To: Martin Gudgin
Cc: Frystyk; XML Protocol Comments
Subject: Re: Thoughts about path and intermediaries

Marting Gudgin writes:

>> I'm sorry, I still don't get it. I can't see how 
>> soap:actor works. How does putting a URI on a 
>> part of the message help me if I don't get to stipulate
>> that the message has to go via that URI? 

At the risk of somewhat muddying the waters, this reminds me of a 
distinction that I have been drawing in my own mind, and which may or may 
not in fact be a good one: I tend to think of the identities of actors as 
being in principle distinct from the binding specific URIs that one might 
actually use to transmit a message.

One way to motivate this is to consider a situation in which two 
applications happen to be connected by two parallel bindings, perhaps one 
HTTP and one a queuing system.  I think I would expect to see in the actor 
attribute a URI that identified the receiving application or code (I think 
we have a term for this but I forget what it is) in the abstract.  So, 
this header might be directed to the transaction manager inside my 
application (not the transaction manager has reached by HTTP as distinct 
from the transaction manager as reached by the queuing system).  As I have 
previously suggested, there may be a useful role for some notion of path 
or partial order expressed at this level: which headers must be processed 
ahead of which others.

Now, I would assume that the SOAP implementation at the sending end would 
be aware of the multiple delivery strategies available from the two 
bindings, and would in fact actually send the message along the "physical" 
path by directing it to the appropriate binding-dependent URI.  In 
general, I would assume that headers would be generated and actors 
identified far in advance of any knowledge of the actual interconnection 
technology used to deliver the message.  This is particularly true in 
scenarios were messages to travel across organizational boundaries: I 
certainly do not want you to know if I have changed my internal delivery 

So in summary, the notion of path that interests me at the moment, if any, 
is at the abstract level of headers and actors.  In any case, I would 
welcome discussion of my presumption that actors are, at least in the 
general case, named at a level that is potentially independent of 
particular bindings or physical end points.  Of course, nothing would 
prevent one from basing an actor name on a binding-specific URI in 
situations where that is in fact a sensible strategy.  Comments?

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Thursday, 15 February 2001 14:40:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC