c) mapping to requirements

ATFers:

William posted an initial list of requirements [1].  Assuming we go with an
approach that looks like a) or b) as listed in a summary I posted
previously [2].  To recap the list of proposals detailed in [2]:
> I see several possible approaches:
>a) CORBA IDL-like convention
>b) similar to a) but single operation, no strong typing
>c) JavaBeans pattern
>d) a “base” Web services interface that defines the attribute >operations.

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.

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.

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 :-).

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.

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.

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.

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.

So to keep a score card of the number of requirements supported by each
proposal:
(++ ==> supports well, + ==> supports with some effort, - ==> no support)

     a  |  b  |  c  |  d  |
 1) ++  | ++  |  +  | ++  |
 2)  -  |  -  |  -  | ++  |
 3) ++  | ++  |  +  | ++  |
 4) ++  | ++  |  +  | ++  |
 5) ++  |  +  |  +  |  +  |
 6)  +  |  +  |  -  | ++  |
 7)  +  |  +  |  +  |  +  |
 8) ++  | ++  | ++  | ++  |
 9) ++  | ++  |  +  | ++  |
10) ++  | ++  |  -  | ++  |
11)  -  |  -  |  -  | ++  |
12) ++  | ++  | ++  | ++  |

[1]
http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Jun/0013.html

[2]
http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Jul/0064.html

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++

Received on Saturday, 19 July 2003 13:25:46 UTC