Re: Fujitsu & Savvion proposal

[Sandy Klausner <klausner@coretalk.net>]

Chris:
I still think that there is a basic issue here of mixing level of processing
concern. Tangling domain transaction closure with transport closure leads
one down a path that is inherently not scalable from a practical deployment
perspective. Proving a reliable messaging mechanism that "works" is a
required infrastructure ebXML capability. I just don't understand how one
would practically untangle the domain transaction information from the
communications transport stream in a generic fashion. The first is a
background task while the later is a foreground task. The required
"overhead" for the round robin trip to verify message receipt (unsigned or
signed) for any particular payload size is a constant due to network
propagation delay.

I must admit that I have not read the particulars of the Sliding Windows
approach and perhaps I am reading to much into this proposed capability. If
the issue is restricted only to avoiding getting tangled up in queued
incoming message payload traffic, then the approach is well worth pursuing.
Sandy

> From: christopher ferris <chris.ferris@east.sun.com>
> Organization: XTC Advanced Development
> Date: Fri, 26 Jan 2001 07:42:35 -0500
> To: Sandy Klausner <klausner@coretalk.net>
> Cc: jacques durand <jacques@savvion.com>, ebxml-poc@lists.ebxml.org,
> iwasa@fsc.fujitsu.com, shima.masa@jp.fujitsu.com
> 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
>>>