Re: [sca-policy] ISSUE-92 Further Rationale

[David Booz <booz@us.ibm.com>]

Replies inline below.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

ashok malhotra <ashok.malhotra@oracle.com> wrote on 12/04/2009 12:35:15 PM:

> [image removed]
>
> [sca-policy] ISSUE-92 Further Rationale
>
> ashok malhotra
>
> to:
>
> OASIS Policy
>
> 12/04/2009 12:37 PM
>
> Please respond to ashok.malhotra
>
> http://www.osoa.org/jira/browse/POLICY-92
> Earlier note
> http://lists.oasis-open.org/archives/sca-policy-comment/200906/msg00006.html
>
> Intent inheritance adds considerable complexity to the spec.  Structural
> inheritance goes downwards, implementation
> inheritance goes upwards.  The question we asked earlier was:  is this
> complexity warranted just to provide a
> convenient shorthand?
>
> Our developers have other concerns with the inheritance mechanism.  
> Consider a situation where the SOAP
> intent is applied at a component or composite level.  This means it
> applies to the bindings of all services and references
> within the composite/component.  But some bindings may not support the
> SOAP intent, for example JMS or REST.
> What do we do about these bindings?
>

I see two problems here (just observations):
1) The inability of a bindingType to say that it doesn't support something.  I note that when I tried to introduce "capabilities" into the FW we discussed these exact problems and they were all shot down as corner cases.  The capabilities feature was CNA'd.
2) The inability of the Policy FW to recognize that in this instance, JMS and SOAP seem to be mutually exclusive.  I note that this is not necessarily always the case.  It is possible that binding.ws could support both JMS and SOAP, again the "capabilities" discussion raises it's head.

> Similarly, the confidentiality.message intent may be applied at a high
> level and now suppose that one of the bindings it is applies to is SSL.  
> What do we do in such a situation?   POL30001 says an error MUST be
> raised.  We think this is a fairly common situation and if such errors
> arise, the developer is then forced to apply the intent to specific
> bindings.  This is exactly what we are recommending.   Furthermore,
> intent inheritance incurs the cost of checking whether the intent
> violates the semantics of of the binding (etc) that it applies to.  If
> intents could only be applied to bindings, portTypes or implementations,
> this checking would be much less.
>

I don't want to lose the ability to annotate service, reference and component with intents.  I think going to the binding/implementation level is going too far.  We need to keep the design principle that bindings/implementations should be replaceable in the assembly model, i.e. given a set of constraints on a service/reference/implementation, any binding/implementation that satisfies those constraints should be acceptable to the runtime.  Therefore, it is imperative that intents are allowed to be attached to services/references and components. In most use cases, the bindings won't be applied until the assembly phase, which leaves services/references and components as the only places available for intents to be attached.


> Finally, what are the expectations that such a mechanism sets for the
> developer.  Intents are supposed to make his life simple.  He applies an
> intent at a high level and assumes that's it.  But very often this will
> fail for some cases and then he is forced to look more closely at the
> situation making his life more difficult.
>

I don't quite follow this argument, but it may be a mute point. If the developer misunderstood the constraints on his implementation or the assembler misunderstood the constraints on the assembly, then a fix will be needed when the bug surfaces.  Intents make capturing requirements easier, but if the requirements are misunderstood then bugs will result.

> RECOMMENDATION:
> We recommend that we restrict the application of intents to bindings,
> portTypes and implementations.
>
> Alternately, we could change the conformance statements POL40014 and
> POL40005 associated with Rule 1 and Rule 2
> for implementation and structural hierarchies to say SHOULD rather than
> MUST.
>
>
> --
> All the best, Ashok
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>