[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] Is WSRF9 the only issue from WS-RF and is there anything else in WSRF that WSDM uses?
MUWS leverages
the Web Services Resources Framework ([WSRF]), in which, the MUWS manageable
resources are represented by Web services as “resources”, in the WSRF sense of
the term. This implies that references to manageability endpoints in MUWS use
the mechanism defined by WSRF, leveraging endpoint references (EPR) as defined
by WS-Addressing.
If the manageability
endpoint corresponds to a variable number (zero or more) of manageable
resources, then the WSRF Implied Resource Pattern MUST be followed. This means
that the element(s) listed in the ReferenceProperties of a WS-Resource qualified
EPR must be included in the header of messages sent to such manageability
endpoints. This specification does not currently define how to obtain the EPR.
There may be an out-of-band agreement between provider and consumer on how to
obtain EPRs or future versions of this specification would clarify this
subject.
In the specific case
where a manageability endpoint corresponds to one and only one manageable
resource, then either the WSRF Implied Resource Pattern, as above, or the
singleton WS-Resource implied pattern MUST be used. If the singleton WS-Resource
implied pattern is used, this means that the manageability endpoint does not
expect to receive the elements listed in the ReferenceProperties section of
WS-Resource qualified EPRs in the message headers to indicate which resource is
being managed. A manageability consumer who does not have an EPR for a
manageability endpoint MAY try to invoke manageability operations without
including reference properties information[WV1] . If such an
invocation succeeds, the manageability consumer can infer it is talking about a
manageable resource through a manageability
provider.
[WV2] [IS3] Further,
management properties defined in MUWS are represented as “properties”, in the
WSRF sense of the term, using the mechanisms defined in WS-ResourceProperties
([WS-ResourceProperties]). This means that each manageable resource exposes a
resource properties document and makes this document available as specified in
WS‑ResourceProperties.
Supporting
WS-ResourceProperties means that any implementation of an interface that
includes properties MUST include access methods to these properties as defined
by WS‑ResourceProperties. Specifically, the interface MUST include the
GetResourceProperty operation defined by WS-ResourceProperties and MAY include
the GetMultipleProperties, SetResourceProperties and QueryResourceProperties
operations. If the QueryResourceProperties operation is provided, it SHOULD
support the XPath 1.0 query expression dialect, represented by URI http://www.w3.org/TR/1999/REC-xpath-19991116.
All
I am a bit confused by today's discussion regarding WSDM use of WSRF specs. In going over the WSRF Issues list and the email archives, I can only find one issue that WSDM has requested from WSRF (WSRF9 below). Am I missing something?
So exactly how does WSDM use WSRF? Do the WSDM (MUWS and MOWS, others) now use the WSRF specs as they currently exist, e.g. WS Resource Properties and WS Resource Lifetime to model or better describe manageable resources. WS Base Faults for error reporting? Any consideration in using WS Service Groups?
For the WSRF App Note, my motivation for including WSDM's use of WSRF was to provide an illustrative example showing the WSDM problem/ issue(s) that was (were) resolved by WSRF specs and how so. Any insight into why and how WSRF specs were used would be helpful to WS Application developers who were considering use of WSRF to model aspects of their WS application(s) and associated stateful resources.
The issue below is all I could find. Isn't there anything else?
alan Weissberger
Issue WSRF9: Need an API to list all properties including those allowed in an xsd:any
There is no way for a client to determine the properties that are allowed to be added to a property document if there is an xsd:any in the property document. Worse, there is no way for a client to ask what properties are currently contained in the property document if they are not listed in the property document schema and QueryResourceProperties is not supported.
WSDM would like to be provided a way to retrieve a list of the properties currently available with the WS-Resource (so we know which ones of the optional properties are available and what other properties might be available that do not appear explicitly in the schema of the resource properties document).
Specifications
WS-ResourceProperties, Version 1.1, March 5, 2004
Notes
As a heads up, WSDM might decide to submit a related requirement regarding the ability to retrieve the schema of a "dynamic" property (one that is not explicitly listed in the schema of the resource properties document) but this is still being discussed inside WSDM. (July 14, 2004)
WSDM needs this capability to list all of the ‘present’ or currently instantiated resource properties. We may also need this capability to list all allowable resource properties.
Proposed Recommendations
Add an operation that returns a list of QNames for all of the properties currently contained in the property document.
Another alternative is to add a property that must be provided which will return the list of QNames for the properties currently in the document.
Add operation or property to return schema for the resource property document.
Consider adding an operation to return a list of all QNames that are acceptable in the property document.
Concrete proposal: http://www.oasis-open.org/archives/wsrf/200406/msg00070.html
Another concrete proposal: http://www.oasis-open.org/archives/wsrf/200406/msg00115.html
At the July 2004 face-to-face the proposals were made.
Proposed a) A new resource property – allowedRPQNames, ie those which will not throw ‘unknown resource’ fault.
This properties will return the relevant RP QNames and the schemalocation.
(No objections)
Proposed b) A new resource property – presentRPQNnames, which indicates a property of the relevant name in the instance document.
This property will return the relevant RP QNames and the schemalocation.
(No Objections)
Proposed c) A capability - GetRPDecl (QName) - to return the current RP document declaration ( minoccurs/maxoccurs/nillable etc) for each QName requested.
(No Objections)
Status: Open since April 28, 2004
Contact: Bryan Murray, Steve Graham, William Vambenepe
Cross Reference:
___________________________________________________________
Sign-up for
Ads Free at Mail.com
http://www.mail.com/? sr=signup
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]