Arvola
All
the approaches you suggest are possible for determining the end
points:
by
looking up the CPA
the
application specifying the endpoint directly (e.g. an HTTP or SMTP
URL)
by
lookup within the MSH, for example the application specifies the Trading
Partner (e.g. using a DUNS) the service and action.
I also
agree with Marty that various communities of users, e.g. RosettaNet, will
specify CPA information which can then be used by everyone in the community.
This works naturally with the third option - endpoint lookup. In fact, IMO, this
will be a frequently used option which is why using a CPA should not be
required.
As far
as islands of non-interoperability are concerned I don't think that, in practice
this will be huge issue especially if the ebXML Messaging group specifies
profiles for using ebXML which can then just be adopted.
David
-----Original Message-----
From: Arvola Chan
[mailto:]
Sent: Tuesday, July 17, 2001 8:31
PM
To: David Fischer; Martin W Sachs; Burdett, David
Cc:
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?
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:
