[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Storing B2B contracts in uddi
Hello all, Further to the teleconference on Tuesday,
I would like to start a discussion about how best to store contracts in
uddi. First I should explain what I mean by contract. Specifically I
am talking about a technical bilateral agreement between two organizations to
perform a collaborative business process according to a predefined standard
where each organization takes a complementary role in the process (eg buyer
& seller). At present (for lack of an equivalent open & semantically
well defined Web Service standard) we are using ebXML CPA for this purpose.
However I can see WS-Policy evolving to fulfill the same role in the WS domain
once a set of WS-Policy assertions are defined. The business scenario: 1
The
Australian national uddi registry will contain standard collaborative process
definitions. It will provide a simplified interface for organizations to
publish services which represent compliance with one role in a collaborative
process – corresponding businessService & bindingTemplates will be
generated automatically. 2
A
contract represents the mutually agreed overlap between two complementary profiles.
At this time, we don’t think that the typical end-point will have
software capable of computing technical contracts (ie CPAs) so we have added
that as a hosted service on the registry. 3
A
contract must only be visible to the specific parties involved in the
collaborative process – or else we are effectively publishing an organization’s
customer list. 4
A
contract should not be changeable by one side without agreement of the other. 5
The
contract is a machine readable document that is used to automate end point
middleware configuration. It needs to be accessible to the middleware via
a standard interface. 6
Contracts
need to be persisted at the registry so that they can be accessed
asynchronously and also support disaster recovery and non-repudiation. So how to store them? Some options: 1
As
publisher assertions. Advantage is that this is the only data structure
in uddi which is designed to support the concept that both sides need to
agree. In principle we could use publisher assertions where the uddi-org:relationships
keyed reference name is “contract” and value is the UUID of the
tModel that points to the contract (CPA). Problem is that I can see no
easy way to associate an access policy with an assertion so if an organization has
read access to a businessEntity then it also has read access to the associated
assertions (and we break rule #3 above). 2
As binding
templates under the corresponding businessService. This might seem the
most obvious approach. Advantage is that it is more like what uddi would
expect us to do. Also I can associate a policy with a binding template so
that only the parties in the contract have visibility. Downside is that either
party could arbitrarily delete the binding template and then the contract
meta-data is lost. Ie we’d have a floating contract tModel with no
idea who owns it until we download and examine the associate object
contents. Another problem is that a CPA typically involves multiple
services & bindings so it might govern more than one businessService.
It really operates at the businessEntity level rather than the businesService
level. 3
As an independent
tModel owned & published by the node operator and classified with two “owningBusiness”
entries in the category bag that point to the two businesses that have agreed
the contract. We then need to provide an extra service (both UI and API)
for the negotiation and publishing of contracts. However we can attach
policies so that the businessEntities concerned have read & get (but not
write / delete) privileges. For the moment, we have opted for option 3
because this whole CPA computation and negoatiation is already provided as an
additional registry service and publish rights can be obscured behind our
additional application layer. Yet we still maintain a standard uddi query
interface for end points to read/get their CPAs. Questions for the TC: 1
Is this
something that is outside the scope or charter of uddi? Before answering
that question I would ask whether uddi is supposed to support B2B
interoperability – and the associated non-repudiation requirements.
If yes then I’d suggest that the ability to handle contracts is
necessary, whether they are manifest themselves as ebXML CPA or WS-Policy or
some other syntax. 2
If in
scope then is this something for the ebXML TN or is it really a requirement for
v4? 3
Does
anyone have any completely different suggestions about how to handle this
issue? A point of clarification about our use of ebXML….
We are most assuredly not trying to push the ebXML cart & horse down the WS
community path. No hidden agendas here. It is really just that the
focus of our project is specifically B2B automation and ebXML was developed for
that purpose. I believe that most if not all of the ebXML technical protocols
(MS, BPSS, CPP, CPA, RegRep) will eventually be replaced by WS
equivalents. It’s just that for now, the WS equivalents are either
too immature / incomplete or their IP is not yet in the public domain
(government projects have to be sensitive of these things..). Comments welcome. I’ll
get around to starting the e-mail thread on the repository / object lifecycle
management requirement next week…. If anyone wants to understand more about
our use of uddi as a B2B registry then please feel free to take a look at http://www.bizdex.com.au/download.html
- particularly the BizDex technical overview & BizDex registry whitepapers
at the bottom of the downloads page. Regards, Steve Capell Red Wahoo Pty Ltd +61 410 437854 From: Rogers, Tony
[mailto:Tony.Rogers@ca.com] Attached please find the minutes of yesterday's meeting. Tony Rogers co-chair UDDI TC |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]