RE: MOAP v2

Doug,

 

Got it. Sorry I was looking at a pre-MOAP version of MEX following the
link in the MOAPed WS-E :-(

 

Thanks.

 

Li  

________________________________

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Tuesday, March 02, 2010 3:08 PM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org
Subject: RE: MOAP v2

 


Hi Li - comments inline. 

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. 



"Li, Li (Li)" <lli5@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org 

03/02/2010 02:45 PM 

To

Doug Davis/Raleigh/IBM@IBMUS 

cc

<public-ws-resource-access@w3.org> 

Subject

RE: MOAP v2

 

 

 




Doug, 
  
Thanks for the clarification. For #2, here is an example: 
  
The endpoint has an "application WSDL" W1 that composes with WS-Eventing
which is defined by WSDL W2. To declare this relationship, the endpoint
attaches <wse:EventSource /> and <wse:SubscriptionManager /> to W1,
without any of the parameters. The endpoint also attaches the two
assertions with parameters to W2. 
  
Q1: is the above setup supported? 
<dug>  yes but two things come to mind.  1) you have no relationship
between W1 and W2.  W1 needs to have some ref to W2 so that people can
traverse to the eventing WSDL - assuming its not the default one
provided by the spec.   2) while you can put the assertions into W2, its
not clear to me if this is a good or bad thing.  :-)   It seems odd to
having an eventing wsdl also be required to have the eventing assertions
- but it probably does no harm - just seems weird to me  </dug> 
  
According to the following paragraph in Section 9 of your proposal: 

The WS-Eventing WSDL containing the operations indicated by the
EventSource or SubscriptionManager Assertion MAY be exposed by including
the WSDL as a child of the appropriate Policy assertion or by including
a reference to it using the mex:Location or mex:Reference element (as
described in WS-MetadataExchange [WS-MetadataExchange] Section 9). 
In order to retrieve W2 using MEX, I can use 
  
O1: GetMetadata(Dialect=" http://schemas.xmlsoap.org/wsdl/
<http://schemas.xmlsoap.org/wsdl/> ", identifier="target namespace of
W2"), 
<dug> yes </dug> 
  
and look at mex:Location for W2 in the response. 
<dug> this depends on on GetResponseResponse looks.  It could include
the metadata directly or it could include a reference to it with
mex:MetadataReference or mex:MetadataLocation  </dug> 
  
Q2: Is this understanding correct?  <dug> see above </dug> 

Q3: How would the client know "target namespace of W2" as it is not
declared in W1? Is there a one-to-one mapping from the policy assertions
to the target namespace? 
<dug> see above - you really need that link/reference I talked about
from W1's assertions.  Otherwise, unless W2's tns is ws-eventing's tns,
you're out of luck - hence the need for the link  </dug> 
  
The reason I ask the above two questions is because I couldn't find the
following MEX elements you cited in the proposal: 
  
i) GetWSDL (a short-hand for O1?) 
<dug> look in section 6.1 of mex moap v6 </dug> 
ii) mex:Reference (should be mex:MetadataReference?) 
<dug> 
mex:Reference and mex:Location are for refs that are outside of a
mex:MetadataSection. 
mex:MetadataReference and mex:MetadataLocation are for refs inside of a
mex:MetadataSection 
</dug> 

Li   

 

________________________________


From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Tuesday, March 02, 2010 2:06 PM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org
Subject: Re: MOAP v2 
  

Li, 
on #1:  yes I think that is supported.  One of the things that MOAP
tried to get away from was the idea of having someone define what
"application WSDL" is.  To some people WS-Eventing _is_ the application
and to others its just a "feature".  We tried to avoid this discussion
by letting the service decide this for itself.  So GetWSDL() will return
a WSDL doc and whatever the service thinks should be returned, is
returned, even if it looks pretty much like the WS-Eventing WSDL. 

on #2: can you elaborate on this use case - I'm not following it.   

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. 

"Li, Li (Li)" <lli5@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org 

03/02/2010 10:45 AM 

 

To

<public-ws-resource-access@w3.org> 

cc

  

Subject

Re: MOAP v2


  

 

  

 





Doug,

I have a question regarding the following paragraph in
wseventing-moap.doc in your MOAP version 2 proposals:

9 WS-Eventing Metadata
An endpoint MAY indicate that it supports WS-Eventing, or its features,
by including the WS-Eventing EventSource or SubscriptionManager Policy
assertions within its WSDL. By doing so the endpoint is indicating that
the corresponding WS-Eventing operations are supported by that endpoint
even though they do not explicitly appear in its WSDL (i.e. the
WS-Eventing operations do not appear in the WSDL that MAY be retrievable
by using a WS-MetadataExchange GetWSDL to that endpoint).


The paragraph seems to suggest that the endpoint has a WSDL that is
different from the WS-Eventing WSDL, and the policy assertions are
attached to that WSDL. I wonder if these policy assertions can also be
attached to the WS-Eventing WSDL instead. There are two use cases for
this:

1) The endpoint has ONLY WS-Eventing WSDL. It is an event source and
subscription manager, but has no other services.

2) The endpoint has some services other than WS-Eventing, but the
endpoint chooses to consolidate all policy related to WS-Eventing in the
WS-Eventing WSDL. 

My questions are: if these use cases are supported; 2) if so, how the
WSDLs look like.

Thanks,

Li