OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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.


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