Sadky that is a lot more complicated than a security issue. If the computer "requiring" the callback is behind NAT that wont work. Now, NAT may be: * Your home router protecting your home network * The WLAN you are logged in - doing the same * The stupid UMTS provider doing the same. etc.etc.etc. So, it ends up having a otentially not knowledgeable user trying to work around his firewall, OR even trying to do so WITHOUT having access to said firewall. It is quite common for networks one logs in to allow outgoing traffic but be NAT'ing for various reasons - I have seen this in Hotels, companies etc. I do the same in my own, actually. All that means that this is simply not a working solution outside a well controlled environment. What one CAN do (but that is not in the standard) is have a permanent HTTP callback channel - basically the application asks for a URL and the sever keeps it open, never closing it, writing out events as they appear. This is used by various chat systems. It is sadly not really covered in any standard. Now realize that those tools are a LOT more than Trigger, Facebook and you get a point. Some usefull tools on my desk that support web services are: * SQL Server Integration Services. Like for downloading transaction history and acccount data to a database daily automatically. * Visual Studio / .NET - point it to a standards compliant web service, wrappers are auto generated. * Various reporting frameworks that work well with XML and could load it from a URL Makes quite some stuff. I really miss a REST / XML based account statement mechanism at Mirus / RCG.... to automatically pull account statements into a database.
Agreed. Agreed and implies then that there's no benefit to using HTTP at all as the protocol. Sure, a lot of tools to make working with SOAP easy have been around a long time (although it took a while to get to that point); Given a WSDL there exist tools or IDEs for most languages to auto-generate proxys etc transparent to the developer. But then came Web 2.0 and SOAP was all but abandoned in some verticals in favor of REST et al. It was the tools and libraries around these "newer" and vastly simpler mashup technologies that I was referring to - it's made web services accessible to a much larger audience and allowed it to become fashionable and in vogue. I'm not disagreeing with what you've said though. Actually, that would be quite cool and relatively simple to implement for the broker. As for order management on the other hand, I couldn't see myself using web service technology for that. But never say never....
Fully agreed. I must say that I am in the situation right now to try to get something similar work The environment is C# / .NET / Microsoft all the way, but supposed to be open (i.e. I have to stick to standards as much as I can, at least for some parts). The goal is something "like" NinjaTrader, just professional - including handling multiple instruments, a.k.a. "complete exchange feeds" (that is around 400.000 symbols on CME alone), client/server architecture and having prop shop functionaliy (system accounts mapped to broker accounts, but with separate risk and attached to users). I am stuck with something similar - for market data, I have given up. THere is NO way to do that even with binary encoded XML in a sane way. So, I work on my own binary coded data feed - pretty nice, I can get SOME status updates down to one byte and most down to 5 bytes. Note that I need scalability up to around 250.000 updates - per second. CME alone generates a base load of around 10.000 events normally, up to 30.000 during opening times, and easily publishes a million events AT open/close (most of them in the form "market closed for instrument x" - with around 400.000 instruments I see... that is a lot of events). Some stuff just is great in a SOAP / Web based API. THat includes, for me, handling data feeds ("request feed", "subscribe to instruments") - just the data has to go through a binary coded thing. Where I am getting semi-stuck is sadly exactly the back channel to the clients. Here, to my rescue, I can use TCP bi directional binding by Microsoft's WCF framework, which basically registers a back channel. As my API on THAT thing basically has only one method in both ends (SubmitMessage - it is a message based protocol, mostly also because if scalability) this is hardly a problem. But a silverlight implementation would have to do the same... using HTTP polling. This seriously does not scale, especially in a near real time scenario (how often do you WANT to poll - 100 times per second? - Imagine the load on the server).
rebtut, To manage trades at multiple brokers from one trading platform, have you looked at Trade Bullet?
Someone mentioned Gain Capital's API (http://www.gaincapital.com/forex_api.html) in this thread. From my understanding, they only support FOREX and not stock trading. Can someone verify this?