altaira
Junior Member
Posts: 6
Joined: May 2010
|
Sat May 15, 10 05:15 PM
|
|
I have received various calls regarding the asset coverage and the technology of Altaira. It is a Cross Asset System, so everything from equity, options, futures, fx, bonds, convert bonds, asset swaps, swaps, cds, repos, swaptions, caps/floors, money market, cfd's and custom deals.
Technology is: Technology
Two paradigms exist with regard to the burden of processing: Thick-client (i.e., "Client-side" where the processing is done entirely on the client machine) and Thin-client (i.e., "Server-side" where processing is done on one or more server machines). Although Thick-client applications typically have the benefit of a rich interface (GUI), heavy computational use can not only degrade a system's overall performance, but sometimes puts the operating system into a state of "resource starvation" ? making it totally unresponsive.
Altaira offers the best of both worlds by providing a rich GUI while off-loading the computational burden to multi-threaded "agents" either on a single or clustered server. The benefits of this approach are concurrent processing, load balancing, and flexible scalability ("scale-up" and/or "scale-out").
The system uses a "divide and conquer" approach to large pricing jobs (e.g., 20,000 structured product deals) by breaking each "job" into smaller "tasks." Drones continually compete for tasks to process and cache much of the data locally.
Interface
Message Handler
Datafeed
"One-off" pricing jobs are performed synchronously and are load-balanced using IP (Internet Protocol) routing. "Batch" jobs are performed asynchronously so a trader has the freedom of revaluing his entire book while performing other tasks ? or even logging out to go to a meeting and checking the results later.
A new user installs the software using Click-Once Deployment. Presuming that he or she has been given sufficient rights by the administrator, the user will see a tree-based view of the portfolio that is customized for the user.
When a trade is opened or created, trade details transmitting back to the client application via compressed XML. When applying changes, the client application transmits the deal changes to the web server which routes the deal ? and causes it to be saved by the database using a highly efficient recordset comparison.
For "batch"-type operations (i.e. Shock, VaR, MTM), the job is queued to the database as a collection of individual tasks. "Drones" (or worker processes) continually poll the database for tasks to perform, and are served tasks in a specific priority order (using the SQL Service Broker). Since much of the data is cached locally, each drone checks for update flags before either refreshing data, or processing the data in the local cache. Each drone is multithreaded, and multiple drones can run concurrently on a single machine.
The client application continually polls the database for completed jobs. This polling uses very little overhead and allows the user to submit several jobs which can run concurrently. Because of this distributed computing model, responsiveness is crisp ? and jobs (with their corresponding results) can be accumulated or deleted at at a predefined interval or on-demand.
Quotes are posted to the database in a separate process which includes its own logic. In addition, "quote sets" (or "snapshots" of the current quotes) can be created either on a scheduled interval or on-the-fly.
Since all system functions are exposed via web services, companies have the choice of extending their existing system(s) or customizing the Altaira system ? using either native .NET objects or Web Services (for cross-platform compatibility with UNIX, etc...); this translates to virtually unlimited customization and extensibility
-------------------------
Blaise F. Labriola
|
|
