[
Lists Home |
Date Index |
Thread Index
]
Hi Walter, Tony, Tom,
Thank you for your outstanding inputs! Tony and Tom have brought
forward some excellent examples of concrete problems that must be
addressed. Walter has brought the broad, internetwork perspective to
the issue.
I'd like to take a stab at tying it all together - frame it within the
internetwork perspective and yet address the concrete, real problems
that Tony and Tom raise.
Walter spoke of the importance of decoupling the sender of the data from
the recipients (clients). In the internetwork world the sender simply
publishes data without being bound by who the client might be and how
the data might be used.
This perspective has given me additional insights into the nature of
good interchange data:
Good interchange data is data that is not influenced by
user's expectations or user processing.
Sorry, this is rather vague. Let's see if examples will help.
I will take two examples - the distance vs position example and a
financial example (although the later is way out of my field and I am
sure that my example is totally bogus)
Example 1: In this example the "resource" is an aircraft. I will argue
that position data is more decoupled data than distance data. If the
"aircraft resource" publishes position data then there are a lot of
different things that clients can do with it. Further, position data is
highly reusable and would be an excellent component. In the
internetwork world it seems to make sense that an aircraft resource
should publish position data.
But a concrete problem remains: suppose that a Radar Control Tower is a
client of the aircraft resource. It receives position data from the
aircraft resource, calculates the distance, and due to differing
algorithms calculates a distance that is different from the distance
value that the aircraft resource has computed. This could be a costly
problem. If instead the aircraft resource has sent the distance data
then there would not be this problem.
Example 2: A financial institution sells a stock whose ticker code is
"xyz". On the internetwork an "xyz stock resource" is created. I think
that good interchange data for this resource would be the share price.
There are many things that clients could do with the share price -
compute trends, calculate the cost for "n" shares, plug it into an Excel
spreadsheet, etc.
Suppose that a client wishes to purchase 3 million shares of xyz stock.
The client does a GET on the xyz stock resource and learns that the
current share price is $3.156/share. The client gets together the
$3.156 million and then sends it to the xyz stock resource. However, by
the time that it does this, the stock price has jumped to $3.200/share.
This is a big difference. If instead, the xyz resource had just sent to
the client the total cost ($3.156 million) then this problem would not
have happened. (Sorry, this is a really poor example. Can someone help
create a more realistic example?)
Summary
The internetwork perspective yields decoupled, multi-purpose, high value
data for interchange. This high value data is highly reusable and lends
itself to component-based designs and to increased interoperability.
This is certainly where we want to head.
However, at times there seems to be a need to interchange data that is
customized to a specific client. The danger is that every client wants
customized data, resulting in decreased interoperability.
Solution?
Perhaps the solution is to differentiate between "internal interchange
data" and "external interchange data". The internal interchange data is
for a (hopefully small) circle of clients that require custom data. The
external interchange data is the decoupled, highly reusable data for the
rest of the world. Over time the clients in the internal circle should
be pushed out to join the rest of the external clients.
What are your thoughts on this? /Roger
|
