• Save
Client-Facing  Web E-Trading Platforms
Upcoming SlideShare
Loading in...5
×
 

Client-Facing Web E-Trading Platforms

on

  • 2,259 views

 

Statistics

Views

Total Views
2,259
Slideshare-icon Views on SlideShare
1,756
Embed Views
503

Actions

Likes
0
Downloads
0
Comments
0

7 Embeds 503

http://www.gigaspaces.com 493
http://translate.googleusercontent.com 3
http://gstil.com 2
http://www.gigaspaces-old.com 2
http://www.gigaspaces.rsvp1.com 1
http://wiki.gigaspaces.com 1
http://old.gigaspaces.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Client-Facing  Web E-Trading Platforms Client-Facing Web E-Trading Platforms Presentation Transcript

    • Client-Facing Web E-Trading Platforms
      A Leading Fortune 100 Company 1.2.2011
    • 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
    • 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
      High Level Initial Architecture
    • 5
      High Level Initial Architecture –FULL SCREEN
    • 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
      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
      Scalability Examples, Part 1
      Account Management Tool
      Change data
      Invalidate caches
      Send notifications to users
      All done by the tool
    • 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
      High Level Arch. incorporating XAP
    • 11
      High Level Arch. incorporating XAP –FULL SCREEN
    • 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
    • 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
    • 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
      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.
    • 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
      Wrap-up
      Q&A