[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uddi-spec] V4 contacts requirements
Hi all, I added a few scenarios to the intial Daniel's doco. I support his initiative with both hands up and would be very happy to see it in v.4 requirements. Please, find a minute to go thru the attachment. Cheers, Max ----- Original Message ----- From: "Daniel Feygin" <feygin@unitspace.com> To: <uddi-spec@lists.oasis-open.org> Sent: Saturday, January 10, 2004 7:28 AM 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 > ---------------------------------------------------------------------------- ---- > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.
uddi-spec-tc-req0xx-contacts-20040101.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]