----- Original Message -----
Sent: Wednesday, 14 January 2004
10:33
Subject: RE: [uddi-spec] V4 contacts
requirements
What implications on trustworthiness would this new v4
contacts requirements have?
If we can use this to improve trustworthiness, then its a +1
to make this a formal v4 requirement.
-----Original Message-----
From:
Daniel Feygin [mailto:feygin@unitspace.com]
Sent: Friday, January 09, 2004 10:33 AM
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] V4 contacts requirements
As I was reviewing RQ-016 Instance-Based Security (ACLs), I
came across a
scenario that I think merits a separate
requirements document and a separate
solution that is
independent of RQ-016. The scenario I'm referring to is
"update contacts independent of business and services".
Since V1, contacts in UDDI have been a human-targeted
descriptive part of
the businessEntity data
structure. They were never intended to enable
service discovery by a computerized service consumer and are very
vaguely
supportive of automated design-time
collaboration. Much has changed since
V1 though,
including the very meaning of what businessEntity is most
commonly thought to represent. More often than not,
businessEntity is a
generic service provider, which
can be anything from an ad-hoc team to an
organizational unit of any size. In addition, UDDI registry's
design-time
role is now more clear than ever and its
capabilities should support
development and management
tools. These new considerations indicate that
perhaps it is time to revisit the design choices made back when V1 was
being
developed, whereby contacts are stored within a
businessEntity and have no
means of being
published/queried/included in a query.
A more elaborate contacts feature in UDDI would
benefit:
- semantic matching efforts
- design-time developer communication
-
contacts-driven discovery
- effective re-use of
contacts
- UDDI-assisted communication between service
providers and consumers
If interested, please find attached my thoughts on contacts
requirements
laid out in the V4 requirements template
format.
I tend to think of a possible solution as incorporating at
least the
following components:
- independent (top-level) contact data structure
- functions that operate on contacts
- ability
to associate contacts (form relationships) with other UDDI data
structures including businessEntity
-
categorization of contact relationships (publisherAssertion-style
keyedReference) to represent contact roles
Daniel