OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [uddi-spec] V4 contacts requirements


Title: 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]