- From: Doug Davis <dug@us.ibm.com>
- Date: Thu, 25 Feb 2010 10:25:00 -0500
- To: public-ws-resource-access@w3.org
- Message-ID: <OF47FFC366.9E837EF6-ON852576D5.004DD689-852576D5.0054B7B9@us.ibm.com>
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 Thursday, 25 February 2010 15:26:07 UTC