[cddlm] deployment API notes
steve_loughran at hpl.hp.com
Wed Dec 7 10:15:09 CST 2005
Returning to the deployment API, here are some notes and issues I made
while working on it in the runup to GGF15. I had some notes about Axis2
and xmlbeans, but I have dealt with them myself. These are issues with
the deployment API specification itself.
We can discuss these via email, or I can file them as bugreps, which
will keep the issues open.
Possible enhancements to deployment API
-what is our policy for queries on values (esp state values) that
arent there yet
e.g. terminatedtime, terminationrecord
-there is no definition of what the value of the started/finished/failed
timestamps are. Implementations may either have null values
return an error that a property is undefined (HP)
-add property for 'failed time' on a system, recording when it entered the
rationale: the other transitions all have a timestamp. There may be a
between failing and terminating.
-add a property for both nodes that lists all current properties.
rationale: makes it good for testing/diagnosis, discovering extras.
-add a management capability for this property, so it can be used in
it would seem generally useful for any system w/ dynamic properties, and
is more useful at runtime than WSDL, especially on platforms that
do not support dynamic WSDL generate/parse.
the value of this would be the same as for the property in the wsdl; a
* see GetResourceNames
-see what happens when you ask for a property qname with an
incomplete, missing prefix
" : "
-AddFile to require you to specify file extension? make it an option.
Rationale: used in filesystem mode to generate extension, many things
depend on it.
Unless we derive the extension from the URI.
Possible: make it an informal bit of metadata.
-Addfile to take a (relative) expiry time
OGSA-Basic Profile Changes
HP Impl must support GetResourceProperties() plural as it is required.
OGSA defines the following requirements which are not in conflict with
the deploy API,
but nor are they explicitly mentioned. To be compatible with the OGSA
BP, they need
to be met:
R0420 A DESCRIPTION MUST contain in the Resource Property Document
referred to by the wsrf-rp:ResourceProperties attribute on the portType, a
Resource Property Element ogsa-bp:ResourceEndpointReference as defined in
R0421 A RECEIVER SHOULD respond to a wsrf-rp:GetResourceProperty
the child of the wsrf-rp:GetResourceProperty is the QName
with the wsa:EndpointReference of the endpoint to which the message was
R0411 A DESCRIPTION MUST contain in the Resource Property Document
referred to by the wsrf-rp:ResourceProperties attribute on the portType,
a Resource Property
Element ogsa-bp:ResourcePropertyNames as defined in the schema
R0412 A RECEIVER MUST respond to a wsrf-rp:GetResourceProperty request
child of the wsrf-rp:GetResourceProperty is the QName
with the complete list of the xs:QNames of all Resource Property Elements
contained in the Resource Property Document at the time of receipt of
-collect and incorporate all requested changes. Are there bugs in the
XSD of WSRF?
-have template WSDL files for each endpoint, portal and system, that
import the core WSDL
-have a build process that turns these templates into WSDL that
describes the real endpoint
(or hard code to some local URL as a hint). This is to force WSDL
tools to act.
Proposed new Faults
UnsupportedFeature -generic unsupported ness;
UnsupportedUrlSchema -for AddFile: if the caller asks for a schema type
(e.g. https:) that
the endpoint does not uspport.
More information about the cddlm-wg