W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > February 2010

RE: MOAP v2

From: Doug Davis <dug@us.ibm.com>
Date: Fri, 26 Feb 2010 07:08:20 -0500
To: public-ws-resource-access@w3.org
Message-ID: <OFC77957A2.AFAA1D7C-ON852576D6.0041E76B-852576D6.0042B694@us.ibm.com>
There's one other thing that I should mention about the mex:SOAP assertion 
- doesn't it seem a bit odd that using Policy intersection you can figure 
out which endpoint to use based on whether it supports RM, Tx, 
Eventing.... pretty much everything EXCEPT which version of SOAP it 
supports?   One of the most basic bits of information people will need to 
know is something that isn't available (or "intersectable") through the 
Policy framework.  Seems like a huge hole to me.

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.



Doug Davis/Raleigh/IBM@IBMUS 
Sent by: public-ws-resource-access-request@w3.org
02/25/2010 10:25 AM

To
public-ws-resource-access@w3.org
cc

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> 
   <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
The more I'm around some people, the more I like my dog. 

Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
02/23/2010 03:16 PM 
  


To
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <
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> 
(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
The more I'm around some people, the more I like my dog. 

  

  
Received on Friday, 26 February 2010 12:09:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:24 GMT