Your SlideShare is downloading. ×
Next Generation Grid Enabled SOA:
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

Next Generation Grid Enabled SOA:

449

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
449
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
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. <Insert Picture Here> Next Generation Grid Enabled SOA: Delivering Continuous Availability and Linear Scalability for Applications in a Service Oriented Architecture Dave Chappell VP & Chief Technologist, SOA
  • 2. About the Speaker 2
  • 3. Agenda/Outline • SOA Today: Drivers for Change • SOA Tomorrow: SOA Grid • State Management in the SOA Grid • SOA Grid – Advanced Capabilities • QoS and Distributed SOA Processing • Relocatable Stateful Orchestrations (BPEL) • Not Your MOM’s Bus • New Model for Scaling SOA • Summary 3
  • 4. SOA Today: Level Setting What were we suppose to get from SOA? • IT Management Paradigm Shift • Reduce Cost and Complexity Large XML Payloads • Service Enablement of IT Assets Unexpected Usage • Leverage investment, reuse Demands • Business Agility Meeting SLA • Better align with the Business Needs Expectations • Automate Business Function • Business Process Orchestration Tearing Down / De-coupling • Composite Applications Silos • Flexibility • Loose Coupling, Modularity Sharing Information • Easily integrated, upgraded, replaced Across Multiple Services • Re-Focus on Innovation, New Business Services 4
  • 5. Drivers for Change: The Evolving Problem Set 50,000 foot view • SOA Architect: Tearing Down Silos • Reuse of Shared Services • New Flexible Business Processes • IT Operations: Deployment Complexity • How many configurations of servers? • When and how to add more flavors? • Cost and Efficiency • Datacenter resource utilization • Usage typically 13% – 17% • Virtualization only solves part of the problem Tight Coupling & Contention Between SOA Architect & IT Operations 5
  • 6. Continuing Challenges • Predictable Scalability • Continuous Availability • Infrastructure AND Services • Reliable QoS • Conventional Reliable Messaging only solves part of the problem • Availability / Reliability of transient application data • Shared context across load balanced / HA services 6
  • 7. Complexity of Managing “state” in SOA Applications Hard-wired Shared Complexity Context DB Tight Coupling i ty ex State passing via pl XML Payloads C om e ic Cookies + rv Servlet Se Session Stateless Service Sophistication, Stateful Longevity 7
  • 8. Agenda/Outline • SOA Today: Drivers for Change • SOA Tomorrow: SOA Grid • State Management in the SOA Grid • SOA Grid – Advanced Capabilities • QoS and Distributed SOA Processing • Relocatable Stateful Orchestrations (BPEL) • Not Your MOM’s Bus • New Model for Scaling SOA • Summary 8
  • 9. The SOA Grid • State-aware continuous availability for service infrastructure, application data, and processing logic • Predictable scalability • Scales out linearly, whether 2 or 2,000 servers • Heterogeneous Environment • High-end / low-cost commodity hardware • Dramatic overall increase in performance and throughput • Linearly scalable shared memory and logic • Reduced dependency on disk persistence • Reduced operations cost • Reduced deployment complexity • Less flavors of servers to deploy 9
  • 10. SOA Grid - Primary/Backup synchronization Non-storage-aware Storage-aware Datagrid clients Datagrid servers Primary Update/Fetch Node P Application Ack/Nack Backup Node B Application Application 10
  • 11. SOA Grid - Primary/Backup synchronization Non-storage-aware Storage-aware Datagrid clients Datagrid servers Application Ack/Nack Update/Fetch X Backup P Node Application Primary B Node Application 11
  • 12. Asynchronous DB Updates Non-storage-aware Storage-aware Datagrid clients Datagrid servers Primary Node Update/Fetch P Ack/Nack Application Backup Node B Application DB Grid Application = Write Behind Queue 12
  • 13. Near-Cache Optimization Non-storage-aware Storage-aware Datagrid clients Datagrid servers Primary Node Fetch P Application Cache Backup Node B Application DB Grid Application 13
  • 14. SOA Grid – Advanced Capabilities • Co-locate service code with grid data • Load balance and dispatch requests appropriately • Availability and failover of Stateful services • State Passing Model Redefined • BPEL dehydration into the grid • Relocatable BPEL processes 15
  • 15. SOA Grid Primary Update/Fetch Node P Ack/Nack Service Backup Node B ESB Service Service SOA Grid BPEL Process 16
  • 16. Stateful Service load balancing Service ‘A’ Invocation Primary Update/Fetch Node P Ack/Nack Service A Backup Node B ESB Service A1 Load Balanced SOA Grid BPEL Process Services 17
  • 17. Stateful Service load balancing Service ‘A1’ Invocation Primary Node P Service Backup A Node Fetch B ESB Service A1 Load Balanced SOA Grid BPEL Process Services 18
  • 18. Stateful Service availability/failover Service ‘A’ Invocation Primary Update/Fetch Node P Ack/Nack Service A Backup Node B ESB Service A1 Load Balanced SOA Grid BPEL Process Services 19
  • 19. Stateful Service availability/failover Service ‘A1’ Invocation X Primary Node P Service Backup A Node Fetch B ESB Service A1 Load Balanced SOA Grid BPEL Process Services 20
  • 20. BPEL Dehydration Example BPEL Server 1 Process 1 Data Flow 1 Invoke 1) BPEL Server 1 Process 1 invokes Service 1 setting callback URL to LBR ESB 3 2) BPEL Server 1 Process 1 dehydrates to Load Balancer Service 1 Grid Callback 3) Service 1 Invokes LBR 4) LBR invokes BPEL Server 2 Process 2 BPEL Server 2 5) Server 2 Process 1 rehydrates process Process 1 data from grid and continues 4 ESB Service 1 and 2 can store their own Service 2 data in the SOA Grid but they do not require access to the BPEL dehydration store in this example. 5 P B SOA Grid 21
  • 21. Relocatable BPEL processes 1 234 Dehydrate •Activate/Rehydrate BPEL Svc 5 process where the primary P data resides •Lightweight signaling across nodes Lightweight signal B •State transitions using grid triggers •Tradeoffs: BPEL payload B rehydration/serialization vs. P biz object serialization 1 234 Svc Rehydrate 5 SOA Grid 22
  • 22. Agenda/Outline • SOA Today: Drivers for Change • SOA Tomorrow: SOA Grid • State Management in the SOA Grid • SOA Grid – Advanced Capabilities • QoS and Distributed SOA Processing • Relocatable Stateful Orchestrations (BPEL) • Not Your MOM’s Bus • New Model for Scaling SOA • Summary 23
  • 23. SOA Grid – Not Your MOM’s Bus Conventional Messaging for QoS Web Service WS-A ddr Inbound <ReplyTo> Callback Portal CRM ERP 1 2 3 4 JMS / MOM / WS-RM Core 5 BPEL CEP BAM Rules Web Service Provider 24
  • 24. QoS and Distributed SOA Processing Not Your MOM’s Bus • Rethink Assumptions of Conventional MOM • JMS, MQ, RV, WS-RM, etc • Reliably pass data from one place to the other • If its already in the grid, and all interested parties can access it, then why “send” it? • For large data sets, why create JMS or SOAP messages simply to put things into the bus and take them out again? • Rather make changes in the grid, and notify interested parties of the change 25
  • 25. SOA Grid – Not Your MOM’s Bus Why send it when its already there? Web WS-Addr WS-Addr Service <ReplyTo> <ReplyTo> Consumer Callback Callback Portal CRM ERP 1 2 3 4 5 BPEL CEP BAM Rules Web Service Provider 26
  • 26. That Being Said… Still Plenty of Use Cases for Conventional Messaging WS-Addr WS-Addr Web <ReplyTo> <ReplyTo> Service Callback Callback Portal Consumer CRM ERP JMS / WS-RM / EDA 1 2 3 4 5 JMS / WS-RM / EDA BPEL CEP BAM Rules Web Service Provider 27
  • 27. Rule of Thumb • Still need MOM for – • Familiar client API / usage model • Ordering • Pub/Sub • Avoid putting state in Queues where it doesn’t belong • Avoid “sending” stuff when it doesn’t really have to travel anywhere • Subscribe to state changes in the grid using observer pattern 28
  • 28. Federated SOA Grid Autonomy of Control, Consolidated Business Web WS-Addr Service <ReplyTo> Consumer Callback Portal 1 2 3 4 5 WS-Addr <ReplyTo> BAM CEP Callback ERP 1 2 3 4 5 CRM Rules Web Service Provider 29
  • 29. Service Component Architecture (SCA) Combine BPEL, BAM, Rules, Custom Logic… Web WS-Addr Service <ReplyTo> Consumer Callback Portal 1 2 3 4 5 WS-Addr <ReplyTo> BAM CEP Callback ERP SCA Composite 1 2 3 4 5 CRM Rules Web Service Provider SCA Composite 30
  • 30. Agenda/Outline • SOA Today: Drivers for Change • SOA Tomorrow: SOA Grid • State Management in the SOA Grid • SOA Grid – Advanced Capabilities • QoS and Distributed SOA Processing • Relocatable Stateful Orchestrations (BPEL) • Not Your MOM’s Bus • New Model for Scaling SOA • Summary 31
  • 31. DataCenter Resource Utilization • What Does it Mean to Scale a Service? • A New Model for Service Scalability • More Effective Service Virtualization 32
  • 32. Scaling SOA - Approaching Limits and Bottlenecks • Memory, Disk, CPU • Typical Virtualization Solutions don’t optimize this balance • CPU is maxed, then memory is underutilized • Memory is maxed, then CPU underutilized • Disk bottlenecks can back up processing • Necessitates Queueing • Scale-down can kill sessions (Coherence Web solves this) • SOA Grid • Disk bottlenecks virtually eliminated • Memory utilization delegated to storage enabled grid nodes • Only CPU-bound resources need to be load-balanced. 33
  • 33. Server Utilization Typical Virtualization Scenario Server A Server B Server C Memory Usage Memory Usage Memory Usage Memory 50 % 10 % 20 % CPU CPU Usage CPU Usage CPU Usage … 10 % 50 % 10 % Disk Usage Disk Usage Disk Usage Disk 20 % 20 % 50 % 34
  • 34. Server Utilization SOA Grid Server Z Memory Usage Memory 50 % … CPU Usage CPU 50 % Disk Usage Disk 1% 35
  • 35. Scaling SOA A new model for efficient resource utilization Data Memory Usage Data Memory Usage Data Memory Usage 50 % 50 % 50 % … Service A Logic Logic Logic CPU Usage CPU Usage CPU Usage XSLT Transformation … ESB 50 % 50 % 50 % Logic & Data Logic & Data Logic & Data Memory Usage Memory Usage Memory Usage Service B 50 % CPU Usage 50 % CPU Usage 50 % CPU Usage … Application Logic 50 % 50 % 50 % BPEL Process 36
  • 36. SOA Grid • State-aware continuous availability for service infrastructure, application data, and processing logic • Predictable scalability • Scales out linearly, whether 2 or 2,000 servers • Heterogeneous Environment • High-end / low-cost commodity hardware • Dramatic overall increase in performance and throughput • Linearly scalable shared memory and logic • Reduced dependency on disk persistence • Reduced operations cost • Reduced deployment complexity • More efficient server resource utilization • Less flavors of servers to deploy 37
  • 37. For More Information • SOA Magazine – SOA – Ready for Primetime: The Next Generation, Grid Enabled SOA • http://www.soamag.com/I10/0907-1.asp • Data Grid – • http://www.oracle.com/products/middleware/cohere nce/index.html • General SOA Information – http://www.oracle.com/technologies/soa/ index.html 38
  • 38. Q&A 39
  • 39. 40

×