[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Proposed resolution to BINDINGS-85
Eric Johnson wrote: > Hi Dave, > > I agree that calling out the explicit conflict is a good idea. I guess > my question is whether we get any value from an additional normative > statement? I tend to think that we should document the known conflicts and just point to the Policy normative statement in the binding spec. -Anish -- > > -Eric. > > David Booz wrote: >> >> Maybe, it depends on how the reader might interpret the meaning or >> purpose of the various intents and config options. We had an >> interesting debate on the meaning of delivery-mode. I still see value >> in being explicit about conflicts that we know about. If there are >> others we should get those addressed as well. >> >> 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 >> >> Inactive hide details for Eric Johnson ---09/14/2009 02:32:42 PM---Hi >> Dave If that's the case, isn't the other normative stateEric Johnson >> ---09/14/2009 02:32:42 PM---Hi Dave If that's the case, isn't the >> other normative statement equally redundant? >> >> >> From: >> Eric Johnson <eric@tibco.com> >> >> To: >> David Booz/Poughkeepsie/IBM@IBMUS >> >> Cc: >> sca-bindings@lists.oasis-open.org >> >> Date: >> 09/14/2009 02:32 PM >> >> Subject: >> Re: [sca-bindings] Proposed resolution to BINDINGS-85 >> >> ------------------------------------------------------------------------ >> >> >> >> Hi Dave >> >> If that's the case, isn't the other normative statement equally redundant? >> >> More below. >> >> David Booz wrote: >> >> Eric, >> >> There's this from the policy FW spec: >> >> If the configured instance of a binding is in conflict >> with the intents and policy sets selected for that >> instance, the SCA runtime MUST raise an error. [POL30001]. >> >> It's the very first normative statement in the spec. >> >> I guess that's proof enough that I really, really, really, haven't >> read it! >> >> I don't think we need your second normative statement below. >> >> Agreed. >> >> -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_ <mailto:e-mail:booz@us.ibm.com> >> >> Inactive hide details for Eric Johnson ---09/14/2009 >> 01:38:20 PM---Hi Simon, I like the proposal, but I'm >> wondering whether thEric Johnson ---09/14/2009 01:38:20 >> PM---Hi Simon, I like the proposal, but I'm wondering >> whether the text at the end is singling out the pa >> >> From: >> Eric Johnson _<eric@tibco.com>_ <mailto:eric@tibco.com> >> >> To: >> Simon Holdsworth _<simon_holdsworth@uk.ibm.com>_ >> <mailto:simon_holdsworth@uk.ibm.com> >> >> Cc: _ >> __sca-bindings@lists.oasis-open.org_ >> <mailto:sca-bindings@lists.oasis-open.org> >> >> Date: >> 09/14/2009 01:38 PM >> >> Subject: >> Re: [sca-bindings] Proposed resolution to BINDINGS-85 >> >> ------------------------------------------------------------------------ >> >> >> >> Hi Simon, >> >> I like the proposal, but I'm wondering whether the text at >> the end is singling out the particular policy intent >> "atLeastOnce", when, in fact, a more general statement >> applies - for example, transaction intents, or vendor >> defined intents that might conflict with a JMS configuration. >> >> That is, something more like this: >> >> This specification does not define a fixed relationship >> between any intents or combination thereof, and a >> particular configuration of a JMS binding. For example, >> this specification does not define any relationship >> between reliability intents and the persistence of JMS >> messages. Deployers/assemblers can configure >> NON_PERSISTENT for @deliveryMode in order to provide >> higher performance with a decreased quality of service. A >> binding.jms element configured in this way might not be >> able to satisfy the "atLeastOnce" policy intent. The SCA >> runtime MUST raise an error at deployment time if it is >> unable to support the combination of >> @deliveryMode=NON_PERSISTENT and the "atLeastOnce" intent >> [BJM5000X]. More generally, the SCA runtime must raise >> an error if it is unable to support the intents on a >> binding in combination with the specific configuration of >> the JMS binding [BJM5000X]. >> >> (I'm not entirely happy with the above, because we would >> then have two normative statements, where one is just a >> generalization of the other, but I thought I'd get across >> my notion for discussion purposes.) >> >> Once again, my unfamiliarity with policy spec strikes >> again. Are both of these normative statements actually >> redundant with normative requirements that come from the >> policy specification? If so, shouldn't we just reference >> that part of the policy spec? >> >> -Eric >> >> Simon Holdsworth wrote: >> >> Folks, in the interests of moving >> to a conclusion on this here's my >> proposed resolution. I think >> there is also an issue with >> respect to the lack of defaults >> defined in the JMS binding for >> deliveryMode, priority and >> timeToLive attributes, I believe >> they should be defined as having >> the same defaults as on the JMS >> API (persistent, 4 and unlimited >> respectively) so I will open a new >> issue for that. >> >> Proposal: >> >> Keep the deliveryMode attribute as >> is. >> >> Replace the final paragraph in >> section 5 (as updated in the >> resolution to issue 48) to read: >> >> This specification does not define >> a fixed relationship between the >> reliability intents and the >> persistence of JMS messages. >> Deployers/assemblers can >> configure NON_PERSISTENT for >> @deliveryMode in order to provide >> higher performance with a >> decreased quality of service. A >> binding.jms element configured in >> this way might not be able to >> satisfy the "atLeastOnce" policy >> intent. The SCA runtime MUST raise >> an error at deployment time if it >> is unable to support the >> combination of >> @deliveryMode=NON_PERSISTENT and >> the "atLeastOnce" intent [BJM5000X]. >> >> Regards, Simon >> >> Simon Holdsworth >> STSM, SCA Bindings Architect; >> Master Inventor; OASIS SCA >> Bindings TC Chair >> MP 211, IBM UK Labs, Hursley Park, >> Winchester SO21 2JN, UK >> Tel +44-1962-815059 (Internal >> 245059) Fax +44-1962-816898 >> Internet - >> _Simon_Holdsworth@uk.ibm.com_ >> <mailto:Simon_Holdsworth@uk.ibm.com> >> From: ashok malhotra >> _<ashok.malhotra@oracle.com>_ >> <mailto:ashok.malhotra@oracle.com> >> To: Eric Johnson >> _<eric@tibco.com>_ >> <mailto:eric@tibco.com> >> Cc: David Booz >> _<booz@us.ibm.com>_ >> <mailto:booz@us.ibm.com>, >> _sca-bindings@lists.oasis-open.org_ >> <mailto:sca-bindings@lists.oasis-open.org> >> >> Date: 11/09/2009 22:12 >> Subject: Re: [sca-bindings] >> Further thoughts on issue BINDINGS-85 >> >> >> ------------------------------------------------------------------------ >> >> >> >> One of the cornerstones of the >> intent model is that intents can be >> satisfied either intrinsically by >> a binding >> or by use of config params on the >> binding. I see Eric's message and >> some >> of the earlier discussion saying that, >> no, intents cannot be satisfied by >> config params. If this is true, we >> need to change the model. >> If this is not the case, can we >> have a few examples of how intents >> can >> be satisfied by configuring a binding. >> >> All the best, Ashok >> >> >> 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. >> > >> > David Booz wrote: >> >> >> >> Simon, >> >> >> >> I don't like the idea of >> expanding the meaning of any of the >> >> reliability intents beyond >> their current numerical meaning. It's >> >> important (though not required) >> for intents to have a consistent >> >> meaning across bindings to >> enable binding replace-ability >> within SCA >> >> as much as possible. Therefore, >> given your concern that >> >> NON_PERSISTENT might encompass >> an implied non-functional requirement >> >> for a high speed transport, >> then I would tend to favor the latest >> >> solution that you just proposed. >> >> >> >> 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_ >> <mailto:e-mail:booz@us.ibm.com> >> >> >> >> Inactive hide details for Simon >> Holdsworth ---09/11/2009 06:05:18 >> >> AM---Ashok, Comments >> inline.Simon Holdsworth >> ---09/11/2009 06:05:18 >> >> AM---Ashok, Comments inline. >> >> >> >> >> >> From: >> >> Simon Holdsworth >> _<simon_holdsworth@uk.ibm.com>_ >> <mailto:simon_holdsworth@uk.ibm.com> >> >> >> >> To: >> >> >> _sca-bindings@lists.oasis-open.org_ >> <mailto:sca-bindings@lists.oasis-open.org> >> >> >> >> Date: >> >> 09/11/2009 06:05 AM >> >> >> >> Subject: >> >> Re: [sca-bindings] Further >> thoughts on issue BINDINGS-85 >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> Ashok, >> >> >> >> Comments inline. >> >> >> >> ashok malhotra >> _<ashok.malhotra@oracle.com>_ >> <mailto:ashok.malhotra@oracle.com> wrote >> on 10/09/2009 18:41:27: >> >> >> >> > Simon: >> >> > Let me analyze this from the >> other side i.e. what the reliability >> >> > intents map to in terms of >> the DIMS binding config params. >> >> > The Policy Framework defines >> 4 reliability intents. Here is what, >> >> in my >> >> > understanding, they map to in >> >> > terms of DIMS delivery mode: >> >> > >> >> > - atLeastOne: Persistent >> (this is more than what is >> requested but >> >> that >> >> > may be OK) >> >> > - atMostOnce: Non-Persistent >> >> > - exactlyOnce >> (atLeastOnce+atMostOnce): Persistent >> >> > - ordered: No appropriate >> config param. Supported by the >> runtime. >> >> > So, two questions: >> >> > - Simon, is this what you >> suggested? >> >> >> >> Yes, that's what I was >> suggesting. The problem with this >> >> relationship is that it is >> asymmetric - you can't say >> "atMostOnce >> >> implies delivery mode is >> Non-Persistent" because if >> exactlyOnce is >> >> required, it also requires >> atMostOnce, and in that case >> delivery mode >> >> is Persistent. >> >> >> >> The problem for me is that >> while exactlyOnce satisfies the >> abstract >> >> numerical requirement of >> atMostOnce, the cost of providing the >> >> additional restriction of >> atLeastOnce doesn't satisfy the >> (in my >> >> opinion expected) >> non-functional requirement of >> atMostOnce which is >> >> provision of a high performance >> lightweight message interaction. I >> >> think that would be the reason >> the intent would be selected by >> people >> >> familiar with JMS, expecting to >> use it to achieve a NON_PERSISTENT >> >> deliveryMode for their messages >> sent by the JMS binding. >> >> >> >> Another way of saying this is >> that I don't believe >> >> deliveryMode=PERSISENT >> satisfies the requirements of >> >> deliveryMode=NON_PERSISTENT so >> I don't believe we can say that the >> >> JMS binding always satisfies >> atLeastOnce, which I think Anish was >> >> questioning. >> >> >> >> My take on this issue is that >> if we can't come up with a clear >> >> relationship between the >> intents and delivery modes that we >> can >> >> explain in the JMS binding so >> that JMS-savvy people know what to >> >> expect from their JMS binding, >> or if we retain the purely numerical >> >> interpretation of the >> reliability intents, then we >> should retain the >> >> current deliveryMode attribute >> and resolve the issue by weakening >> the >> >> current statement of >> incompatibility along the lines: >> >> >> >> Deployers/assemblers can >> configure NON_PERSISTENT for >> @deliveryMode >> >> in order to provide higher >> performance with a decreased >> quality of >> >> service. A binding.jms element >> configured in this way might not be >> >> able to satisfy the >> "atLeastOnce" policy intent. The >> SCA runtime MUST >> >> raise an error at deployment >> time if it is unable to support the >> >> combination of >> @deliveryMode=NON_PERSISTENT and >> the "atLeastOnce" >> >> intent [BJM5000X]. >> >> >> >> > - Others, does this make sense? >> >> > All the best, Ashok >> >> > >> >> > >> >> > Simon Holdsworth wrote: >> >> > > >> >> > > The JMS 1.1 specification >> has the following to say about the >> >> > > deliveryMode attribute >> (Section 4.7, Message Delivery Mode): >> >> > > >> >> > > A JMS provider must deliver >> a NON_PERSISTENT message >> /at-most-once. >> >> > > /This means that it may >> lose the message, but it must not >> deliver it >> >> > > twice. >> >> > > A JMS provider must deliver >> a PERSISTENT message >> >> /once-and-only-once/. >> >> > > This means a JMS provider >> failure must not cause it to be lost, >> >> and it >> >> > > must not deliver it twice. >> >> > > >> >> > > So it seems quite >> reasonable to map the SCA >> atMostOnce intent to JMS >> >> > > delivery mode of >> NON_PERSISTENT, and exactlyOnce to >> PERSISTENT, >> >> > > although exactlyOnce is a >> profile intent that combines >> atMostOnce >> >> and >> >> > > atLeastOnce, which would >> imply to me that atLeastOnce maps >> to a JMS >> >> > > delivery mode of >> PERSISTENT. Although this does >> make life quite >> >> > > difficult, because bindings >> that require exactlyOnce do also >> require >> >> > > atLeastOnce. >> >> > > >> >> > > The only question I have >> left with regards to removing the >> >> > > deliveryMode attribute as >> the resolution to this issue is >> whether we >> >> > > should mandate in the JMS >> binding spec a specific mapping of >> these >> >> > > intents to deliveryMode >> values, or remain silent and leave >> that >> >> > > interpretation up to the >> SCA runtime. >> >> > > >> >> > > If we were to mandate the >> mapping, then the resolution to >> the issue >> >> > > would be to remove the >> deliveryMode attribute, and >> replace the >> >> > > following paragraph in >> section 5: >> >> > > >> >> > > Deployers/assemblers can >> configure NON_PERSISTENT for >> >> @JMSDeliveryMode >> >> > > in order to provide higher >> performance with a decreased >> quality of >> >> > > service. A binding.jms >> element configured in this way >> cannot satisfy >> >> > > the "atLeastOnce" policy >> intent. The SCA runtime MUST raise >> an error >> >> > > for this invalid >> combination at deployment time. >> >> > > >> >> > > with: >> >> > > >> >> > > The JMS delivery mode used >> to send messages from a JMS binding >> >> > > instance which requires the >> atMostOnce intent and not the >> >> atLeastOnce >> >> > > intent MUST be >> NON_PERSISTENT [BJM5000X] >> >> > > The JMS delivery mode used >> to send messages from a JMS binding >> >> > > instance which requires the >> atLeastOnce intent MUST be PERSISTENT >> >> > > [BJM5000Y] >> >> > > >> >> > > Given the deliveryMode >> default is PERSISTENT, we could >> also say: >> >> > > >> >> > > The JMS delivery mode used >> to send messages from a JMS binding >> >> > > instance which does not >> require either of these intents >> MUST be >> >> > > PERSISTENT [BJM5000Z] >> >> > > >> >> > > In fact these could all be >> collapsed into a single statement: >> >> > > >> >> > > The JMS delivery mode used >> to send messages from a JMS binding >> >> > > instance MUST be >> NON_PERSISTENT if it requires the >> atMostOnce intent >> >> > > and not the atLeastOnce >> intent, and PERSISTENT otherwise >> [BJM5000X] >> >> > > >> >> > > Comments? >> >> > > >> >> > > Regards, Simon >> >> > > >> >> > > Simon Holdsworth >> >> > > STSM, SCA Bindings >> Architect; Master Inventor; OASIS >> SCA Bindings >> >> TC Chair >> >> > > MP 211, IBM UK Labs, >> Hursley Park, Winchester SO21 2JN, UK >> >> > > Tel +44-1962-815059 >> (Internal 245059) Fax +44-1962-816898 >> >> > > Internet - >> _Simon_Holdsworth@uk.ibm.com_ >> <mailto:Simon_Holdsworth@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/ >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail >> list, you must leave the OASIS TC that >> generates this mail. Follow this >> link to all your TCs in OASIS at:_ >> __https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_ >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> /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/ >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the >> OASIS TC that generates this mail. Follow this link to all >> your TCs in OASIS at: >> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_ >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]