Re: Describing which blobs are to be optimized.

On Jun 5, 2004, at 11:41 AM, Ugo Corda wrote:
>  
> 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.
>
That wasn't the question I asked. I want to know the semantics implied 
by including the feature but marking it as optional. Regardless of 
client/server preference for use of the feature, its essential that the 
meaning of this is completely clear.

Marc.

> -----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.
>
>
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.

Received on Monday, 7 June 2004 08:57:57 UTC