sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [Assembly-31] Wiring from a reference with no binding to a service witha binding
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Mon, 3 Dec 2007 13:31:55 +0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]