Received: from tk5-exmlt-c102.redmond.corp.microsoft.com (157.54.24.67) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.21; Mon, 1 Mar 2010 14:24:55 -0800 Received: from SVC-EXGWY-E803.partners.extranet.microsoft.com (10.251.24.244) by TK5-EXMLT-C102.redmond.corp.microsoft.com (157.54.24.67) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 1 Mar 2010 14:24:34 -0800 Received: from mail186-tx2-R.bigfish.com (65.55.88.114) by mail06.microsoft.com (10.253.160.186) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 1 Mar 2010 14:24:03 -0800 Received: from mail186-tx2 (localhost [127.0.0.1]) by mail186-tx2-R.bigfish.com (Postfix) with ESMTP id 22AB91C0457; Mon, 1 Mar 2010 22:24:03 +0000 (UTC) X-SpamScore: -52 X-BigFish: ps-52(zz146fK14c3L1503M604T936eM1442J9371Pf4eM8c8aizz1202hdafMz4fhzz2fheL6bh2a8h61h) X-Spam-TCS-SCL: 0:0 Received: from mail186-tx2 (localhost.localdomain [127.0.0.1]) by mail186-tx2 (MessageSwitch) id 1267482234690401_16424; Mon, 1 Mar 2010 22:23:54 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.246]) by mail186-tx2.bigfish.com (Postfix) with ESMTP id A083B1030057; Mon, 1 Mar 2010 22:23:54 +0000 (UTC) Received: from frink.w3.org (128.30.52.56) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.0.482.39; Mon, 1 Mar 2010 22:23:52 +0000 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NmE1g-0006GF-2p for public-ws-resource-access-dist@listhub.w3.org; Mon, 01 Mar 2010 22:23:44 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NmE1d-0006FC-PV for public-ws-resource-access@listhub.w3.org; Mon, 01 Mar 2010 22:23:41 +0000 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NmE1Y-00009U-Fy for public-ws-resource-access@w3.org; Mon, 01 Mar 2010 22:23:41 +0000 Received: from TK5EX14CASC129.redmond.corp.microsoft.com (157.54.52.7) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 1 Mar 2010 14:23:03 -0800 Received: from TK5EX14MBXC112.redmond.corp.microsoft.com ([169.254.5.207]) by TK5EX14CASC129.redmond.corp.microsoft.com ([157.54.52.7]) with mapi; Mon, 1 Mar 2010 14:22:54 -0800 From: Ram Jeyaraman To: Doug Davis , "public-ws-resource-access@w3.org" Thread-Topic: MOAP v2 Thread-Index: AQHKtMDrVBQ2WSr8r0yUYR8RD2/NtpHUH8WQgAC89YCAAUtPAIAAicIAgAAmA4CAAKIvAIAGNaZg Date: Mon, 1 Mar 2010 22:22:56 +0000 Message-ID: <503546C5699C1144BDEA0D0DFFE7F881229AFF96@TK5EX14MBXC112.redmond.corp.microsoft.com> References: <4F4942E980BD7147AE7F7D3DCB9CBA9F34E98581@TK5EX14MBXC140.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_503546C5699C1144BDEA0D0DFFE7F881229AFF96TK5EX14MBXC112r_" Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-10.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1NmE1Y-00009U-Fy 382f8cfc65dfe281039b8273e903e85b X-Original-To: public-ws-resource-access@w3.org Subject: RE: MOAP v2 Archived-At: Resent-From: X-Mailing-List: archive/latest/1663 X-Loop: public-ws-resource-access@w3.org Sender: Resent-Sender: Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-ID: Resent-Date: Mon, 1 Mar 2010 22:23:44 +0000 X-Reverse-DNS: frink.w3.org Return-Path: public-ws-resource-access-request@listhub.w3.org X-MS-Exchange-Organization-Antispam-Report: IPOnAllowList X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-SCL: 0 X-MS-Exchange-Organization-AuthSource: SVC-EXGWY-E803.partners.extranet.microsoft.com X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 --_000_503546C5699C1144BDEA0D0DFFE7F881229AFF96TK5EX14MBXC112r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 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 a= llows 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 purpo= ses of progressing the MOAP issue, [1] seems sufficient to me. If we need t= o analyze this some more, I suggest we explore it further in the future - p= erhaps 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:Ge= tWSDL (01) (02) http://services.example.org/stockquote (03) (04) (05) (13) (14) (15) The policy assertion at line 05 in Example 12-1 indicates to consumers of t= his EPR that the GetWSDL operation is supported by the referenced Service E= ndpoint. The parameters described in Section 11 WS-MetadataExchange Metadat= a could be added to the policy assertion at line 05 to indicate additional = capabilities such as support for the mex:GetMetadata operation. Extra bindi= ng information (such as SOAP version) could either be implied by the contex= t 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:Ge= tWSDL (01) (02) http://services.example.org/stockquote (03) (04) (05) {06) (07) (08) (09) (10) (11) (12) From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-a= ccess-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 M= EX is critical in being able to get more metadata about how to interact wit= h the endpoint, but unless we expect clients to _always_ ask for the WSDL a= t runtime before they invoke any operation (application or feature operatio= n) I think we need accept the notion that there are times when people are g= iven 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 no= t - and that the only bit of extra information the client wants/needs is th= e EPR+QoS options for the particular endpoint they're going to hit. In the= se cases, while obviously retrieving the WSDL from the endpoint will get th= is information, just as embedding the WSDL for all QoS/Features into the EP= R (under the appropriate policy assertion) will work too, I think both of t= hese 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 kno= w the transport info from the wsa:Address. We'll know if the MEX operation= s need to be secured by any security policy assertions under the MEX assert= ion ( section 9 of mex.moap tells us this). So, are we really suggesting t= hat the pattern people need to follow when they want to have the client avo= id 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 Tr= ansfer do we really want people to have to include the WSDL for each of the= se Features in the EPR just so they can get the soap version for those Feat= ure 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 (impl= icitly) provide the missing binding information. For example, what soap ve= rsion should people use when sending Notifications? While the spec is sile= nt on this, I bet most people will use the same soap version that carried t= he wse:NotifyTo. But of course, this isn't required, nor should it be. Th= ere 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 el= se - 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 a= ll 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 ne= xt 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. Perha= ps 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 t= he one listed in the example is the soap version (assuming it can't be impl= ies because we're living in a vacuum :-). So, this is a long way of saying that perhaps we should look for a much sim= pler 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: or And like all assertions, its location indicates its scope and applicability= . So: mysink.com 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 o= nly help cement the idea that SOAP is just too complex. Notice too that th= is EPR is a bit simplistic (like the example we're discussing) in that it o= nly includes one assertion. As I discussed above, if there were several Fe= ature 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 c= ases I think its true that the soap version would apply to all operations t= o 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 th= e 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 t= he group will appreciate, above I talked about how people sometimes make as= sumptions about how to use the EPR based on how it was provided. So, in th= is NotifyTo case if we want to send the Notifications using the same soap v= ersion 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 stand= ardized 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: http://services.example.org/stockquote> and add text that says the extra binding information (ie. soap version) i= s implies by the context in which the EPR was provided. or #2: http://services.example.org/stockquote> and define some new SOAP assertions. Or we could include both along with Ram's and explain when each one might b= e needed. For example, I can see Ram's being useful in cases where there a= re operational bits of metadata needed to be conveyed - a more advanced cas= e. While #2 is good in cases where we're in a vacuum (or just want to be e= xplicit) and we only have Endpoint level policy. And #1 is for when there'= s contextual information that provides the missing soap version. Personall= y, 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 > 02/25/2010 12:44 AM To Doug Davis/Raleigh/IBM@IBMUS, Ram Jeyaraman > cc "public-ws-resource-access@w3.org"= = > Subject RE: MOAP v2 > When the WSDL is not included then the binding information for the MEX op= erations would default to be the same as the binding information for the st= ockquote EPR itself. The quoted example below is a bootstrap case (in section 12 in the MOAP pro= posal). 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 Dav= is 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 d= ifferent from the MEX WSDL in the spec (e.g. having a different EPR), I wou= ld 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 d= efault to be the same as the binding information for the stockquote EPR its= elf. 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 tal= ks 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 > 02/24/2010 10:16 PM To Doug Davis/Raleigh/IBM@IBMUS cc "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 a= ssertion? 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 > 02/23/2010 03:16 PM To Doug Davis/Raleigh/IBM@IBMUS, "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 th= e binding information. The additions are highlighted below. Thanks. Example 12-1: Endpoint reference to a Service Endpoint that supports mex:Ge= tWSDL (01) (02) http://services.example.org/stockquote> (03) (04) (05) (06) (12) (14) (15) (17) (18) ... (19) (20) ... (21) (22) (23) (24) From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-a= ccess-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/MOAP= v2.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 w= ere made. - the v6 version contains all of the edits since v1. All v1 edits were "ac= cepted" 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? name= s. It wasn't until round 4 of edits that I remembered to change the user n= ame. The MEX edits include: - lots of minor editorial tweaks - there's a new Terminology section. This was added because it was felt th= at 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 tryin= g 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 mo= ve 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 The more I'm around some people, the more I like my dog. ________________________________ --_000_503546C5699C1144BDEA0D0DFFE7F881229AFF96TK5EX14MBXC112r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>  and add text that says the ext= ra binding information (ie. soap version) is implies by the context in whic= h the EPR was provided.

 

On the issue about the ex= ample in section 12: I like to suggest [1]. This allows any extra binding i= nformation to be made available by the context in which the EPR was provided (as Doug states above) or could be also provided expl= icitly (a simpler form of what I had suggested earlier). For the purposes o= f progressing the MOAP issue, [1] seems sufficient to me. If we need to ana= lyze 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.

 <= /p>

Does this seem reasonable= ?

 <= /p>

Thanks.=

 <= /p>

[1] Suggested text for is= sues on example in Section 12

 <= /p>

Example 12-1: Endpoint referenc= e to a Service Endpoint that supports mex:GetWSDL

(01) <wsa:EndpointReference ... >

(02)   <wsa:Address>http://services.example.o= rg/stockquote</wsa:Address>

(03)   <wsa:Metadata>

(04)     <wsp:Policy>

(05)       <mex:MetadataExch= ange/>

(13)     </wsp:Policy>

(14)   </wsa:Metadata>

(15) </wsa:EndpointReference>

The policy assertion at line 05 in Example 12-1 indica= tes 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 asser= tion 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 cou= ld be conveyed as in Example 12-2.

Example 12-= 2: Endpoint reference to a Service Endpoint tha= t supports mex:GetWSDL

(01) <wsa:EndpointReference ... >

(02)   <wsa:Address>http://services.example.o= rg/stockquote</wsa:Address>

(03)   <wsa:Metadata>

(04)     <wsp:Policy>

(05)       <mex:MetadataExch= ange/>

</mex:Met= adataExchange>

(10)  &nbs= p;  </wsp:Policy>

(11)   <= ;/wsa:Metadata>

(12) </wsa:Endpoi= ntReference>

 <= /p>

From: public-w= s-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 bootstrappi= ng.  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 th= ere 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&#= 43;QoS options for the particular endpoint they're going to hit.  In t= hese cases, while obviously retrieving the WSDL from the endpoint will get this information, just as embedding the WS= DL for all QoS/Features into the EPR (under the appropriate policy assertio= n) will work too, I think both of these options are not only verbose but ov= erkill.

Second, what's really missing from the example as it currently s= tands?  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 f= ollow when they want to have the client avoid the overhead of doing more metadata retrieval is to include the WSDL for e= ach Feature in the EPR?  Even if all that's missing is the soap versio= n?  If an EPR includes policy for RM, Eventing, MEX, Security, Tx, Enu= m and Transfer do we really want people to have to include the WSDL for each of these Features in the EPR just so the= y can get the soap version for those Feature specific operations?  I h= ope 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 examp= le, what soap version should people use when sending Notifications?  While the spec is silent on this, I bet most people will use the sam= e 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 m= ight 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 provid= ed to us.  I think in most cases this is sufficient and for those time= s 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 th= ose "hints" I referred to in point #1.  This then leads me b= ack 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 ne= xt 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 th= e one listed in the example is the soap version (assuming it can't be impli= es 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 tha= t 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 ap= plicability.

So:
<wse:NotifyTo>
  <wsa:Address> mysink.com = </wsa:Address>
  <wsa:Metadata>
    <wsp:Policy>
      <wsrmp:RMAsser= tion/>
      <mex:SOAP12/&g= t;
    </wsp:Policy>
  </wsa:Metadata>
</wse:NotifyTo>

