RE: [uddi-spec] 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]
Sent: Thursday, 4 March 2004 4:33 PM
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Minutes of yesterday's telephone conference call

Attached please find the minutes of yesterday's meeting.

Tony Rogers

co-chair UDDI TC

tony.rogers@ca.com

uddi-spec message