System of Service
Over the last n months I’ve been giving a lot of though to ideas centered around delivery of vNext applications in the Capital Markets space – specifically Complex Event Processing (CEP) applications, HPC and RIA platforms (RIAP). This posting is mainly centred around RIAP, since it’s still a somewhat debated subject is many corners of the world, coupled with a roadmap in many corportations that extends for a number of years with considerable dollar spend.
Scala has been somewhat debated within the sell-side as a language that should be “approved” for use. I know of numerous software engineers who’d love to use Scala in their day job, but don’t today because either Scala isn’t on the approved language map or nobody has come up with a business viable reason to “really” use the language. Interestingly both Scala, the time I’ve spent working with Axum, coupled with the work in F# all point to an interesting thought – Actor’s. Which neatly brings us to Ray Racine ‘System of Service’ – reference by Arjan over on Xebia. Akka is an interesting framework that offers the Actor pattern amongst other things – scalability and fault tolerance being features that are very relevant to the delivery of trading applications.
In the .NET space n-act and Retlang offer some of the feature of akka – event based actors – but are nowhere near as rich in terms of features and functionality. Microsoft appear still unwilling to provide any roadmap on its Axum incubation project. What is clear is that some of the Axum ideas are going into F# – LAgent. Also what happened to Microsofts STM?
Don has a relevant posting on F# agents. Eagle eye’d reader of his posting will notice that Don offers thoughts for a “quote server” 
So where am I going? Well it’s clear that the actor/agent pattern could help to improve the delivery of financial applications. LMAX is essentially using these ideas, and from my work I see an upside in continueing to go down this road for certain application architectures. More to come….
Off-topic: Danny Macaskill Mountain Bike Tricks.
For CLR STM – see Joe Duffy’s blog post “When readonly is not readonly”, good background on the lack of guarantees in the C# language spec which make it particularly difficult to layer write-once guarantees. I’m consigned to the future of parallel solutions on the CLR being in other ‘specialized’ languages. F#, Scala, or a special non-backward-compatible flavor of C# (which might be Axum).
http://www.bluebytesoftware.com/blog/PermaLink,guid,4a49c0a0-3e4e-4d9f-b9de-599d89a94283.aspx