This document discusses technical challenges with an existing client-facing web trading platform and proposes incorporating the XAP platform to address them. The existing architecture has a middle tier connecting to many trading systems through point-to-point connections and a shared message bus, which involves high overhead. It also has challenges around distributed data management, latency tolerance, and interdependent development groups. The proposed architecture using XAP would provide a space for non-web traffic handling, a consistent cache, transactional processing of downstream events, deployment independence through processing units, and built-in scalability.

1. Client-Facing Web E-Trading PlatformsA Leading Fortune 100 Company 1.2.2011

2. About the ProjectWeb-based DeliveryBrowser-based rich internet applicationSome state shared between the client and the serverLatency tolerance is very low with streaming prices and tradingMultiple StakeholdersSeveral business units with different priorities and interestsExisting applications that need to be integrated Downstream System TimelinesRelease/Change management windows of downstream systemsAggressive delivery schedule 2

3. Existing ArchitectureWeb E-Trading PlatformLargely an integration project with the actual trading systemsDiffering downstream dependencies Differing downstream performance characteristicsNot a Typical Web-ApplicationMany non-request-driven event flowsCaching difficult as data can change in multiple waysNot every downstream system is designed for end-user responsiveness3

4. 4High Level Initial Architecture

5. 5 High Level Initial Architecture –FULL SCREEN

6. Technical Challenges, Part 1Middle Tier to reach Trading SystemsMany point-to-point (p2p) connectionsShared message bus to notify components of changesDistributed nature involves high translation overheadDistributed transactions required over many p2pconnectionsVery distributed management of shared dataLow tolerance for system latencyInter-tangled SDLCs of various teams6

7. 7Technical Challenges, Part 2ChallengesLarge number of non-request handling processes/moving partsHigh DB/downstream connection countDB Latency and scalability, pessimistic locking, etc.Performance bound to downstream systemsInconsistent data/state in various systems without constant event broadcastInter-dependency of development groupsManagement tools require too much awareness of infrastructure.Too many ptp connections over reliance on shared message bus

8. 8Scalability Examples, Part 1Account Management ToolChange dataInvalidate cachesSend notifications to usersAll done by the tool

9. 9Scalability Examples, Part 2Data Maintenance JobsChange data in local DBNotify other processesStream updates to usersAll done by the job

10. 10High Level Arch. incorporating XAP

11. 11High Level Arch. incorporating XAP –FULL SCREEN

12. Benefits of incorporating XAP, Part 1A home for non-web trafficProcessing Units house downstream system event reactors.Transactionally handle downstream events alongside the golden source of application dataEmit events to the web event bus if and when necessaryConsistent Admin API for monitoring services in the gridReal-time self-updating cacheLocal Cache/Views eliminate out-of-web process lookups when necessary.Moves the RDBMS off the critical path to the recovery pathThe Space becomes a Primary data source for web tier 12

13. Benefits of incorporating XAP, Part 2More than a cache: A platform and APINot 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’sOptional elastic capacity capabilities are available.Deployment IndependenceFunctional units deployed as Processing UnitsContracts between Web Services and UI, and Web Layer and GS via Space RemotingHot redeployment of units without downtime.Intra-platform dependencies abstracted to Space URLs 13

14. Scalability Examples Revisited, Part 1Account Management ToolSpace Remoting CallsCaches notified by spaceSimple admin APITool is a user of the Admin API14

15. 15Scalability Examples, Part 2Data Maintenance JobsListening from the SpaceChanging space data inside a transactionConsistent data modification patternEasy failover to a backup node.

16. SummaryBefore Distributed modification of Shared DataVarying SLA’s of downstream systemsToo many moving parts needed attending to when making data changesRDBMS overloaded by being on the critical path with too many processesAfterA platform for deploying distributed event driven architectureDatabases moved to the recovery pathBenefits to the SDLC with each PU being a differently released contextInbuilt resilience and scalability with configurable partitioning and failoverDelivering a true platform ecosystem16

17. 17Wrap-upQ&A