Layer 7: Understanding XML & Web Services Performance


Published on

Security will be the major cause of Web services performance problems in the future. What’s needed is a new approach to managing this.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Layer 7: Understanding XML & Web Services Performance

  1. 1. Understanding XML and Web Services Performance K. Scott Morrison Director, Architecture January 2005
  2. 2. Bio – K. Scott Morrison Director, Architecture at Layer 7 Technologies • • 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
  3. 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
  4. 4. What Does Performance Mean for Web Services? The Typical Web Services Firewall Use Case Provider (Web Services Server) SOAP Request SOAP Msg Response Msg Requestor Provider (Web Services Client) Network Identity Requestor Network Jan 2005 SecureSpan™ Solution Overview 4
  5. 5. Performance is Measurable Performance requirements may be articulated through QoS: • Availability/Accessibility • Reliability • Throughput Audit • Response time/Latency • Regulatory (Sarbanes-Oxley, etc) • Security Policy Throughput Resource Response Utilization Time Identity Real goals are critical Jan 2005 SecureSpan™ Solution Overview 5
  6. 6. Haven’t We Been Dealing With This For Years? Yes; however, XML is particularly problematic… “Traditional” Process Data… Distributed Computing (CORBA, COM+, etc) Clean separation between content and transport Serialize Data Unserialize Data Tight, fast protocols (fixed Security, routing, Transport Transport reliability, etc binary, name/value pairs, etc) Network The Web Services Process Data… Approach XML-based, contained Process Msg Security, routing, Protocol reliability, etc in SOAP header Serialize Data Unserialize Data Pushed up the Transport Transport stack into the message itself Jan 2005 SecureSpan™ Solution Overview 6
  7. 7. Consider WS-Addressing: <S:Envelope xmlns:S="" xmlns:wsa=""> <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 Jan 2005 SecureSpan™ Solution Overview 7
  8. 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
  9. 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> Subject may sign security token ds:Reference Reference to … elements Subject’s certificate <ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> Subject signs body <SOAP-ENV:BODY wsu:Id=“B0"> Jan 2005 SecureSpan™ Solution Overview 9
  10. 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
  11. 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) • So here are some general approaches: Jan 2005 SecureSpan™ Solution Overview 11
  12. 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
  13. 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
  14. 14. Scaling Up and Scaling Out More Powerful Server Scaling up Blade servers, of Overloaded course, attempt to Servers combine the best of both worlds Scaling Server out Farms Not as simple as it seems. Lots Sprayer of general affinity issues: • Replay defense • Caching • DB Cursors, transactions, locks, etc Jan 2005 SecureSpan™ Solution Overview 14
  15. 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
  16. 16. Intelligent Parsing (cont.) Outgoing SOAP Hybrid hardware/software message Layer 7 solution SecureSpan 1. Responsive to change Gateway 2. Acceleration of well- understood problems Incoming SOAP • Message classification message • Validation • Policy application cribs • Cryptographic acceleration • etc Classify Extract Locate Jan 2005 SecureSpan™ Solution Overview 16
  17. 17. Offloading Processing Delegation of Gateway Appliance Responsible for: Responsibility to Gateway • Consistent application of security policy • Validation of schemas • Transform • Monitoring Web Svc • PKI Servers • Policy publication Appliances offer consistency and performance SOAP Request Msg Internal Network DMZ Web Service Client Layer 7 SecureSpan Gateway Jan 2005 SecureSpan™ Solution Overview 17
  18. 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 DMZ Document Layer 7 SecureSpan Bridge Jan 2005 SecureSpan™ Solution Overview 18
  19. 19. For further information: K. Scott Morrison Layer 7 Technologies Suite 501 – 858 Beatty St. Vancouver, BC V6B 1C1 Canada (800) 681-9377 January 2005
  20. 20. Axis Jan 2005 SecureSpan™ Solution Overview 20