Some Performance and Security Findings Relative to a SOA Ground Implementation March 28, 2007 John Hohwald Slide 1
Ground SOA Implementation Issues SOA Benchmarking Benchmarked a variety of vendors IBM Websphere Process Server 6.0.1; IBM Advanced Websphere (Message Broker) 6.0.0 (on AIX 5.3) DataPower XS40 (HW appliance: XML Accelerator and SAML 2.0 Tokens) BEA Aqualogic 2.5 (on SUSE Linux) Oracle ESB Suite 10.1.3.1(on Windows 2003) Prototyped multi-vendor ESB interaction and cross-platform operations Enabled legacy C/C++ code with gsoap 2.7.NET and J2EE Interoperability Performance with large messages Security (Multi-Domain) Installed, configured, and benchmarked ESB products from major SOA vendors Slide 2
Prototype SOA Infrastructure Slide 3
Prototype SOA Infrastructure Constructed web services Test Harness to generate both sequential and concurrent service invocations Test Harness Client Service Proxy Service Endpoint ESB / Application Server Routing Service A Service B Service C What additional overhead does an ESB carry compared to direct service invocation? What are the performance limiting factors in using web services? Slide 4
Implementing a Ground SOA Comparison of Performance of ESB Products for Concurrent Requests Time in Seconds 8 7 6 5 4 3 2 1 0 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 Sample Number Direct IBM WebSphere IBM Advanced BEA Oracle 50 Concurrent Service Invocations All major ESB products handle concurrent requests relatively well some variability due to dynamic garbage collection Slide 5
Implementing a Ground SOA Comparison of Performance of ESB Products for Single Messages Seconds 35 30 25 20 15 10 5 0 0 200 400 600 800 1000 1200 1400 1600 Size in KB direct IBM advanced oracle WebSphere BEA ESB overhead shows small but increasing overhead as message size increases compared to direct service invocation Slide 6
Web Services Performance and Large Messages IBM Advanced ESB and DataPower tested with large messages 3MB (335 hrs Eph Data) response: 30 seconds 6MB (675 hrs Eph Data) response: 75 seconds 8.7MB (1080 hrs Eph Data) response: 125 seconds Time (Secs) 140 120 100 80 60 40 20 0 Performance (Msg Size) 3 6 8.7 0 2 4 6 8 10 Size (MB) Real Performance Bottleneck is in SOAP Processing for large messages XML Serialization in client + XML De-serialization in server CPU time and memory intensive Message Size/Complexity dependent Additional ESB overhead can handle these size messages But heap size and timeout must be increased Slide 7
Addressing Large Messages in Web Services Message Transfer Options SOAP Ordinary XML encoded payload document in SOAP envelope SOAP with Attachments (SwA( SwA) Compound Document Structure MIME Encoding (De-facto usage standard) of attachment information DIME Encoding (Direct Internet Message Encapsulation) largely obsolete MTOM (Message Transmission Optimization Mechanism, W3C), XOP (XML- binary Optimized Packaging, W3C) Relatively new standards Out-of of-band Transfer E.g., pass URI and use other transfer mechanism (FTP) Places burden of decoding message payload back to the application PREVIOUS DATA RESULTS Alternatives exist to mitigate performance bottlenecks of XML Serialization/Deserialization with large messages Slide 8
Web Services Performance Findings Additional Performance Considerations SOAP Encoding Styles RPC/Encoded (Worst Performance) o Deprecated and not WS-I compliant RPC/Literal (Middle) Document/Literal Wrapped (Best Performance) o Greater user control of parsing o Namespace element tagging allows complex datatype validation Performance Conclusions True performance bottlenecks due to XML Serialization and De-serialization of large messages mitigate mitigate via: Alternative transfer mechanisms (e.g. SwA) ) for XML payload messages > ~ 10 MB SOAP encoding style (Document/Literal) H/W appliance XML Accelerators ESB products add modest overhead which increases as message sizes grows Slide 9
Web Services and SOA Security Multi-Domain SOA Security Do not confuse Multi-Domain Security with Multi-Level Security (MLS) Multi-Level Security implies a single domain with electronic access by one or more individuals not briefed at all security levels (or compartments) for data within the system Typically requires DCID 6/3 PL-4 4 protection Multi-Domain Security implies there are multiple infrastructure domains, managed by different organizations, that may have different requirements and standards Data in each domain may in fact have same set of Classification Level(s), Compartments Key issue is trust: you must trust that your partner s s security implementation is reliable Slide 10
Web Services and SOA Security: Logical Architecture User 1 UID / Password Portal External Service Bus 2 3 DOMAIN A Identity Provider (LDAP, AD, etc) 5 WS-Trust Service 4 WS Gateway / XML Firewall 8 6 Identity Provider (LDAP, AD, etc) WS-Trust Service 7 WS Gateway / XML Firewall Internal Service Bus 9 Service DOMAIN B Slide 11
Web Services and SOA Security: Configuration 1 Service Client (Horizon) Windows Service Provider Windows 2003 LDAP Windows Websphere Product Server ESB Windows 2003 WSSM/Tivoli Access Manager AIX WS-Trust Windows DataPower XML Gateway Security Domain 1 Security Domain 2 CONFIGURATION 1 Complex and fragile architecture but acceptable performance Componentized architecture permits flexibility TFIM implementation of WS-Trust and WSSM is still maturing Enforcement via WS ESB is proprietary; no security on response SAML Token Exchange Across security domains Slide 12
Web Services and SOA Security: Configuration 2 Service Client (Horizon) Windows Service Provider Windows 2003 Websphere Product Server ESB Windows 2003 Tivoli Access Manager AIX DataPower XML Gateway Security Domain 1 Security Domain 2 CONFIGURATION 2 Simplified and easy to configure; very fast Can transform and route messages based on content & policy Can sign and encrypt responses XML gateway product is proprietary Transformations can only be written in XSLT (no custom adaptors) SAML Token Exchange Across security domains Slide 13
Performance Overhead Dynamic Routing & Security The two tests are identical (1-72 hours of Ephemeris Generation/Retrieval) Adding security (DataPower appliance, SAML 2.0 token generation, trust chain, etc.) and dynamic routing did not significantly degrade performance Runtime 16 14 12 10 8 6 Secure ESB with Systinet Registry Overhead Secured ESB Invocation Unsecured ESB Invocation 4 2 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 Sequential Eph Hours Adding security and dynamic routing to service invocation did not dramatically alter performance Slide 14
Summary and Conclusions SOAP/XML based web service performance is largely a factor of serialization and de-serialization of XML messages at mediation Size of response is the critical factor in performance analysis: large size (MB range) results in rapid performance degradation Alternative approaches for transferring large messages/files via web services required and available Impacts how you should structure your services Additional ESB overhead is small compared to message size effect ESB products handle consistent, moderate loads dramatically better er than sudden, heavy loads SOAP encoding style has an impact: prefer document/literal wrapped ped Practical message size is not changed with the addition of cross-domain security Additional network hops, but small data size exchanges in each A man has got to know his (COTS) limitations. Slide 15