[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Storing B2B contracts in uddi
Steve,
I view this as something that should be addressed in the
ebXML TN [1]. I probably do not understand the requirement enough, it
would help if you clarified why you think our current ebXML TN does not satisfy
it. You can already integrate your ebXML B2B artifacts, including CPA's,
CPP's, CPA templates and BPSS instances, into a UDDI-based interoperability
infrastructure. We can certainly expand the TN if there is interest in
doing so.
Are
you suggesting that there should be a normatively specified way for a
publisher to submit a contract to a registry for storage?
Generally contracts in UDDI are communicated via tModel
data structures, which are then associated with services and endpoints. A
tModel may refer to an external document or documents that contain human- or
machine-readable contract terms. Such tModel-based contracts may be
applied to multiple services and endpoints. A properly signed [2] service
definition cannot be reasonably repudiated by the publisher (other than perhaps
blaming the UDDI registry operator, e.g. for failure to process an
update request).
Regards,
Daniel
From: Steve Capell [mailto:steve.capell@redwahoo.com] Sent: Friday, March 05, 2004 8:49 AM To: 'Rogers, Tony'; uddi-spec@lists.oasis-open.org Subject: [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] 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]