Relevant to some of our recent
discussions on the development of oBIX.
tc
"There are seldom good
technological solutions to behavioral problems."
-- Ed Crowley.
Toby Considine
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
|
|
Email: Toby.Considine@fac.unc.edu
Phone: (919)962-9073
|
From: Paul Denning
[mailto:pauld@mitre.org]
Sent: Tuesday, February 01, 2005
6:25 PM
To: uddi-spec@lists.oasis-open.org
Cc: Lesch,Robert J; Scarano,James
G.
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".
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.