uddi-dev message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [uddi-dev] Questions on V3 specification.
- From: Nobuyuki Tomizawa <n-tomizawa@ap.jp.nec.com>
- To: uddi-dev@lists.oasis-open.org
- Date: Wed, 04 Dec 2002 15:22:30 +0900
Title: メッセージ
Joel-san and Luc-san:
At first, I appreciate your quick and detailed
responses.
as we
were writing the replication of the specification, we maintained an
informal policy of specify as little as we need to. much of the
processing of the replicationConfiguration element is wrapped into the the
actual implementation itself. as such, we intentionally did not specify
much of what you ask for below. we believed that this does not impact
interoperability within a registry.
I also
think that the spec does not impact the interoperability in usual replication
process with relatively simple topology like one described in the spec after,
once such topology has been build. But, how about the
case to add (and
delete) nodes to a topology? (Yes, I know the process
described in the spec, section 7.8/7.9, are with "MAY".
)
the handling of the
replicationConfiguration may very well be automated but that does not directly
imply that is needs to be specified.
I agree this. If multi-nodes-registry
consists of single implementation of nodes, whether the detailed process of
automation is specified or not MAY NOT BE problem. For example, a vendor can
implement replicationConfiguration management in fully or partially
automated way based on the specification.
But, how about the case when we have to
build multi-nodes-registry with multiple implementations from different vendors?
Building up multi-nodes-registry-with-deferent-vendors could be possible, but it
seems difficult in practice for me, because basic process (I think) like adding
node seems not to be specified exactly.
If this my observation is correct, I can
rephrase my question: "Interoperability of replication management (like adding
node) is out-of-scope?".
with no
commmunicationGraph specified, any node MAY communicate any message with any
other node. this does not imply that there is no control. there
are suggestions that have been included within the specification that describe
a use of the communicationGraph that "orders" the minimum set of messages that
we believed eliminated some potential areas where interoperability issues
might occur.
But, the spec does not say how each nodes communicate
each other when no communicationGraph specified, does it? If this is correct
(sorry if I overlook the description), there may be cliques in the registry and
this may break the assumption "all nodes in a registry have same
content".
The simplest solution is "each nodes must communicate
with *all* the other nodes.", but it looks bad idea that leads over
traffic...
when
setting up a multi-node registry, "communication" between node operators is
required. making simple decisions like the ones described in your
questions and luc's replies is a natural step in this
process.
You mean non-automated
processes like sending/receiving e-mail for humans by "communication" ? If
so, it makes sense to me.
modeling an "ack" as a change record made sense to us.
again, we believed that this would simplify the processing of
"changeRecords." if an "ack" is requested, it is required to propagate the
"ack" to the originator. there are many ways that this could
occur. if the communicationGraph is not constrained then the receiver
MAY send a "ack" directly back to the originator. or the "ack" could
make its way back to the originator via other means. we believed that it
made more sense to simply add this to the stream and process normally (that is
according to a directed and controlled communicationGraph). the other
end of the spectrum to this is to allow, plan, and test for communications
between any node at any time for any message.
Sorry, I could not
understand this point. My understandings are:
* ' "ack" as change record '
is OK.
* But if so, to assure "ack"
comes back to originating node we need some constraints on topology
like:
Topology
should be something like cyclic.
If some or all node has no
constraints on replication topology, I think the spec should say how each node
send and route ack to make acks to go back to the originating
node.
* Or, the spec may NOT
require that "ack" comes back. In this case, I fear that basic assumptions
and/or some algorithms (like one described in section 7.3.9.1)
breaks.
i hope
that these (historical) thoughts help you.
joel
munter
intel
corporation
Sometimes, historical
course and reason like you mention is not described in the spec. So it helped me
well.
Again, thank you very
much for your explanation.
-- Nobuyuki
Tomizawa
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC