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
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
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: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
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" <david.burdett@commerceone.com>
on 07/17/2001 01:24:00 AM
To: Arvola Chan <arvola@tibco.com>, ebxml-msg@lists.oasis-open.org 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: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 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 (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
|