W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

RE: Describing which blobs are to be optimized.

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Sat, 5 Jun 2004 08:41:51 -0700
Message-ID: <EDDE2977F3D216428E903370E3EBDDC9032B8B24@MAIL01.stc.com>
To: "Prasad Yendluri" <pyendluri@webmethods.com>
Cc: "Marc Hadley" <Marc.Hadley@Sun.COM>, "Jonathan Marsh" <jmarsh@microsoft.com>, <www-ws-desc@w3.org>, <xml-dist-app@w3.org>
Prasad,
 
My point is that in general it is not clear whether the MTOM
optimization is done for the benefit of the client(s), the server, or
both. It's easy to think of situations where it is irrelevant to the
server whether messages are optimized or not, but it is crucial to the
client that they are. Likewise, other situations might represent the
opposite case. Depending on the application and the deployment
environment for the service and corresponding client(s), it is
reasonable to assume that in some cases the WSDL was created out of the
collaboration of both the server provider and its client(s). In such a
collaboration, it is conceivable that, in some cases, the server
provider agreed to provide MTOM optimization not for its own benefit but
for the benefit and under the request of its client(s).
 
Going back to Marc's original questions, I think it is impossible to
say, by just looking at a WSDL file, whether it is the client(s) or the
server that prefer to have messages optimized. It all depends on the
particular application and its associated deployment environments.
 
Ugo

	-----Original Message-----
	From: Prasad Yendluri [mailto:pyendluri@webmethods.com] 
	Sent: Saturday, June 05, 2004 8:20 AM
	To: Ugo Corda
	Cc: Marc Hadley; Jonathan Marsh; www-ws-desc@w3.org;
xml-dist-app@w3.org
	Subject: Re: Describing which blobs are to be optimized.
	
	
	Ugo,
	
	Ugo Corda wrote:
	

		Hi Prasad,
		I am not sure what you mean by "WSDL still represents a
contract from the service perspective". In my view, WSDL represents a
mutual contract that equally binds both the client and the server.

	Exactly what I said. WSDL represents the description of what the
service provides (the interfaces, operations etc.) and how the service
can be accessed by the clients. Not a client describing what a service
needs to provide it.  The service is bound to what it describes to
offer; and how and the client to, what the service requires / expects
from the client.
	

		
		If we are talking about who really desires the MTOM
feature, that should be whoever wrote the WSDL and introduced the
request for that feature. And, as I mentioned before, that could either
be the client or the server provider.

	It does not matter if the client had influence in what  the
service offers and how. WSDL description does not have any formal
representation of it and things need to be interpreted as what the
service offers and expects from (all) clients (not just the one
influenced, it if at all).
	

		 
		Regards,
		Ugo

			-----Original Message-----
			From: Prasad Yendluri
[mailto:pyendluri@webmethods.com] 
			Sent: Friday, June 04, 2004 7:45 PM
			To: Ugo Corda
			Cc: Marc Hadley; Jonathan Marsh;
www-ws-desc@w3.org; xml-dist-app@w3.org
			Subject: Re: Describing which blobs are to be
optimized.
			
			
			Hi Ugo,
			
			Ugo Corda wrote:
			

				Prasad,
				You are assuming that the WSDL was
defined by the server provider. 

			No, I was not assuming that. Even if the service
(and hence the WSDL) was defined to meet the requirements of a client, 
			the WSDL still represents a contract from the
service perspective. If it was defined to meet the client requirement,
we have 
			the best case scenario; the client and server
have the same understanding (for a change ;)
			

				That
				should not necessarily be the case. The
typical use case is the one
				where the user of the service dictates
the WSDL details to the server
				provider (e.g. Walmart asking one of its
partner to provide a service
				that satisfies a WSDL interface as
specified by Walmart). In that case,
				the optimization requirements come from
the user, not the provider.
				
				Ugo
				
				  

				-----Original Message-----
				From: www-ws-desc-request@w3.org 
				[mailto:www-ws-desc-request@w3.org] On
Behalf Of Prasad Yendluri
				Sent: Friday, June 04, 2004 5:27 PM
				To: Marc Hadley
				Cc: Jonathan Marsh; www-ws-desc@w3.org;
xml-dist-app@w3.org
				Subject: Re: Describing which blobs are
to be optimized.
				
				
				
				Since it is the server that is marking
this optional, my 
				interpretation 
				would be that the server prefers to send
and receive optimized 
				serializations but the client is not
required oblige it. If 
				the client 
				does not initiate with an optimized
serialization then the 
				server SHOULD 
				not use the optimization. I agree the
semantics of "optional" 
				nature of 
				this feature need to be captured
properly.
				
				Regards, Prasad
				
				Marc Hadley wrote:
				
				    

				On a related note I'm unclear on the
semantics implied by 
				      

				marking the
				    

				MTOM/XOP feature as optional. I can see
several interpretations:
				
				(i) a service will never use it but a
client may
				(ii) a service will not use it unless
client does first
				(iii) a service will always use it but a
client isn't obliged to
				
				Marc.
				
				On Jun 4, 2004, at 2:27 PM, Jonathan
Marsh wrote:
				
				      

				The WS Description WG is working through
an issue (#207 
				        

				[1]), which 
				    

				is XOP-related.  As we communicated to
you earlier [2], 
				        

				the ability 
				    

				of a service to accept and transmit XOP
can be indicated by 
				indicating the HTTP Transmission
Optimization Feature is in use 
				through the WSDL feature syntax.  This
syntax also allows the MTOM 
				feature to be "required", which we
interpret as, the 
				        

				service must be 
				    

				sent a XOP envelope and media type,
though XOP itself doesn't 
				constrain which parts of the XML within
that envelope have been 
				optimized (it could be none).
				
				A question arises ([3] continuing on
[4]) that if XOP is required, 
				whether it further makes sense to say
precisely which parts of the 
				message are to be optimized.  As we
understand it, this allows a 
				service to place additional restrictions
on the use of XOP beyond 
				what the XOP spec describes, but not
leaving it completely 
				        

				up to the 
				    

				application layer.  These additional
restrictions could be 
				        

				along the 
				    

				lines of "anything marked with an
expectedMediaType 
				        

				attribute must be 
				    

				optimized", to a fine level of
granularity through an 
				xop:optimize="true" attribute on the
schema.
				
				The working group has a preference
(straw poll 7 to 4 [5]) to 
				indicate in some fashion which parts
must be optimized.  However, 
				since you own the HTTP Transmission
Optimization Feature, 
				        

				we wanted 
				    

				to ask you two
				questions:
				
				1) Do you feel that such descriptive
hints would be useful 
				        

				or is it 
				    

				contrary to the expected usage patterns
of XOP?
				2) If it is useful, would you be willing
to describe these hints, 
				including introducing syntax, in the
MTOM or XOP specs?  
				        

				(Splitting a 
				    

				feature and it's descriptive hints
across multiple specs seems 
				suboptimal to us.)
				
				[1]
http://www.w3.org/2002/ws/desc/2/06/issues.html#x207
				[2] 
				        

	
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0077.html
				    

				[3] 
				        

	
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0089.html
				    

				[4] 
				        

	
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0000.html
				    

				[5] 
				        

	
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0019.html
				    

				---
				Marc Hadley <marc.hadley at sun.com>
				Web Products, Technologies and
Standards, Sun Microsystems.
				      

				    

				
				  
Received on Saturday, 5 June 2004 11:42:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT