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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

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


Subject: Re: Fujitsu & Savvion proposal


Sandy,

I think that you're missing the point of the demonstration
proposal. The "batch" of messages is purely artificial,
for purposes of demonstrating that reliable messaging
a) works and b) does not impose significant overhead.

Indeed, the whole purpose of the demonstration is to
dispel *precisely* the myth/comment you cite in the 
last sentence of your email:

> It just seems to me that the TR&P implementation path you are suggesting may
> be technically elegant, but introduces a level of complexity that in itself
> will have scaling difficulty.

Cheers,

Chris

Sandy Klausner wrote:
> 
> Fujitsu & Savvio:
> 
> I have read your demo draft proposal and question the general technical
> solution to this round robin ack performance problem. If the concern here is
> transaction throughput, wouldn't it be more practical to declare a singular
> message that contains a collection of trade instances and assuring that this
> payload has indeed been received intact. The receiver can always return a
> message that itself could contain a subset of "rejection trade" instances.
> It just seems to me that the TR&P implementation path you are suggesting may
> be technically elegant, but introduces a level of complexity that in itself
> will have scaling difficulty.
> 
> Sandy Klausner
> CoreTalk Corporation
> 408.867.1100 O
> 408.813.1124 C
> 
> > From: jacques durand <jacques@savvion.com>
> > Date: Thu, 25 Jan 2001 20:50:01 -0800
> > To: ebxml-poc@lists.ebxml.org
> > Cc: jacques@savvion.com, iwasa@fsc.fujitsu.com, shima.masa@jp.fujitsu.com
> > Subject: Fujitsu & Savvion proposal
> >
> > Here is a demo proposal, focused on the new RM / TRP spec.
> > The proposal is intentionally terse on the business scenario side,
> > but strong in business *significance*, so that it can accommodate other
> > proposals
> > that are more architectured around a business scenario, (e.g.
> > CommerceOne proposal.)
> >
> > For your review...
> >
> > Regards,
> >
> > jacques Durand
> > Savvion
> >
> 
> > From: jacques durand <jacques@savvion.com>
> > Date: Thu, 25 Jan 2001 20:50:01 -0800
> > To: ebxml-poc@lists.ebxml.org
> > Cc: jacques@savvion.com, iwasa@fsc.fujitsu.com, shima.masa@jp.fujitsu.com
> > Subject: Fujitsu & Savvion proposal
> >
> > Here is a demo proposal, focused on the new RM / TRP spec.
> > The proposal is intentionally terse on the business scenario side,
> > but strong in business *significance*, so that it can accommodate other
> > proposals
> > that are more architectured around a business scenario, (e.g.
> > CommerceOne proposal.)
> >
> > For your review...
> >
> > Regards,
> >
> > jacques Durand
> > Savvion
> >
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC