Re: Some Issues with the Reliable Messaging Specification inVersion1.0 of ebMS

[Martin W Sachs <mwsachs@us.ibm.com>]

Gee, I was wondering if you had disappeared off the face of the earth :-)

Around here, the view is that the configuration information always ends up
in a database, whether its contents are derived from a CPA, GUI tool, or
faxes.

Another thing that has (unfortunately) not been addressed in ebXML is an
abstract upper interface to the Message Service spec. Such an interface
would resolve a lot of the ambiguities resulting from the CPA vs no CPA
dichotomy as well as perhaps some of the other things the Arvola Chan
brought up. Its on the list of possible CPPA work items, hidden under the
title "Middleware Interoperability".  Of course this is joint work among
CPPA, MSG, and perhaps BP.

Another item on the proposed CPPA work list is the missing appendix on how
CPA constructs appear in the message header. The recent "no CPA"
discussions along with a colleague's difficulty in parsing the Message
Service spec because of the "no CPA" ambiguities have made it clear that
that appendix has to be much more than a compendium of elements in the
message header.  There will have to be a lot of normative discussion that
pins down the meaning of things in the Message Service spec for the case
where there is a CPA.  This one also has to be joint with the MSG team.

Tomorrow I will be posting the latest version of the CPPA new work and
loose ends list that I will be discussing at next week's F2F. A bunch of
additional loose ends have surfaced along with further ideas for
enhancement items.

Have you contacted Dale about attending next week's CPPA F2F remotely?
Dale is arranging some kind of web-based conferencing setup for those who
can't attend in person.  At least 5 people will be attending remotely.

We are also going to discuss the possibility of coordinating with the MSG
team so that future F2F meetings of the two teams are always  at the same
time and place.  The discussions of the past few days have underlined the
need for coordination between the two teams.

I hope that you will be able to hook in next week and that coordination of
future meetings will allow your presence in person.

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
*************************************************************************************



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 07/18/2001
12:12:34 PM

Please respond to ebxml-msg@lists.oasis-open.org

Sent by:  Chris.Ferris@Sun.COM


To:   ebxml-msg@lists.oasis-open.org
cc:
Subject:  Re: Some Issues with the Reliable Messaging Specification in
      Version1.0 of ebMS



David,

While I certainly agree that it "... isn't feasibile to create *manual*
database entries for ...", no one ever said that this was a manual
process;-)

Also, when you say "No, you really don't need a CPA." and follow that
with a statement that suggests that you "can't imagine a system without
some sort of TP database", you are in fact arguing against yourself.

What I think is a clearer position would be to state that there is no
requirement that there be a physical CPA *document* conforming to
the CPP/CPA specification for the ebXML MSH to function.

However, as you correctly cite, there needs to be something. What the
ebXML MS spec calls for is that the information that is referenced as
defined
in the CPA as defined by the CPP/CPA specification MUST be available
to the runtime. Whether that is by virtue of defaults that the system
knows of through some other means or whether these values are derived
from some manner of TP database or whether they are read directly
from a document that conforms to the CPP/CPA specification is
implementation
specific detail about which the specification should make no claims
whatsoever, IMHO.

The issue of "bootstrap" situations has (unfortunately) not been
addressed within ebXML formally in terms of a specification or whitepaper
that defines a normative approach to dynamic negotiation of a CPA to
enable the exchange of messages via ebXML MS. This is (I believe) where
there is
much confusion and disagreement. It is certainly a topic that should
be undertaken jointly by the MS and CPP/CPA TCs as part of their
work going forward.

Cheers,

Chris

David Fischer wrote:
>
> 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.
>

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org