Programs that talk to the shim, the shim itself, the tws client, and its connected and indirect servers together make up a chain where every interior node is both a client and server, and although data feeds back in loops, there is still a clear directionality from the user to the external markets, and so throughout this text I'll refer to the user-facing node in this chain as the downstream, and the external servers as the upstream, so that the chain becomes downstream-shim-tws-upstream.
Api and related IO objects are referred to collectively as events, and these events are partitioned into four categories: commands, from the downstream to the shim; requests, from the shim to the IB tws; messages, from the tws to the shim; and comments, generated internally by the shim and sent downstream.
The IB tws api is complex, with about 50 request and message events defined, and the largest of these, the place-order request, consisting of more than 50 attributes in the latest version. No formal specification for this protocol language has been publicly released by IB; instead, the source code for a Java program, the sample client, is the best available guide to the request and message formats, which I refer to as wire formats, reflecting their use in a socket protocol. Note also that the request-message language is fundamentally asynchronous: some data is requested via subscription; the initial response time for order events, though excellent for the common case, is unbounded; and the children of bracket orders may fire at any time.
Bill Pippin 2010-01-14