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
- From: Paul Denning <pauld@mitre.org>
- To: uddi-spec@lists.oasis-open.org
- Date: Tue, 01 Feb 2005 18:25:13 -0500
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]