Re: MOAP v2

This problem (how to indicate which SOAP version to use) is old. I first 
saw it in the OASIS WS-RX Working Group when we tried to figure out what 
version of SOAP should be used for the CreateSequence exchanges and the 
SequenceAck messages, and it was an old problem then. Given that there 
will be situations in which there simply isn't enough contextual 
information to make the determination on which SOAP version to use or 
such contextual information would lead to the wrong conclusion (i.e. the 
minter of the EPR wants something other than the "obvious" version) it 
seems that we face a choice between creating some new assertions that 
indicate the version or including lots of mini-WSDLs all over the place.

There is another option that I have been thinking about. We could use 
the value of the @URL attribute of the mex:Location element as a unique 
identifier to indicate the use of specific SOAP versions. That is, for 
WS-MEX (and each of WS-Eventing, WS-Enumberation, and WS-Transfer), we 
could define three WSDLS:

1.) http://www.w3.org/2002/ws/ra/edcopies/ws-mex/metadataexchange.wsdl 
-current abstract WSDL

2.) 
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/soap11/metadataexchange.wsdl - 
includes above WSDL and binds it to SOAP 1.1 (no other changes from 
abstract WSDL)

3.) 
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/soap12/metadataexchange.wsdl - 
includes above WSDL and binds it to SOAP 1.2 (no other changes from 
abstract WSDL)

An EPR that wanted to advertise that it supported MEX using SOAP 1.2 
would look like this:

<wsa:EndpointReference>
<wsa:Address>http://services.example.org/stockquote</wsa:Address>
<wsa:Metadata>
<wsp:Policy>
<mex:MetadataExchange>
<mex:Location 
URL="*http://www.w3.org/2002/ws/ra/edcopies/ws-mex/soap12/metadataexchange.wsdl*"/>
</mex:MetadataExchange>
</wsp:Policy>
</wsa:Metadata>
</wsa:EndpointReference>

