- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Mon, 19 Feb 2001 16:14:47 +0100
- To: Noah_Mendelsohn@lotus.com
- CC: Martin Gudgin <marting@develop.com>, Henrik Frystyk Nielsen <frystyk@microsoft.com>, XML Protocol Comments <xml-dist-app@w3.org>
I would claim that identifying actors via binding-specific URIs is a degenerate case of the more general form of identification you propose. Indeed, let: * httpUri be the URI for the HTTP binding; * queueUri be the URI for the queue binding; * actorUri be the URI for the actor itself (let's call the actor Y). A sender X may reach Y through two different routes: * X -> httpUri -> actorUri -> Y * X -> queueUri -> actorUri -> Y In the degenerate case where Y is accessible only through HTTP, there is only one route: * X -> httpUri -> actorUri -> Y It is then probably an overkill to use two URIs to identify the same target; hence the reason for generally dropping one of them: * X -> httpUri -> Y Now the question becomes: what does the actorUri look like? It is a URN? Jean-Jacques. Noah_Mendelsohn@lotus.com wrote: > 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 > technologies. > > 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 Monday, 19 February 2001 10:15:48 UTC