Hide Notes 

Slide 1: Understanding XML and Web Services Performance K. Scott Morrison Director, Architecture January 2005
Slide 2: Bio – K. Scott Morrison Director, Architecture at Layer 7 Technologies • http://www.layer7tech.com • Layer 7 is based in Vancouver BC, Canada Co-author of Sams’ Java Web Services Unleashed & Wrox’s Professional JMS • Over 40 other publications in academic journals and trade magazines Co-editor WS-I Basic Security Profile Frequent speaker on Web services, XML, mobile/wireless computing systems, distributed systems architecture, and Java design issues Jan 2005 SecureSpan™ Solution Overview 2
Slide 3: Agenda and Theme Performance and Web services WS-Paradigm Shift: Why Web services perform so poorly And why security will exacerbate the problem… Designing for performance Transaction tuning: a new approach to dealing with Web services performance issues Theme: Security will be the major cause of Web services performance problems in the future. What’s needed is a new approach to managing this. Jan 2005 SecureSpan™ Solution Overview 3
Slide 4: What Does Performance Mean for Web Services? The Typical Web Services Use Case Firewall Provider (Web Services Server) SOAP Request Msg Requestor (Web Services Client) SOAP Response Msg Provider Network Identity Requestor Network Jan 2005 SecureSpan™ Solution Overview 4
Slide 5: Performance is Measurable Performance requirements may be articulated through QoS: • Availability/Accessibility • Reliability • Throughput • Response time/Latency • Regulatory (Sarbanes-Oxley, etc) • Security Policy Throughput Audit Response Time Resource Utilization Identity Real goals are critical Jan 2005 SecureSpan™ Solution Overview 5
Slide 6: Haven’t We Been Dealing With This For Years? Yes; however, XML is particularly problematic… “Traditional” Distributed Computing (CORBA, COM+, etc) Serialize Data Transport Tight, fast protocols (fixed binary, name/value pairs, etc) Unserialize Data Transport Process Data… Clean separation between content and transport Security, routing, reliability, etc Network The Web Services Approach XML-based, contained in SOAP header Process Msg Protocol Process Data… Security, routing, reliability, etc Serialize Data Unserialize Data Transport Pushed up the stack into the message itself Jan 2005 SecureSpan™ Solution Overview 6 Transport
Slide 7: Consider WS-Addressing: <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <S:Header> <wsa:MessageID> uuid:6B29FC40-CA47-1067-B31D-00DD010662DA </wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://business456.example/client1</wsa:Address> </wsa:ReplyTo> <wsa:To>http://fabrikam123.example/Purchasing</wsa:To> <wsa:Action>http://fabrikam123.example/SubmitPO</wsa:Action> </S:Header> <S:Body> ... </S:Body> </S:Envelope> All intermediates need to parse XML to route, kill duplicates, etc. There are also many additional fields in WS-A not shown here. Source: Web Services Addressing – Core, W3C Working Draft 8 December 2004 http://www.w3.org/TR/2004/WD-ws-addr-core-20041208/ SecureSpan™ Solution Overview Jan 2005 7
Slide 8: Security Exacerbates Performance Issues Consider OASIS Web Services Security (WSS) Core spec describes a mechanism for securing SOAP messages using arbitrary security tokens under existing W3C specs: W3C Signing W3C Canonicalization W3C Encryption These W3C approaches were designed for generalized document security, and are certainly not optimized for performance For example, consider signing: Jan 2005 SecureSpan™ Solution Overview 8
Slide 9: <SOAP-ENV:Envelope> <SOAP-ENV:Header> <wsse:Security> <wsu:Timestamp wsu:Id="T0"> Subject signs timestamp <wsse:BinarySecurityToken wsu:Id=“x509token"> Base64 Encoded X509.v3 Certificate <ds:Signature> <ds:SignedInfo> ds:Reference elements … Subject may sign security token Reference to Subject’s certificate <ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> Subject signs body <SOAP-ENV:BODY wsu:Id=“B0"> Jan 2005 SecureSpan™ Solution Overview 9
Slide 10: Security Exacerbates Performance Issues (cont.) And that’s just signing! • Canonicalization is insanely expensive Encryption similarly complex Considerably more complicated are mechanisms like OASIS SAML Token Profile, under the Holder-of-key mechanism. How can we design for this? Jan 2005 SecureSpan™ Solution Overview 10
Slide 11: Design Strategies A lot of designing for performance is using common sense Optimization is an iterative process toward a concrete goal Key is to adopt certain principles up front, profile constantly, but don’t optimize until it’s possible to understand where the problem is Compartmentalize bottlenecks and optimize − Problems distributed throughout programming logic are very difficult to optimize Eg: XML Security SSL acceleration is a good example of this eXtreme Programming (XP) codifies this process: Test constantly Optimize last Optimization is all about balance between effort and payoff •Remember: Assumptions are the villain here. So is lore. •BTW: We’ve found Apache Bench useful, but is only one simple piece in a full arsenal of load testers (eg: it’s no good for SSL) • http://httpd.apache.org/docs-2.0/programs/ab.html So here are some general approaches: Jan 2005 SecureSpan™ Solution Overview 11
Slide 12: API Design Chunky vs. chatty APIs: Think coarse granularity • Aggregate behind façade patterns • But watch for stupidly large transfers Favour document/literal over RPC/encoded APIs • Be very careful of complex objects. Favour simple, strongly typed parameters Validate schemas early (esp. externally) Avoids costly parsing faults in processing Cache where appropriate Never encapsulate large binary data sets in XML • SwA • XOP, MTOM, & RRSHB (New W3C recommendations from just this last Tuesday) Go asynchronous when possible Jan 2005 SecureSpan™ Solution Overview 12
Slide 13: Compression and Binary XML Usually a win only in high latency or very expensive networks Wireless, satellite Trans-ocean Problem is, it destroys readability GZIP very easy, but slow WAP WBXML W3C Binary Characterization WG • Plus many others Compressed XML et rn te In Regular uncompressed Web services call Wireless Svc Provider Equipment In particular, keep an eye on XOP, MTOM, & RRSHB from the W3C Jan 2005 SecureSpan™ Solution Overview 13
Slide 14: Scaling Up and Scaling Out Scaling up More Powerful Server Overloaded Servers Blade servers, of course, attempt to combine the best of both worlds Scaling out Server Farms Sprayer Not as simple as it seems. Lots of general affinity issues: • Replay defense • Caching • DB Cursors, transactions, locks, etc Jan 2005 SecureSpan™ Solution Overview 14
Slide 15: Intelligent Parsing STOP! Do you really need to write your own Web services framework? OK, then avoid DOM Avoid DOM some more Use SAX, but consider also pull parsers • Interestingly, some standards work is helping here Consider XPATH • This is an area where hardware acceleration can provide huge wins Example is Layer 7’s partnership with Tarari Jan 2005 SecureSpan™ Solution Overview 15
Slide 16: Intelligent Parsing (cont.) Hybrid hardware/software solution 1. Responsive to change 2. Acceleration of wellunderstood problems Layer 7 SecureSpan Gateway Outgoing SOAP message Incoming SOAP message • Message classification • Validation • Policy application cribs • Cryptographic acceleration • etc Classify Extract Locate SecureSpan™ Solution Overview Jan 2005 16
Slide 17: Offloading Processing Gateway Appliance Responsible for: • Consistent application of security policy • Validation of schemas • Transform • Monitoring • PKI • Policy publication Appliances offer consistency and performance Web Svc Servers Delegation of Responsibility to Gateway SOAP Request Msg Internal Network DMZ Web Service Client Layer 7 SecureSpan Gateway Jan 2005 SecureSpan™ Solution Overview 17
Slide 18: Transaction Tuning Bridge/Gateway Combination Allows: • Complete, end-to-end control over Web services security • Dynamic, run-time application of Policy • Security model can be tuned anytime against observed performance • All without any code changes! Secure SOAP Msg (WS-Security) Internal Network WS-Policy Document DMZ Layer 7 SecureSpan Bridge SecureSpan™ Solution Overview Jan 2005 18
Slide 19: For further information: K. Scott Morrison Layer 7 Technologies Suite 501 – 858 Beatty St. Vancouver, BC V6B 1C1 Canada (800) 681-9377 smorrison@layer7tech.com http://www.layer7tech.com January 2005
Slide 20: Axis Jan 2005 SecureSpan™ Solution Overview 20