ISSUE-92 Further Rationale

[ashok malhotra <ashok.malhotra@oracle.com>]

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?

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.

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.

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