Next in thread → Next in month →

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

From
Mike Edwards <>
Date
2008-06-18T10:30:43+00:00
ID
Thread
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:  

David Booz <>

17/06/2008 19:03

To



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:

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
Next in thread → Next in month →