EDABlog

A lot of  traditional eventing systems  use C++  and are dubious about whether the Lego block style SOA can provide sufficient performance.

Again it boils down to design

 WCF  C# can process  over 22000 small messeges per second on an average 2 year old quad server.   http://msdn.microsoft.com/en-us/library/bb310550.aspx#wcfperform_topic4.

This is more than sufficient for most applications especially as with eventing systems you can add servers relatively simply , the algorithms which manage  the propogation of  subscriptions and the path are far more important . ( Distributed Event-Based Systems  (Muhl , Fiege and Pietzuch) is a good book which covers the theory here .

The other big issue often sited is latency but EDAM ( which uses Windows Communication Foundation ) has sometimes achieved cross machine rates of 3ms again the design is critical here if you pass through 6 nodes each adding 20 ms  it can become  quickly unacceptable.  Often people will use all the features of SOA such as queues , transactions , encryption etc  yet wouldn't implement these on a typical C++  system  these can be killers , don't use them unless you HAVE to and since most C++ eventing systems dont you better have a good reason. .

I would also add Network latency between companies , cities  or even countries add far more significant delays.  With human reaction being about 120ms (At best)  the small delays these services add are insignificant.

The end result is you CAN build lego block style SOA , high speed eventing systems  with a good a design and gain all the SOA benefits .

You could argue computer trading systems require better times but again i think the small differences you will get ( single figure ms at best ) are more than outweighed by a flexible design.  eg  instead of running the trades on the clients premises , critical trades can be uploaded to a providers machine near to the exchange this is often hard due to inflexible implementations .  A strong and flexible design means more optomization can be made more easily eg message priritization , packing multiple data messeges for efficiency etc

Like premature code optomization  the desire to be as fast as possible does not outweigh good progamming algorithms and design. 

Ok i said it enough a flexible and strong design is far more important than premature optomization and making things as fast as possible,