The other reason for using the CPA in its XML form is that it permits using
common deployment tools built for XML CPAs rather than special purpose
tools for your own agreement formats.
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
*************************************************************************************
Dale Moberg <> on 12/04/2001 03:58:38 PM
To: "Anarkat, Dipan" <>,
cc:
Subject: RE: [ebxml-dev] ebXML specifications interdendancies
Some comments in line.
-----Original Message-----
From: Anarkat, Dipan [mailto:]
Sent: Tuesday, December 04, 2001 12:17 PM
To:
Subject: [ebxml-dev] ebXML specifications interdendancies
" Hi,
" I am trying to assess the functional interdependancies b/w the
diferent systems in the ebXML stack from an implementation standpoint,
used in an e-business framework.
" As we know, the ebCPPA spec does specify how a CPA is negotiated
between 2 trading partners.
DaleMoberg> Negotiation is currently being specified in the OASIS
ebxml-cppa TC. There was no
normative definition at the CPPA 1.0 level. There was a lot of information
about how to use CPA templates
or even to compose CPPs to arrive at CPAs, but you were on your own in
exchanging these documents.
" I also understood from a couple of vendors that the CPA instance XML has
to be loaded into the internal database (any form) of the MSH. It really
doesnt matter how the CPA is negotiated or for that matter even if it is
in XML form.
DaleMoberg> Typically for MSHes that support CPAs, importing a CPA and
using it to populate the MSH's
configuration "database" would be an operation that would be done,
obviously. Just how much of the information is
actually used might vary. Minimally you will need to get the URLs of the
other side. You might pull out
other information.The software might then need to ask a user for some
other information. You could pull
out certificates, trust anchors, signature formats and conventions, and a
whole lot of stuff.
" All that is required is a conclusion representing the CPA that can be
in any format, as long as it can be loaded into the internal database of
the MSH as provided by the vendor.
DaleMoberg> If you are talking about what a MSH could get away with, it
need not
serialize any information it uses in configuration.
That is, you could use property sheets or wizards or whatever to
let a user do the configuration. Most implementations will
have this capability unless they are telepathic. What importing a
CPA allows is drastically reducing what the user has
to configure, what choices on security (etc) are forced on users,
how to get certificates loaded, and so on. The CPA and CPP are
standardized
XML schemas used to define ways to exchange information expressed
in XML that is used for configuration. They also have signatures so
that you trust the information, and hooks to other potentially useful
information.
" This means that an ebMS compliant MSH has also to be compliant with
the ebCPPA. "
DaleMoberg> It means that an ebMS compliant MSH has to be configurable as
a ebMS MSH.
Compliance with ebCPPA means that XML inputs or outputs conform to the
schemas that
have been defined. Since the ebMS is not required to serialize its
configuration information
in any format, it does not have to conform to the ebCPPA compliance
clause. I think you
are trying to find some dependency here, when both groups have been
reasonably careful
to explain how to use specifications together and separately. It would be
far more useful
to consider what you gain and lose by not using certain ebXML modules
rather than trying
to see how little you can get away with. You will have to configure the
software somehow.
You can invest in automating the process for a community or you can let
them struggle
and set it up themselves (with consultants).
" Also since the ebCPP and ebCPA instances identify the Business Processes
in an ebBPSS instance, it means that the ebMS compliant MSH will also have
to be compliant with the ebBPSS if it has perform the intended function of
being able to validate and process ebMS TR&P messages . "
DaleMoberg> No. No real use needs to be made of the information about
Business Processes, even if there
is a pointer to it. Otherwise, a dummy BPSS can be set up in 15 minutes or
so if you really want to make
certain the pointer resolved.I will even send you one.
" This means that the ebMS TR&P cannot be used independantly for TR&P
and forces you to use ebCPPA and ebBPSS. "
DaleMoberg> No. If a web page has links on it, does that mean you cannot
view the page without clicking on the links?
You are really reaching here to find a dependency, when you should just be
asking yourself: what is the value of
using this? Could there be some ROI if we used this? And so on. What is
the point ot these questions really?
"As such, even though an agreement may not be required between trading
partners , we still need a bare bones 'void agreement' .
Is my understanding right, or am I missing a point here !? "
DaleMoberg> No and Yes.
Dipan Anarkat
EC Systems Analyst
Uniform Code Council, Inc.
Tel: (609)-620-4509
http://www.uc-council.org/
----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>
