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?

 

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/",
identifier="target namespace of W2"), 

 

and look at mex:Location for W2 in the response.

 

Q2: Is this understanding correct?

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?

 

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?)

ii) mex:Reference (should be mex:MetadataReference?)

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