Paul Lipton. Abstract. Speaker. SOA is Naturally Diverse. The New SOA Synergy: How Runtime Governance, Triage, and Security Must Work Together

Transcription

1 Abstract The New SOA Synergy: How Runtime Gnance, Triage, and Must Work Together Sr. Architect, Office of the CTO, CA Inc. We will consider how the unique architectural characteristics of SOA can be a two-edged sword affecting the requirements, nature, and success of many important aspects of SOA, especially runtime gnance and security. For example, SOA services can be vulnerable to accidental or deliberate denial-of-service attacks resulting in costly service level failures. How will you understand the nature of these and other problems that can severely impact the performance and reliability of the runtime SOA environment? The success of any SOA project requires that one must gain an understanding of the true nature, performance characteristics, and availability of the business transactions that flows in real-time through highly distributed services and their supporting IT infrastructure. Only the synergy of transaction-oriented operational and security management can achieve adequate visibility into such problems before they grow serious. This session will discuss best practices related to both so that you can be prepared to deliver a verifiably reliable and successful SOA, and can effectively triage SOA business transaction failures and risks in real-time. Speaker is a Senior Architect in CA s Office of the CTO where he specializes in SOA, Web services, and emerging technologies. He has also participated in many standards organizations such as OASIS and W3C, is a founding member of the CA Council for Technical Excellence, a Microsoft MVP, and a Sun Java Champion. Paul has also been an architect and developer of enterprise systems for 20 years. He is a highly sought-after author and speaker, and has shared his knowledge with appreciative audiences around the world cing such topics as Enterprise Architecture, SOA, Web services, management/security, gnance, Java,.NET, EAI, and emerging technologies. As SOA gains acceptance, how are platforms evolving? What is gnance? Are there different types? Where does management and security (runtime gnance) fit in? SOA is Naturally Diverse SOA Gnance Best Practices & Products Multi-Platform & Heterogeneous MOM, app & integration servers Platform ESB Routing, message transformation, guaranteed delivery, etc. You may already have several ESBs Wide range of characteristics Performance, features, cost, etc Roots in app dev, deployment, or messaging Management and security: limited, platform-centric Focus on development assets ( artifacts ) Development process Human approvals, visibility, methodologies, etc. Development tools IDEs, modeling tools, source-control systems, etc. Development policy Artifact scanning, coding standards, etc. Registry and/or repository Enterprise scope or enterprise integration? Gnance

2 SOA Management and Runtime Considerations for Exposure Management Runtime Gnance Visibility into Transactions Beyond individual platform perspective Availability and reliability of transactions Across multiple, heterogeneous platforms Spans J2EE and.net middleware, ESBs, mainframes, transaction systems, messaging middleware, databases, ERP systems, etc. Meeting commitments with customers, partners, suppliers, regulators, employees, etc. Management and security in synergy (run-time gnance) Will all parties meet their obligations? Adequate and reliable performance? Proactive vs. reactive: can you predict/forecast? Level Agreements (SLA) Will services be dependable? Problems or lost transactions? If so, what service? What underlying IT infrastructure is a factor? What component? Can you prove it and provide information needed to help fix? Quality of QoS Only the right people and the right information at the right time Autht/authz, encryption, federation, etc. Is this a denial-of-service attack? How do you really know? Documentation of service activity (other issues like privacy, legal, etc.) Audit trail and logging of runtime transactions Issue: centralized vs. platform specific Development Time Considerations for Exposure How do you meet commitments with customers, partners, suppliers, regulators, employees, etc.? Gnance (development time) Will all parties meet their obligations? Are all changes in sync? Distributed coordination and approval process? Satisfaction or penalties? Coding standards enforced? Will services be dependable? Behavior of services correct? Code scanning, correct metadata, etc. Quality of QoS Who can approve or make changes to services? Regulatory compliance? Can you document your service changes and who made them? Audit trail and artifact control Development workflow and lifecycle-centric How is SOA different? What are the characteristics of SOA? Do these innate characteristics of SOA change the game? Do they put the business at greater risk? Retail Banking Credit Card Division Less dependencies between services More distributed and heterogeneous Transaction context crosses domains Mortgage DL Credit DL Credit Employment History DL

