[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with nobinding to a service with a binding
Picking out only one part of your reply:
Dave said:
> binding.sca will be declared as supporting a particular set of intents
> <dab> I assume this is done through the bindingTypes declaration
> so that vendors can decide what intents they want their binding.sca
> implementation
> to support.</dab>
Mike said:
I hadn't thought of it like that - I thought that the specifications would
simply lay down a list of supported intents. However, I can see the merits
of an approach like the one you describe. The downside is that binding.sca
would mean different things on different vendors runtimes.
I think this is fundamentally important. binding.sca is already not
interoperable across vendors for very important reasons. I see no reason
to constrain the intents that binding.sca supports, in the same way that we
should not constrain the intents supported by any other binding. This is
an appropriate place for vendor freedom and for community/industry
involvement over time to fine tune the important aspects of the standard.
We're only on v1 right now.
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
Mike Edwards
<mike_edwards@uk.
ibm.com> To
David Booz/Poughkeepsie/IBM@IBMUS
12/03/2007 08:40 cc
AM sca-assembly@lists.oasis-open.org
Subject
[sca-assembly] RE: [ASSEMBLY-31]
Wiring from a reference with no
binding to a service with a binding
Dave,
Comments inline.:
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
David Booz <booz@us.ibm.com> wrote on 29/11/2007 13:59:08:
> First to Mike E's proposal with my comments <dab> </dab>:
>
> - 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)
> <dab> right </dab>
>
> - 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.
> <dab> This raises a deployment problem when new clients, which use
> something
> other than binding.sca, are deployed after a service that exposes only
> binding.sca. This would force the service to be re-deployed in order
> to create the new protocol/binding endpoint. </dab>
>
In my model, this is not a redeployment. This is the creation of a new
endpoint for the existing service component. I think binding.sca does
this already due to the ability to use "shortcuts" when the client and
provider run in the same process (for example).
> binding.sca will be declared as supporting a particular set of intents
> <dab> I assume this is done through the bindingTypes declaration
> so that vendors can decide what intents they want their binding.sca
> implementation
> to support.</dab>
I hadn't thought of it like that - I thought that the specifications would>
simply lay down a list of supported intents. However, I can see the merits
of an approach like the one you describe. The downside is that binding.sca
would mean different things on different vendors runtimes.
> 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
> <dab> right </dab>
>
> Second, to Peter's idea:
> In general I agree because it avoids the deployment problem I mentioned
> above and
> because binding.sca should be the 80%, maybe 90% use case for component
> interactions. The additional burden for the 10-20% is not onerous IMHO.
>
>
> Going back to the original problem, another alternative might be to have
> slightly different rules for consumers versus providers. I don't like
> asymmetry, but
> let's try this out anyway for a moment. What if we allowed a reference
> with only
> binding.sca to wire to any provider binding, AND we require that any
> non-binding.sca reference to match (binding type match) a provider
binding?
>
> 1) This avoids the deployment problem.
> 2) This would allow a reference binding.sca implementation to morph
itself
> into
> any provider binding (ed: which is one of the reaons that SCA should
> _never_
> try to create a cross vendor interoperable binding.sca). It enables
easier
> access
> to the one of the 10-20% use cases (domain component using another
> Domain component that is also exposed outside the domain).
> 3) It would also work with callbacks as the provider only has to be able
to
> speak
> what he's already configured to speak.
This is a subset of my proposal. Depends on whether you think that a
provider using "binding.sca" is capable of running multiple endpoints
simultaneously for different protocols. I think that this is OK, so I
don't>
need to subset the proposal and it remains symmetric.
Interesting to see what other folk think on this point.
>
>
>
> Dave Booz
> STSM, SCA and WebSphere Architecture
> Co-Chair OASIS SCA-Policy TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
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]