Understanding XML and Web Services Performance
•
0 gostou•4,220 visualizações
Security will be the major cause of Web services performance problems in the future. What’s needed is a new approach to managing this.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Understanding XML and Web Services Performance
Semelhante a Understanding XML and Web Services Performance (20)
Mais de CA API Management
Mais de CA API Management (20)
Último
Último (20)
Understanding XML and Web Services Performance
- 1. Understanding XML and Web Services Performance K. Scott Morrison Director, Architecture January 2005
- 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
- 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. 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. 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. 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. 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/ Jan 2005 SecureSpan™ Solution Overview 7
- 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. <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. 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. 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
- 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. 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. 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. 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. 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. 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. 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. 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
- 20. Axis Jan 2005 SecureSpan™ Solution Overview 20