Re: Fujitsu & Savvion proposal

[Sandy Klausner <klausner@coretalk.net>]

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
>