Trading bot construction (IB)

I see that it is possible to 'setServerLogLevel()' and that there are some things in EClientSocket that
might be useful in finding out about what happened to an order.

Here is the disconnect method

Code:

    public void disconnect() {

        try {

            logger.log("disconnecting\n");
            client.eDisconnect();
            Thread.sleep(1000);     // BUG? wait for disconnect?

        } catch (Exception e0) {

            //BUG? Is it something other than a socket closed exception?
            //BUG? Is 'Exception' too broad?
            logger.log("disconnect caught %s\n", e0);
            //BUG: printStackTrace() untested
            e0.printStackTrace();
        }
    }

A call of that replaces the block of code that is after "if (!pseudotrade)";
it is also called when RandomBot returns something other than OK, right before logger.fatal() is called.

 

I highly recommend XML for storage of configuration data - not bad at all too for an instrument 'database', though time series data belongs elsewhere. Far more flexible than command line arguments. I use XML for quite a few things including data feed configuration, instrument data base, workspace configuration (screen layouts of chart frames, chart contents, including colours, rendering styles etc), real time alerts and soon for trading system specification. Some of it is fairly complex and would be a real nightmare without XML.

jdom from http://www.jdom.org is a very good and easy to use API for processing XML documents.

 

I concur. Also have a look at:

Digester: http://jakarta.apache.org/commons/digester/

XMLBeans:
http://xmlbeans.apache.org/

 

Suggest using Commons CLI for any command line handling situations in your programs:

http://jakarta.apache.org/commons/cli/

 

Thanks for the xml and cli pointers.

It looks useful and my Java book has an intro. xml chapter.
While looking into data feeds,
I have run into at least one vendor that delivers xml,
and IB uses xml to store some things under .../IBJts.

 

I was reading about XML -- chapter 27 of van der Linden's book.
He writes about the wisdom of parsing XML without knowing anything about the implementation of the parser,
without even knowing the parser's name.

Here is a way to work with an abstract broker:

Code:

abstract class Broker {

        abstract void placeOrder();     // a trader places an order with a broker 
}

interface CallBack {

        // a broker calls a trader back about the status of an order

        void orderStatus(String status);
}

class OneAndOnly extends Broker {

        CallBack trader;        // remember the trader

        OneAndOnly(CallBack trader) {

                this.trader = trader;
        }

        // accept an order and call-back the trader with order status
        void placeOrder() {

               // Use OneAndOnly's API to place order
               // Get order status via OneAndOnly's API

               // Provide order status to Trader
                trader.orderStatus("Filled!");
        }
}

class Brokerages {

        static Broker getBroker(CallBack trader) {

                return new OneAndOnly(trader);  // return the most suitable broker
        }
}

class Trader implements CallBack {

        Broker broker = Brokerages.getBroker(this);

        public void run() {

                System.out.printf("Placing order ... ");

                broker.placeOrder();
        }

        public void orderStatus(String status) {

                System.out.printf("%s\n", status);
        }
}

public class Main {

        static public void main (String[] args) {

                Trader trader = new Trader();
                trader.run();
        }
}

The factory design pattern ... .
There is one and only one broker here, 
but the intent of Brokerages is to choose one from among those that may be available.
Brokerages.getBroker might be passed parameters to help it choose; 
I suppose it could even be asked for a particular broker. The point is that 'Trader' works
with an abstract 'Broker', so 'Trader' doesn't need to know anything about any particular broker's API.

 

In 'OneAndOnly', 'placeOrder' would wait for the API to return the status.
The consequence of that is that 'OneAndOnly' and 'Trader' would block
until the status is returned. For an alternative that may work with an
API like IB's, add an interface 'BrokerCallBack', which is implemented by
'OneAndOnly':

Code:

interface BrokerCallBack {

    // an API calls a broker back about the status of an order

    void orderStatus(int status);  // API provides an 'int'
}

class OneAndOnly extends Broker implements BrokerCallBack {

    CallBack trader;  // remember the trader

    OneAndOnly(CallBack trader) {

        this.trader = trader;
    }

    // accept a trader's order
    void placeOrder() {

        // Use OneAndOnly's API to place order
        ;

    }

    // when OneAndOnly's API calls back with status, call-back the trader
    public void orderStatus(int status) {

        // Provide order status to Trader.
        // With OneAndOnly's API, 'status' is 'String'ized for the trader
       trader.orderStatus("Filled!");
    }
}

'CallBack' might be better named 'TraderCallBack'.
With this, 'orderStatus' in both classes, in the one that implements
'TraderCallBack' and in the one that implements 'BrokerCallBack', is
called asynchronously to whatever else they may be doing. With a broker
other than 'OneAndOnly', 'BrokerCallBack' might be different, which
would require that its 'orderStatus' be different, maybe even named
differently -- because some other broker's API is probably different.
With an 'IB' that 'extend'ed 'Broker' and implemented 'BrokerCallBack',
its 'placeOrder' would call something in EClientSocket and its 'orderStatus'
would be called by something in EReader.

I am thinking of calling rewrite.
But do I know enough about the Broker/Trader
relationship to write a 'TraderCallBack' interface that isn't heavily
influenced by IB's API? Some other Broker's API might not do callbacks,
which might require Trader to block for the order's status or run a thread to call that Broker's 'placeOrder' method.
Does it matter whether Trader might block?
Is there anything else that Trader might need to do?
In manual trading, when I place an order,
I think that my only concern is whether the order gets filled,
because what I do next is very dependent on that order's status,
unless I have other open positions that I'm watching.

I suppose that bot's, like humans, trade best if they can pay full attention to one position at a time.

I suppose that more than one Trader might exist, each managing one position.
If that were the case, a concrete 'Broker' might have to be careful about the number of APIs it instantiated.
Would there be a problem associating returned API status with the 'Trader' that placed the order?


Decisions, decisions ... .

 

If you're new to design patterns et al, you may want to check out: Head First Design Patterns

It might be a little patronizing/long winded if you are already quite familiar with most of the GoF patterns though.

Also, if you want to take your standard Java to the next level:

Effective Java

It's a little out of date now (doesn't cover Java 5 etc.) but still worth a look until the next version comes out (this year sometime...)

If you're comfortable reading things online via FlashPaper/PDF style then you may consider subscribing to Safari Books Online as it's both much more economical and environmentally friendly

Both of the books mentioned above are on Safari.

 

I read "Design Patterns" once. Maybe it didn't sink in. I learn experientially; I had to try abstracting IB.

I got far with:

Code:

class IB extends Broker implements BrokerCallBack, EWrapper {

but ended up with just:

Code:

class IB extends Broker implements EWrapper {

Why? 'EWrapper' is nothing but broker callbacks and has the correct prototype for 'orderStatus'

I've attached 'Main.java' as 'main.txt'. It can be built if placed in .../IBJts/java/Abstract, then in
.../IBJts/java: javac Abstract/Main.java

I don't know yet whether a rewrite will happen.

 

Retry the attachment. Last time was click on the file, then 'open'. This time I'll try a double-click.