RE: Issue 7 - processing model for SOAP headers

Inline...

> > If I get an URI out of a repository, I agree with you that 
> there might 
> > be a context there to help me process. If I get a URI on 
> the wire as I 
> > am network device, where is my context?
> 
> <TE>
> Depends where/how you got the URI. If it was embedded in 
> anchor tag in an (X)HTML page it's a link that can be 
> dereferenced. If it appears in a namespace declaration, it is 
> an opaque identifier of a namespace that may or may not be 
> dereferencable. My point is, there is always some context, 
> unless someone builds a service that simply returns a URI 
> with no other information, which is likely to be useless.
>  </TE>
> > The resolution of the logical to physical is part of the 
> network and 
> > is dynamic so I cannot use another intermediary for that 
> like the DNS 
> > or something.
> 
> <TE>
> I don't understand why not. The mapping of DNS names to IP 
> addresses is dynamic and uses a well-known lookup mechanism. 
> The same could be done TE) here.
> </TE>
> 
> DNS is not dynamic. Once you fix the name it takes upto 24 
> hours to propagate and you cannot change it lets say for 
> every transaction. So it is dynamic with turnaround time of 
> over 24 hours. That is not acceptable in a real-time enterprise. 

DNS is dynamic, though not dynamic enough in some case ;-) I should have
said we could do something similar, but not the same.

> > Let's step back for a moment to recap where I am coming from. 
> > 
> > I read in the Core Spec of WSA 1.0 that "[address]: URI 
> (Mandatory). 
> > It says this address is logical/physical". The resolution of this 
> > logical address to physical address should depend upon it's 
> binding to 
> > the wire transport. So in the WSA-SOAP binding it should 
> define how a 
> > logical address can be resolved to physical. If the binding 
> was some 
> > other transport then that transport should define the resolution.
> > 
> > My recommendation is either we should remove the text which says 
> > "logical/physical" in the core spec and say the address is logical 
> > ONLY and the transport binding will specify how to resolve 
> it down to 
> > physical.
> > Alternative is to assume that transport at the end of the 
> day is HTTP 
> > and that the address is physical.
> 
> <TE> I don't think that we should limit ourselves to HTTP 
> only traffic or assume that the wsa:To is a physically 
> reachable URL. Instead, the binding should define the mapping 
> from the logical to the physical, as the wording from the 
> spec suggests. So I think we're in agreement.
> </TE>
> 
> Actually I am suggesting that the WSA-Core spec say it should 
> be logical only. That way the WSA-SOAP-BINDING spec will 
> decide the physical address.
> Currently the WSA-Core spec says it is logical or physical. 
> BTW the wsa:To as per the spec is after the binding of a EPR 
> defined in WSA-Core to SOAP and therefore should be physical. 
> The logical address as defined in WSA-Core is the wsa:address 
> and that should be logical only. Atleast that is how it reads 
> in the specs that I downloaded.

Yes, you are correct. I was being sloppy in my use of wsa:To. I think we are
in agreement that the WSA-Core spec should deal with logical endpoints and
the mapping to the physical should be in the binding.
 
> > Now let's say all address are now logical and my transport binding 
> > resolves it to physical. Then a message is likely to travel 
> multiple 
> > transports. It is for this reason, that I need the 
> 'physical' address 
> > of the original destination. As I have no way to keep state 
> > information of how many transport hops this message took to 
> get to me.
> 
> <TE>
> This part I don't understand. I assume that like IP routing, 
> the mapping from logical to physical would be done in a 
> series of steps. As long as each node (may or may not be a 
> SOAP intermediary) can map the logical To to the physical 
> address for the next hop, the message will move along making 
> as many hops over as many transports as necessary. 
> 
> </TE>
> 
> You are right we can determine the forward hop physical 
> address given a logical address and its forward binding. The 
> problem is in finding the physical address of the original 
> sender. The binding of WSA:Source Endpoint from WSA-Core spec 
> to SOAP. Let's say we are talking about a business process 
> which was triggered by an email sent to node which in turn 
> issued SOAP messages to consummate the transaction. In this 
> case being an intermediary, I would need to send an 
> acknowledgement to the original sender. Since the sender is 
> on physical SMTP address, I would need to send an email. But 
> if I have the logical address without any historical 
> information on the message path, I cannot come up with a 
> physical address.
> Here the analogy with IP breaks down. 

Yes, I agree that you need a physical address for the message source, but
not for the destination. That we can get by the forward binding. You still
don't need the physical address of the original destination, which is what
confused me in your earlier post.
 
> <TE>
> Maybe another way to look at
> it is that in a sense, the logical URI used in the wsa:To 
> *is* a physical address the same sort of way that a DNS name 
> is a physical address. You can program against a machine 
> using it's DNS name without knowing where it actually lives 
> or even what it's IP address is.
> </TE>
> 
> Actually, I am suggesting that since WSA is a higher level 
> abstraction than the transport, it should not use any 
> physical address or it's associate naming scheme. It should 
> simply give a logical address that when combined with the 
> binding gives its physical address for the next hop. I think 
> on this point, we are saying the same thing. It is just that 
> the spec does not say what we are saying. 

Yes, I agree!
 
> Overall, I am sure we can work around this at the cost of 
> interoperability, but that would defeat the purpose of the specs. 

The spec needs to be absolutely clear on this.

Thanks,
Tim-

Received on Tuesday, 18 January 2005 19:37:24 UTC