OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-bindings] Further thoughts on issue BINDINGS-85


Hi Dave,

David Booz wrote:
>
> It's the latter (the knowledge that the configuration parameters can
> satisfy the intent determined by the binding implementation). It's the
> vendor-specific doc and vendor-specific admin/config tooling that
> would know.
>
> BTW, I am also including policySets within the definition of "binding
> configuration". That is, when it is determined that an attached
> policySet is applicable to the binding instance in question, the
> policy within that policySet also constitutes some (or all) of the
> configuration of the binding.
>
> What's troubling me about Eric's email is the tie to the JMS APIs that
> might be used in the component implementation. I think we've discussed
> the notion that the SCA component impl may or may not be using JMS
> APIs when interacting with a service that is exposed over JMS (or
> vice-versa). So Eric, are you referring to what the JMS binding
> implementation does or what the SCA component which is just using the
> binding, is doing?
>

I hope that the details of the binding can be isolated from a component
that is using that binding.  Unfortunately, without concrete
implementation experience, I'm not convinced that a component can always
enjoy ignorance of the binding details.  Abstractions have an annoying
habit of leaking around our imposed boundaries.

-Eric.

>
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
>
[cut]
>
>
> Eric Johnson wrote:
> > I also like Simon's text, but for a different reason.
> >
> > I just checked with one of our JMS experts, and he pointed out to me
> > that PERSISTENT and NON_PERSISTENT have little to do with the policy
> > notions of atMostOnce or atLeastOnce.  Instead, what matters is the
> > particular use of the JMS APIs.  Are transactions being used?  What
> > kind of acknowledgment mode is in play?  Does the particular JMS
> > vendor provide any extensions that might be used to satisfy the
> policies?
> >
> > So I concur - policy settings shouldn't map to a specific delivery
> > mode setting, and the proposed text about flagging a conflict between
> > delivery mode and policy seems appropriate to me.
> >
> > -Eric.
> >
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]