[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: FW: T2, Proposed solution for ... Re: SyncReplyandReliableMessagingMethod in QualityOfServiceInfo
Comments below.
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 09/21/2001 12:10:59 PM
To: Chris.Ferris@Sun.COM, ebxml-msg@lists.oasis-open.org
cc:
Subject: RE: FW: T2, Proposed solution for ... Re: SyncReply
andReliableMessagingMethod in QualityOfServiceInfo
Chris,
Does this mean communications between two Trading Partners is ALWAYS RM or
NEVER
RM? We've already decided DeliveryChannel is address specific so there
cannot
be two DeliveryChannels between one set of addresses.
MWS: There certainly be two or more delivery channels with the same
endpoint
address. All but one have to be associated with specific (different)
business
transactions. These are defined in the override element. In any case, one
can
always associate different endpoint addresses with delivery channels even
though
they go to the same physical place (different URIs with the same IP
address).
Does this mean the RM
settings are fixed and never changing between these two Trading Partners?
Doesn't sound very flexible. Some documents will be critical and thus
require
RM while some do not. How do we accommodate this?
MWS: We don't have anything in the CPA that specifies anything per
instance of
a message. I don't know how that could be done. I don't think that the
BPSS
provides this capability either. Anything that has to be per instance of a
message has to be done through information in the message header. The
application
has to specify this information.
Chris wrote:
How does this work if the sending MSH knows nothing of intermediaries?
Are you suggesting that the Via element is now REQUIRED on all messages?
In the case of single-hop, no retryCount is necessary. I have to agree
though,
how does the sender know this is single-hop? Since there is always the
potential of transparent IMs, shouldn't we assume that nothing is
single-hop and
therefore Via is ALWAYS required for RM?
On the issue of an MSH knowing it is an IM, this decision has to be made at
the
MSH layer since security is an MSH layer function (see figure 6-1). If you
wait, the MSH will try to validate the signature (or decrypt) and fail thus
sending an error message back to the From Party. Again, message packaging
and
security are in the MSH, not the Application*. The MSH MUST know it is an
IM.
Packaging and forwarding are MSH functions, not application.
*A different set of criteria might apply to an intra-company mailroom
situation.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
Sent: Friday, September 21, 2001 9:25 AM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: FW: T2, Proposed solution for ... Re: SyncReply
andReliableMessagingMethod in QualityOfServiceInfo
Dan Weinreb wrote:
>
> Date: Thu, 20 Sep 2001 16:45:07 -0500
> From: David Fischer <david@drummondgroup.com>
>
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
> Sent: Thursday, September 20, 2001 11:50 AM
>
> How does this work if the sending MSH knows nothing of intermediaries?
> Are you suggesting that the Via element is now REQUIRED on all
messages?
>
> <df>Yes, this is a problem, not only for retryCount but for all
parameters
in
> Via. I have asked this same question before, is Via always required?
If
we are
> doing RM at all, then Via is required in order to pass the
ackRequested and
> reliableMessagingMethod parameters. I guess Via is REQUIRED for all
RM
> messages -- regardless of retryCount.
> </df>
Here, I disagree. The parties to a single-hop exchange can via the
CPA "know" whether the message is being sent via ebXML RM and hence there
is no need whatsoever for ackRequested. Again, I want to make it clear
that the "CPA" is a "virtual CPA" in the sense that there is an
understanding
between the parties that is shared whether by means of a physical CPA
or otherwise. I think you know my preference;-)
>
> Right, the question is whether it's an RM transmission or not.
>
> Every hop in a communication is either using ebXML RM or not: ebXML RM
> is being used if (a) this is supposed to be a reliable communication
> and (b) reliableMessageMethod says that the reliability is done with
> ebXML RM rather than by the transport layer.
>
> Even if there is no IM, there is still one hop, and the hop is either
> using ebXML RM or not.
>
> How does an intermediary distinguish itself as such?
>
> <df>The IM must know that it is an IM in order to forward rather than
process
> the payload. If the IM is not the From Party or the To Party then it
must
be an
> IM. This is not quite true for a mailroom situation (need to work on
this --
> something like MTA routing tables? or MX records?).
> </df>
Again, I disagree here. I think of an MSH as being unaware of the fact that
it is anything but a MSH. The IM-ness of a node is captured in application
logic as we have discussed, not as an aspect of the MSH itself. IMO,
the fact that intermediary functionality is being applied by the "routing
app"
is no different than if the "application" were a responding application
of a true endpoint.
I suppose that the MSH node could detect that the ToParty is not itself
and apply a different set of logic, but again, this seems to be a bit more
complexity than might be needed otherwise.
RoutingApp
^ |
| V
MSH-in MSH-out
>
> And whenever a hop happens, the MSH's at each end of the hop have to
> "know" somehow what the reliableMessageMethod parameter is, so that
> they know whether to talk ebXML RM or not.
Agreed.
>
> retryInterval applies to the RM retry. You are now stating that the DR
is
the RM
> artifact, not the Acknowledgment. What happens when no DR is
requested/required?
> Does the sending MSH wait for the response message?
>
> <df>Chris, you are right, almost. There is a CPA to the first IM and
a CPA
with
> the end.
>
> If we're going to be using CPA's this way, I think the CPA is going to
> need some work.
Agreed. This is a known issue.
>
> The overall idea of the CPA is that you examine what business process
> you're doing, what role you're in, and what service and action you're
> performing; you submit this to the CPA, and it gives you back a
> DeliveryChannel and a Packaging. DeliveryChannel, in turn, give you
> a Transport and a DocExchange, plus some parameter values.
>
> The information in Transport is only relevant to hop-to-hop
> communications; it's meaningless to ask for, say, the TCP address of
> the To Party when there are IM's, since the From Party doesn't talk
> directly to the To Party.
>
> The information in Packaging is all about the payload, and so it's
> only relevant to end-to-end communications; IM's don't pay attention
> to the contents.
>
> How about the parameters in DeliveryChannel, and DocExchange? It
> looks to me like they are about the communication as a whole, i.e. all
> the hops, but this perhaps should be clarified.
Supposed to be.
>
> Should the IM's really be looking at the Service and Action fields of
> the message, and looking through the Override elements of a CPA, in
> order to decide what parameters to use?
----------------------------------------------------------------
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