Java高伸缩应用最佳实践Coherence.pptVIP

* * * * * 当时 PoC 的要求 No Single Points of Failure No Simple Points of Bottleneck No Service Registries No Masters + Workers already got one that is partitioned into over 200 separate clusters No Manual Partitioning Keep everything in Memory Active + Active Sites Across WAN Develop system on a note book Scale to over 500 servers No reconfiguration outages No byte-code manipulation / proxies No Data or Task Loss During failure During server upgrade During scale out No Transactions (XA) Support multiple versions Predictable response times Predictable scale out costs Manage via JMX, from any point in the “Cloud”. Pure Java Standard Edition Infrastructure add a maximum of 3ms latency to tasks. Integrate with existing applications (Java 1.4.2+) * * As we continue to enhance the vision of the SOA grid and work with Oracle Coherence customers in thinking through its ramifications in practical use, there are some stunning realizations that become blaringly obvious that cause us to re-evaluate assumptions for how to reliably get data from one place to another. The basic question to ask is “Why send it when its already there?”. If you have a SOA grid that can reliably hold application state data, and the necessary systems can access it, why continue to utilize conventional messaging? Particularly for large XML data sets, why create large JMS or SOAP message and send them across the wire through the ESB simply to take them out again? Rather if the data in question is held reliably in the SOA grid, and all interested parties can access it, then why “send” it anywhere? The next generation service bus inherently has direct access to service state data using in-memory-grid based stateful HA, BPEL process orchestration capabilities, and today’s notions of ESB capabilities such as data transformation and routing, service level abstraction, and protocol and adapter support * * Bring up on stage two customers to tell the audience about their experiences. Manpower Associates