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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: Re: Proposed Revisions to MS ver 0.8

Mr. Andrew Eisenberg, 

Thank you for sending your comments.

Andrew Eisenberg <aeisenbe@progress.com> wrote:
> I've looked it over and have a couple of questions and comments.
> - lines 158-159, "In the Receiver, ..." also line 196, 3rd bullet in table
>   These lines state:
>      "In the Receiver, WindowSize determines the maximum number of messages
>       that the Receiver may receive at one time before sending Acknowledgement
>       Messages to the Sender."
>   This seems either incorrect or misleading. The Receiver should be ack'ing
>   messages asynchronously, and as soon as possible.

Yes, probably this sentence should be changed to:
    "In the Receiver, WindowSize specifies the maximum number of
     messages which reach the Receiver at one time before sending
     Acknowledgement Messages to the Sender."

> - lines 187-190, "When the Sender has sent all of the messages ..."
>   This paragraph is stating that a Sender may perform the recovery sequence that
>   it uses for timeout before a timeout has occurred. Why is this useful? Could
>   it be dropped?

It is not easy to determine most appropriate timeout setting. If
timeout setting is too long, communication performance will lower. This
function (lines 187-190) prevents that communication performance lowers
even if timeout setting is too long.

> - line 258, "This method of Simple Routing ..."
>   This is one instance of messaging parameters being acquired from "the CPA
>   or other suitable document". This might be expensive and error prone when
>   it is evaluated at multiple Hubs. Have you considered looking this up in
>   the initial Sending MSH and instantiating it in part of the XML Header?

Your idea might be another good selection. However your idea means that
different routing method may be specified per message. I think it is
expensive for Hub and/or MS. It might lower communication performance.
What do you think?

> - lines 290-297, Editor Note 5:
>   Same issue as above. Can the messaging parameters acquired from "the CPA
>   or other suitable document" really be acquired without the initial To and
>   From parties?

My answer is same above.

> - line 299, Figure 2-4
>   Can the DNM really be sent from URI=6 to URI=1, given the use of multiple
>   transports among the MSH's?

Yes. Editor Note 5 on page 10 said:
    "Because the returning DNM is sent with reliable message semantics,
    the following picture might not be clear: this DNM must traverse
    all the nodes back to the From_Party, and one of the three methods
    for confirming delivery must be used."

However, originally DNM is Mr. David Burdett's idea. He is more
appropriate person to answer to your question. Do you have other
comments, David?

E-mail: shima@rp.open.cs.fujitsu.co.jp
TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED

[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