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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: Re: [ebxml-msg] Re: SyncReply Module


David,
 
Please refer to what Chris said in answer to your question:
"There is nothing, nor should there be nothing to preclude OTHER SOAP headers, not just ebXML MessageHeader in a SOAP message that just happens to also contain ebXML defined extensions. There is no need for a non-ebXML MSH SOAP node to understand anything in the MessageHeader as long as it understands whatever headers are targetted to it by virtue of the actor of "next" or anything else for that matter. ebXML is not, nor should it be, a closed protocol, especially given that it is layered on top of SOAP."
An intermediate SOAP node may route and forward based on these additional headers and not the MessageHeader element.  In fact, the MessageHeader is addressed to the To Party or default actor.  A full-fledged ebXML MSH intermediary is not required to look in that module if it is not necessary for the processing done at that node.  Routing based only on information in the URL is completely legal.
 
Again, we're rehashing a conversation that occurred at length last week.  If the current document doesn't make everything clear, additional editorial work might be required.
 
thanx,
    doug
 
----- Original Message -----
Sent: Monday, 19 November 2001 11:56
Subject: RE: [ebxml-msg] Re: SyncReply Module

OK Chris, since you are just talking and not answering the questions, I will KIS and ask one at a time.
 
How can there be SOAP nodes in our path which do not understand MessageHeader?  How would it route/forward?
 
- David.
 
BTW, I like the HTML ;-)
-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Monday, November 19, 2001 12:17 PM
To: David Fischer
Cc: Arvola Chan; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: SyncReply Module

David,

Some comments below.

Cheers,

Chris

David Fischer wrote:
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com type="cite">
First, I agree there are still some difficulties with multihop and syncReply.
This new element does not do anything to solve those difficulties. The only
answer I can see is to do as Dale suggested and use a cascading Ack -- but that
has difficulties too.
This doesn't address the problem, the issue isn't acknowledgments, it is all about
message exchange patterns.
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com type="cite">


Second, I still think there cannot be IM SOAP only nodes. This makes no sense
at all since any SOAP IM MUST understand MessageHeader in order to route. This
is the Store-and-Forward only IMs we have been discussing -- doesn't need to
touch the Manifest. If it can look in MessageHeader to get the To then it can
also look in MessageHeader/QualityOfServiceInfo to get syncReply. So I must ask
again, why are we adding a new element.
There is nothing, nor should there be nothing to preclude OTHER SOAP headers, not just
ebXML MessageHeader in a SOAP message that just happens to also contain ebXML
defined extensions. There is no need for a non-ebXML MSH SOAP node to understand
anything in the MessageHeader as long as it understands whatever headers are
targetted to it by virtue of the actor of "next" or anything else for that matter. ebXML is not,
nor should it be, a closed protocol, especially given that it is layered on top of SOAP.
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com type="cite">


Third, when I made the assertion that syncReply is for MSHsignals, I did not
mean to imply that it did not match SyncReplyMode -- it does follow. If
SyncReplyMode is not *none* then syncReply MUST be *true*. This does not imply
that syncReply cannot still be *true* even if SyncReplyMode is *none* -- this
would mean MSHsignals only.

However, when would the MSH syncReply ever be *false*?

I must reiterate, we don't need syncReply at all.

I don't buy this unless we are going to completely abandon multi-hop and intermediaries
for v1.1. There needs to be some way of communicating to a node whether the
connection over which a message was received is expecting a response so that it
can be held open (as long as feasible and practical). Whether the node is a MSH or a
plain old SOAP node serving some other purpose for which ebXML does not
define itself is irrelevant. The reason that the actor of "next" is used is just to provide
for the possibility, regardless of how remote that the node at which a message is received
can be asked, in a manner that REQUIRES it to understand (mustUnderstand=1)
at least the part about the fact that the connection over which the message was received
will need to be kept open for a subsequent response.

We agreed to this in the F2F by vote. I see no reason why it needs to be continuously
debated.

NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com type="cite">


Doug, Chris?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Monday, November 19, 2001 1:16 AM
To: David Fischer; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: SyncReply Module


David:

Chris and Doug are the SOAP experts who have recommended the use of the
SyncReply element. I would defer to them for an explanation on the necessity
of this elemen (possibly for inclusion in the spec).

Doug stated in his last message:

http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00223.html

"The previous synchronous mode would have sup ported MSH -> HTTP proxy -> MSH
because HTTP proxies operate in a synchronous mode by default. The new flag
allows MSH -> SOAP -> MSH in spite of the asynchronous mode the SOAP node
might prefer."

I suspect that is the main reason for the SyncReply element.

I don't quite agree with your statement "SyncReply in the MSH concerns
sending back MSHsignals." Depending on the sync reply mode set in the CPA,
SyncReply can mean returning the MSH signal synchronously, or returning the
MSH signal along with business level message (signal and/or response)
synchronously.

It also occurs to me that SyncReply may be incompatible with an AckRequested
element that is only targeted to the nextMSH. If the nextMSH returns the
intermediate Ack synchronously, how can it possibly return the application
level response also synchronously? If this observation is correct, perhaps
the incompatibility should be identified in appropriate pl aces within the
spec.

Regards,
-Arvola

----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "Arvola Chan" <arvola@tibco.com>; <ebxml-msg@lists.oasis-open.org>
Sent: Sunday, November 18, 2001 3:04 PM
Subject: RE: [ebxml-msg] Re: SyncReply Module


If SyncReply is always included, then why is it needed in the CPA?  If it
always
goes all the way through, why is there Actor=Next?  What is the advantage
to
having this as a top level element instead of in QualityOfServiceInfo?

