[
Lists Home |
Date Index |
Thread Index
]
With all respect, gentlemen, I believe that this thread misses the salient
point: that we are comparing the scalability, interoperability, and efficiency
of REST vs. SOAP for *distributed processing*. IMHO, if both the delegating and
the invoked nodes or processes must know the full detail of either the
implementation of a shared process or of the precise data structures required as
input and returned as output by that process, then there is no point in
implementing that as a distributed process. Knowing the full detail of the
process implementation, the invoking node might as well create and execute that
process locally (or on the client-server model, which is not distributed
processing and which is effectively local) and economize on internetwork
bandwidth, not to mention uncertainly. But even if the invoking node were
required to know 'only' the exact input and output data structures of a process,
it might, in all but the most minuscule number of cases, more easily infer and
then implement the necessary transformation than ship that input and output data
around an internetwork.
Roger's conclusion that 'each machine'--presumably a distributed processing
node--'must have n customized programs to
process the n [possible input data structures]' misunderstands distributed
processing. A distributed processing node performs a particular function because
it is particularly expert at that function, perhaps even uniquely capable of it.
Of course, the internal local implementation of processing at that node is,
literally, hard-coded to expect a specific input data structure and to return a
particular output. What makes it a distributed processing node is that neither
of those structures is predicated on the expectations of any other node. The
autonomy of a distributed processing node is that its particular expertise alone
dictates the form of input which it expects, internally, as well as the output
which it produces as the direct expression of its expertise. With that autonomy
comes the obligation, when offering distributed processing services, to accept
varying input from invoking nodes which want to use those expert services
precisely because they do not understand, and find it comparatively unprofitable
to learn, how to implement those processes for themselves. In other words, there
is a semantic equivalence to what an invoking node submits and an invoked node
accepts as input, but not necessarily a syntactic uniformity. The invoker, for
example, wants to execute a complex order. For the same reason that it lacks the
expertise to process that order it lacks the specific understanding of how (and
why) the data submitted as the necessary input to that order must be structured.
That invoker therefore submits its own understanding of the data which it wants
processed, in a form which expresses that understanding. It is the job of the
distributed processing node to understand the semantic equivalence of this to
the input that it expects, and then to instantiate from what it is given, if it
can, the particular syntactic form of input which its processing requires.
In other words, in distributed processing the invoking and the invoked nodes are
not so tightly coupled as Roger's premise assumes over the particular syntactic
form of the data structure passed between them. In transaction processing under
the two-phase commit protocol, it is in fact the identical expectations of two
parties for a specific data structure which is the basis of the model. Because,
however, the first goal of distributed processing ('distributed' before
'processing', after all) is vast scalability, a single process must decouple
itself from the multiple, syntactically varying inputs on which it might be
expected to operate. Yet as the second goal is interoperability, that process
must be able to instantiate data to fill its own input needs from the
syntactically various submissions which it is offered. That instantiation is a
data transformation which the processing node may uniquely be capable of
performing, as only it may know the particular syntactic form of input which its
processing requires.
Therefore the suggestions which Roger makes (but which are common
misconceptions)--to create common data vocabularies or to create shared
ontologies of the data passed between nodes--miss the point of distributed
processing. Distributed processing as a concept escapes the n^2 order of
complexity by handling the shared-semantics-to-local-syntax transformation at
the input side of the processing node and by refusing to handle any
transformation of the local syntax at the output side. At the output side, a
process expresses its particular expertise in a local syntax specifically suited
to it, and cannot be expected to know who might be the interested parties to
downstream use of that output, nor in what form or for what purpose. Any party
making use of the output of a process becomes at that point a new process acting
upon it, with the responsibility to instantiate it in its own form for its own
purposes. Even the original invoking node must be expected to understand the
output of the process which it invoked, as expressed in the local syntax of that
process. If it cannot do so, the invoking node is effectively unable to make use
of the expertise of that process and has no business invoking it.
Respectfully,
Walter Perry
|
