I gave this presentation at the Oracle InSync09 Conference in Sydney in May 2009. It's all about Oracle Coherence - Napster for the enterprise - and how you can use it to get the most out of your applications. Use Coherence like our customers are doing today; - Sharing web session state across multiple portals - Caching the results of calls to back end systems - State management for stateful services, bring the processing to the data - Process large XML payloads more quickly and efficiently

1. Pop quiz… who’s this? Ian Fleming – creator of James Bond Second question what was James Bonds first car?

2. It was this (not the Aston Martin DB5 from the 1964 movie ‘Goldfinger’) in the first Bond novel, 'Casino Royale' published in 1953 Fleming put our James in one of these. This is a 4.5 litre supercharged Bentley from the 1920’s. W.O. Bentley famously said when talking about engine performance - "there's no replacement for displacement". One of his engineers said ah ha, I'll show you, and bolted a supercharger on to the engine of the regular 4.5 litre Bentley - the supercharger is the big silver box on the front of this car - forcing more oxygen into the engine allowing more fuel to be burnt and increasing performance. Now that's exactly what I'm going to outline for you in this presentation, how you can bolt on some currently available technology to increase the performance of your applications.

3. co·her·ence I'm going to start with an overview of the supercharger - Oracle Coherence - what it is and how it works. And then show how it can be used and is being used by our customers to increase performance, reduce costs and improve user experience. What does coherence mean? Well, it’s defined as the state of cohering or sticking together, or the logical and orderly and consistent relation of parts. I like that, logic, order, consistency.

4. “ If you want a 3 second response time. You’ve got 3 seconds. 1 in the presentation layer, 1 in the mid-tier and 1 in the back end” This quote from the CIO of one of our customers really sums up the problem space that we’re in here. If you want a ‘n’ second response time then you only have ‘n’ seconds to deliver that. There are no silver medals for second place in the response time Olympics.

5. wrote the book

6. David Chappell – Enterprise Service Bus

7. Avoid processing wherever possible What does a scalable architecture need to ensure? And see if you can identify a theme here...

8. Avoid I/O where possible

9. Avoid serialization and deserialization

10. Avoid sending a large document around

11. Avoid distributed file schemes

12. Avoid driving increased traffic to back end systems I like this one a lot... and it's a classic SOA example, and if it's a mainframe there's a monetary cost in terms of haw many MIPS you need to pay for, using the technologies described here you can actually reduce the traffic to the back ends, reduce the MIPS that you're paying for.

13. Value simplicity. Maximize the amount of work not done Thanks to the Agile Alliance for this one – more details here http://agilemanifesto.org/principles.html

14. where are we today?

15. Thanks to http://zapthink.com/ for the Lego block analogy to explain SOA – interoperable, unbreakable, composable, reusable.

16. paradigm shift

17. business agility

18. flexibility

19. We're trying to achieve business agility, business alignment, so that when a line of business comes to IT and says government legislation on superannuation just changed, make our systems change to reflect it. IT can say sure thing rather than suck it's teeth and say, "it's gonna cost ya" like some dodgy plumber.

20. large payloads

21. unexpected usage

22. unmet SLAs

23. tearing down silos

24. hard to share

25. boundary costs

26. And then there's this organisational tension that developing between the SOA architects who come up with these pristine blueprints for how the IT world should look within their organisation and then they hand that off…

27. … to IT operations and say make that run, make it highly available, make it high performance, ensure that it will scale. And today there is too tight a coupling between those two sets of folks - between the people that design the architecture and the people that have to operate it. For example, what does it mean to scale up the order to cash process? That process might consist of 42 different services across 8 machines. How do IT ops go about bringing some scale to that process at the same as managing the end of month financial close and keeping the lights on and fixing the printer on level 6 while resetting my password?

28. Scalability

29. Reliability

30. Availability – always open, always on. 24 hours a day, 7 days a week.

31. stateless

32. idempotent

33. So thinking about state and state management we have this continuum that runs from completely stateless to fully stateful. and there are a few things that can affect or influence this - one is complexity - the more complex a service the more likely it is that it will need to manage state across multiple requests coming in and out of the service, and the longevity of the service - how long the service needs to run to satisfy a particular business transaction. Service Sophistication, Longevity Complex Stateless Cookies + Servlet Session State passing via XML Payloads Loose Coupling, Tight Coupling Service Complexity Stateful Service State Repository Simple

34. state aware So that's where we are... where should we be?

35. continuous availability

36. predictable linear scalability

37. Next pop quiz question, who knows what this is? That’s right, Napster. Remember Napster? Well think of Coherence like Napster for your business data - highly available, highly distributed peer to peer clustering protocol.

38. P B Backup Node Primary Node Put() HashKey/CacheKey Hashmap iFace Here's a picture of how it works. At the core are a set of connected network nodes - software processes, which cooperate together across a network, with the sole purpose of storing and maintaining instance data for individual application objects. An application does a ‘put’, that operation is delegated to the grid and the grid automatically elects a primary storage node and a backup storage node on another machine and it does that in a highly available way. So each of these nodes is on a different physical server, and each knows about each other, they are aware of each other existence, health, availability etc... If the primary owner goes down the grid detects that and selects a new primary and backup pair. And this switching this failover can happen in flight without affecting a transaction because of the self-healing nature of the grid. Application Object Application Object Application Object

39. Put() HashKey/CacheKey Hashmap iFace P B Backup Node Primary Node X Application Object Application Object Application Object

40. Put() HashKey/CacheKey Hashmap iFace P B Backup Node Primary Node X Application Object Application Object Application Object

41. Backup Node Primary Node Write Behind Queue DB Grid Put() HashKey/CacheKey ESB Mediation P B Service Service Service

42. Shared web session state across multiple portals

43. Caching the results of service calls

44. State management for stateful services

45. Process large XML payloads

46. Shared web session state across multiple portals

49. Caching the results of service calls

52. State management for stateful services

55. Process large XML payloads

56. So this picture is fairly typical - every vendor of a Service Bus could draw out this picture - they all use some sort of Message Oriented Middleware (MOM) to achieve high reliability and quality of service - and I'm using MOM here to cover anything that's JMS based or MQ based or Rendezvous based or implements WS-RM - all those similar techniques of message retries and store and forward to reliably send data from one place to the next... And then it dawned on us, why do I have to send something, when it really doesn't have to go anywhere? Everything is already in the grid. All interested parties can act on it. Why do I have to put it in a big JMS message or a big SOAP message and put it into the bus and send it across the wire just so someone can take it out again - if all you really want to do is share that information reliably? So this is what the new bus looks like. Same as the old but without some MOM implementation at the core. There's just no need when the data is in the grid and everyone can access it. Web Service Consumer WS-A ddr <ReplyTo> Callback Portal BPEL CRM ERP CEP Rules BAM JMS / MOM / WS-RM Core Web Service Provider

57. Web Service Consumer WS-A ddr <ReplyTo> Callback Portal BPEL CRM ERP CEP Rules BAM Web Service Provider

59. The XTPP — a new generation of platform middleware meant to enable low-cost, commodity hardware-based XTP — is emerging from the convergence of current enterprise application servers, enterprise service buses, flow management technology and innovative XTP point technologies. Massimo Pezzini, Gartner

60. state aware

61. continuous availability

62. predictable linear scalability

63. dramatic increase in performance and throughput

64. “ Major, often unexpected, changes will directly affect IT organizations in 2009. The successful CIOs will be those who execute well, expand their influence within the enterprise, and, perhaps, are a little bit lucky.” Stefan Spang, McKinsey