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:
OF7EAFF36D.4DB3AE30-ON8525762E.004180A3-8525762E.00423697@us.ibm.com"
type="cite">
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
Simon
Holdsworth ---09/11/2009 06:05:18 AM---Ashok, Comments inline.
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
|