Note that you don't actually have to do an HTTP GET on 
"http://www.w3.org/2002/ws/ra/edcopies/ws-mex/soap12/metadataexchange.wsdl" 
to know that SOAP 1.2 is supported. The MEX spec would call out that URI 
as a "pre-defined WSDL location" with specific semantics (i.e. "this is 
the abstract WS-MEX portType bound to SOAP 1.2"). On the other hand, if 
the client didn't support the idea of "pre-defined WSDL locations" and 
actually did an HTTP GET, we would make sure that the W3C put the 
correct WSDL there and things would still work.

The main problem with this idea is that it isn't a general solution. It 
could be made to work for WS-Eventing, WS-Enumeration, WS-Transfer, and 
WS-MEX because we control the specs for these and can add normative 
definitions of these URIs and publish the appropriate WSDLs. It won't 
work for things like WS-RM (unless the WS-RX WG agreed to publish an 
errata that defined the new URIs), it won't work for things like the 
Notification/EndTo EPRs, and it won't work in the case of a generic, 
unknown services, because there is no way for the client to know 
anything about the service (if there were, we wouldn't be in the 
"bootstrap" use case).

- gp

On 2/25/2010 7:25 AM, Doug Davis wrote:
>
> Let's take a step back here.
>
> First, I don't think this issue is really just about bootstrapping. 
>  Sure MEX is critical in being able to get more metadata about how to 
> interact with the endpoint, but unless we expect clients to _always_ 
> ask for the WSDL at runtime before they invoke any operation 
> (application or feature operation) I think we need accept the notion 
> that there are times when people are given an EPR and they know what 
> they want to use it for and what operations they're going to invoke. I 
> would claim that this happens more often than not - and that the only 
> bit of extra information the client wants/needs is the EPR+QoS options 
> for the particular endpoint they're going to hit.  In these cases, 
> while obviously retrieving the WSDL from the endpoint will get this 
> information, just as embedding the WSDL for all QoS/Features into the 
> EPR (under the appropriate policy assertion) will work too, I think 
> both of these options are not only verbose but overkill.
>
> Second, what's really missing from the example as it currently stands? 
>  As far as I can tell the only bit of info we need is the soap 
> version.  We know the transport info from the wsa:Address.  We'll know 
> if the MEX operations need to be secured by any security policy 
> assertions under the MEX assertion ( section 9 of mex.moap tells us 
> this).  So, are we really suggesting that the pattern people need to 
> follow when they want to have the client avoid the overhead of doing 
> more metadata retrieval is to include the WSDL for each Feature in the 
> EPR?  Even if all that's missing is the soap version?  If an EPR 
> includes policy for RM, Eventing, MEX, Security, Tx, Enum and Transfer 
> do we really want people to have to include the WSDL for each of these 
> Features in the EPR just so they can get the soap version for those 
> Feature specific operations?  I hope not.
>
> For our purposes I think there are two ways to look at EPRs:
> 1 - The EPR doesn't live in a vacuum.
> The EPR was given to the client in some context and that context will 
> (implicitly) provide the missing binding information.  For example, 
> what soap version should people use when sending Notifications?  While 
> the spec is silent on this, I bet most people will use the same soap 
> version that carried the wse:NotifyTo.  But of course, this isn't 
> required, nor should it be.  There will be plenty of times when the 
> Event Source supports both versions of soap and the Subscriber is 
> issuing the Subscribe() on behalf of someone else - and that someone 
> else wants their Notifications in a different version than the 
> Subscribe message.  Or in the case of the Sink pulling messages, it 
> might not even know what version of soap the Subscriber used.  The 
> point here is that there are lots of times when we make assumptions 
> about how to use an EPR based on how it was provided to us.  I think 
> in most cases this is sufficient and for those times I think the 
> example (w/o the wsdl) has all the info needed for the client to use 
> MEX or the EPR itself.
>
> 2 - The EPR lives in a vacuum.
> The EPR was given to the client in some way that there aren't those 
> "hints" I referred to in point #1.  This then leads me back to the 
> points above... what's really missing from this EPR in order for the 
> client to take the next step?  And yes in this example the next step 
> might be to use MEX, but in the more general case its to use one of 
> many possible QoS features.  Perhaps its to setup an RM sequence, or a 
> Transaction.  Who knows.  The point is, in the simple (and most common 
> cases) all that's missing from EPRs like the one listed in the example 
> is the soap version (assuming it can't be implies because we're living 
> in a vacuum :-).
>
> So, this is a long way of saying that perhaps we should look for a 
> much simpler solution to all of this and just define a new assertion 
> that provides us this one missing bit of information - the soap 
> version.  Something like:
>
> <mex:SOAP11/>  or <mex:SOAP12/>
>
> And like all assertions, its location indicates its scope and 
> applicability.
>
> So:
> <wse:NotifyTo>
> <wsa:Address> mysink.com </wsa:Address>
> <wsa:Metadata>
> <wsp:Policy>
> <wsrmp:RMAssertion/>
> <mex:SOAP12/>
> </wsp:Policy>
> </wsa:Metadata>
> </wse:NotifyTo>
>
> This indicates that the Notifications are to be sent using RM and 
> SOAP12.  The only other option is to include the Notification WSDL 
> under this EPR.  While technically possible - that sure seems like 
> overkill to me and will only help cement the idea that SOAP is just 
> too complex.  Notice too that this EPR is a bit simplistic (like the 
> example we're discussing) in that it only includes one assertion.  As 
> I discussed above, if there were several Feature assertions do we 
> really want to force people to include the WSDL for each?  Having just 
> one SOAP assertion as a sibling to these assertions (as shown above) 
> would mean that all of the Features use SOAP12 - and in most cases I 
> think its true that the soap version would apply to all operations to 
> an EPR.
>
> Also, the minter of the EPR might not always know how its going to be 
> used - it might be asked to create a reference to itself without even 
> knowing the Notification WSDL (or even knowing about eventing at all) 
> so asking it to insert it might be a bit odd and mixing of purposes.
>
> Notice something else, and this is a point that I think the developers 
> in the group will appreciate, above I talked about how people 
> sometimes make assumptions about how to use the EPR based on how it 
> was provided.  So, in this NotifyTo case if we want to send the 
> Notifications using the same soap version as the Subscribe message 
> then the implementation would be forced to carry around the soap 
> version information with this EPR.  By defining a new assertion, this 
> information can now be included within the EPR (in a standardized way) 
> and we're back to the model where the EPR contains all of the SOAP and 
> Transport information needed by the sender to get its job done.  I 
> think its a much cleaner design.
>
> Anyway, back to this example.  I'd prefer if it ended up looking like:
> #1:
> <wsa:EndpointReference ... >
> <wsa:Address>http://services.example.org/stockquote</wsa:Address>
> <wsa:Metadata>
> <wsp:Policy>
> <mex:MetadataExchange/>
> </wsp:Policy>
> </wsa:Metadata>
> </wsa:EndpointReference>
>   and add text that says the extra binding information (ie. soap 
> version) is implies by the context in which the EPR was provided.
>
> or
> #2:
> <wsa:EndpointReference ... >
> <wsa:Address>http://services.example.org/stockquote</wsa:Address>
> <wsa:Metadata>
> <wsp:Policy>
> <mex:MetadataExchange/>
> <mex:SOAP12/>
> </wsp:Policy>
> </wsa:Metadata>
> </wsa:EndpointReference>
>   and define some new SOAP assertions.
>
> Or we could include both along with Ram's and explain when each one 
> might be needed.  For example, I can see Ram's being useful in cases 
> where there are operational bits of metadata needed to be conveyed - a 
> more advanced case.  While #2 is good in cases where we're in a vacuum 
> (or just want to be explicit) and we only have Endpoint level policy. 
>  And #1 is for when there's contextual information that provides the 
> missing soap version.  Personally, I think #2 will be the most common 
> case, but your milage may vary.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *Asir Vedamuthu <asirveda@microsoft.com>*
>
> 02/25/2010 12:44 AM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS, Ram Jeyaraman 
> <Ram.Jeyaraman@microsoft.com>
> cc
> 	"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> Subject
> 	RE: MOAP v2
>
>
>
> 	
>
>
>
>
>
> > When the WSDL is not included then the binding information for the 
> MEX operations would default to be the same as the binding information 
> for the stockquote EPR itself.
>
> The quoted example below is a bootstrap case (in section 12 in the 
> MOAP proposal). The binding information for the 'stockquote' EPR is 
> NOT known.
>
> Regards,
>
> Asir S Vedamuthu
> Microsoft Corporation
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug 
> Davis*
> Sent:* Wednesday, February 24, 2010 7:28 PM*
> To:* Ram Jeyaraman*
> Cc:* public-ws-resource-access@w3.org*
> Subject:* RE: MOAP v2
>
>
> Unless we want the example to show a more advanced case of the WSDL 
> being different from the MEX WSDL in the spec (e.g. having a different 
> EPR), I would suggest that we keep it simple and not include the WSDL. 
>  When the WSDL is not included then the binding information for the 
> MEX operations would default to be the same as the binding information 
> for the stockquote EPR itself.  There really isn't any other choice - 
> but perhaps we could make this assumption more explicit by adding 
> something to the section of MEX that talks about policy within an EPR.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
> *Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>*
>
> 02/24/2010 10:16 PM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS
> cc
> 	"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> Subject
> 	RE: MOAP v2
>
>
>
>
> 	
>
>
>
>
>
>
> Yes, the WSDL is child to the mex:MetadataExchange assertion. Thanks.
> *
> From:* Doug Davis [mailto:dug@us.ibm.com] *
> Sent:* Tuesday, February 23, 2010 3:30 PM*
> To:* Ram Jeyaraman*
> Cc:* public-ws-resource-access@w3.org*
> Subject:* RE: MOAP v2
>
>
> Ram - did you mean for the WSDL to be a child of the 
> mex:MetadataExchange assertion?
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  | _dug@us.ibm.com_ 
> <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *Ram Jeyaraman <**_Ram.Jeyaraman@microsoft.com_* 
> <mailto:Ram.Jeyaraman@microsoft.com>*>*
>
> 02/23/2010 03:16 PM
>
> 	
>
>
> To
> 	Doug Davis/Raleigh/IBM@IBMUS, "_public-ws-resource-access@w3.org_ 
> <mailto:public-ws-resource-access@w3.org>" 
> <_public-ws-resource-access@w3.org_ 
> <mailto:public-ws-resource-access@w3.org>>
> cc
> 	
> Subject
> 	RE: MOAP v2
>
>
>
>
>
> 	
>
>
>
>
>
>
> I like to suggest an addition to MEX Example 12-1 to show how to 
> specify the binding information. The additions are highlighted below. 
> Thanks.
>
> *Example 12-1: Endpoint reference to a Service Endpoint that supports 
> mex:GetWSDL*
>
> (01) <wsa:EndpointReference ... >
>
> (02) 
> <wsa:Address>_http://services.example.org/stockquote</wsa:Address_ 
> <http://services.example.org/stockquote%3c/wsa:Address>>
>
> (03) <wsa:Metadata>
>
> (04) <wsp:Policy>
>
> (05) <mex:MetadataExchange/>
>
>  (06) <wsdl:definitions name='StockQuoteMetadataExchangeMetadata'
>
>   (07)                 
>  targetNamespace='http://services.example.org/stockquote/metadata'
>
> (08)                  xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
>
> (09)                  xmlns:mex='http://www.w3.org/2009/09/ws-mex'
>
> (10)                  xmlns:wsp='http://www.w3.org/ns/ws-policy'
>
> (11)                 
>  xmlns:wsoap12='http://schemas.xmlsoap.org/wsdl/soap12/'>
>
> (12) <wsdl:import namespace='http://www.w3.org/2009/09/ws-mex'
>
> (13)                               
> location='http://www.w3.org/2009/09/ws-mex/metadataexchange.wsdl' />
>
> (14) <wsdl:binding name='MetadataExchangeBinding' 
> type='mex:MetadataExchange'>
>
> (15) <wsp:PolicyReference
>
> (16)                               
> URI='http://services.example.org/stockquote/MetadataExchangePolicy' />
>
> (17) <wsoap12:binding transport='http://schemas.xmlsoap.org/soap/http' />
>
> (18)                        ...
>
> (19) </wsdl:binding>
>
> (20)                   ...
>
> (21) </wsdl:definitions>
>
> (22) </wsp:Policy>
>
> (23) </wsa:Metadata>
>
> (24) </wsa:EndpointReference>
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug 
> Davis*
> Sent:* Tuesday, February 23, 2010 11:45 AM*
> To:* public-ws-resource-access@w3.org*
> Subject:* MOAP v2
>
>
> All,
> after several rounds of talks between Oracle, Microsoft and IBM, the 
> latest version of MOAP can be found here: 
> _http://www.w3.org/2002/ws/ra/10/02/MOAPv2.zip_
>
> The zip file contains all proposed spec changes and the changes include: *
>
> WS-EVD*: no changes since last time *
>
> WS-Eventing/Enum/Frag/Transfer* - look for edits done by "Dugv5":
> - Only minor wordsmithing/editing to the definitions of the assertions *
>
> WS-MEX:*
> - there are two MEX docs in the zip file.
> - the v1 version is the one sent to the WG a few weeks ago - no new 
> edits were made.
> - the v6 version contains all of the edits since v1.  All v1 edits 
> were "accepted" so it should be easy to see the diff from v1.
> - the edits were done in stages so that's why you'll see several Dugv? 
> names.  It wasn't until round 4 of edits that I remembered to change 
> the user name.
>
> The MEX edits include:
> - lots of minor editorial tweaks
> - there's a new Terminology section.  This was added because it was 
> felt that the two roles ('service endpoint' and 'metadata resource') 
> needed to be defined and clarified.  People should read/review this 
> carefully.
> - the assertion was modified to advertise whether GetMetadata is 
> supported - and the Dialect/Content params are now under 
> GetMetadataSupported.
> - there's a new section 12 about Bootstrapping.  This section was 
> added to pretty much put all of the various pieces of the puzzle 
> together when trying to bootstrap the process of talking to an endpoint.
> - updated the xsd/wsdl for GetWSDL
>
> Note: I'm planning on moving section 5 before section 4.  This will 
> make it so that we define the new mex:Metadata type before we use it. 
>  I didn't move it in the doc because then it would show up as modified.
>
> Outstanding MEX issues for the WG to discuss:
> - Example 8-5 - see comments in the doc
> - Example 12-1 - see comment in the doc
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  | _dug@us.ibm.com_ 
> <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
>
>
> ------------------------------------------------------------------------
>
>