3 Employment History Employment History s DL Credit DL Credit DL DL Linux But management becomes much more difficult Much more distributed Greater (and even unpredictable) heterogeneity Greater complexity and more rapid change DL Linux SOA Encourages Reuse of s The Ideal: Efficient Invocation reuse Primary ROI factor Reduces development and maintenance cost Principle architectural goal: maximization of reuse CLIENT PRODUCER Billing Direct to Consumer Accounting End-of- Quarter Transaction SOA business agility and service reuse means utilization patterns can change drastically New consumers (some authorized, but unknown) Can you predict and identify potential bottlenecks? Backend System The Reality: Death by a Thousand Cuts IT Infrastructure Supports the s CLIENT What precipitates this behavior? Design flaw? New use cases? Different types of transactions? PRODUCER Transaction ESB J2EE APPLICATION APP SERVER Over JMS MQ Series HTTP DL J2EE APPLICATION APP SERVER Web RP Portal XML HTTP Finding the Cause of Problems is Challenging How many errors? What caused them? Who is affected by an outage? How can I measure and manage SLAs? Which applications are dependent on which services?.net

4 In Complex, Heterogeneous Environments 99% Availability Isn t Enough s are Usually Stateless State/Context is in the Message Web Server App logic MQ Server Database CICS Siebel End-User App Unavailable or Slow Available, Performant 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 % available 99% 99% % Web s 98% 80% Borrow n Yes Retail Banking Credit Card Division XML is extensible/flexible Many ways to express permitted state Unpredictable behavior or head? What is happening? Is this an attack? DL Credit Mortgage SOA Makes Development Easier But Management Challenges Harder Top Management Challenges CA Wily Has Seen Innate characteristics of SOA Much more heterogeneous and volatile (loosely-coupled) More critical points-of-failure (reuse) Problem isolation in full context Transaction integrity & verification Transaction mapping Results in Difficult to isolate and understand problems Hard to trace and understand business transactions Transaction routing based on message content New and changing components and services all the time Rapid change introduces new vulnerabilities very quickly More exposed points-of-entry More outside services Can you depend upon them? Problem Isolation in Full Context Transaction Integrity & Verification End User Network Need to monitor services within the context of the full application Which applications are dependent on which services? Router Firewall How can I measure and manage SLAs? Switch Load Balancer Where do I start tuning performance? Identity Manager Web Servers Who is affected by an outage? Portal 3 rd Party SAP PSFT SAP Siebel How many errors? What caused them? Database External Web s I was quoted a $150 rate Validate transaction contents Alert to out-of-bounds conditions upon transaction volume Verify service request and response Rate Quote Inventory

5 Transaction Flow: The Fantasy Transaction Flow: The Reality! Presentation Layer Presentation Layer Backend Backend Backend Backend Backend Backend System System System System System System Backend Backend Backend Backend Backend Backend System System System System System System It s impossible to deploy a new architecture all at once Can you trace where your customer transactions go? They won t always go to the same places (loose-coupling)! Developers conforming to standards? What about outside services? What is the impact when something breaks or slows down? Summary Some Resources SOA Characteristics Require More Interdependency Between IT Groups Operational Visibility Becomes a Common Concern, Ops, Support, Architects, dev, LOB owners, etc. Architects/development must lead Attack by causing failure to meet SLAs! Potentially expensive and embarrassing Threatens customer relationships threats map to runtime business transactions What components and services are touched? What are the trends (predictive analysis) Problem determination and root-cause analysis All stakeholders need common viewpoint and monitoring tools Develop services with a view towards evolution of both the SOA and the service CA Wily Technology Management CA SOA Solutions SOA World C Story SOA Web s Journal, February 1, 2007 Are You Being Served?, Latest column in SearchWebs.com (TechTarget) d26_gci ,00.html My blog on webservices.org The New SOA Synergy: How Runtime Gnance, Triage, and Must Work Together Sr. Architect, Office of the CTO, CA Inc. paul.lipton@ca.com