[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Issue WSRF9] summary of alternatives
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.
There are several possible ways to address
this issue. They all basically provide answers to the following questions
a requestor may have:
i) I know the QNames of the resource
properties that explicitly appear in the resource properties document schema,
but the schema includes xsd:any, so what is the list of ALL resource properties
that are currently in the resource properties document associated with
this WS-Resource?
ii) ok, I know the QName of the resource
property, but where can I find out the exact schema definition for the
global element? eg how to I find the definitive description (.XSD)
for the namespace URI associated with the QName
iii) ok, I know the type of the resource
property (from the QName) but I don't know the minOccurs and maxOccurs
iv) I don't want all the resource properties,
just the ones that are utilizing the xsd:any of the resource properties
document definition.
We discussed several alternative approaches
to this on the June 14th TC call [1].
0) add nothing new normative
In this alternative, requestor question
i) is not addressed. Question ii) is addressed by "recommending"
the use of WS-MetaDataExchange [2] or the use of xsi:schemaLocation attribute
on any response message containing resource property elements. Question
iii) is not addressed, nor is iv).
Pros: adds nothing new
Cons: doesn't address all the questions
Conclusion: do nothing solution is not
satisfactory.
1a) Use operations for all Resource
Property QNames:
In this alternative, we create, in the
WS-ResourceProperties specification, a "ResourcePropertyDiscovery"
portType with operations "GetResourcePropertyQNames" and "GetResourcePropertyDeclaration"
to solve the requestor questions.
Question i) is addressed by a "GetResourcePropertyQNames"
operation that would return a "sequence of QNames" for all of
the resource properties currently associated with the WS_Resource.
Question ii) could be solved by using
WS-MetaDataExchange to request the xsd:schema for the namespace associated
with the QName. Of course, we would also recommend the use of xsi:schemaLocation
on the elements returned by GetResourcePropertyQNames
Question iii) could be solved by adding
a new GetResourcePropertyDeclaration(QName) which would return the xsd:element
declaration (including minOccurs and maxOccurs) that is associated with
that resource property QName.
Question iv) is up to the requestor
to do a delta between the resource properties "statically" declared
in the resource properties document schema and the list returned by the
GetResourcePropertiesQNames operation.
Solution summary:
Add the following operation definitions
(in a new portType) to the WS-ResourceProperties specification:
<portType name='ResourcePropertyDiscovery'>
<operation name='GetResourcePropertyQNames'>
<input ... > <!--
none -->
<output ... > <!--
sequence of elements of type QName each with a recommended @xsi:schemaLocation
-->
<fault ...> <!--
tbd -->
</operation>
<operation name='GetResourcePropertyDeclaration'>
<input ... > <!--
QName -->
<output ... > <!--
xsd:element -->
<fault ...> <!--
tbd -->
</operation>
</portType>
Pros: questions i) and iii) solved directly
using existing WSRF mechanisms. Question ii) solved using other Web
services specifications. Question iv) solved with a little bit of requestor
side processing.
Cons: Question iv) is a little harder
for the requestor to complete.
1b) Use operations for ONLY the xsd:Any
("Dynamic") Resource Property QNames:
This is a variant on 1a), in that it
uses an operation approach to address the requestor's questions. However
the operations are restricted to deal only with the subset of resource
properties that are NOT statically declared in the schema of the resource
properties document.
Question i) is addressed by the requestor's
application combining the "static" resource properties derived
from the resource properties document schema with the results of this variant
of the GetResourcePropertyQNames operation that would return a "list
of QNames" for JUST the resource properties in associated with the
WS_Resource but NOT defined "statically" in the resource properties
document schema. We would consider this approach in the case where there
are many many resource properties associated with the WS-Resource and therefore
answering the entire list of all resource properties is much more expensive
than simply listing the ones that cannot be derived from the resource properties
document schema.
Question ii) no different from 1a).
Question iii) could be solved by adding
a new GetResourcePropertyDeclaration(QName) which would return the xsd:element
declaration (including minOccurs and maxOccurs) that is associated with
that resource property QName. Note, this would work equivalently for the
QName of a resource property defined "statically" in the
resource properties document schema, or a resource property added "dynamically"
Question iv) This is addressed precisely
by the list returned by the GetResourcePropertiesQNames operation.
Solution summary:
The WSDL looks the same, the semantics
on the operations are different.
Pros: questions i) is a little more
complicated for the requestor to solve (must do combination). Question
ii) solved using other Web services specifications. Question iii) solved
directly using existing WSRF mechanisms. Question iv) solved directly
using existing WSRF mechanisms.
Cons: Question i) is a little harder
for the requestor to complete.
Not much difference between 1a) and
1b). The choice between them boils down to our perception on which
is more common, question i) or question iv).
2a) Use Resource Properties for Resource
Property Qnames:
In this alternative, we create, in the
WS-ResourceProperties specification a "ResourcePropertyDiscovery"
portType with two resource property elements "wsrp:ResourceProperty"
and "wsrp:ResourcePropertyDocumentSchema":
Question i) is addressed by defining
a portType, named "ResourcePropertyDiscovery" containing a "wsrp:ResourceProperty"
resource property, type="xsd:QName" minOccurs="0" maxOccurs="unbounded"
where there is one wsrp:ResourceProperty element for each resource property
associated with the WS-Resource. The requestor's application would use
the WS-ResourceProperty operation "GetResourceProperty" passing
in the QName "wsrp:ResourceProperty".
Question ii) is addressed by adding
to the "ResourcePropertyDiscovery" portType a resource property
named "wsrp:ResourcePropertyDocumentSchema", type="xsd:schema"
minOccurs="0" maxOccurs="1". This resource property
(if present) contains the schema definition for the resource properties
document of the WS-Resource. the requestor's applicatoin would use the
WS-ResourceProperty operation "GetResourceProperty" passing in
the QName of "wsrp:ResourcePropertyDocumentSchema" to retrieve
the schema, determine the place in the schema where the ResourceProperty
is declared then follow the schema import/includes to determine the type.
Of course, a QueryResourceProperties passing in the right expression
could allow the service itself to do the lookup.
Question iii) is addressed by the "wsrp:ResourcePropertyDocumentSchema"
resource property (for the statically defined resource properties). This
does not address the case for the resource properties "dynamically"
added.
Question iv) This is addressed by the
requestor processing the response of the Get (perhaps a GetMultipleResourceProperties
operation) on the "wsrp:ResourceProperty" and "wsrp:ResourcePropertyDocumentSchema",
manually processing the results to determine the delta between the complete
list of the ResourceProperties and those that are declared statically in
the resource properties document schema.
Solution summary:
Define resource properties:
<xsd:element name ="ResourceProperty"
type="xsd:QName" />
<xsd:element name="ResourcePropertyDocumentSchema"
type="xsd:schema" />
define a resource properties document
definition
<xsd:element name="ResourcePropertyDiscoveryResourceProperties">
<xsd:sequence>
<xsd:element ref="wsrp:ResourceProperty"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element ref="wsrp:ResourcePropertyDocumentSchema"
minOccurs="0" maxOccurs="1" />
</xsd:sequence>
</xsd:element>
<portType name="ResourcePropertyDiscovery"
wsrp:ResourceProperties="wsrp:ResourcePropertyDiscoveryResourceProperties
>
...
</portType>
Pros: Question i) is solved directly
using existing WSRF techniques. Question ii) requires a little requestor-side
processing, but is addressable using existing WSRF techniques. Question
iii) is MAINLY addressed. Question iv) is addressed with some requestor
side processing.
cons: Does not address discovery of
"dynamic" resource properties declaration in Question iii)
2b) Use resource properties for ONLY
the xsd:Any ("Dynamic") Resource Property QNames:
In this alternative, we create, in the
WS-ResourceProperties specification a "ResourcePropertyDiscovery"
portType with two resource property elements "wsrp:DynamicResourceProperty"
and "wsrp:ResourcePropertyDocumentSchema":
Question i) is addressed by defining
a portType, named "ResourcePropertyDiscovery" containing a "wsrp:DynamicResourceProperty"
resource property, type="xsd:QName" minOccurs="0" maxOccurs="unbounded"
where there is one wsrp:ResourceProperty element for each resource property
associated with the WS-Resource that is NOT in statically declared in the
resource properties document schema. The requestor's application would
use the WS-ResourceProperty operation "GetResourceProperty" passing
in the QName "wsrp:DynamicResourceProperty" to discover the "dynamic"
resource properties. The requestor would need to merge this list
with the list of resource properties defined statically in the resource
properties document schema.
Question ii) same as 2a).
Question iii) same as 2a), same problems
too.
Question iv) This is addressed by the
requestor processing the response of the Get on the "wsrp:DynamicResourceProperty"
.
Solution summary:
Define resource properties:
<xsd:element name ="DynamicResourceProperty"
type="xsd:QName" />
<xsd:element name="ResourcePropertyDocumentSchema"
type="xsd:schema" />
define a resource properties document
definition
<xsd:element name="ResourcePropertyDiscoveryResourceProperties">
<xsd:sequence>
<xsd:element ref="wsrp:DynamicResourceProperty"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element ref="wsrp:ResourcePropertyDocumentSchema"
minOccurs="0" maxOccurs="1" />
</xsd:sequence>
</xsd:element>
<portType name="ResourcePropertyDiscovery"
wsrp:ResourceProperties="wsrp:ResourcePropertyDiscoveryResourceProperties
>
...
</portType>
Pros: Question i) is addressed with
some requestor side processing. Question ii) requires a little requestor-side
processing, but is addressable using existing WSRF techniques. Question
iii) is MAINLY addressed. Question iv) is solved directly using existing
WSRF techniques.
cons: Does not address discovery of
"dynamic" resource properties declaration in Question iii)
Again, not much difference between 2a)
and 2b). The choice between them boils down to our perception on
which is more common, question i) or question iv).
Therefore on the whole, I prefer the
the 1a) or 1b) depending on whether question i) or question iv) is more
common. My intuition suggests question iv) is more common, therefore
I lean towards 1b).
Thoughts?
[1]http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/7266
[2]ftp://www6.software.ibm.com/software/developer/library/WS-MetadataExchange.pdf
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]