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

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

Comments inline

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	ashok malhotra <ashok.malhotra@oracle.com>
To:	OASIS Policy <sca-policy@lists.oasis-open.org>
Date:	04/12/2009 17:40
Subject:	[sca-policy] ISSUE-92 Further Rationale

---

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?

<mje>
I note that the "upwards" mechanism
is essential - it arises because an intent expressed on an
implementation is an absolute requirement
that must be satisfied - and it can't be erased no
matter how an implementation is used.  This
is an essential aspect of intents
</mje>

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?

<mje>
The whole point about applying an intent
at the higher level of the composite or the component
is that the assembler is trying to say something
important - "all the services and references
here must use "intentX" - which
then DOES mean that bindings that can't satisfy that intent
CAN'T be used - that was the whole idea...

If the assembler did not intend this, then
the assembler places the intents on individual services
and references.

The ability to place at a higher level is
a useful shorthand - but the assembler must be aware
of what it means...
</mje>

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.
<mje>
Again, if confidentiality.message is applied
at the higher level then it means what it says
and if there is an attempt to use a binding
that does not provide this THEN IT IS AN ERROR
- far from being bad, this is good.

If the "common case" is to use
a mix of bindings, then the assembler should either
a) apply just "confidentiality"
at the higher level (if confidentiality is required everywhere...)
b) apply appropriate intents on each service
and reference individually

But I don't think that this invalidates the
usefulness of applying an intent at the higher level.

The checking is something that the runtime
has to do, but it is not hard to write the code for this
- the SCA runtime is evaluating all kinds
of other stuff that is more complex than this.
</mje>

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.

<mje>
This sounds like an argument for providing
no function for a developer at all in case the
function gets misused.

Applying an intent at a higher level is useful
in that it avoids the need to apply the same
intent all over the place, which is at least
as error prone.  And if the higher level intent is
"misplaced" then an error will
be generated which is clear.  Forgetting to set an intent
is more damaging - no error ever gets generated,
but the consequences may be undesirable
(eg unencrypted messages...)
</mje>

RECOMMENDATION:
We recommend that we restrict the application of intents to bindings, 
portTypes and implementations.

<mje>
I disagree - this removes useful function.
 
</mje>

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

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU