Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