We are adding a new top-level element and gaining nothing. This is
definitely
not backward compatible, not a fix and not a clarification.  If all we are
doing
is renaming Via, then we should leave Via alone since that would be
backward
compatible and this change gains nothing.  If this is always present then
it
should be combined with MessageHeader since it adds no functionality to
have it
separate and adds 100+ characters to every single message.

As we discussed, the simple solution is ALWAYS assume syncReply=true for
HTTP
then we don't need this at all.  Why would we ever need syncReply=false?
I can
only think of one use case (very large files), which we have decided to
ignore.
In the case where there is an async hop/IM in the middle, the
response/signals
will be sent back async anyway so the IM can just close the connection --
the IM
already knows what to do.

If you are concerned with the BPSS requirements, then you are talking
about
another layer (layering violation).  SyncReply in the MSH concerns sending
back
MSHsignals.  If BPSS needs for the MSH to wait and send back a combo
message,
then only the end/ToParty needs that info, not the IMs.  IMs can ALWAYS
assume
syncReply=true (there is no syncReply flag for SMTP and if it appears it
is
ignored -- no error).

This is a bad/unnecessary idea that needs to go away.

Regards,

David.

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, November 16, 2001 8:35 PM
To: David Fischer; Doug Bunting; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: SyncReply Module


David:

We used to have a syncReply attribute under both QualityOfServiceInfo and
Via. We determined that the one under QualityOfServiceInfo is not needed
because it should be obtained from the CPA.

The Via element is essentially renamed as SyncReply because once we
removed
the TraceHeaderList, syncReply is the only attribute that is left in Via.

Because the sender may not be aware of the presence of SOAP or MSH
intermediaries, it should always include a syncReply element in the
message
header if the CPA specifies any syncReplyMode other than 'none'.

Regards,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>; Doug Bunting <dougb62@yahoo.com>;
ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Friday, November 16, 2001 6:18 PM
Subject: RE: [ebxml-msg] Re: SyncReply Module


No, SyncReply is NOT perMessage.  I added a paragraph in 6.1 to cover
this
issue.

My problem is that you never know if there is an intermediary so should
you
always include SyncReply if SyncReplyMode not equal *none*?  If SyncReply
is
included, it will make it all the way to the end (one hop at a time),
isn't
there always a potential for mismatch?  If it is always going to be pass
all the
way through, why put actor=next?  If it is always included, then why
bother
with
it in the CPA?

What was the value of taking this out of QualityOfServiceInfo and making
it
an
element?  IMO, we just added 100+ bytes for nothing.

Regards,

David.

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, November 16, 2001 7:37 PM
To: Doug Bunting; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: SyncReply Module


Doug:

Thanks for the clarification why SyncReply belongs in 'Core
Functionality'
rather than in 'Additional Features'.

I have two related questions:

1. Is syncReply assumed one of those parameters that are perMessage? I
don't
think that the CPP/A team is aware of such an assumption.

2. If not, is the element mandatory when it is already specified in the
CPA?
When no intermediaries are involved, I would have expected that a
syncReply
specification in the CPA would imply that sync reply is to be used
regardless of the presence or absence of a SyncReply element in the
message
header. What triggers the sender to include a SyncReply element in the
first
place?

Thanks,
-Arvola

-----Original Message-----
From: Doug Bunting <dougb62@yahoo.com>
To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Friday, November 16, 2001 5:15 PM
Subject: Re: [ebxml-msg] Re: SyncReply Module


Arvola,

My, you're a quick reader...

You're understanding covers the flag's semantics as it appeared in the
1.08
document.  Maintaining the existing "keep channel open 'til a response is
ready" semantics, we slightly expanded the feature to include making sure
an
intermediate SOAP processor doesn't close the connection.  In essence, we
recognised the possibility of "regular" SOAP nodes linking full-blown MSH
nodes.

The previous synchronous mode would have supported MSH -> HTTP proxy ->
MSH
because HTTP proxies operate in a synchronous mode by default.  The new
flag
allows MSH -> SOAP -> MSH in spite of the asynchronous mode the SOAP node
might prefer.

You're correct that the previous flag in QoS is no longer necessary.

We discussed placement of this module's description in our document
during
the meeting and the consensus seemed to be putting this feature in the
base
section because it may apply even to a SOAP node with just a bit of ebXML
smarts -- level 0 in ebXML conformance.

thanx,
doug

----- Original Message -----
From: "Arvola Chan" <arvola@tibco.com>
To: "David Fischer" <david@drummondgroup.com>
Cc: <ebxml-msg@lists.oasis-open.org>
Sent: Friday, 16 November 2001 16:47
Subject: [ebxml-msg] Re: SyncReply Module


David:

My understanding is that the SyncReply module is equivalent to the
renaming
of the former Via module, minus the TraceHeaderList. As such, shouldn't
it
stay in Part II (Additional Features) and under the Multi-hop chapter?

The syncReply attribute under QualityOfServiceInfo goes away because the
use
of syncReply between the From and To parties is governed by a static (not
per pessage) parameter in the CPA.

In the single-hop case, it should be sufficient to indicate in the CPA
that
sync reply is to be used, without explicitly including a SyncReply
element
in the SOAP header.

Regards,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Friday, November 16, 2001 3:59 PM
Subject: [ebxml-msg] v1.09


This includes all the edits I have received including those decided upon
at
the
F2F this week.

I do not yet have a Conformance Clause or the new sub-section dealing
with
Signature Security (Galvin).

Regards,

David Fischer
Drummond Group
ebXML-MS Editor.



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC