Re: [sca-policy] Issue 54 - wire validity - proposal

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

We didn't get to this discussion on the policy call today, so I'm going to write down my thoughts before I forget them. This is the readers digest version.

Issue 54 (http://www.osoa.org/jira/browse/POLICY-54) was born as a result of ASSEMBLY-57 (http://www.osoa.org/jira/browse/ASSEMBLY-57) to give the Policy FW TC a chance to analyze the resolution to ASSEMBLY-57.

I had to do some digging to figure out where we were on this issue. Mike, I re-read your email several times and I think you're main point is that using external attachment to attach bindings is going to be very difficult because of this decision in the Assembly TC on ASSEMBLY-57. The reason is because the only way for a reference to chose a specific binding is to mention it in the @target attribute of the reference. The other way is by specifying intents which result in the selection of one and only one binding type, but I don't think we want our users to create an intent just to have a particular binding attached. I should point out that we haven't been concentrating on using external attachment to attach bindings, just policySets, so the TC needs to decide if this is something we're going to pursue.

In my proposal to resolve this issue, I also mentioned the fact that application of a binding to a reference is one means for satisfying an intent that is attached to the reference. In fact, the policy FW spec allows for the case where an intent could be satisfied in this way without the need for a policySet at all. Removing the ability to attach a binding to a reference (except when the reference is connecting to something outside the SCA Domain) impedes the ability of the Policy FW to do it's job.

This TC needs to decide how we feel about ASSEMBLY-57.

So (while I was part of the Assembly-57 decision) the discussion I was planning to have in the telecon today was to get a feel for other opinions in the TC. These are roughly the points I would make to the Assembly TC:
1) I agree with the statements in ASSEMBLY-57 which assert that binding type matching is neither sufficient nor necessary to ensure that a wire is valid.
2) However, the solution they have chosen impedes on the Policy FW's ability to provide support for external attachment of bindings, and it removes one of the Policy FW's mechanisms for satisfying intents.


Let's try to have an email discussion about this to see if we can save some time.


thanks

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

Mike Edwards <mike_edwards@uk.ibm.com>

06/18/2008 06:29 AM

To	"OASIS Policy" <sca-policy@lists.oasis-open.org>
cc
Subject	Re: [sca-policy] Issue 54 - wire validity - proposal

Dave,

Thanks for getting this resolution together.

Tackling your comments:


Assembly 57 (and the prior decision of the Bindings TC) imply that specific (non SCA) bindings can only be used in the
case where "SCA mechanisms are not being used" - and that a resolved target must be supplied.

I'll be frank and say that I was not keen on those decisions - they have real consequences. So let's peer into a couple of
usecases and observe their effects:

A) I make a policy decision that I want all "internal" communications to be made via JMS (using a company messaging
system). External stuff will use specific other mechanisms. How can I do this?

In the past, we could have envisaged simply attaching "binding.jms" to those "internal" wires. This would have had to be
done by hand - long & laborious. A non-standard way of avoiding this would be for the runtime to provide the capability
for us to indicate that "binding.sca" == "binding.jms" for this Domain.

External attachment (once we've resolved it !!!) would allow us to define a rule that picks out "internal communications"
and then apply "binding.jms" to such references/services. EXCEPT now, we would also have to write in the target
explicitly. This would be virtually impossible to do using a rule. So the idea of applying a binding using external
attachment is effectively killed, at least for internal comms (unless it's done the laborious way - one attachment for
each service and reference, one at a time).

This leaves the only "standard" way of getting what is needed here along these lines:

a) Use "external attachment", with suitable rules to pick out the "internal communication" targets
b) Apply one or more intents to those locations - intent(s) that pick out the need for "binding.jms"
c) But the binding actually present at those locations MUST BE binding.sca (to be able to use @target)
d) So we have to define binding.sca as being capable of handling whatever set of intents are necessary to
pick out the use of a given concrete binding !!!!

I'm going to dump this one into the lap of the Bindings group to show the effect of these decisions....


B) Any similar decision to A) to apply particular bindings ANYWHERE below the Domain is made equally
painful, with the same consequences.

EITHER I have to specifically identify each wire that I care about and provide configuration for it, one at a
time.
OR I have to use a general rule, but only apply an intent and rely on binding.sca to sort it out.

C) To apply bindings at the domain level, I can at least do it as a deployment decision - ie apply the
bindings I want as I deploy components into the Domain. But in each case, whereever I want a specific
binding to apply, I have to supply unique configuration relevant to that binding. The idea of saying something
as simple as "connect to that component service over there" using "binding X" is gone. You have to go
fetch the endpoint and any and all parameters relevant to that binding type and endpoint.

So much for SCA simplifying things.

I now discover an empty bath - no water, no baby.
I am rapidly turning into a revolting peasant ;-)


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

David Booz <booz@us.ibm.com>

17/06/2008 19:03

To	sca-policy@lists.oasis-open.org
cc
Subject	[sca-policy] Issue 54 - wire validity - proposal

This completes my AI 2008-06-16-03.

Please take careful note of the proposed changes and the two comments as I
discovered an interesting twist in the resolution of Assembly-57 which
spawned this issue in the first place.

(See attached file: Issue54_proposal_on_wd-05.doc)




Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome[attachment "Issue54_proposal_on_wd-05.doc" deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and 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