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


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]