[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] Re: wrt CPP version 2.0
I believe that the text quoted below already contains
Marty's points indicated in his message. I hope
this documentation is sufficient. It is succinct
and IMO documents the semantics of these constructs.
However, the ebXML CPA TC needs to
consider what TC response
should be made to this
comment. I will put this on the
September agenda.
Dale
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Thursday, August 29, 2002 7:13 AM
To: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-cppa] Re: wrt CPP version 2.0
I believe this is our first public review comment!
Someone, please review the questions and my answers to see if we need
more
explanatory text in the specification.
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
************************************************************************
*************
----- Forwarded by Martin W Sachs/Watson/IBM on 08/29/2002 10:11 AM
-----
Martin W Sachs
To: Radhika Menon
<radikamenon@yahoo.co.in>
08/29/2002 10:10 cc:
ebxml-cppa@lists.oasis-open.org
AM From: Martin W
Sachs/Watson/IBM@IBMUS
Subject: Re: wrt CPP
version 2.0(Document link: Martin W. Sachs)
Radika,
My responses to your questions are below.
Regards,
Marty Sachs
************************************************************************
*************
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
************************************************************************
*************
Radhika Menon
<radikamenon@yaho To:
ebxml-cppa-comment@lists.oasis-open.org
o.co.in> cc:
Subject: wrt CPP version
2.0
08/29/2002 05:33
AM
Hi,
As am involved in providing implementation for CPP
version 2.0 specs, I would like to get clarification
on the following points emerged after going through
the CPP 2.0 specification.
1. what is the purpose of CanSend and CanReceive
elements in CPP.
MWS: CanSend and CanReceive identify the delivery
channel to be used for sending and receiving the
messages for each action. In general, an action
maps to a particular requesting or responding
business activity in the BPSS instance.
8.4.10 CanSend element
The CanSend element identifies an action message that a Party is capable
of sending. It has
three sub-elements: ThisPartyActionBinding, OtherPartyActionBinding, and
CanReceive. The
ThisPartyActionBinding element is REQUIRED for both CPPs and CPAs. It
identifies the
DeliveryChannel and the Packaging the Party described by the
encompassing PartyInfo
element will use for sending the action invocation message in question.
The
OtherPartyActionBinding element is only used in the case of CPAs. Within
a CPA and under the
same CanSend element, the DeliveryChannels and Packaging used/expected
by the two Parties
MUST be compatible. The CanReceive element can occur zero or more times.
When present, it
indicates that one or more synchronous response actions are expected.
This is illustrated in the CPP and CPA examples in the appendices.
8.4.11 CanReceive element
The CanReceive element identifies an action invocation message that a
Party is capable of
receiving. It has three sub-elements: ThisPartyActionBinding,
OtherPartyActionBinding, and
CanSend. The ThisPartyActionBinding element is REQUIRED for both CPPs
and CPAs. It
identifies the DeliveryChannel the Party described by the encompassing
PartyInfo element will
use for receiving the action message in question and the Packaging it is
expecting. The
OtherPartyActionBinding element is only used in the case of CPAs. Within
a CPA and under
the same CanReceive element, the DeliveryChannels and Packaging
used/expected by the two
parties MUST be compatible. The CanSend element can occur zero or more
times. When
present, it indicates that one or more synchronous response actions are
expected.
2. what is the significance of having the (0 or more
)CanReceive element as a child element of CanSend
element.
MWS: CanReceive is included as a child element of CanSend
to support synchronous responses. CanReceive provides
the necessary delivery channel information for receiving
the response message when this party is the sender
of the message in the requesting business activity..
See passages above, such as:
"When present, it indicates that one or more
synchronous response actions are expected.
This is illustrated in the CPP and CPA examples in the appendices."
3. what is the significance of having the (0 or more
)CanSend element as a child element of CanReceive
element.
MWS: CanSend is a child of CanReceive for synchronous
messages. This is the case where this party is
sending the response message in the responding
business activity.
Again see the passage under the CanSend documentation:
"Within a CPA and under the same CanReceive element,
the DeliveryChannels and Packaging used/expected by the two
parties MUST be compatible. The CanSend element can occur zero or more
times. When
present, it indicates that one or more synchronous response actions are
expected.
4. upto how many levels the CanSend or CanReceive
Elements can be recurring within itself.
MWS: For practical purposes, there is only one level
since a requesting or responding business activity
is only a single request and response pair. The
choreography is defined by the BPSS instance document.
The schema may not prohibit multiple levels but I
don't think there is a use case for more than one
level.
DWM:
Business protocols with extended chains of responses
are not yet common, and may not be common for quite
a while. [If CPA negotiation were undertaken with synchronous
communications,the open ended state of counter
proposals permits indefinite responses,
and then there would be a use case. I am not certain
whether indicating indefinite nesting is something
that we need to support. We now could only indicate some fixed
number of levels of inclusion, and some people are already
claiming that the complexity is too high.]
5. I do understand the purpose of ReliableMessaging
element and its child elements in the context of
ebXMLSenderBinding Element. I really don't understand
why is it required in case of ebXMLReceiverBinding
Element.
MWS: Each delivery channel has to contain information
about both parties in order to ensure that their
messaging characteristics are compatible. That's why
both ebXMLSenderBinding and ebXMLReceiverBinding are
needed. One simply example is that both parties
have certificates and the CPA has to identify whose
certificate is used in each security function. For
example, a sending Party has to encrypt using the
receiving Party's certificate so that the receiving
party can decrypt.
I would be glad if anyone of you can clear all my
doubts and provide with the necessary information.
Thanks in Advance.
with best regards,
radika.
________________________________________________________________________
Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!!
visit http://in.autos.yahoo.com
----------------------------------------------------------------
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