[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo
David and David,
Taking David Fischer's statement literally, it means that we should
deprecate the current CPA specification. and start over after the MSG spec
reaches version 2.0. Yes, the CPA is a higher level function, but some of
us believe that it is essential to widespread interoperability and to
dynamic e-commerce.
By the way, three companies are prepared to send written statements to
OASIS that they are using the CPA. This is a prerequisite to getting a
standard approved by OASIS.
A better view is that the CPA and MSG spec must get in sync and stay in
sync as both evolve.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
"Burdett, David" <david.burdett@commerceone.com> on 08/24/2001 08:29:33 PM
To: "'David Fischer'" <david@drummondgroup.com>, Martin W
Sachs/Watson/IBM@IBMUS
cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
nfo
>>>I know of several in-work implementations and I don't know of any which
are
implementing CPPA (I'm sure someone out there must be). This does not mean
they
won't. CPPA is generally seen as a second level of implementation over
Messaging. Messaging is the base. Once Messaging is in place, then we add
CPPA, Registries, etc. <<<
I completely agree and I think we have to recognise this.
David
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Tuesday, August 21, 2001 4:11 PM
To: Martin W Sachs
Cc: ebXML Msg
Subject: RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
Marty,
How can SyncReply be used without a CPA?
The only purpose for the SyncReply parameter is for the Sender to tell the
Receiver whether or not to keep the connection open and wait for a reply or
to
close and send the reply later. If the SyncReply behavior was implicit
with
transport (True with HTTP and False with SMTP) then why have this parameter
at
all? I am not suggesting getting rid of this parameter because I believe
there
is good functionality here. SyncReply's sole purpose is requesting
non-synchronous behavior on normally synchronous transports (you couldn't
specify SyncReply=True on SMTP!).
One of the basic premises of ebXML is that all the specs are orthogonal.
We
need to support both with or without a CPA. How can SyncReply be used
without a
CPA? Why is this hard? We didn't think it was before. SyncReplyMode,
along
with other parameters, was removed because the information was already in
the
CPA so why carry it? Then we realized that these parameters weren't
necessarily
in the CPA because we couldn't guarantee the CPA's existence. We have been
putting parameters back, in MessageHeader or in Via. I am only asking that
this
too be put back so SyncReply can be used without a CPA. IMO, these
parameters
should never have been removed.
I know of several in-work implementations and I don't know of any which are
implementing CPPA (I'm sure someone out there must be). This does not mean
they
won't. CPPA is generally seen as a second level of implementation over
Messaging. Messaging is the base. Once Messaging is in place, then we add
CPPA, Registries, etc. We have to support non-CPA implementations -- at
least
for now. (One vendor actually suggested leaving CPAid blank for now since
it is
not needed -- except that the Schema specifies non-empty-string ;-).
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, August 21, 2001 5:30 PM
To: David Fischer
Subject: RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
David,
Your proposal will reopen the whole discussion of what happens when an
element in the message header clashes with an element in the CPA.
If you are sending the large file as a requester, you might have the option
of defining the collaboration protocol such that large file is sent using a
separate business transaction which could then be associated with an
"override" delivery channel. If you are sending the large file as a
responder, then I am less certain if there is any alternative to overriding
the CPA by specifying syncReply in the message header.
Regards,
Marty
****************************************************************************
****
*****
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
****************************************************************************
****
*****
David Fischer <david@drummondgroup.com> on 08/21/2001 11:58:02 AM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject: RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
Yes, I agree. Make DeliveryChannelId tie to a unique address for v1.1.
Normal mode, IMO, for HTTP will be SyncReply=True. However, there will be
fairly common cases where there is a large file (100MB+, 500MB+) where we
want
to change SyncReply to False, just for this one message. My original
premise
has nothing to do with Delivery Channels. I wanted to be able to set
SyncReply
at send time. Chris brought Delivery Channels up as an alternative to
having
SyncReply in MessageHeader. I originally agreed but I am now convinced
this
will not work - at least not in v1.1.
Back to the original topic... We need SyncReply in MessageHeader (in
QualityOfServiceInfo -- see Subject Line).
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, August 21, 2001 10:36 AM
To: David Fischer
Cc: ebXML Msg
Subject: RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
David,
As I explained in my response to Arvola, it appears that at present, each
delivery channel must have a unique endpoint address. I suggested saying
that in version 1.1 of the CPP-CPA spec and then working on associating
multiple delivery channels with the same endpoint address (adding an
additional element to disambiguate), if there is a good case for doing so,
for version 2.0.
We certainly want to avoid putting elements in the message header whose
sole purpose is to make up for deficiencies in the CPA spec.
Regards,
Marty
****************************************************************************
****
*****
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
****************************************************************************
****
*****
David Fischer <david@drummondgroup.com> on 08/21/2001 10:59:07 AM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject: RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
This is exactly the problem I see. How do I send to the same address but
slightly vary the parameters (change SyncReply from True to False)? Chris
suggested (I think) that all that was necessary was to define another
DeliveryChannel. I don't understand how this solves the problem since I
can't
figure out how to tell the receiver which DeliveryChannel to use -- maybe I
can't by design which means this solution won't work. This is too tightly
coupled!
Am I missing the mark? If not, then I need to go back to my original
premise
that SyncReply needs to be in MessageHeader.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Monday, August 20, 2001 10:20 PM
To: Arvola Chan
Cc: David Fischer; Christopher Ferris (E-mail); ebXML Messaging
(E-mail); ebxml-cppa@lists.oasis-open.org
Subject: Re: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
Arvola,
It's late at night and I have just gone through 140 emails accumulated
Friday and today so maybe I am getting a bit dull.
Each party knows about its delivery channels and the other party's delivery
channels and which one goes with each business transaction. This is the
information that is in the CPA and has to be installed in each party's
system.
The missing element in your posting is the endpoint address, defined for
each delivery channel. As long as each delivery channel has a unique
endpoint address, the From MSH should have no ambiguity in where to send
each message and the To MSH has no ambiguity in which delivery channel to
use for a received message. Service and Action should be needed only by
the To Party's MSH and only for routing to the application entry point.
There may be a problem if one wants to define two delivery channels with
the same endpoint address but slight variations in some parameters. I
believe that we have assumed that each delivery channel has a unique
endpoint address but I suspect that we don't say so. Allowing two
different delivery channels to share an endpoint address would certainly
require an additional piece of information that the To MSH would need to
use to identify the correct receive channel for an incoming message.
I suggest that V1.1 state that every delivery channel SHALL have a unique
endpoint address (if V1.0 doesn't say so). For V2.0, we could consider
permitting different delivery channls to share the same endpoint address
and adding whatever disambiguator is required to make this work.
Regards,
Marty
Regards,
Marty
****************************************************************************
****
*****
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
****************************************************************************
****
*****
Arvola Chan <arvola@tibco.com> on 08/20/2001 09:43:52 PM
To: David Fischer <david@drummondgroup.com>, "Christopher Ferris
(E-mail)" <chris.ferris@east.sun.com>
cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>,
ebxml-cppa@lists.oasis-open.org
Subject: Re: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
David and Chris:
I have a similar issue. It is not clear to me that a sender MSH
can uniquely determine a delivery channel to be used to send to
a receiver without knowing the collaboration role played by the
receiver.
The structure of the CPP/A elements is such that a Party
may play multiple collaboration roles. For each such role,
there can be one or more prioritized service bindings. Each
service binding has a service element that essentially identifies
the service provided by the party in question. Each service
binding specifies a default delivery channel, along with zero
or more override elements. Each override element pertains
to a particular action and specifies the delivery channel for
that action.
If the sender knows the role played by the receiver, then it
is straightforward to determine the delivery channel that should
be used in order to send the message to the receiver. However,
there is no role element in the message header. If the Message
Service Interface is defined in such a way that the burden of
determining the delivery channel falls on the MSH, then I am
not sure if the MSH has sufficient information to determine
the delivery channel. The problem I see is that the service
name associated with a service binding is not necessarily
unique. Is it possible to have multiple roles played by the
same receiver with service bindings that share the same
service name? If so, it is not clear to me which corresponding
delivery channel should be used. For this discussion, let's assume
that none of the service bindings in the CPA have override elements.
Thus, it is not possible to use the Action element in the message
header to determine the delivery channel.
Regards,
-Arvola
-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Christopher Ferris (E-mail) <chris.ferris@east.sun.com>
Cc: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
Date: Monday, August 20, 2001 5:33 PM
Subject: RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
Maybe I acceded to quickly? I am trying to understand how to use another
delivery channel to support SyncReply. I see CPAid in the MessageHeader so
the
receiving end knows which CPA to use. I guess the DeliveryChannel is
chosen
based upon which transport is involved.
What if there are two DeliveryChannels with the same transport. One HTTP
w/
SyncReply=True and one HTTP w/ SyncReply=False, how does the receiver know
which
one to use? The CPAid would be the same. Do we need to append the
DeliveryChannel ID on the end?
<eb:CPAid>CompanyA-003</eb:CPAid>
Where CPAid is "CompanyA" and the DeliveryChannel ID is "003"? I'm not
sure
how
the sender tells the receiver which DeliveryChannel to use. Please forgive
my
ignorance but, how does this work?
David Fischer
Drummond Group.
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Friday, August 10, 2001 10:37 AM
To: Arvola Chan
Cc: ebXML Messaging (E-mail)
Subject: RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
Arvola, I agree with you but I don't think this is a significant enough
Requirement to fight for. I will accede to the majority as long as it
seems
like a workable solution.
My personal opinion is that everything in the Via (CPA message related
parameters) should also be represented in MessageHeader -- again I don't
feel
strongly enough about this to fight for it very much.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, August 10, 2001 6:09 AM
To: Arvola Chan
Cc: David Fischer; Burdett David; ebXML Messaging (E-mail);
ebxml-cppa@lists.oasis-open.org
Subject: Re: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
Arvola,
It was not the intent to require use of the syncReplyMode
attribute (and hence the Via). The two parties exchanging
messages point-to-point are assumed to "know" by virtue of
their CPA (or the virtual equivalent of one) what their
syncReplyMode is. The Via element needs this because the
intermediaries don't have access to this information.
Cheers,
Chris
Arvola Chan wrote:
>
> David:
>
> I don't think using a second DeliveryChannel will work. The following is
an
> excerpt from the CPP/A spec:
>
> The ebXML Message Service's syncReply attribute is set to a value of
"true"
> whenever the 1190
> syncReplyMode attribute has a value other than "none". 1191
>
> Even if you have a channel that calls for the use of synchronous reply
mode,
> the syncReply attribute still has to be set. In other words, it is still
> necessary to use the Via element if the syncReply attribute is present
only
> there, but this constradicts the assumption that the Via element is only
> used when intermediaries are involved.
>
> -Arvola
>
> ----- Original Message -----
> From: "David Fischer" <david@drummondgroup.com>
> To: "Arvola Chan" <arvola@tibco.com>; "Burdett David"
> <david.burdett@commerceone.com>
> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> Sent: Thursday, August 09, 2001 7:45 PM
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
>
> > This was my original proposal, syncReply in both. However, I was told
> this
> > could be accomplished using a second DeliveryChannel. While this is
not
> my
> > first preference, it would work... <shrug>
> >
> > David Fischer
> > Drummond Group
> >
> > -----Original Message-----
> > From: Arvola Chan [mailto:arvola@tibco.com]
> > Sent: Thursday, August 09, 2001 12:24 PM
> > To: Burdett David; David Fischer (E-mail)
> > Cc: ebXML Messaging (E-mail)
> > Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceInfo
> >
> >
> > David:
> >
> > I was mostly concerned with how to obtain synchronous replies in the
> single
> > hop case, assuming the Via element is to be used exclusively for
multi-hop
> > scenarios. I didn't realize there is a need to have syncReply vary hop
by
> > hop.
> >
> > I think it is reasonable to have syncReply both in the QOS and in the
Via
> > elements, and to say that the information in the Via element overrides
the
> > information in the QOS element. I don't have any particular preference
> > between the names Via versus RoutingHeader.
> >
> > Thanks,
> > -Arvola
> >
> > -----Original Message-----
> > From: Burdett, David <david.burdett@commerceone.com>
> > To: David Fischer (E-mail) <david@drummondgroup.com>; 'Arvola Chan'
> > <arvola@tibco.com>
> > Cc: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
> > Date: Thursday, August 09, 2001 9:57 AM
> > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceInfo
> >
> >
> > >Arvola
> > >
> > >I disagree. You need syncReply in the Via. The attached PDF file
titled
> > "Why
> > >you need syncReply in the Via" contains a diagram which illustrates
the
> use
> > >case. Where the first hop is synchronous and the second not.
> > >
> > >If we want Via to be used only when intermediaries are being used then
> you
> > >would need ackRequested held elsewhere, e.g. in the Quality of
Service.
> > >However since syncReply can vary from hop to hop (see previous
example),
> > you
> > >would then need to also have it in the Via and a rule that the Via
> > >over-rides the QoS.
> > >
> > >There is also the issue that the sender of a message may not know that
it
> > is
> > >multiple hop as the PDF file titled "Using ebXML RM behind the
firewall"
> > >illustrates. In this case external communications are done
synchronously,
> > >but the messaging to an application within the company is done
> > >asynchronously.
> > >
> > >I think we need to keep ackRequested and syncReply in the Via, but
rename
> > it
> > >... to "Routing Header" perhaps, although I have no strong preference
...
> > ;)
> > >
> > >I'd appreciate your thoughts on these use cases.
> > >
> > >David
> > >PS Slides very similar to these two were posted ages ago and discussed
in
> > >Tokyo last November I think.
> > >
> > >
> > >-----Original Message-----
> > >From: Arvola Chan [mailto:arvola@tibco.com]
> > >Sent: Wednesday, August 08, 2001 6:59 PM
> > >To: David Fischer; ebXML Msg
> > >Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> > >QualityOfServiceInfo
> > >
> > >
> > >David:
> > >
> > >Sorry for the delayed response. I agree with you that the Via element
> > should
> > >be used exclusively for those cases where intermediaries are involved.
> > >Therefore, it makes sense to move the syncReply and ackRequested
> attributes
> > >to be under the QualityOfServiceInfo element.
> > >
> > >Since there already is a deliverySemantics attribute under the
> > >QualityOfServiceInfo element, and the reliableMessagingMethod
attribute
> can
> > >vary from one hop to another, I think reliableMessagingMethod should
stay
> > in
> > >the Via element.
> > >
> > >Regards,
> > >-Arvola
> > >
> > >-----Original Message-----
> > >From: David Fischer <david@drummondgroup.com>
> > >To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
> > >Date: Monday, August 06, 2001 8:51 PM
> > >Subject: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
> > >
> > >
> > >There should be nothing in the Via which is not also in other headers.
> Via
> > >should only be used for multi-hop intermediaries. In the case of
> > SyncReply,
> > >there is no single-hop way of requesting SyncReply=true.
> > >
> > >Attributes SyncReply and ReliableMessagingMethod should also be in
> > >QualityOfServiceInfo. They should retain their current defaults.
> > >
> > >Regards,
> > >
> > >David Fischer
> > >Drummond Group.
> > >
> > >
> > >------------------------------------------------------------------
> > >To unsubscribe from this elist send a message with the single word
> > >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> > >
> > >
> > >------------------------------------------------------------------
> > >To unsubscribe from this elist send a message with the single word
> > >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> > >
> > >
> >
> >
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
----------------------------------------------------------------
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>
----------------------------------------------------------------
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