[
Lists Home |
Date Index |
Thread Index
]
"Anthony B. Coates" wrote:
> This is somewhat orthogonal to the original discussion, though. Even if a node is publishing without regard for what other nodes may do, that doesn't mean it should only publish fundamental values, and not derived values. Indeed, if your node is to assume the minimum about all other nodes, it should publish as much derived information as seems practicable, since it is unknown whether other nodes are in a position to calculate the derived values.
No, sorry. This is still another manifestation of the same mindset that I am hoping to supplant. "Publishing without regard for what other nodes may do" means not knowing, nor caring, what is fundamental vs. derived from some other node's perspective, and therefore not seeking to publish the one rather than the other. From the publishing node's point of view, what is fundamental is the data on which that node depends for performing its own particular processing, but what exactly an instance of that data might be
is often (particularly in the financial world!) a proprietary trade secret of the processor or the confidential information of that processor's client and must not be divulged. The design that I advocate recognizes that crucial commercial fact. Other designs--either for processes or for the nature of data interchanged between them--focus on the form of input. Conversely, my design principles recognize that for a specialized processing node to publish its precise input requirements (let alone to contract, as in
any RPC scenario, to perform some process whenever those input requirements are met) may divulge the very trade secrets which are the basis of that node's business. By contrast, the *output* of that node's processing must be divulged because it is the product for which that node is useful, and is therefore employed. Or, in the terms of this discussion, what is derived is apparent to the node which derives it, because that is the specific product of that node's own particular processing. To a different node,
performing different processing on different assumptions, a given product might not result from (nor imply) the same inputs, and the distinctions of fundamental and derived at the first node would be meaningless to the second.
> Also, I feel we need to subdivide the cases. Some practices work well for "informational messages", where there is a more-or-less 1-directional communication of information. However, they may be inappropriate appropriate for "transactional messages", where the communication is bi-directional, and where it is important that both ends agree on all values, be they fundamental or derived. These are two very different cases, and no one solution suits both.
Again, this is a distinction appropriate to traditional processing in homogenous enterprise networks. It is a meaningless distinction to the autonomous nodes of an internetwork, where every node may be addressed, and with sufficient authorization someone may GET its output, but only the node itself knows its input requirements and the nature of its local processing. Published information is published information; how it was created is immaterial to the usefulness, or not, of that data. On an internetwork, and
adhering to REST principles, a processing node acts upon published data, either PUT or POSTed to it, or which it GETs. That node performs its own processing and then publishes the result. Properly designed, that node publishes results in the form best suited to expressing the product of its own particular processing. In your terms, this is a 1-directional operation. If an interested party to the output of a node's processing happens to be a node from which data had been drawn for that process, then a sort of
back-and-forth communication is achieved, but I hardly think it is what you distinguish as bi-directional communication. Likewise, while in the traditional homogenous network processing depends on both ends agreeing on all values (two processes using the same data in the same structure is the basis of two-phase commit), on the internetwork that homogeneity is only accidentally attainable. In the internetwork topology, each node is know by its address and by what it publishes. If what it publishes it useful to
another node, then with proper authorization that node may gain access to that data and use it. What is uses that data for, or how, or understood in what form are not subject to any agreement, nor could they be given the nature of the internetwork topology.
Respectfully,
Walter Perry
|
