[
Lists Home |
Date Index |
Thread Index
]
John Cowan wrote:
> I want to know *how* to submit data to your node. If you publish your requirements,
> then I know. If you don't, I am in the dark, and may well be talking Georgian when
> you understand nothing but Armenian.
In the first ones of these that I designed, there was a push/pull lookup table at each
site. A site is composed of a number of autonomous processing nodes, each of which
interacts directly with other nodes, whether on-site or off-, rather than through a
gateway or portal of any sort (coincidental RESTfulness?). Yet for efficiency, lookup
tables were shared at a physical site, and the push/pull table retrieved network
addresses on a three-part key: e.g., push/order/Frankfurt or
pull/CashSettlement/M123456DVP, where M123456DVP would be the transaction number by
which this settlement was known locally. At a given site, only one sort of order is
produced. It will vary internally by whether it is on a cash or margin basis, is a buy
or sell, etc., and by the particular details required by the type of security.
Required, that is, to process orders in that type of security locally at this site.
The form of an order will *not* vary by where it is to be sent, though Frankfurt and
Djakarta have different expectations for the form of an incoming order for execution.
The order is sent, that is, to a node identified as the target for orders in a given
market.
You could think of this as the converse of programming to an interface. Utilizing an
interface requires knowing, and then accommodating, precisely what your target
expects, even if that means you cannot use the native data structures which are most
meaningful to you and upon which your internal processing depends. Looked at another
way, a concept like 'order' is defined in the world of interfaces from the bottom up
by particularity: conforming to this interface produces what Frankfurt considers an
order; conforming to that one yields a Djakarta order. By contrast, my approach
asserts that a particular data structure is an order (essentially because that is how
an order is understood in my local processing) and then sends it as such to Frankfurt
or to Djakarta. The node addressed has been identified as specific to receiving and
executing orders in its native market, which greatly narrows what it has to figure out
to instantiate this foreign form of order into one which it natively understands. For
how the transaction process unfolds from there, see my answers to Paul Prescod on this
same subject: http://lists.xml.org/archives/xml-dev/200208/msg01525.html et seq.
I have recently been thinking about how the generalization of design which which is a
fundamental principle of REST (well described by Mark Baker at
http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085.html) is closely
analogous to the generalization of 'order' which I accomplish by sending the same data
structure to different processing nodes which have different expectations. This has
led me to rework in a provisional design the lookup tables, which contain Too Much
Information, or at the least information too specific to targets which are going to be
sent, or asked for, only a single form of record anyway. As I make these changes, the
fundamental *how* of presenting data to processing nodes does not change, but I am
moving steadily farther from the specificity of data presentation which you are asking
for.
Respectfully,
Walter Perry
|
