Client-Facing Web E-Trading Platforms


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Client-Facing Web E-Trading Platforms

  1. 1. Client-Facing Web E-Trading Platforms<br />A Leading Fortune 100 Company 1.2.2011<br />
  2. 2. About the Project<br />Web-based Delivery<br />Browser-based rich internet application<br />Some state shared between the client and the server<br />Latency tolerance is very low with streaming prices and trading<br />Multiple Stakeholders<br />Several business units with different priorities and interests<br />Existing applications that need to be integrated <br />Downstream System Timelines<br />Release/Change management windows of downstream systems<br />Aggressive delivery schedule <br />2<br />
  3. 3. Existing Architecture<br />Web E-Trading Platform<br />Largely an integration project with the actual trading systems<br />Differing downstream dependencies <br />Differing downstream performance characteristics<br />Not a Typical Web-Application<br />Many non-request-driven event flows<br />Caching difficult as data can change in multiple ways<br />Not every downstream system is designed for end-user responsiveness<br />3<br />
  4. 4. 4<br />High Level Initial Architecture<br />
  5. 5. 5<br /> High Level Initial Architecture –FULL SCREEN<br />
  6. 6. Technical Challenges, Part 1<br />Middle Tier to reach Trading Systems<br />Many point-to-point (p2p) connections<br />Shared message bus to notify components of changes<br />Distributed nature involves high translation overhead<br />Distributed transactions required over many p2pconnections<br />Very distributed management of shared data<br />Low tolerance for system latency<br />Inter-tangled SDLCs of various teams<br />6<br />
  7. 7. 7<br />Technical Challenges, Part 2<br />Challenges<br />Large number of non-request handling processes/moving parts<br />High DB/downstream connection count<br />DB Latency and scalability, pessimistic locking, etc.<br />Performance bound to downstream systems<br />Inconsistent data/state in various systems without constant event broadcast<br />Inter-dependency of development groups<br />Management tools require too much awareness of infrastructure.<br />Too many ptp connections<br /> over reliance on shared message bus<br />
  8. 8. 8<br />Scalability Examples, Part 1<br />Account Management Tool<br />Change data<br />Invalidate caches<br />Send notifications to users<br />All done by the tool<br />
  9. 9. 9<br />Scalability Examples, Part 2<br />Data Maintenance Jobs<br />Change data in local DB<br />Notify other processes<br />Stream updates to users<br />All done by the job<br />
  10. 10. 10<br />High Level Arch. incorporating XAP<br />
  11. 11. 11<br />High Level Arch. incorporating XAP –FULL SCREEN<br />
  12. 12. Benefits of incorporating XAP, Part 1<br />A home for non-web traffic<br />Processing Units house downstream system event reactors.<br />Transactionally handle downstream events alongside the golden source of application data<br />Emit events to the web event bus if and when necessary<br />Consistent Admin API for monitoring services in the grid<br />Real-time self-updating cache<br />Local Cache/Views eliminate out-of-web process lookups when necessary.<br />Moves the RDBMS off the critical path to the recovery path<br />The Space becomes a Primary data source for web tier <br />12<br />
  13. 13. Benefits of incorporating XAP, Part 2<br />More than a cache: A platform and API<br />Not only for the data – also a giant distributed spring context <br />Space Remotedinterfaces, Polling Containers, and the standard partitioned data grid.<br />Scalability built-in with configurable SLA’s<br />Optional elastic capacity capabilities are available.<br />Deployment Independence<br />Functional units deployed as Processing Units<br />Contracts between Web Services and UI, and Web Layer and GS via Space Remoting<br />Hot redeployment of units without downtime.<br />Intra-platform dependencies abstracted to Space URLs <br />13<br />
  14. 14. Scalability Examples Revisited, Part 1<br />Account Management Tool<br />Space Remoting Calls<br />Caches notified by space<br />Simple admin API<br />Tool is a user of the Admin API<br />14<br />
  15. 15. 15<br />Scalability Examples, Part 2<br />Data Maintenance Jobs<br />Listening from the Space<br />Changing space data inside a transaction<br />Consistent data modification pattern<br />Easy failover to a backup node.<br />
  16. 16. Summary<br />Before <br />Distributed modification of Shared Data<br />Varying SLA’s of downstream systems<br />Too many moving parts needed attending to when making data changes<br />RDBMS overloaded by being on the critical path with too many processes<br />After<br />A platform for deploying distributed event driven architecture<br />Databases moved to the recovery path<br />Benefits to the SDLC with each PU being a differently released context<br />Inbuilt resilience and scalability with configurable partitioning and failover<br />Delivering a true platform ecosystem<br />16<br />
  17. 17. 17<br />Wrap-up<br />Q&A<br />