Your SlideShare is downloading. ×
0
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
Client-Facing  Web E-Trading Platforms
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

2,010

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,010
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
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

×