Hi Dave
If that's the case, isn't the other normative statement equally
redundant?
More below.
David Booz wrote:
OFCA7CC1E4.FEE2A91D-ON85257631.0064577E-85257631.0064BF68@us.ibm.com"
type="cite">
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!
OFCA7CC1E4.FEE2A91D-ON85257631.0064577E-85257631.0064BF68@us.ibm.com"
type="cite">
I don't think we need your second normative statement below.
Agreed.
-Eric.
OFCA7CC1E4.FEE2A91D-ON85257631.0064577E-85257631.0064BF68@us.ibm.com"
type="cite">
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
Eric 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
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
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
---------------------------------------------------------------------
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
|