[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]