This is really about CPA lifecycle management, where for some
reason you want to be able to revoke (or disable) a particular CPA some time
after you (and your trading partner) have deployed it, but before it expires.
Or to reissue a CPA (perhaps without revoking the existing CPA, but
creating a new CPA that is allowed to co-exist with the existing CPA for
some time). That reason may be a change in the CPP, but CPAs can also be
created using other mechanisms than CPP intersection, such as e.g. template
instantiation. And perhaps someone wants to change the CPP (so
that it is no longer viewed as an input for new CPAs) but is happy to continue
running the existing CPAs with existing partners based on it for some
time. So CPAs have their own lifecycle issues, even though (when
using CPPs) the lifecycle of a CPP may impact the lifecycle of any derived
CPA. Encoding the creation history of a CPA (such as the
identifiers of the CPPs it was derived from, if using CPP intersection) is
useful as it helps you track which CPAs are impacted, but the key issue is not
really the CPA XML file format but the management process around
it.
In the customer environments that I have worked in, these
changes are handled as a regular ITIL change process, where the change can
be about any piece of information in the CPA, such as properties of the
partner (e.g. the URL of their server changes, or their Party Id code) or the
business process of services. CPA management then really is a kind of
configuration management, and regular ITIL configuration management tools can be
used to manage dependencies. Yes, in an ideal world changes in
capabilities or configurations could be uploaded to e-business registries and
distributed automatically across a community, but if you look at the
manual processes, approval workflows etc. the average medium to large size
organization still has to go through for much more basic changes in components
like firewalls or routers (technology that is ubiquitous and decades more
mature than any e-business registry technology), I'm not convinced the
world is ready for this. Making the changes to the actual CPAs can be
done in minutes using technology like the open source CPA toolkit http://www.osor.eu/projects/cpatoolkit.
Changes due to
PKI issues (e.g. certificate revocation or expiration, reissue) are obviously a
special case, the ebMS handler should disable CPAs as soon as certificates used
in them are revoked, and generate alerts about CPA that have certificates in
them that are about to expire. The better B2B gateway products in fact support
this.
Pim
From: Geir Ståle Eidissen [mailto:geir.eidissen@medilink.com] Sent: 26 January 2011 14:47 To: ebxml-dev@lists.ebxml.org Subject: [ebxml-dev] CPP reference in CPA Is there a way to identify which CPPs has been used to make
the CPA?` This question is based on a situation where a party issues
several CPPs (making corrections/additions) and want to check that a specific
CPA actually has used the latest CPP. A reference to cppid in the CPA would be nice, but I can’t
find it. Thankful for any suggestions on this. Best Regards Geir S. Eidissen |