This is indeed the use case that I had in
mind when I originally opened the issue. Thank you Mike, for writing it up.
Michael
From: Mike
Edwards [mailto:]
Sent: Wednesday, November 28, 2007
5:21 AM
To: OASIS Assembly
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
