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] Second objection - OASIS UDDI v3 Specification


I understand that the TC voted to approve the UDDI v3.0.2 spec [0].

However, for the record, let me further explain the rational for MITRE's "no" vote and try to address your questions.

During the review period I asked for the TC's rationale for making the Subscription API optional [1].
There was one reply [2].

In terms of addressing this concern during the earlier 3.0.0 and 3.0.1 review, we were not aware of the relative importance we now see for the Subscription API.
We have recently been looking at ways to "federate" multiple registries (not a single registry with multiple nodes).  We see the Subscription API as an important mechanism for some approaches to "federation".

You may recall that I asked the TC about a federated query [3] in June 2004.  That message described one form of federation that used the Inquiry API, not the Subscription API.  A different approach may use the Subscription API to effectively copy entries from a registry to a subscriber (or replicate, not to be confused with the Replication API used within a multi-node registry).  If the subscriber is another registry, there may be some logic or processing to add the entries from the notification to the subscriber's registry.  The subscription can be for a subset of entries, for example, using a categoryBag in the subscription.

The subscriber registry would probably be an "affiliate" as defined in section 1.5.5 of the UDDI v3.0.2 spec, which states "By choosing appropriate policies, multiple registries may form a group, known as an "affiliation", whose purpose is to permit controlled copying of core data structures among them."  In this case, the "controlled copying" could be done using the Subscription API.  I understand that the UDDI v3.0.2 spec does not describe the processing that an affiliate registry (subscriber) would need to affect the copy operation.

Let me introduce some example labels to make the discussion a little easier to follow.

Assume registry R1 is a UDDI registry for one organization or business.  Assume registry R2 is another UDDI registry.  R2 subscribes to R1; R1 notifies R2 in accordance with the subscription parameters.  R1 may not know that its subscriber (R2) is another UDDI registry; from the point of view of R1, its just a subscriber.

The subscriber registry R2 may not be an affiliate of R1.  This would imply that the keys assigned in R2 are not coordinated with those in R1.  R2 would assign a new key to an entry from R1 sent in the notification; however, R2 may put the R1 key inside an identifierBag (where the keyedReference/tModelKey is for a tModel associated with R1).  There are a bunch of details to work out, but that is beside the point.  The point is that R1 and R2 may be implemented using different vendors UDDI products, but the Subscription API provides a convenient mechanism for interoperable "controlled copying", whether or not R1 and R2 are strictly "affiliates".

Some of MITRE's customers are the US DoD and other government branches.  R1 may be a UDDI registry deployed by DISA.  R2 may be a UDDI registry deployed by the Air Force.  The Air Force may want a subset of the entries in the DISA registry copied into the Air Force registry.  We are exploring ways of using the Subscription API to move information to where it may be needed.

Note that MITRE is NOT arguing that the Subscription API "MUST" be implemented.  We would prefer the UDDI spec said that it SHOULD be implemented in cases where federation of the registry may be required.  Since the word "federation" does not appear in the v3.0.2 spec, perhaps a different term would be used.  Note that some people often use the term "federation" when discussing UDDI v3 features [4].

Perhaps "If a UDDI registry affiliates with other UDDI registries, then the registries SHOULD have at least one node that offers the Subscription API, otherwise the Subscription API is OPTIONAL".

Hope this cleared up our concerns.  Congratulations on it becoming an OASIS standard!  We are hoping that vendors of UDDI products choose to implement the OPTIONAL Subscription API.

[0]  http://lists.oasis-open.org/archives/uddi-spec/200502/msg00000.html
[1]  http://lists.oasis-open.org/archives/uddi-spec/200501/msg00003.html
[2]  http://lists.oasis-open.org/archives/uddi-spec/200501/msg00004.html
[3]  http://lists.oasis-open.org/archives/uddi-spec/200406/msg00014.html
[4]  http://www.mywebservices.org/index.php/article/articleview/894/1/24/

Paul

At 10:20 PM 2005-01-31, Rogers, Tony wrote:
Was there any attempt to raise this issue during the public review period?
 
For that matter, was there any attempt to raise this during the time that Version 3.0.0 and 3.0.1 were available?
 
Seems awfully late to be raising this.
 
Looks like we will have something to discuss on the call :-)
 
Tony
-----Original Message-----
From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Tue 01-Feb-05 14:07
To: uddi-spec@lists.oasis-open.org
Cc:
Subject: [uddi-spec] Second objection - OASIS UDDI v3 Specification

Please note the second objection
 
 
Luc Clément
Senior Program Manager, Systinet
Tel: +1.781.362.1330 / Cell: +1.978.793.2162 / www.systinet.com
 
 
http://www.oasis-open.org/apps/org/workgroup/voting/vote_details.php?id=675&voter_id=777
 
 
Ballot:  Approve UDDI v3.0.2 as an OASIS standard
Company:
Mitre Corporation

Vote:
No

Comment:
MITRE would like the TC to reconsider the current wording in the standard regarding Subscription APIs, a functionality that is being seriously considered by a MITRE customer. Specifically, the TC could consider the foll. wording change "If a UDDI registry must federate with other UDDI registries, then the registries SHOULD have at least one node that offers the Subscription API, otherwise the Subscription API is OPTIONAL".


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