Some Performance and Security Findings Relative to a SOA ...


Published on

  • 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

Some Performance and Security Findings Relative to a SOA ...

  1. 1. Integrated Systems & Solutions Some Performance and Security Findings Relative to a SOA Ground Implementation March 28, 2007 John Hohwald Slide 1
  2. 2. Ground SOA Implementation Issues Integrated Systems & Solutions 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 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
  3. 3. Prototype SOA Infrastructure Integrated Systems & Solutions Slide 3
  4. 4. Prototype SOA Infrastructure Integrated Systems & Solutions Constructed web services Test Harness “Test Harness” to generate both Client Service Proxy sequential and concurrent service invocations 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
  5. 5. Implementing a Ground SOA Integrated Systems & Solutions Comparison of Performance of ESB Products for Concurrent Requests 8 7 Time in Seconds 6 Direct 5 IBM WebSphere 4 IBM Advanced 3 BEA 2 Oracle 1 0 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 Sample Number 50 Concurrent Service Invocations All major ESB products handle concurrent requests relatively well – some variability due to dynamic “garbage collection” Slide 5
  6. 6. Implementing a Ground SOA Integrated Systems & Solutions Comparison of Performance of ESB Products for Single Messages 35 30 direct 25 Seconds IBM advanced 20 oracle 15 WebSphere 10 BEA 5 0 0 200 400 600 800 1000 1200 1400 1600 Size in KB ESB overhead shows small but increasing overhead as message size increases – compared to direct service invocation Slide 6
  7. 7. Web Services Performance and Large Messages Integrated Systems & Solutions IBM Advanced ESB and DataPower tested with large messages 3MB (335 hrs Eph Data) response: Performance (Msg Size) − 30 seconds 140 6MB (675 hrs Eph Data) response: 120 8.7 75 seconds Time (Secs) − 100 80 6 8.7MB (1080 hrs Eph Data) response: 60 − 125 seconds 40 20 3 0 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
  8. 8. Addressing Large Messages in Web Services Integrated Systems & Solutions Message Transfer Options SOAP PREVIOUS DATA RESULTS − Ordinary XML encoded payload document in SOAP envelope SOAP with Attachments (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-Band Transfer − E.g., pass URI and use other transfer mechanism (FTP) − Places burden of decoding message payload back to the application Alternatives exist to mitigate performance bottlenecks of XML Serialization/De- serialization with large messages Slide 8
  9. 9. Web Services Performance Findings Integrated Systems & Solutions 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 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
  10. 10. Web Services and SOA Security Integrated Systems & Solutions 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 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 security implementation is reliable Slide 10
  11. 11. Web Services and SOA Security: Logical Architecture Integrated Systems & Solutions User 1 Portal UID / Password External Service Bus DOMAIN A 2 3 5 4 Identity Provider WS-Trust WS Gateway / (LDAP, AD, etc) Service XML Firewall 8 6 7 Identity Provider WS-Trust WS Gateway / (LDAP, AD, etc) Service XML Firewall DOMAIN B 9 Internal Service Bus Service Slide 11
  12. 12. Web Services and SOA Security: Configuration 1 Integrated Systems & Solutions Service Client Security Domain 1 (Horizon) Windows LDAP Windows WS-Trust Windows CONFIGURATION 1 DataPower XML Gateway Security Domain 2 WSSM/Tivoli Access Websphere Product Server Manager Service Provider ESB Windows 2003 AIX Windows 2003 Complex and fragile architecture but acceptable performance SAML Token Exchange Componentized architecture permits flexibility Across security TFIM implementation of WS-Trust and WSSM is still maturing domains Enforcement via WS ESB is proprietary; no security on response Slide 12
  13. 13. Web Services and SOA Security: Configuration 2 Integrated Systems & Solutions Service Client Security Domain 1 (Horizon) Windows CONFIGURATION 2 DataPower XML Gateway Tivoli Access Security Domain 2 Manager AIX Service Provider Websphere Product Server Windows 2003 ESB Windows 2003 Simplified and easy to configure; very fast SAML Token Exchange Can transform and route messages based on content & policy Across security Can sign and encrypt responses domains XML gateway product is proprietary Transformations can only be written in XSLT (no custom adaptors) Slide 13
  14. 14. Performance Overhead – Dynamic Routing & Security Integrated Systems & Solutions The two tests are identical Secure ESB with Systinet Registry Overhead (1-72 hours of Ephemeris Generation/Retrieval) 16 Adding security (DataPower 14 appliance, SAML 2.0 token 12 generation, trust chain, etc.) and dynamic routing did not 10 significantly degrade Runtime Secured ESB Invocation 8 Unsecured ESB Invocation performance 6 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
  15. 15. Summary and Conclusions Integrated Systems & Solutions 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 than sudden, heavy loads SOAP encoding style has an impact: prefer document/literal wrapped 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