RE: Reliable Messaging - Summary of Threads

You may certainly suggest adding that reference.  In fact, anticipating
your every desire, I in fact DID include that reference, labelled
"Multiple hops and intermediaries" -- which it seems to me is at least
in the same ballpark as "Identifying the ultimate receiver".  Multiple
hops to the ultimate receiver?
 
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com] 
Sent: Friday, December 13, 2002 12:37 PM
To: 'Ugo Corda'; Cutler, Roger (RogerCutler); www-ws-arch@w3.org
Subject: RE: Reliable Messaging - Summary of Threads


+1.
 
I also briefly discussed exactly this problem (see [1]) of identifying
what is the "ultimate receiver" in the SOAP sense as the sender of the
message often will never know, as it is the private concern of "B" as
Ugo describes below.
 
Can I suggest you add this as a reference to your otherwise excellent
summary.
 
David
 
[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0095.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0095.html>  -
Identifying the ultimate receiver.

	-----Original Message-----
	From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
	Sent: Friday, December 13, 2002 10:26 AM
	To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org
	Subject: RE: Reliable Messaging - Summary of Threads
	
	
	I was referring to the case where the SOAP-based communication
actually goes deeper inside the enterprise (probably over a MOM
transport). So when enterprise A targets a SOAP node at enterprise B,
this final node is not the Web server that connects B to the Internet,
but is actually a SOAP node internal to B, for which the Web server is
just a SOAP intermediary. One reason for doing this, for example, is
that the target node inside B might not always be available, so I want
to interpose an asynchronous connection (e.g. a queuing mechanism)
between the receiving Web server and the target node.
	 
	Of course, the segment between the Web server and the target
node inside B might not be implemented as a SOAP connection, so the
issue I am raising does not exist in that case (and A would not even see
that internal node as a target SOAP node). But I am making the
assumptions that more and more businesses will start using Web services
technologies inside the enterprise, so that the SOAP path will extend
(seamlessly, we hope) from outside to inside.
	 
	Ugo

		-----Original Message-----
		From: Cutler, Roger (RogerCutler)
[mailto:RogerCutler@ChevronTexaco.com]
		Sent: Friday, December 13, 2002 10:07 AM
		To: Ugo Corda; www-ws-arch@w3.org
		Subject: RE: Reliable Messaging - Summary of Threads
		
		
		No, I think that I am referring to B2B, but maybe I'm
not understanding what you are saying.  If you are tallking about the
firewall and proxies, I sort of consider that transparent.  Or something
that somebody else works out.  Somebody like people from SeeBeyond, I
guess.  That is, there is communication of some sort between the
backoffice stuff and a server that has access to the internet on my
side, and similarly on the other side, but the primary messaging is just
one hop between the B2B app on my server and the B2B app on the other
side.
		 
		Does this just display my ignorance?
		 
		-----Original Message-----
		From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
		Sent: Friday, December 13, 2002 12:03 PM
		To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org
		Subject: RE: Reliable Messaging - Summary of Threads
		
		
		Roger,
		 
		>There are MANY, MANY important business applications
that involve simple A<->B communication.
		 
		Are you referring to business applications within an
enterprise? Because it seems to me that as soon as you do B2B you are
likely to deal with intermediary nodes at the edge between Internet and
intranet, and to deal with different transports.
		 
		Ugo