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?

 

Thanks,

-Arvola

 

Arvola Chan ()
TIBCO Software (on loan 
to  RosettaNet)
+1-650-846-5046 (US-Pacific)

-----Original Message-----
From: David Fischer 
<>
To: 
Martin W Sachs <>; Burdett, David 
<>
Cc: 
Arvola Chan <>;  
<>
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" situations.
EDI does much the same thing with Open EDI -- 
Automatic Trading Partner Entry.
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 message
values and anything which can be gleaned 
from the MessageHeader with all other
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 manual
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, large
volume 
organizations.

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

Regards,

David Fischer
Drummond 
Group.

-----Original Message-----
From: Martin W Sachs [mailto:]
Sent: 
Tuesday, July 17, 2001 8:27 AM
To: Burdett, David
Cc: Arvola Chan; 
Subject: 
RE: Some Issues with the Reliable Messaging Specification in
Vers ion 1.0 of 
ebMS

David,

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 implementer.
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 CPA.
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 the
form "this is what you 
do if you have a CPA and this is what you do if you
don't have a 
CPA."

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

To:   Arvola Chan <>, 
cc:
Subject:  
RE: Some Issues with the Reliable Messaging Specification in 
Vers
      ion 1.0 of 
ebMS

Arvola

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 
and
Wednesday.

Thanks  for your 
comments.

David
PS  Most specifications seem to go through some 
type of revision after they
are  published ... ;)
-----Original 
Message-----
From: Arvola Chan  [mailto:]
Sent: Sunday, 
July 15, 2001 10:43  AM
To: 
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 parameters:
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 the
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 
persistDuration
   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 over
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 message
are to be used.

I also find the 
following issues with  Section 10.3.2 on Receiving 
Message
Behavior:

   Line 1783 uses the URI
   
http://www.ebxml.org/namespaces/messageService/MessageAcknowledgement.
   
This is not consistent with the URI specified on line 1823:
   
uri:www.ebxml.org/messageService.
   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 of
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 
of
retransmission?

Thanks,
-Arvola

Arvola Chan ()
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: 

------------------------------------------------------------------
To 
unsubscribe from this elist send a message with the single word
"unsubscribe" 
in the body to: