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: Not using a CPA


The CPAId element itself is REQUIRED in the message header.  The question
is what it means in the absence of a CPA. In my mind, in the absense of a
CPA, the CPAId has to be a pointer into the configuration database that you
mention.  However without a CPA, the contents of that data base have to be
either a collection of defaults that everyone agrees to or a collection of
stuff entered manually into each system.



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 07/17/2001 11:30:59 PM

To:   "David Fischer" <david@drummondgroup.com>, Martin W
      Sachs/Watson/IBM@IBMUS, "Burdett David"
cc:   <ebxml-msg@lists.oasis-open.org>
Subject:  Re: Not using a CPA

The CPA contains one or more Endpoint elements which specify  the receiving
party's communication addresses. If there is no CPAId specified in  the
message header, how does the sending MSH determine the communication
endpoint for the recipient? Will the sending application have to specify
the  destination endpoint using the Service element? Or, do we have to
assume that  the sender's MSH has a configuration database that maps the
receiver's party ID  to an appropriate endpoint?


Arvola Chan (arvola@tibco.com)
TIBCO Software (on loan  to  RosettaNet)
+1-650-846-5046 (US-Pacific)

-----Original Message-----
From: David Fischer  <david@drummondgroup.com>
To:  Martin W Sachs <mwsachs@us.ibm.com>; Burdett, David  <
Cc:  Arvola Chan <arvola@tibco.com>; ebxml-msg@lists.oasis-open.org  <
Date:  Tuesday, July 17, 2001 7:26 PM
Subject: RE: Some Issues with the Reliable  Messaging Specification in
Version1.0 of ebMS

No, you really don't need a CPA.  While I can't image a  system without
some sort
of TP database, there can easily be defaults which  allow "bootstrap"
EDI does much the same thing with Open EDI --  Automatic Trading Partner
When you receive a message which does not  match any entry in the database,
automatically create one with the transport  values set to the incoming
values and anything which can be gleaned  from the MessageHeader with all
values set to defaults.  This is  the only way large scale communications
in a
world-wide economy is going to  work.  It is simply not feasible to create
database entries for  hundreds of thousands of potential customers (like
the case
of Sears or  L.L.Bean).  This will be a must for small quantity/value,
volume  organizations.

In large value propositions, you will probably want a more  structured
This is where CPA/CPP will  excel.


David Fischer
Drummond  Group.

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent:  Tuesday, July 17, 2001 8:27 AM
To: Burdett, David
Cc: Arvola Chan; ebxml-msg@lists.oasis-open.org
Subject:  RE: Some Issues with the Reliable Messaging Specification in
Vers ion 1.0 of  ebMS


But if the CPA is not used, the two parties  have to first get on the phone
to negotiate what they have to agree on to be  able to send that message
without a CPA, and then they both have put that  information into their
systems and get it consistent and correct.   There's no free lunch. If the
negotiable information is simple, the CPA will  also be simple.  In some
cases a third party may be able to dictate all  of the variables. The RNIF
seems to be one such case and I assume that  CommerceOne is another.
Relying on such third parties may only serve to  divide the world into
islands that can't easily interoperate.

I have  been discussing this with someone who is trying to implement a
message  service to work either way. That's not easy. In order for the
message service  spec to cover both cases, some of its statements are so
broad or vague that  they don't give sufficient guidance to the
The CPPA team has an  open work item to write an appendix for its spec
showing how the elements in  the message header are to be used with the
However, that information  really should be in the message service spec.

Yes, the spec needs to be  clarified.  Clarification is needed not just to
make it clear that the  CPA is optional.  All of the ambiguities resulting
from the CPA needing  to be optional have to be located and clarified in
form "this is what you  do if you have a CPA and this is what you do if you
don't have a  CPA."



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 07/17/2001 01:24:00

To:   Arvola Chan <arvola@tibco.com>, ebxml-msg@lists.oasis-open.org
Subject:   RE: Some Issues with the Reliable Messaging Specification in
      ion 1.0 of  ebMS


