OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] NEW ISSUE: Is an implementation supporting a smaller maxmessage number valid? [Re: [ws-rx] NEW ISSUE: Max message number in policy]


Doug,

A Java long is signed and hence it's maximum value is 
+9,223,372,036,854,775,807.

In order to support an unsigned long, you need to resort to use of 
java.math.BigInteger which 
is less efficient than using the primative type long. Besides that, J2ME 
doesn't include java.math
so it would therefore be even more difficult to implement a WS-RM endpoint 
on that platform.

Since nine quintillion is a REALLY BIG NUMBER,  (yeah, yeah, 19 
quintillion is an even bigger number) 
we would like to propose that an endpoint  could declare the maximum 
MessageNumber it supported 
is the maximum value of a long such that it would be possible to implement 
processing of the 
MessageNumber using a Java long primitive type and so that the spec could 
be implemented
in a conformant manner on the J2ME platform.

It would take ~292,471,208.67 years to exhaust a sequence that was only 
the size of a long 
if you processed 1000 messages per second.

Most of us will be dead before the first WS-RM Sequence is exhausted even 
if it is reduced
from 18 quintillion to 9 quintillion.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

Doug.Bunting@Sun.COM wrote on 07/14/2005 05:32:20 PM:

> *Title*: Is an implementation supporting a smaller max message number 
valid?
> 
> *Description*: The existing specification includes the clause "If the 
> message number exceeds the internal limitations of an RM Source or RM 
> Destination ...".  This allows a source or destination to handle 
> unexpected failures gracefully.  It does not clearly allow, require, or 
> prevent the implementation to be designed or deployed with a message 
> number limit.  Should we support such a limitation?
> 
> *Justification*: Issue below presupposes a "yes" answer to this 
> question.  Should decide this larger question before deciding how to 
> fill gap left if the answer is "yes".
> 
> *Target*: core (RM spec)
> 
> *Type*: design
> 
> *Proposal*: I lean toward "no" but could be convinced otherwise.  If 
> "no" is the answer, the specification could change to make it clear a 
> WS-RM compliant implementation _must_ support the full unsigned long 
> range for the message number.  That likely requires conformance 
> terminology not presently in the specification; this issue is not 
> intended to broach the even-more-general subject of conformance clauses. 

>   My proposal therefore comes down to "close, no action".
> 
> *Related issues*: Max message number in policy [no number yet]
> 
> thanx,
>    doug
> 
> On 12/07/05 07:39, Doug Davis wrote:
> > 
> > *Title*: Max message number in policy
> > *Description*: define a policy assertion that defines the highest 
> > message number the RM destination will accept.
> > *Justification*: without knowing in advance what the highest message 
> > number is the RM source may exceed it, causing the entire sequence to 
be 
> > terminated - when it may have been able to start a 2nd sequence to 
> > continue its work.  By allowing the RM source the option of 
terminating 
> > the sequence gracefully it can still deliver lost messages for the 
> > original sequence.  As it stands now, if the sequence is terminated 
the 
> > lost messages will not be resent.
> > *Target:* RM policy spec
> > *Proposal:* Define:
> > /wsrm:RMAssertion/wsrm:MaxMessageNumber
> > /wsrm:RMAssertion/wsrm:MaxMessageNumber@number - unsigned long
> > 
> > thanks
> > -Doug
> > 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]