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: Some Issues with the Reliable Messaging Specification inVersion1.0 of ebMS


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

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.



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.

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

Powered by eList eXpress LLC