You  have spotted one of the  inconsistencies that, in my opinion, needs to
be fixed.  It arose  because there were two different views on the
relationship between the   CPA spec and the ebMS spec. This really boiled
down to whether the CPA  was  always required or optional. I will say now
that I was always  firmly in the  latter camp and think that the CPA should
be optional.  The main reason for this  was that if the CPA is required,
then you  cannot just send a message to someone,  you have to negotiate the
CPA  first and how you do this has not been  specified.

You  are  also right that there are issues around using the reliable
messaging  spec  over multiple hops which need to be resolved.

However the spec  does need to be clarified in my  opinion to make it clear
the the CPA is  optional. Removal of this inconistency  (and a few others)
is one of the  things that I will suggest at the ebMS meeting  tomorrow

Thanks  for your  comments.

PS  Most specifications seem to go through some  type of revision after
are  published ... ;)
-----Original  Message-----
From: Arvola Chan  [mailto:arvola@tibco.com]
Sent: Sunday,  July 15, 2001 10:43  AM
To: ebxml-msg@lists.oasis-open.org
Subject:  Some Issues  with the Reliable Messaging Specification in Version
1.0  of  ebMS

Section 10.2 in the ebMS spec describes the   reliable messaging
deliverySemantics, mshTimeAccuracy,  TimeToLive, reliableMessagingMethod,
ackRequested, retries,  retryInterval,  persistDuration. Only
deliverySemantics,   TimeToLive, reliableMessagingMethod, ackRequested can
be found in Appendix A  (ebXML SOAP Extension Elements  Schema); retries,
retryInterval,  and  persistDuration can only be found in Appendix D  of
ebCPP  spec.

I find the statement on line 1695 "This parameter information can  be
specified in the CPA or  in the MessageHeader (section 8.4.2)."   imprecise
in the following sense:

   mshTimeAccuracy is  neither in the MessageHeader  nor in the CPA.
   TimeToLive is  not mentioned anywhere in the CPA.  It is not clear how
   the  sending MSH should pick a value for this  parameter.
   The  sub-sections describing retries,  retryInterval, and
   do not clearly indicate that these   parameters are to be obtained from
   the CPA. Furthermore, their  spellings do  not match those in the CPA
   (case difference).  It will be helpful to specify  how elements in the
    MessageHeader can be used to look up these values from  the CPA.  The
   CPAId alone is not sufficient. The Service and Action  elements  will
   also have to be used to locate the relevant  DocExchange, ebXMLBinding,
   and ReliableMessaging elements from  the CPA.

It is not clear if the current Reliable Messaging   specification works
multiple hops. Line 1774 prescribes that a   TraceHeader be created in
accordance with Section 8.5.2. The latter  section  however does not say
anything about how to determine the next  intermediary, in  those cases
where one or more intermediaries are to be  involved. The  descriptions on
lines 1825 and 1829 on how to populate  the From and To element  in the
Acknowledgement Message also do not  clearly explain the circumstances
under which sub-elements under the last  TraceHeader in the incoming
are to be used.

I also find the  following issues with  Section 10.3.2 on Receiving

   Line 1783 uses the URI
    This is not consistent with the URI specified on line 1823:
   Steps 2.d)i) on line 1800 and  2.d)ii) on line  1802 are confusing. The
   phrase "and resend  it" on line 1800 should be struck  out. Otherwise,
   the  message would be resent twice.
   Step 2.c) omits the crucial  action of passing on  the message which has
   been found not  to be a duplicate to the  application.
   Step 2.d)iii) is  incomplete. The action to be  taken when syncReply is
   set  to True and the CPA indicates no application  response is  included
   is left unspecified. I believe in this case an   Acknowledgement Message
   should be generated and returned   synchronously.

Under Section 10.3.5 Duplicate Message Handling,  I  find the description
an "identical message" puzzling. Why is it   possible for a duplicate
"identical" message to have an additional   TraceHeader? Is the sending MSH
required to append another TraceHeader when  it  resends a message because
an Acknowledgement Message has not been  received in  time? Or is it
required to update the Timestamp in the  TraceHeader  to reflect the time


Arvola Chan (arvola@tibco.com)
TIBCO Software (on loan  to  RosettaNet)
+1-650-846-5046  (US-Pacific)

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

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

Powered by eList eXpress LLC