Please
remove me from this list as I have no idea of what it is.
+1 on Dale and Pim's responses.
An ebXML RegRep may be used to manage the end-to-end lifecycle
of CPPs and CPA from initial creation, usage, versioning,
deprecation and removal. The life cycle stages are
configurable. Interested parties may be notified of Changes to
CPPs and CPAs if the change matches their interest. Fine
grained role / attribute- based access control and
authorization is provided using XACML access control policies.
CPPs and CPAs may be discovered using flexible and
customizable parameterized queries via REST or SOAP interface.
Finally CPPs and CPAs may be linked to CPPs and CPAs in
partner' ebXML RegRep's using the federation and remote object
reference features.
What is currently lacking but can be done relatively quickly
is a spec "ebXML RegRep Profile for CPP/A" that codifies the
following narrow requirements:
-
What new parameterized queries need to be defined to search
for a CPP or CPA. Note existing canonical queries would do
fine in 70% of the use cases
-
What data from CPP or CPA needs to be cataloged (if any)
into ebRIM metadata to support CPP/A discovery queries
Developing such as spec is not likely to be
complex. If any one is interested in writing it then please
let me know and I will be glad to help throughout the process.
Again I want to emphasize that the above spec is not a
requirement to use an ebXML RegRep for managing CPP/A.
On 01/26/2011 09:42 PM, Moberg Dale wrote:
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.
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
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com