This indicates that the Notifications are to be sent using RM an= d SOAP12.  The only other option is to include the Notification WSDL u= nder this EPR.  While technically possible - that sure seems like overkill to me and will only help cement the idea that SOAP is just t= oo complex.  Notice too that this EPR is a bit simplistic (like the ex= ample 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 c= ases 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 o= f purposes.  

Notice something else, and this is a point that I think the deve= lopers in the group will appreciate, above I talked about how people someti= mes make assumptions about how to use the EPR based on how it was provided.  So, in this NotifyTo case if we want to send th= e Notifications using the same soap version as the Subscribe message then t= he implementation would be forced to carry around the soap version informat= ion with this EPR.  By defining a new assertion, this information can now be included within the EPR (in a stand= ardized 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. &n= bsp;I think its a much cleaner design.

Anyway, back to this example.  I'd prefer if it ended up lo= oking like:
#1:
 <wsa:EndpointReference ... &g= t;
   <wsa:Address>http://services= .example.org/stockquote</wsa:Address>
   <wsa:Metadata>
     <wsp:Policy>=
       <mex:Met= adataExchange/>
     </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 ... &g= t;
   <wsa:Address>http://services= .example.org/stockquote</wsa:Address>
   <wsa:Metadata>
     <wsp:Policy>=
       <mex:Met= adataExchange/>
       <mex:SOA= P12/>
     </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 cas= es 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 leve= l policy.  And #1 is for when there's contextual information that prov= ides 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 Jeyarama= n <Ram.Jeyaraman@microsof= t.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 op= erations would default to be the same as the binding information for the stockquote EPR itself.
 
The quoted example be= low is a bootstrap case (in section 12 in the MOAP proposal). The binding i= nformation for the ‘stockquote’ EPR is NOT known.
 
Regards,
 
Asir S Vedamuthu
Microsoft Corporation=
 
From: public-ws-resou= rce-access-request@w3.org [mailt= o: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-resou= rce-access@w3.org
Subject: RE: MOAP v2
 

Unless we want the example to show a more advanced case of the WSDL being d= ifferent from the MEX WSDL in the spec (e.g. having a different EPR), I wou= ld 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 bin= ding information for the stockquote EPR itself.  There really isn't an= y 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] <= br> Sent: Tuesday, February 23, 2010 3:30 PM
To: Ram Jeyaraman
Cc: public-ws-resou= rce-access@w3.org
Subject: RE: MOAP v2
 

Ram - did you mean for the WSDL to be a child of the mex:MetadataExchange a= ssertion?

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.c= om>

02/23/2010 03:16 PM

 

 

To

Doug Davis/Raleigh/IBM@IBMUS, "public-ws-re= source-access@w3.org" <p= ublic-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 th= e binding information. The additions are highlighted below. Thanks.

 

= Example 12-1: Endpoint reference to a Service Endpoint that supports mex:Ge= tWSDL

(01= ) <wsa:EndpointReference ... >

(02= )   <wsa:Address>http://services.example.org/stockquote</wsa:Address<= /span>>

(03= )   <wsa:Metadata>

(04= )     <wsp:Policy>

(05= )       <mex:MetadataExchange/>

&nb= sp;(06)         <wsdl:definitions name=3D'StockQuote= MetadataExchangeMetadata'

&nb= sp; (07)                  targ= etNamespace=3D'http://services.example.org/stockquote/metadata'

(08= )                  xmlns:wsdl= =3D'http://schemas.xmlsoap.org/wsdl/'

(09= )                  xmlns:mex= =3D'http://www.w3.org/2009/09/ws-mex'

(10= )                  xmlns:wsp= =3D'http://www.w3.org/ns/ws-policy'

(11= )                  xmlns:wsoap= 12=3D'http://schemas.xmlsoap.org/wsdl/soap12/'>

(12= )                  <wsdl:im= port namespace=3D'http://www.w3.org/2009/09/ws-mex'

(13= )                     &nb= sp;         location=3D'http://www.w3.org/2009/09/ws-me= x/metadataexchange.wsdl' />

(14= )                   <wsdl:b= inding name=3D'MetadataExchangeBinding' type=3D'mex:MetadataExchange'>

(15= )                     &nb= sp; <wsp:PolicyReference

(16= )                     &nb= sp;         URI=3D'http://services.example.org/stockquo= te/MetadataExchangePolicy' />

(17= )                     &nb= sp; <wsoap12:binding transport=3D'http://schemas.xmlsoap.org/soap/http' = />

(18= )                     &nb= sp;  ...

(19= )                  </wsdl:b= inding>

(20= )                   ...

(21= )         </wsdl:definitions>

(22= )     </wsp:Policy>

(23= )   </wsa:Metadata>

(24= ) </wsa:EndpointReference>

 

 

From: public-ws-resource-access-re= quest@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 w= ere made.
- the v6 version contains all of the edits since v1.  All v1 edits wer= e "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? name= s.  It wasn't until round 4 of edits that I remembered to change the u= ser name.

The MEX edits include:
- lots of minor editorial tweaks
- there's a new Terminology section.  This was added because it was fe= lt that the two roles ('service endpoint' and 'metadata resource') needed t= o 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 adde= d 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 ma= ke 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
The more I'm around some people, the more I like my dog. =


 


 

--_000_503546C5699C1144BDEA0D0DFFE7F881229AFF96TK5EX14MBXC112r_--