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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: Re: Intermediary support in the 1.1 version of the MSG and CPP/A specs



Regarding Arvola's second paragraph:  I believe that the existing content
of the CPA is sufficient for expressing the interaction between each
endpoint and the intermediary.  A separate CPA would express whatever
configuration information has to be known between the two endpoints
(marketplace clients); possibly, this CPA would be only a subset of the CPA
definition and might require redefining some elements/attributes to have
minOccurs="0".  I believe, but am less certain, that a normal CPA would
also suffice to interconnect two adjacent intermediaries.  For the example
that I gave in the previous posting, I don't believe that it would be
necessary for those CPAs to reference each other.  I am, of course, talking
about a use case in which the intermediary is not "hidden".

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 09/25/2001 03:45:25 PM

To:   christopher ferris <chris.ferris@Sun.COM>
cc:   ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org
Subject:  Re: Intermediary support in the 1.1 version of the MSG and CPP/A
      specs



Chris:

I agree with you that there will be use cases where a forwarding
intermediary may need to use different transport protocols for inbound and
outbound messages. I believe Dale is assuming that a common CPA will be
used
by the From Party, the To Party, and the intermediary/intermediaries. Maybe
that assumption is too restrictive. Even with such an assumption, it is not
clear to me how it can be made to work. Consider the one intermediary case,
if the intermediary's endpoints are transparently used by the From Party
and
the To Party as their own endpoints in the CPA (i.e., the transport
endpoints in the CPA all contain addresses associated with the
intermediary), then where does the intermediary find the real forwarding
addresses for the From Party and To Party? Clearly, there is extra
configuration information needed by the intermediary that is missing from
the CPA. I also tend to agree with Marty that once you take into
consideration transport level security or if there are multiple
intermediaries, it will be unwieldy to capture all the relevant
configuration information in one CPA.

Has anyone worked out simple examples where a separate CPA is used between
each adjacent pair of MSH nodes? What kind of business processes have to be
used to represent the message forwarding activities? What Service and
Action
elements will be appropriate under the Via element? Is the existing CPP/A
element structure sufficient for this purpose?

Regards,
-Arvola

-----Original Message-----
From: christopher ferris <chris.ferris@Sun.COM>
To: Arvola Chan <arvola@tibco.com>
Cc: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>;
ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Tuesday, September 25, 2001 11:14 AM
Subject: Re: Intermediary support in the 1.1 version of the MSG and CPP/A
specs


>Arvola,
>
>A couple of comments.
>
>Cheers,
>
>Chris
>
>Arvola Chan wrote:
><snip/>
>> ===========================================================
>>
>> Messaging
>>
>> Arvola reported a fair amount of list traffic on RM and whether
end-to-end
>> retransmission should be specified.  He asked if version 1.1 will we
deal
>> with forwarding intermediaries appropriately.  Dale distinguished
between
>> two cases: forwarding intermediaries, where a CPA isn?t needed, and
>> multiparty cases, which is in the scope of version 2.0.  He opined that
the
>> approach taken in the proof-of-concept demo is probably sufficient for
>> forwarding intermediaries (the intermediary is only involved in the CPA
as a
>> transport endpoint).  Arvola questioned whether that made the Via
>> (messaging) element unnecessary.   Dale responded that it wasn?t
necessary
>> for the forwarding case, and would be used at the discretion of the
>> originating MSH.  Our commitment is to support the endpoint mechanism,
and
>> exactly what else is needed is unclear.  We may recommend that CPA
software
>> check the coherence of values given for timeouts, retries, etc.
According
>> to Tim, that assumes the same security and transport on both sides of
the
>> intermediary.   Dale said we?re assuming that the intermediary doesn?t
alter
>
>It isn't a requirement that the same transport protocol be used on either
side
>of a forwarding intermediary, IMO. e.g. the sending node might use
>HTTP between itself and the intermediary and then between the intermediary
>and the recipient, the protocol might be SMTP. What may be necessary
>is that between the Intermediary and the MSH to which it forwards messages
>there be a separate CPA, one that possibly deals only with transport
>details (as David B has suggested). Thus, the intermediary might introduce
>a Via element to account for that. This isn't completely clear.
>
>I certainly agree that for forwarding, there is no explicit need (for the
>first hop) of a Via element.
>
>As for security, things start to get a little crazier. I think that the
>same level of security needs to be applied, whether it is necessarily the
same
>set of certificates, etc is less clear.
>
>> packaging and security - to the extent that the Via element or the
>> TraceHeaderList impacts such things, it will be reflected in an
agreement.
>> Marty asked if the intermediary can pass through transport level
security
>> info, and if not, he suspects we?re into a multiparty situation.  Jamie
>> questioned whether the Via element could potentially thwart the policy
>> intentions of a party if it resulted in changed messaging settings.
Dale
>> recalled ?case 1.5? of a forwarding intermediary that restructures or
>> re-encapsulates the message/payload in some manner - a CPA may be needed
>> then.  Tim proposed acknowledging that such cases exist but are not
>> supported for 1.1.  David stated that the Messaging committee considers
>> intermediaries out of scope for their version 1.1.  Jamie asked if an
>> intermediary is considered to be a pure forwarder bound to respect the
CPA
>> between two end parties; we then discussed advantages of keeping CPA
content
>> technical in nature from the standpoint of expediting agreement and
>> implementation.  Tim asked about how non-repudiation and error
propagation
>> happen with intermediaries.  We discussed that some errors may come from
the
>> endpoint and others from an intermediary, and David (?) thought that in
any
>> case they?re just ebXML messages.  Arvola asked if an intermediary would
>> have to identify itself as the end party if it?s not explicitly
identified
>> in the CPA.
>>
>> ----------------------------------------------------------------
>> 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