Pim addresses a larger context of your question and is correct to notice that lifecycle management of profiles, templates and agreements is not resolved by the specifics of the CPPA xsd and the instance files. Registries, content management systems and the like all could be useful tools to help out. The spec leaves it open as to how you build out lifecycle and community management. From: Pim van der Eijk [mailto:lists@sonnenglanz.net] 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] 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 |