OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsdm] [interop] Starting point & testing scenario


Thus quoth Murray, Bryan P. (~ 26-Mar-04 10:07 AM ~)...
> Using WS-ResourceProperties has the interesting side-effect of making
> the WSDL document alone potentially insufficient to communicate with
> resources supported by the Web service.
> 
> There are 2 cases where the WSDL document may be sufficient:
> 1) An operation in the WSDL that returns an EndpointReference might
> offer a mechanism to locate already existing resources or to create new
> resources.
> 2) There is only 1 resource supported by the Web service and no SOAP
> header(s) are required to identify that resource. Unfortunately, WSDL
> does not require that all SOAP headers be listed and so it may be
> necessary to send a message to test this case.
> 
> In the case of our WSDM interop example (WeatherStationManageability
> service), we do not have an operation that returns an EndpointReference,
> and it is not defined as to whether a SOAP header is required to
> identify the resource. In WSDM we also are not creating resources, but
> instead refer to fixed resources that already exist.
> 
> For these reasons, I think it may be necessary for managers to have an
> EndpointReference as a starting point.
> 
> Another thought: I think our goals are more around testing the
> interoperable exchange of messages and access to manageability
> information rather than the successful  runtime digestion of
> manageability WSDL. Our testing would be a little simpler if we all
> write manageability endpoints that match exactly the same manageability
> WSDL (except for the endpoint address) and managers start with only the
> EndpointReference. In this way the manager already knows what operations
> and properties are supported and can concentrate on sending requests and
> processing responses.
> 
> Comments?
> 
> Bryan
>
In the fullness of time, I think I'd agree.  However, for our 
quicky-prove-we-can-do-it version here, it seems like a URL is probably 
sufficient.

Last week at about this time, I think I raised the question of a 
mananageability endpoint that manages more than one resource.  There 
were, in some sense, two solutions given:  1) (by William, extremely 
informally paraphrased by me) use the EPR to identify the resource about 
which you are querying; and 2) {by Igor, even more poorly paraphrased by 
me) don't worry about it -- we'll get to it later but we won't do that 
this time around.

The latter answer is sufficient for the april interop.  The former 
answer may work, but disallows asking about multiple resources in one 
message, etc. (which may be OK, but it needs to be decided -- not just 
happen).

I think I agree with your goals of "testing the interoperable exchange 
of messages...".  So we can probably safely punt on addressability this 
go-round.  But I think we'll need to deal with it for 1.0, and maybe 
whatever .75 (or whatever) is....


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]