- From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Date: Mon, 1 Mar 2010 22:22:56 +0000
- To: Doug Davis <dug@us.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <503546C5699C1144BDEA0D0DFFE7F881229AFF96@TK5EX14MBXC112.redmond.corp.microsoft.>
> and add text that says the extra binding information (ie. soap version) is implies by the context in which the EPR was provided.
On the issue about the example in section 12: I like to suggest [1]. This allows any extra binding information to be made available by the context in which the EPR was provided (as Doug states above) or could be also provided explicitly (a simpler form of what I had suggested earlier). For the purposes of progressing the MOAP issue, [1] seems sufficient to me. If we need to analyze this some more, I suggest we explore it further in the future - perhaps we can do that as a Last Call issue to refine this example further.
Does this seem reasonable?
Thanks.
[1] Suggested text for issues on example in Section 12
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>
(03) <wsa:Metadata>
(04) <wsp:Policy>
(05) <mex:MetadataExchange/>
(13) </wsp:Policy>
(14) </wsa:Metadata>
(15) </wsa:EndpointReference>
The policy assertion at line 05 in Example 12-1 indicates to consumers of this EPR that the GetWSDL operation is supported by the referenced Service Endpoint. The parameters described in Section 11 WS-MetadataExchange Metadata could be added to the policy assertion at line 05 to indicate additional capabilities such as support for the mex:GetMetadata operation. Extra binding information (such as SOAP version) could either be implied by the context in which the EPR was provided or could be conveyed as in Example 12-2.
Example 12-2: Endpoint reference to a Service Endpoint that supports mex:GetWSDL
(01) <wsa:EndpointReference ... >
(02) <wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03) <wsa:Metadata>
(04) <wsp:Policy>
(05) <mex:MetadataExchange/>
{06) <wsdl:definitions ...>
(07) <!- Binding information -->
(08) </wsdl:definitions>
(09) </mex:MetadataExchange>
(10) </wsp:Policy>
(11) </wsa:Metadata>
(12) </wsa:EndpointReference>
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Thursday, February 25, 2010 7:25 AM
To: public-ws-resource-access@w3.org
Subject: RE: MOAP v2
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<http://services.example.org/stockquote%3c/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<http://services.example.org/stockquote%3c/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<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.
Asir Vedamuthu <asirveda@microsoft.com<mailto:asirveda@microsoft.com>>
02/25/2010 12:44 AM
To
Doug Davis/Raleigh/IBM@IBMUS, Ram Jeyaraman <Ram.Jeyaraman@microsoft.com<mailto:Ram.Jeyaraman@microsoft.com>>
cc
"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>>
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> [mailto:public-ws-resource-access-request@w3.org]<mailto:[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<mailto: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<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/24/2010 10:16 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
"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>>
Subject
RE: MOAP v2
Yes, the WSDL is child to the mex:MetadataExchange assertion. Thanks.
From: Doug Davis [mailto:dug@us.ibm.com]<mailto:[mailto:dug@us.ibm.com]>
Sent: Tuesday, February 23, 2010 3:30 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org<mailto: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.
________________________________
Received on Monday, 1 March 2010 22:23:41 UTC