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

[David Booz <booz@us.ibm.com>]

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?

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

Simon Holdsworth ---09/14/2009 08:32:36 AM---Ashok, So is the satisfaction of the intents by binding configuration something

From:	Simon Holdsworth <simon_holdsworth@uk.ibm.com>
To:	ashok.malhotra@oracle.com
Cc:	David Booz/Poughkeepsie/IBM@IBMUS, Eric Johnson <eric@tibco.com>, sca-bindings@lists.oasis-open.org
Date:	09/14/2009 08:32 AM
Subject:	Re: [sca-bindings] Further thoughts on issue BINDINGS-85

---

Ashok, 

So is the satisfaction of the intents by binding configuration something that is explicitly defined using formal language and calculable, or is it something that the binding implementation itself determines? 

For example could there be something formal that says atLeastOnce is satisfied for binding.jms if @deliveryMode=PERSISTENT?  Or is the knowledge that the configuration parameters can satisfy the intent determined by the binding implementation (and so cannot be determined purely by looking at the binding and policy documents). 

Following from my earlier note, if intents can be satisfied by specific binding configuration, shouldn't we define that relationship in the binding specification? For example saying binding.jms/@deliveryMode=PERSISTENT satisfies atLeastOnce, at least via a conformance statement if there is not formal language to express that. 

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

From:	ashok malhotra <ashok.malhotra@oracle.com>
To:	Eric Johnson <eric@tibco.com>
Cc:	David Booz <booz@us.ibm.com>, 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
>>
>> 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>
>>
>> To:                  
>> 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> 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
>> > >
>> > >
>> > > 
>> ------------------------------------------------------------------------
>> > >
>> > > /
>> > > /
>> > >
>> > > /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