- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Sat, 05 Jun 2004 08:19:53 -0700
- To: Ugo Corda <UCorda@SeeBeyond.com>
- Cc: Marc Hadley <Marc.Hadley@Sun.COM>, Jonathan Marsh <jmarsh@microsoft.com>, www-ws-desc@w3.org, xml-dist-app@w3.org
- Message-ID: <40C1E499.8040204@webmethods.com>
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:20:03 UTC