Peter,
<copying the list too - everyone
needs to see this discussion>
The most common case where a binding
will have been applied to a component service (or reference) is where the
component is top-level (ie in the domain)
and where some aspect of "external access" is required. It
will not be
uncommon for another component in the
domain to also want to access the service and it is much simpler to use
binding.sca to make the connection.
(ie just set @target="ComponentName/ServiceName").
The problem with the idea of "binding.sca
is always present" is exactly the one that you've outlined. There
are
some cases where the requiements of
the component implementation may force the use of one binding - or
of a subset of bindings. A good
example of where web service binding would be needed is an implementation
that uses the
JAX-WS extended APIs for accessing SOAP
headers. SCA does not outlaw this, but it does restrict the binding
types
that can be used.
If you go down this road, let us assume
that the requirement for a particular binding is indicated by some intent
- say @requires="SOAP". Your
suggestion is that if such an intent is specified, then binding.sca is
removed at
that point and binding.ws is required
to be specified. So this implies that "binding.sca is always
present except
when it isn't", which I don't find
very satisfactory.
There has been another criticism of
the my idea of "coercing" binding.sca to a specific binding type
when the
other end of a wire requires it. This
is in the case where a service is declared as binding.sca and the reference
using it specifies some specific binding
like JMS or Web services.
The argument in this case is that "coercion"
of the service's binding.sca to binding..jms for one client reference
and then coercion of the same service
to support binding.ws for another client reference leads to multiple
endpoints being created for the service.
This is valid, in the sense that this would indeed imply multiple
endpoints,
but I've always bought off on the idea
of binding.sca handling multiple endpoints for a service offered via
binding.sca - for example, if
there are local clients of the service, I'm quite happy for those local
clients to use
direct calls to the target service,
rather than going via some remoting endpoint.
So let's make my model clear:
- binding.sca is only present on a service
or a reference if:
a) it is explicitly specified
b) no binding is specified at all (ie
then it is the default binding)
- binding.sca is regarded as compatible
for wiring purposes with any other binding type, and the actual
binding used is the binding type on
the other end of the wire. If both ends of the wire are binding.sca
then
the runtime is free to choose the actual
binding to use.
binding.sca will be declared as supporting
a particular set of intents
if a reference or service uses intents
not supported by binding.sca then it is an error if binding.sca is used
for that service/reference
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:
"Peshev, Peter"
<>
28/11/2007 13:28
To
Mike Edwards/UK/IBM@IBMGB
cc
Subject
RE: [sca-assembly] [NEW ISSUE] Wiring
from a reference with no binding to a service with a binding
Hi Mike,
Your mail leads to a very
good way to allow always binding.sca without any side effects.
In case a particular binding is
mandated by having JMS intent, than the binding.sca will simply not
implement that specific intent, and the tooling \ deployment will
say :
"Hey, that's
not valid wiring, you have JMS intent, you should put explicitly binding.jms
on both ends of the wire)
I am lacking your expertise and
business vision, but I assume such "hardcoded JMS" should be
rare, so the nuisance for declaring binding.jms on both end of the wires
is not that big problem.
Btw, I think at the moment that
implementation.java offers no way for a developer to gain access to the
underlying binding specific objects ( JMS connection, JMS session, etc.)
, so such use case (I would break without JMS) is more theoretical.
In addition I would imagine that
an assembler would put a binding mainly to expose something to the outside
world and configure the exposure, and as long as all policies are specified
it's ok to have binding.sca to be present by default for inter-domain usage.
What do you think ?
Best Regards
Peter
From: Mike Edwards [mailto:]
Sent: Wednesday, 28. November 2007 13:17
To: Peshev, Peter
Subject: RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with
no binding to a service with a binding
Peter,
Thank you for pointing this out.
I agree that these issues are closely related.
I suggest that we should consider a single proposal to deal with both issues.
The question of whether "binding.sca is always present" is not
quite the same
as "binding.sca is always compatible with any other binding type when
matching
the two ends of a wire".
My distinction was mentioned in my previous note earlier this morning
-
the use of a particular binding may be mandated (eg through intents) since
the
component involved uses specific APIs that can only deal with that binding
(eg envisage existing code that uses the JMS APIs). In that case,
the only
binding that can be used for the wire is really the specified binding.
My thinking is that binding.sca on one end of the wire is regarded as compatible
with the mandated binding on the other end of the wire - and that the mandated
binding is what gets used.
This is a bit different from the concept that binding.sca is always present
on both
ends of the wire. In that case, it would be possible for the SCA
runtime to use a
binding other than the mandated one - and this would be an error. I
think it is
likely to be more consistent to say that the binding.sca can be matched
with
(any) other binding type when doing wire compatibility.
However, I realize that the distinction between the two cases is pretty
small.
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:
"Peshev, Peter"
<>
28/11/2007 10:30
To
Mike Edwards/UK/IBM@IBMGB,
"OASIS Assembly" <>
cc
Subject
RE: [sca-assembly] [NEW ISSUE] Wiring
from a reference with no binding to a service with a binding
Hi,
when looking at the description, it seems that this is closely connected
(maybe even classified as duplicate) to the already raised ASSEMBLY-1 (http://www.osoa.org/jira/browse/ASSEMBLY-1),
which has the following description :
It is not clear whether presence of binding.sca can always be assumed for
internal wires, specifically when standard bindings are associated with
either end of that internal wire
Although the suggested proposal in ASSEMBLY-1 (adding binding.sca implicitly
to each service/reference and thus satisfying the wiring algorithm
requirements for the case "reference
with no binding to a service with a binding")
seems to be different than the currently suggested proposal (changing
the algorithm).
Best Regards
Peter
From: Mike Edwards [mailto:]
Sent: Tuesday, 27. November 2007 17:43
To: OASIS Assembly
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
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
