Your SlideShare is downloading. ×
Client-Facing  Web E-Trading Platforms
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Client-Facing Web E-Trading Platforms


Published on

Published in: Technology, Business

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


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