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: "Rogers, Tony" <Tony.Rogers@ca.com>
- To: "Paul Denning" <pauld@mitre.org>,<uddi-spec@lists.oasis-open.org>
- Date: Wed, 2 Feb 2005 10:38:48 +1100
We did discuss this objection.
We assumed that you intended federation to mean affiliation
in the language of the spec.
What you are asking for, in language we saw, is already
implicit in the specification. If you wish to have an affiliated registry, then
yes, you'll most likely be using the Subscription API, and therefore you'll need
to use a server implementation which supports that API. But that is not really
something that the specification should mandate.
We also felt that this was too late in the standards
process - had this been raised during the public review period, or earlier, we'd
have been more amenable to making some change. We'd be happy to look at this for
the next version. Even better, we would be keen to see a contribution in the
form of a Technical Note or Case Study that describes how subscription can be
used in implementing affiliation / federation. This is not the only area of
UDDI where we will be working on documents that explain and expand
upon the specification for specific applications - we have two TNs being
released simultaneously with the standard, and we are working on a number of
others. Perhaps this would be the best path to follow?
Thank you for taking the time to explain in more
detail.
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]