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