Client-Facing Web E-Trading Platforms

  • 1,950 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,950
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
    2
  • 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
    3
  • 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
    6
  • 7. 7
    Technical Challenges, Part 2
    Challenges
    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
    12
  • 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
    13
  • 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
    14
  • 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
    Before
    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
    After
    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
    16
  • 17. 17
    Wrap-up
    Q&A