RE: c) mapping to requirements

[snip]

> 1) User should be able to know what their permissions are on
attributes
> before trying
> - it seems that none of the approaches in [2] make achieving this
> requirement easier or harder. It seems that the key to meeting this is
> providing an extensibility element that allows other groups to define
ACL
> elements (from some security namespace) to decorate the attributes.
Note:
> it would be more difficult with an approach such as c) from [2] to
address
> this.
> - furthermore, the access control can still be broadly applied at the
> get()
> and set() methods.
> 

I believe that this is orthogonal to the definition of an attribute.
Other specifications should address this (like WS-Policy for example).

> 2) Query across attributes (in one service): what query language?
> - this cannot be achieved by any proposal but d) from [2].
> 
> 3) Ability to know (partial?) list of attributes at design time
> - it seems that all the proposals, even the dread c) from [2] can meet
> this. Although c) from [2] requires additional processing (to do the
> pattern match detect across all getXXX and setXXX patterns in all
> interfaces, this is not as straight forward as having the meta data
> modelled in XML and immediately processable from WSDL tooling.
> 
> 4) Ability to know type of attributes ahead of time
> - Again, this seems supported from all of the proposals. Again, the
dread
> c) from [2] supports this but requires more effort for tooling etc.
> 

I don't see 3 and 4 as very useful although I agree that they can be
supported. Even today one can imagine a service changing the set of
available operations at runtime. Whether this is going to be used by the
community is a different manner.

> 5) Input/output messages that manipulate attributes can be validated
> against WSDL
> - This is subject to interpretation.  Proposals related to d) from [2]
> make
> it easy.  Proposals a) or b) from [2] cannot be validated directly,
since
> the operations corresponding to attribute get/set are not explicitly
> modelled.  However a case can be made that all the information is
> available
> in the attribute element(s) within the wsdl interface(s) to
"construct"
> the
> implicit get/set operations and thereby validate them.
> 
> Proposals b) and d) from [2] are cannot be completed validated in all
> cases
> because they do not support strong typing. But recall: strong typing
is
> for
> the weak minded :-).
> 

My proposal to model attributes as messages would solve this in the same
way it's done for WSDL operations.

Unlike Graham, I suggest that weak typing is for those who don't know
how to design interfaces ;-) Weak typing cause interoperability
nightmares, especially in the world of Web Services.

> 6) Support for static attributes
> - This seems to be supported by all proposals except c) from [2].
> Proposal
> d) from [2] addresses this well. Additional metadata (using open
content)
> would be a required extension that we would need to add to proposal a)
or
> b) to support this requirement.
> 

I would like to see an example of static attributes. I am not convinced
that are either needed or the information that they are supposed to
convey cannot be captured by wsdl:feature and wsdl:property.

> 7) Ability to restrict access on a per attribute basis.
> - This seems to be doable by all proposals. However, it is not clear
at
> this point that security meta-data and behaviour would be something we
> model explicitly in the WSDL extension, or leave to be satisfied other
> working groups/task forces.
> 

Why is this different from 1?

> 8) Ability to restrict read vs. write access
> - This seems to be satisfied by all proposals in [2].
> 
> 9) Attributes can be inherited through WSDL 1.2 inheritance
> - All proposals address this, proposal c) from [2] as usual seems to
make
> this a little harder to pull off.
> 
> 10) Support metadata on attributes (creation date, type,
description...)
> - Proposal c) from [2] is the only proposal that does not address
this.
> 

Are you suggesting that attributes like "creation date" should be
modelled in WSDL or that extensibility mechanisms would be used?

> 11) Allow bulk retrieval of several attributes in one operation
> - Only proposal d) from [2] would support this.
> 
> 12) Attributes can be of any schema type (simple or complex)
> - All proposals from [2] support this.
> 

[snip]

.savas.

Received on Sunday, 20 July 2003 18:17:06 UTC