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
I think it may if approach it from the right angle...
 
E.g. it doesn't matter what the name structure looks like for me to claim that i'm a MikkiMouse when i'm not
on the other hand, when i'm looking for Computer Associates in Syd and find a company called CA located in
Sydney - Artarmon
407 Pacific Highway
Artarmon NSW 2064
Tel: +61 2 9937 0500
Fax: +61 2 9937 0600
 
then it is more likely to be the right one.
 
The thing here is that a full and correct record about someone's name and address (+ some additional info e.g. reg no or SSN) adds a great deal to the correct identification of a business or individual entity.
 
Cheers,
Max
 
----- 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



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