+1 on all points
Btw, technically we are not debating not-accepted , since we already
have an open issue for "always there"
From: Simon Holdsworth
[mailto:]
Sent: Wednesday, 28. November
2007 13:33
Cc: OASIS Assembly
Subject: Re: [sca-assembly]
[NEW ISSUE] Wiring from a reference with no binding to a service with a
binding
My 2c
Firstly I agree with Mike that there are valid use cases,
as he describes, where this is a problem, and the current rules don't allow for
a consumable solution (so my vote goes with it being a valid issue).
If you don't think we should debate issues
that are not accepted, please avert your eyes now ;-)
My preference is to treat the SCA binding as "always
there" rather than "don't care".
If I was allowed to wire from a reference with a non-SCA binding to a
service with an SCA binding, and that meant that the non-SCA binding was used,
then the SCA runtime has to somehow generate an implicit non-SCA service binding
that matches the reference binding. In the general case I don't think
that's possible. For JMS, for instance, just because I know how a
reference is going to send a JMS message does not mean I can deduce how a
service is going to receive that JMS message. And what about a JCA
binding? Also the runtime that is dealing with the reference may just not
support the given service binding.
So I'd prefer it that in this case the SCA binding is used, unless there
are intents present that require a specific binding, in which case the wire is
not allowed. I believe we should always be able to derive an implicit SCA
binding for the other end of a wire. I don't believe we can do that for
non-SCA bindings.
Regards,
Simon
Simon Holdsworth
STSM, SCA
Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM
UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal
245059) Fax +44-1962-816898
Internet -
Mike
Edwards/UK/IBM@IBMGB
28/11/2007 10:20
To
"OASIS Assembly"
<>
cc
Subject
Re: [sca-assembly] [NEW ISSUE]
Wiring from a reference with no binding to a service with a
binding
Simon,
You're perfectly entitled (as is anyone else) to take
the view that a new issue is not valid for
any reason. That's the thinking behind the
process whereby anyone can raise an issue but
it has to go through a vote before it gets
opened.
Anyhow, to the merits of the current issue...
let me try to provide some motivation
for the issue, even though I'm not the raiser of the original
issue, but I do see the thinking
behind it.
One
of the ideas within SCA is the simplification of the assembly task - simplifying
the connection
of
some reference to some service. Binding.sca is one of the tools used to
bring simplification.
It basically says "look, I want to connect THIS to THAT and I don't
particularly care how it is done
- just make the connection and satisfy any intents
I've specified"
Dave Booz has always taken the view (which I agree with) that this is
the 80% case when doing
Assembly. Only when you're really dealing with the "outside
world" is there a strong need to
get into concrete bindings and the associated
specialized endpoint addresses and other
paraphernalia.
Now there are cases where you can end up with
mixtures of bindings. So, we may have at the
domain level a component
A with service S1 that needs to be available externally over the
Web Services binding. So
S1 is configured that way. Along comes component B with
reference R1 - and the assembler
decides to connect that reference to S1 as well.
Currently, for R1, we would have to
configure it with a Web Services binding, with an endpoint
URL pointing to the web service endpoint
of A/S1. This is a lot more complex than simply
stating @target="A/S1" on R1. It
is also harder to parse after the fact.
So, that's the real world case, I think. The
argument is being made that it is a great simplification
for the Assembler NOT to have to go deal
with the complexities of the web service binding.
Stating binding.sca and the SCA target
address should be enough. The SCA runtime can
work out the rest - yes, it would
probably use web services under the covers (at least, if the
components lived on different
machines).
Another way of stating this might be to say "binding.sca is ALWAYS
present", except that makes
me uncomfortable for the cases where intents are used to force the
use of particular bindings
where the component code is written using binding-specific APIs.
I prefer to go along with the
idea that it is possible for binding.sca to be
"coerced" to the binding of the other end of the wire.
So, I think the issue is based
on:
a) current
spec is more complex than it needs to be
b) there is a simpler apporach for the assembler -
and the proposal states it
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:
Simon
Nash/UK/IBM@IBMGB
28/11/2007 08:35
To
"OASIS Assembly"
<>
cc
Subject
Re: [sca-assembly] [NEW ISSUE]
Wiring from a reference with no binding to a service with a
binding
This issue raises a general point
about what justification is needed in
order to open an issue.
In
general an issue should say that something is wrong and describe what
the
problem is. It may also give a proposal for a change to resolve the
problem. The "something is wrong" could be an error or inconsistency
in
the spec, or it could be a real world use case that the spec does not
address adequately. I don't think an issue should be raised based on
an
opinion that says "I don't like spec rule X and I prefer rule Y
instead."
With this issue I don't see any clear description of what is
wrong with
the current spec rules. The spec appears to be clear and
consistent as it
stands. All I see is an assertion that the rule in
the current spec
imposes an "unreasonable requirement".
Why is this
spec rule unreasonable? What real world use case has a
problem because
of this rule? IMO the rule is fine as it stands, and no
change is
needed. However, I'm prepared to be educated on this, and if
the rule
is causing a problem, then we we should look at the problem and
see what
spec change needs to be made to resolve the problem. The
solution
could be the one proposed, or there could be a different
solution.
Without a clear problem statement and use case to drive the
discussion, the debate will come down to one person's technical opinion
against another's, which is unlikely to be productive.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy
of Technology
Tel. +44-1962-815156 Fax
+44-1962-818999
Mike Edwards/UK/IBM@IBMGB
27/11/2007
15:42
To
"OASIS Assembly"
<>
cc
Subject
[sca-assembly]
[NEW ISSUE] Wiring from a reference with no binding to a
service with a
binding
<This issue is transferred from the
SCA Policy TC where it was dubbed
POLICY-34>
RAISER Michael
Rowley (original)
TARGET: SCA Assembly Specification
DESCRIPTION:
The algorithm in the policy spec says that it is
_not_ possible to wire
from a reference that does not declare a binding
(i.e. uses binding.sca)
to a service that declares one or more bindings.
However, I think this
should be possible.
It is an unreasonable
requirement to say that a service with a binding can
only be the target of a
reference that has that same binding. The default
binding (binding.sca)
should be treated as the "I don't care" binding, and
should work with any
binding available within the domain. Or, more
precisely, any binding that
can satisfy the required intents.
Section 4.8.1 of the Policy
frmework spec states:
The wiring compatibility algorithm below
determines the compatibility of a
wire by a pairwise choice of a binding
instance and the corresponding
policySets on each side of the wire.
This should be changed to the following:
If either side of a
wire does not specify a binding (or explicitly
specifies binding.sca) the
wire is considered to be valid for the purposes
of policy processing. If
both sides of the wire use binding.sca then the
policies will be determined
by the union of the required intents of both
sides (policy sets aren't used
with binding.sca). Otherwise, the bindings
and policies used for the wire
will be determined by adding the intents
that are required by the
binding.sca end of the wire to the other end of
the wire and then following
the section 4.10 algorithm in the Polcy
Framework.
If neither side
of the wire uses binding.sca, then the wiring compatibilty
algorithm below
is used for determining compatibility. Note that there may
be many binding
instances present at each side of the wire. This algorithm
determines the
compatibility of a wire by a pairwise choice of a binding
instance and the
corresponding policySets on each side of the wire.
PROPOSAL:
The
following should be added to the Wires section of the Assembly
specification:
If either end of a wire does not specify a binding
(or explicitly
specifies binding.sca) the wire is regarded as valid.
In other words,
binding.sca is regarded as being compatible with
any other type of binding. Where other types of binding are applied to
each end of a wire, compatibility of the two bindings is determined by the
specifications for the two bindings
involved, allied to the intent and
policies attached at each end. In
general, a wire which has two
different binding types at each end (non
binding.sca) is likely not to be
valid.
If both ends of the wire use binding.sca then the policies will
be
determined by the union of the required intents of both ends (policy sets
aren't used with binding.sca).
Otherwise, where one end of the wire uses
binding.sca, the bindings and
policies used for the wire will be determined
by adding the intents that
are required by the binding.sca end of the wire
to the other end of the
wire and then following the algorithm defined in the
Policy Framework
specification section 4.10.
If neither end of the
wire uses binding.sca, then the wiring compatibilty
algorithm described in
section 4.10 of the Policy Framework specification
is used for determining
compatibility. Note that there may be many binding
instances present at each
side of the wire. This algorithm determines the
compatibility of a wire by a
pairwise choice of a binding instance and the
corresponding policySets on
each side of the wire.
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:
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
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
---------------------------------------------------------------------
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
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
