Mike,
I’m afraid I’m not addressing
the content of your email, but...
I think we agreed to a subject line format
that looks like this:
RE: [sca-assembly] ISSUE
31: Wiring from a reference with no binding to a service with a binding
rather than:
RE: [sca-assembly] RE:
[Assembly-31] Wiring from a reference with no binding to a service with a
binding
If we aren’t somewhat consistent in
the format of our subjects, it becomes difficult to filter and search.
Michael
From: Mike
Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Monday, December 03, 2007
8:32 AM
To: OASIS Assembly
Subject: [sca-assembly] RE:
[Assembly-31] Wiring from a reference with no binding to a service with a
binding
Peter,
First
- I'm using the assigned number now!
I'm
looking for a good, simple way to address the issue here.
I
have a problem with the idea of "binding.sca is always there except when
it isn't", which
is
a harsh way of describing your approach. If an assembler or a deployer
sees a service
with
a <binding.jms/> attached, it is not possible to know whether
<binding.sca/> is actually
available
on that service without also looking in detail at the intents in force for that
service.
Example
- if the service has the intent "JMS" applied to it, then (let us
assume) only
<binding.jms/>
will satisfy the intent. <binding.sca/> cannot satisfy the
reference and so can't
be
present. This uncertainty causes the problem for me - the assembler /
deployer has to
look
hard to be sure they got it right - or they have to see the error when they try
to deploy.
My
alternative is to view "binding.sca" as a statement that says
"use whatever means is
available
to connect to the target". So in this case binding.sca on the client
will happily use
binding.jms
on the provider, if that is what is present. (ie they are regarded as
"compatible"
for
wiring purposes).
Only
if the runtime node of the client CANT support binding.jms would there be a
problem
with
my proposal.
Turning
around - if the provider is ONLY marked with binding.sca - first, it can only
be accessed
from
clients within the domain. If multiple clients are present that mandate
the use of specific
bindings
like binding.jms, then I think it is OK for the binding.sca to be interpreted
as allowing
multiple
endpoints (one for each protocol that the clients want to use). This is
likely to be the
case
for binding.sca services in any case, for there is exactly the situation that
you describe -
one
client is really remote and one client is local - the local one should be able
to use an
optimised
connection to the service and not be forced to use the same remotable endpoint
used
by the remote client.
I
happen to take the view that this approach of viewing <binding.sca/> as
being flexible and
being
able to match any other binding type at the other end of the wire, as being the
simplest
to
explain to end-users. It does not have cases where binding.sca is either
present or not
present
due to intent settings - if there is an explicit binding present, then
binding.sca is not
there,
period. Without an explicit binding, the intents can't be met and the
configuration causes
an
error.
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
"Peshev,
Peter" <peter.peshev@sap.com> wrote on 29/11/2007 12:45:52:
> Hi Mike,
>
> Let me clarify the idea (sorry if I didn't do
it well before),
> binding.sca is always present, however it
just doesn't implement the
> intent SOAP (or JMS in the earlier use case)
>
> So in case the assembler \ deployer has
not put any bindings and there
> is SOAP intent, than the tooling \ deploy
error will say -- "Hey the
> default binding.sca is not good, you need to
put binding.ws".
> When the assembler fixes this, there will be
both binding.ws &
> binding.sca on both end of the wires , than
the runtime according to the
> current wiring algorithm will choose only
binding.ws as being the only
> binding satisfying the intents.
>
> The downside of such proposal is that in case
there is some specific
> intent -- SOAP, JMS, etc. the assembler \
deployer will need to put
> binding.ws on both ends of the wire, but I
think that's not that
> frequent usecase.
>
> The benefit is that by having binding.sca by
default we can simplify
> the most common use case - quote -
" where the component is top-level
> (ie in the domain) and where some aspect of
"external access" is
> required. The assembler wants to expose
to the outisde world the web
> service, however for any internal
inter-domain wiring, the optimised
> binding.sca can be used.
>
> I.e. if the vendor binding.sca can
detect that let's say two components
> are living on one and the same server, than
it can just make a local
> call between them as long as all policies are
kept, there is no need to
> post HTTP requests or to do any JMS
messaging.
>
>
>
> Best Regards
> Peter
> ________________________________
>
> From: Mike Edwards
[mailto:mike_edwards@uk.ibm.com]
> Sent: Thursday, 29. November 2007 13:28
> To: OASIS Assembly
> Subject: RE: [sca-assembly] [NEW ISSUE]
Wiring from a reference with no
> binding to a service with a binding
>
>
>
> 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: mike_edwards@uk.ibm.com
>
>
>
> "Peshev, Peter"
<peter.peshev@sap.com>
>
> 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:mike_edwards@uk.ibm.com]
> 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: mike_edwards@uk.ibm.com
>
>
> "Peshev, Peter"
<peter.peshev@sap.com>
>
> 28/11/2007 10:30
>
>
>
> To
> Mike Edwards/UK/IBM@IBMGB,
"OASIS Assembly"
> <sca-assembly@lists.oasis-open.org>
> 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
> <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:mike_edwards@uk.ibm.com]
> 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: mike_edwards@uk.ibm.com
>
>
>
> ________________________________
>
>
> 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
>
>
>
>
>
>
>
>
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