The Differences Between an XML Gateway and a Web Application Firewall

Jason Macy, CTO  

Forum Systems, Inc

Introduction

A common industry misconception is understanding the differences between an XML Gateway and a Web Application Firewall.   These technologies are sometimes confused as being competitive, but in fact they are complementary technologies that together provider the foundation of modern-day network perimeter security infrastructure.

Key Areas of Comparison

To better understand the distinctions between these product technologies, the primary areas of comparison are as follows:

Topology

• Deployment Modes

Protocols and Message Formats

• Standards
• Protocols

Security

• Threat Mitigation
• Transaction Privacy
• Transaction Integrity

Identity

• Access Control
• SSO

Transaction Processing and Mediation

• Workflow
• Transformation / Mapping

WAF Topology

WAF technology has several deployment modes, but it is an important distinction from a gateway product that over 50% of WAF deployments are in non-inline mode, also known as passive mode.   The modes of deployment are:

• Non-Inline Mode (50% of deployments)
• Transparent Proxy
• Layer 2 Bridge
• Reverse Proxy

XML Gateway Topology

XML Gateways are always deployed in a reverse-proxy configuration where the gateway component terminates the connection and provides the security, identity, governance, and mediation functions at TCP Layer 4-7.  The reverse-proxy deployment paradigm is necessary since XML Gateways serve as a protocol break intermediary for traffic flow and have the ability to restrict and block traffic flow as needed.  Thus, the mode of deployment for XML Gateway is always:

• Reverse Proxy
• Service Mode (Request/Response directly to Gateway, which performs the business function)

Protocols and Message Formats

A WAF product focuses on different set of protocols and message formats than an XML Gateway technology product.   This follows the logical expectation based on what types of systems and infrastructure these technology products focus on. 

A WAF focuses on the following technologies:

WAF Standards

• Web 2.0, HTML, XML, JSON, AJAX

WAF Protocols

• HTTP, HTTPS
• SSL / TLS

XML Gateway technology needs to have a much more comprehensive set of technology standards and formats it supports since it is an inline deployment which requires the need to bridge technology protocols and messaging standards in order to be the "gateway" conduit of message flow. 

XML Gateway Standards

• XHTML, XML, SOAP,  JSON, AS2, XML-Sec, WS-Sec, WSDL, XSD,
• ebXML, SAML, OAuth, WS-Federation, WS-Trust, XACML
• WS-Addressing, WS-RM, WS-Policy, Xpath, XSLT

XML Gateway Protocols

•     HTTP, HTTPS
•     SSL / TLS
•     JMS (IBM, Tibco, JBoss, Oracle, Active MQ)
•     AMQP
•     FTP/FTPS
•     SFTP
•     SMTP

Security
As WAF and XML Gateway products are both security products by trade, there are 3 primary areas of Security that these technology target.

1. Threat Mitigation
2. Transaction Privacy
3. Transaction Integrity

Security: Threat Mitigation
Threat mitigation is the ability to identify, detect, and re-mediate potential threat vectors in the traffic patterns.

A WAF product mostly focuses on HTML and HTTP based traffic paradigms whereby vendor specific static vulnerability patterns can be detected, as well as other aspects of request/response patterns pertaining to HTTP traffic flow.  The primary vectors for threat mitigation for WAF technology:

• HTML Content Aware
• Intrusion Detection and Prevention (URI patterns)
• URI rate-based heuristics
• Vendor Vulnerabilities
• URL cloaking / rewrite
• Parameter Inspection
• Learning mode (false positive / false negative behavior modeling)

  An XML Gateway performs deep-content inspection and parsing of the messages at the application layer of the message pattern.  Since an XML Gateway is a protocol-break intermediary, it consumes the message, inspects the contents, and then re-assembles for sending to the back-end service infrastructure.  This puts a much higher technology burden on XML Gateway technology to understand and be able to parse a much broader variety of protocols and message formats as well as ensure adherence to industry messaging standards and formats.

The primary vectors for threat mitigation for XML Gateway technology are:

• XML/SOAP/REST Content Aware
• Intrusion Detection and Prevention (parsing and deep-inspection)
• Rate-based, Size-Based heuristics
• Schema Validation
• Virus detection on XML/SOAP payloads
• URL cloaking / rewrite
• XML Parser Attacks

Security: Transaction Integrity
Threat integrity is the ability to ensure conformance can be verified and tampering has not occurred.

A WAF will target the transaction integrity as it pertains to cookies, jsp files, RFC conformance, and other aspects of HTTP and HTML request/response expectations.  The transaction integrity targets of a WAF are:

• Session Tracking
• Cookies, Source/Dest IPs
• HTTP RFC conformance
• HTML Form parameter checking
• Cross-Site Scripting
• Cookie Signing

An XML Gateway deals with more aspects of transaction integrity since it also has to be able to handle cryptography at the message level and be able to process and verify digital signatures and provide conformance checks across a broader spectrum of formats.

XML Gateway transaction integrity features include:

• XML-DSIG, OASIS WS-Security
• Signature Verification
• X509 Path Validation
• DTD Schema Validation
• XSD Schema Validation
• JSON Schema Validation
• HTTP RFC Conformance
• JMS Envelope and Message Conformance

Identity
Identity and Access Control are central requirements for any service-based architecture with consumers and services.  It is also essential for portals and other access to information that may be sensitive or controlled.  WAF technology generally does not deal with identity, but does have some lightweight features in this area. 

The core differences between a WAF and an XML Gateway in this area are broad.  A WAF does not have awareness of many of the identity token formats outside of traditional web and HTTP based formats.

WAF: Native Identity Integrations
    Active Directory, LDAP, RADIUS

WAF: Protocol Tokens
    Basic, Digest, Form Post, SSL X509, NTLM, Kerberos


XML Gateway technology conversely, is heavily dedicated to identity token consumption, generation, authentication, and authorization.  By necessity of the deployment and flow control paradigm of XML Gateway technology, the protocol break interception for security and mediation also becomes the logical point of centralizing the identity enforcement and single-sign on functionality.


XML Gateway: Identity Integrations
   Active Directory, LDAP, Siteminder, Tivoli AM, ClearTrust, Kerberos KDC, CoreID,
   JSAM, WS-Trust, XACML, OAuth

XML Gateway: Message-Based Tokens
     WS-Username, WS-Kerberos, WS-X509, SAML, DSIG

XML Gateway: Protocol Tokens
    Basic, Digest, Form Post,  Cookie, SSL     X509, REST URI, NTLM, Kerberos

XML Gateway: Credential Translation
    Message-to-Protocol, Protocol-to-Message

XML Gateway: SSO + Federation
    Sessions, SAML, STS


Processing, Mediation, and Workflow
An area of stark difference between an XML Gateway and a WAF is in the arena of mediation, transaction manipulation, and workflow routing.  This is again a primary difference due to the topology and deployment paradigms.  Deploying a WAF in passive mode (over 50% of deployments) does not have any ability to manipulate or alter the traffic data.   For the small percentage of WAF deployments that are in-line, the types of traffic that can be manipulated are effectively the HTML variants.

XML Gateway technology is designed specifically to consume the message, parse the message, apply mediation, enrichment, transformations, and finally determine the end-point target based on static or dynamic criteria.  Thus, the XML Gateway technology component is often used to perform a wide variety of business functions outside of pure security processing.

For WAF technology, when deployed in in-line mode, the processing and mediation that can be enforced focuses on the following areas:

WAF: Workflow Management

• Allow/Deny
• URL Rewrite
• Compression
• Content Replacement

For XML Gateway technology (always deployed in-line), the processing and mediation that can be enforced goes across a wide diversity of application payload formats and protocol variants across the following areas:

XML Gateway: Workflow Management

• Attribute Mapping
• Archiving
• Content-Based Routing                  
• Database Mapping
• Digital Signatures
• Header and Body Identification
• Identity Token Conversion
• Enrichment Data Aggregation
• Encryption
• Node Conversion and Encoding
• Transformation

Complimentary, not Competitive
A robust, resilient, secure architecture starts by ensuring the right technology components are in place.  WAF technology serves an essential role in the threat and access control side of web application traffic flows.  XML Gateway technology serves an essential role in the security, identity, governance, and mediation of business services, mobile devices, B2B flows, XML, SOAP, and REST messaging patterns with deep-content inspection and business-logic mediation.   A WAF and an XML Gateway are fundamental components of a secure, centralized architecture strategy.  These technology components focus on the TCP Layer 4-7 aspects of transaction, which comprise a much broader spectrum of the actual information flow across the corporate boundaries.

These components should be deployed where traditional Protocol Firewalls and IDS (Intrusion Detection Systems) are deployed, which provide the TCP Layer 2-3 protection.

Bottom line:
WAF + XML Gateway = Secure Architecture

Managed File Transfer belongs under SOA Governance umbrella.

Jack Vaughan's recent article covers an important emerging trend: convergence between SOA and MFT technologies. Managed File Transfer (MFT) is a baseline mechanism for information movement within and across corporations using legacy protocols such as FTP. However, with the emergence of modern SOA-related protocols, companies are now migrating away from less secure and less reliable MFT transport protocols. This trend is also driven by regulatory requirements including PCI, HIPPA, and GLB

Link to Jack's article: Updated XML gateway brings FTP under SOA Governance umbrella.

Excerpt from the article:

Despite SOAP and SOA inroads, the vaunted File Transfer Protocol (FTP) continues to flourish in organizations that - not surprisingly – need to transfer files. Finance and banking both represent FTP bastions – although both sectors are also on their way to becoming SOA strongholds of sorts.

Bringing FTP - originated in the 1970s - under the general umbrella of governance is an eventual goal for many of these companies. Forum Systems, a Crosscheck Networks' subsidiary, seeks to support such efforts with a recent update to the Forum Sentry Gateway.

The latest version of the gateway offers content-level security for structured and unstructured data for documents of unlimited size using the OpenPGP standard, while also enabling message transfers over a variety of secured and unsecured transport protocols. Moreover, the software allows organizations to plan migrations from batch FTP processing to SOAP with Attachments (SwA)(MIME, DIME, MTOM), while using existing centralized governance policies across both legacy and modern message formats.

Cisco ACE gateway EOL: How to Pick a Replacement XML Gateway

It's official:  Cisco has published End-of-Life announcements for it's Cisco ACE XML Gateway.  Here are the top factors that end customers must consider in making replacement decisions:

1. Select a Patented Product:  Going with non-patented XML Gateway means that customers will have to replace their XML Gateways in the future yet again.  Customers tend to select innovative and leading technology providers with defensible Intellectual Property (IP).  They prefer to minimize their risk by avoiding trailing "me-too" technologies that continue to copy the leading patented XML Gateways.
• Conclusion:  Ask for vendors patents.  Forum Sentry is the only XML Gateway Appliance with a published patent (Patent #7,516,333).
2. Understand XML Gateway vs. ESB:  Would you add custom code to your network packet firewall?  Then why would you ever consider adding custom code to your XML Gateway?  A clear separation of roles should be enforced between an XML Gateway and an ESB/Application Server.  When replacing Cisco ACE XML Gateway, focus on security.  Let the ESBs and Application Servers run your custom code.  If you choose an XML Gateway that allows you to drop jar files, shared objects or any arbitrary code into its runtime environment, then you have selected and XML Gateway with a flawed security model.  Such XML Gateway architectures can make you feel safe while compromising your corporate infrastructure, especially your sensitive data.
• Conclusion: Review vendors' XML Gateway architecture before replacing the Cisco ACE Gateway.  Don't make the same mistake twice.  Cisco's architecture permitted dropping code on the Gateway that resulted in a poor security model.  Other XML Gateway vendors have followed Cisco's XML Gateway architecture that permits adding custom code.  IBM DataPower and Forum Sentry are the only products that do not permit arbitrary code to be dropped into their XML Gateways and stay true to the XML Gateway roles.
3. Demand Independent Security Assessment:  XML Gateways are typically deployed close to the corporate boundary and serve as a centralized conduit for information exchange between corporations and their trading partners.  The nature, volume, and value of transactions flowing through the XML Gateway requires a high degree of security and reliability.
• Conclusion: Review vendors independent security assessment.  FIPS 140-2 is the gold standard for independent security assessment.  Demand certification details from vendors.  Sticking an HSM crypto card into a hardware appliance and claiming FIPS certification is not sufficient.  The ENTIRE XML Gateway, not just the HSM crypto card should be FIPS 104-2 certified.  For any other certification, ask for the "boundary" of certification.  Most vendors have never subjected their entire XML Gateway Appliance to an independent security evaluation.  Forum Sentry is the only product in the industry to have achieved FIP 140-2 security certification across the entire hardware boundary.
4. Validate Comparable Features:  Migration of your policies from the Cisco ACE Gateway to the replacement XML Gateway should be seamless.  The selected XML Gateway should be architected with modular policy design for fundamental constructs such as Keys, Encryption/Signature Policies, Firewall rules can be readily moved from the ACE Gateway to the selected replacement platform.  The selected gateway should have the same or better functionality than Cisco ACE Gateway.
• Conclusion: Selecting patented, industry-leading XML Gateway is paramount.  This ensures that there are no functional gaps between existing and replacement products.  XML Gateway companies that continue to innovate and patent their IP are more sustainable and provide broader features than vendors that follow the leaders.
5. Replacement Costs:  For corporations that have made a bet on technology that has been EOLed, there are a number of costs including: i) Product Cost ii) Configuration Cost iii) Transition Costs. iv) On-going support and maintenance costs.  Replacement vendors should have flexible pricing models to accommodate your corporate EOL plan.
• Conclusion: Select vendors that can work within your budget and time-lines. Vendors should be flexible in reducing your CapEX expense while working with your planned multi-year support and maintenance budgets. Depending on the complexity of your policies, vendors should be open to helping you with your migration costs.  For a duration, you may be required to run both Cisco ACE and your new XML Gateway together while you migrate away from the ACE Gateway.  Your selected XML Gateway vendor should provide pricing options to accommodate this transition process.

XML Gateways are essential components of corporate infrastructure.  Choosing the right vendor initially or for replacement should be a rigorous and methodical process based on key factors as listed above.  Without this rigor, corporations may to choose inferior technology that, in the future, will have to be replaced yet again.

Next Generation of patented XML Gateway - Forum Sentry v8.0 - announced in Berlin, Germany

New Capabilities for Company's Flagship XML Gateway Ease Enterprise-to-Cloud Migration; Enable Seamless Extension of SOA to the Cloud

BOSTON and BERLIN, Oct. 5 /PRNewswire/ -- Crosscheck Networks, Inc. today introduced the next generation of its flagship product, Forum Sentry v8.0, helping organizations seamlessly migrate their enterprise SOA deployments to the cloud while capitalizing on the cloud computing model for business and competitive advantage. The company unveiled the latest version of Forum Sentry at the International SOA & Cloud Symposium, the world's largest international SOA and cloud computing conference.

Notably, at the show today, Crosscheck Networks (Booth # 13) CEO Mamoon Yunus will explore enterprise-to-cloud migration in the session, "Requirements for Extending Enterprise SOA to Public Clouds." Additionally, company CTO Jason Macy will share best practices in SOA threat defense in "SOA Threat Modelling: Attacking and Defending REST, XML and SOAP based Services."

With patented XML security acceleration technology and an architecture certified by NIST and the U.S. Department of Defense, the Forum Sentry XML Gateway is the industry standard for XML and SOAP security, access control and integration. Deployment highlights include processing:

• More than one billion transactions per day globally;
• 95% of the world's credit card information; and
• 80% of the traffic at one of the world's largest and most respected telecommunications services companies.

Underscoring its increasing adoption worldwide, Forum Sentry serves as the transactional foundation at more than 300 global organizations including:

• One of world's premier treasuries, which leverages Forum Sentry to accommodate the increased volume, and processing, of large data files -- up to 10 GB each in size;
• Europe's top counter-terrorism organization, which utilizes Forum Sentry to coordinate rapid information sharing among its neighbor countries; and
• One of the U.S.'s longest-standing and largest health benefits companies, which uses Forum Sentry to promote secure exchange of its Electronic Health Records (EHR).

According to Lydia Leong, Research VP, Gartner, "Although many organizations first look at cloud IaaS [Infrastructure as a Service] because they're interested in cost savings, agility and flexibility, rather than cost, tend to be the eventual primary drivers; the cost of the cloud IaaS, especially in comparison to efficient large-enterprise IT, can be higher than IT managers expect."(1)

"As organizations scale their infrastructures to accommodate rapid business growth and increased customer demand, they are frequently looking to the public cloud to help them offset capital expense and operational costs. But without the appropriate tools, businesses are unable to determine the true costs of cloud migration," said Crosscheck Networks CEO Mamoon Yunus. "With our simulation tool, CloudPort, we enable enterprises and government entities to perform the requisite cost analysis, and evaluate and select a provider for migrating all or parts of their infrastructure to the cloud."

Yunus continued: "Once organizations determine that moving to the public cloud makes business and fiscal sense, Forum Sentry's next-generation platform empowers them to take the next step -- migrating to the cloud cost effectively while securely extending their SOA deployments for the most seamless enterprise-to-cloud integration."

Helping organizations to successfully leverage the cloud computing model, key new capabilities in Forum Sentry v8.0 include:

• Integrated Cloud Adaptors for dynamic provisioning, auto scaling and load balancing across multiple cloud providers including Amazon EC2, OpSource Cloud, GoGrid and Rackspace.
• A Centralized WSDL Library and Extended Virtualization Support via Virtual WSDL and WSDL Versioning for increased collaboration and control of business services across diverse application development, security and testing roles.
• A Robust Management API for enhanced policy life cycle management, and secure, versatile cloud configuration, deployment and administration.
• Oracle WebLogic and JBoss Enterprise Middleware Adaptors to bolster federated SOA deployments. This support builds on Crosscheck Networks', a Red Hat Ready Partner, announcement earlier this year that the company has joined the Red Hat Independent Software Vendors (ISV) Partner Program.
• REST Identity Adaptor for flexible integration with custom enterprise identity systems.

About Crosscheck Networks

Crosscheck Networks and its wholly owned subsidiary Forum Systems deliver solutions for deploying robust, resilient, secure and reliable Service Oriented Architecture (SOA). More than 50,000 users in 42 countries across organizations such as the U.S. Treasury, British Telecommunications, Fidelity, Premera Blue Cross and the Dutch Health Care System rely on Crosscheck Networks and Forum Systems as the backbone of their secure transaction processing. Recognized as a technology innovator and security leader, Crosscheck Networks is the only company granted a patent for its Forum Sentry XML Gateway and has been certified by NIST and the U.S. Department of Defense. Forum Sentry is the de facto standard for XML and SOAP security, and Forum Systems has key OEM relationships with Barracuda Networks and Radware, among others. For more information, please visit www.crosschecknet.com.
(1) Gartner, "Cloud Infrastructure as a Service: An Essential Overview" by Lydia Leong, September 8, 2010

Forum Systems latest XML Gateway targets SOA Federation

Looks like Forum Sentry, the pioneer and leader of XML Gateway and XML Firewall technology has announced its latest product that now addresses the growing need for handling not just XML/Web services traffic, but also HTML/Portal traffic. From a technology standpoint, this is not a revolutionary jump, but a gradual evolution of the XML Gateway that now handles HTTP/HTML-header information, which is by far easier than looking deeper into the XML packets. However, the business implication of this is significant since companies can now use a single platform for HTML and XML processing.

Continuing to set the benchmark for securing Web services, key new capabilities available via Forum Sentry include:

• HTML Portal Virtualization – Deployed in a “proxy” setting, Forum Sentry removes the identity and security burden from Web sites and portals. Leveraging Single Sign On (SSO) functionality across existing infrastructures, Forum Sentry’s non-intrusive, agentless design accelerates security and identity on a dedicated device – without requiring code changes to backend Web applications and services, or additional capital expenditure costs.
• Central Cookie and SAML Processing – Forum Sentry authenticates and authorizes both portal- and Web services-related identity tokens – the cornerstones of Federated SOA. Credentials are shared – regardless of where the services reside – throughout the entire transaction, producing an enhanced, seamless user experience without compromising security.
• Federated Two-Factor Authentication – Promoting greater security, Forum Sentry requires two pieces of information for identity verification of internal and external partners. It removes the complexities so often associated with token sharing across portals and Web services, while still enforcing the highest levels of authentication and authorization.
• Protocol/Document Attribute Mapping – Promoting greater ease of use, HTTP/HTML header information can be mapped into messages and documents. User information from HTTP can be transferred into a SOAP or XML message for usage elsewhere in the network – independent of protocol – enabling SOA Federation across both XML and HTML traffic.

For more details, see: Forum Systems Drives SOA Federation for Enterprises and Government Organizations

Frequent XML Gateway Uses

XML Gateways are becoming standard in enterprise SOA deployments with the following common themes:

1. Identity mediation is the first step for the majority of SOA Deployments. Identities come in may shapes and sizes represented at both the protocol level (e.g., HTTP Basic Auth, SSL Mutual Auth) and message level (WS-Security tokens X.509, SAML, etc.). Even if an enterprise successfully standardizes on a single identity representation, it cannot dictate how it's trading partners should represent its identities. Thus, inditites need to be accepted in many forms and changed to a single internal representation - that is if everyone within an organization can agree to a standardized representation. Most likely, even internally, more than one identity representation exists.
2. XML Firewalling is essential to ensure that information is checked before it makes it to the back end application server. The XML should be clean so that the backend server can safely process the message. Even more significant is the need to ensure that the SOA Gateway checks for information leaking from the corporation. This includes preventing sensitive information such as Credit Card Holder information from being compromised, as mandated by the PCI Security Standards Council.
3. Data Integrity and Privacy using content based signatures and encryption ensures that the message is not tampered with and that any part of the message can be encrypted granularly using standards such as WS-Security.

Other items such as Data Mediation, enrichment, transformation and archiving are also commonly enabled in a XML Gateway deployment.

Why is an XML Gateway a requirement?

The main two reasons to justify the capital expense of an XML Gateway are performance and security. When the enterprise deems those two reasons relevant it is a no-brainer to make the XML gateway a requirement.

Now let's take a simpler scenario where performance is not a problem and security is meant to be accomplished using SSL. I claim even in this scenario purchasing a dedicated server is a wise investment. Let's assume you intent to invoke web services from multiple partners. The number of partners could potentially be on the thousands. As is the case, currently most of this partners do not have any web services as of yet. So they start as usual writing it from scratch using something like .NET. These projects tend to be low key and usually prototypes, so the use of a gateway is not even considered.

Most scenarios, in addition to using SSL mutual auth to secure the connection and authenticate the client will use some sort of XML security such as signature verification. This will require the developer coding the business case to write the required code for the signature verification. This is no trivial task to get done correctly. Even with all the help the .NET framework gives you, there are many caveats the developer will have to be aware and most likely will not have time to properly code for. I see several problems with this approach:

• The security of the deployment solely relies on the time and expertise of the developer writing the security piece. In most cases, verifying the signature is just a small piece of the puzzle, quite irrelevant to the business case. It is a necessary evil that needs to be done, but does nothing for the bottom line of the company.
• Debugging the signature verification code is time consuming. Why bother re inventing the wheel when they are companies that specialize in doing this sort of thing?
• The private keys are most likely sitting on the hard disk not properly secured. Whenever a new web services comes online the procedure will have to be repeated. This model is not scalable and at the end not cost effective.

Such use cases can be readily handled with an XML Gateway fronting all the security aspects: SSL termination, signature verification or any other security requirement. The XML Gateway centralizes all security aspects so that your developers can concentrate on the business case at hand. You can rely that your web service is properly secured without having to trust the individual ability of each developer. After all, the gateway is backed by a company so their reputation is always on the line. Private keys and certificates are on a central secured location not spread around in web servers around your organization. The Gateways are kept up-to-date with the security standards, no need to go back to every one of your coded applications to update the security aspects of it. At the end, you will have save money and time for your company and ensured the Web Service deployment is secured.

XML Gateway Patent

Forum Systems, the pioneer in XML Gateways became the first network appliance to be issued a Patent for XML security functionality.  This issued patent 7,515,333 has a significant impact on the XML Gateway market landscape and locks Forum Systems position as the pioneer in the XML Security appliance marketplace with defensible protection for XML Security hardware related Intellectual Property.  Vendors in this space include:

1. Forum Systems
2. IBM Datapower
3. Cisco
4. Intel
5. Vordel
6. Layer7

For more details on this news click here.

XML Gateway: Best Practices, Requirements and deployment Strategies

XML Gateways are a great IT component for managing information flow between your enterprise and your trading partners.  They provide the required functionality, such as:

• Identity bridging (e.g., from HTTP Basic Auth to SAML)
• Transport mediation (e.g., between HTTP and MQ Series)
• Protocol and content based security (e.g., HTTPS, WS-Signatures, WS-Encryption)
• Message inspection (e.g., for SQL Injection, Viruses, and other malware)
  
• Interface Virtualization
• Transformation, Schema Validation

Such functions make is easy and cost effective for enterprises to integrate with their trading partners is a secure manner.  Here's a good article for best practices using XML-Gateways.

http://forumsys.com/resources/resources/whitepapers/Best_Practices_in_Deploying_SOA_Gateways.html

XML Gateways: Reducing the inherent Cost of Security

Dennis Sosnoski, Consultant and Trainer, Sosnoski Software Solutions, Inc. published an informative article titled: "Java Web Services: The high-cost of (WS-) Security." In the article Dennis compares performance profiles of different security configuration including SSL, username, signatures, encryption and sign-encryption. The tests are conducted using Axis2 version 1.5 with a Rampart code that provides content-level security.

The data clearly shows the overhead associated with security operations. Dennis later describes part of the reasons for the drop in performance is owed to the "Rampart handler implementation, which causes it to convert each request and response message to Document Object Model (DOM) form any time Rampart is engaged." This fact highlights one of the classic reasons for deploying XML Gateways (such as Forum Sentry): specialized commercial parsers designed for performance and security are better suited for security functions compared to java containers with general purpose parsers. Forum Sentry, as an example, has a ground-up parser designed for on-demand intelligent parsing of SOAP and XML messages without any redundant parsing. The security operations are deeply integrated with hardware cryptography. Based on almost a decade of customer installation, we have seen a 16-to-1 ratio between application servers and XML Gateway latency.

Dennis poignantly states:

"Another way of cutting the performance cost of WS-Security is to offload the security processing onto specialized hardware. Some XML gateway appliances provide accelerated processing of WS-Security encryption and signatures. You can use these appliances to handle the heavy-duty WS-Security processing while working with plain SOAP in your application. You obviously need to make sure you don't open any potential security holes in adding an appliance to your server. And you should test the performance gains from the appliance before you purchase. But at least in theory, this type of arrangement can offer some real performance gains."

XML Gateway - Load balancing Techniques

As an XML Gateway, Forum Sentry sits in front of your SOAP/XML/REST Web services protecting back-end services. For externally facing services (traffic comes in from outside your network), Sentry is responsible for handling all incoming XML traffic sent from your trading partner's client applications and destined for your services. Sentry processes these incoming requests and then sends them along to the back-end service (the remote server).

Often times the Forum Sentry gateway resides behind network load balancers which distribute the incoming requests among multiple Forum Sentry appliances. The load balancers ahead of Sentry allow for redundancy and increased throughput.  Forum Sentry,  also includes support for load balancing requests to multiple remote servers. The strategies are broken into two categories: Passive Load Balancing Strategies and Adaptive Load Balancing Strategies. Below is a quick summary of each.

Passive Load Balancing Strategies

Passive strategies choose a Remote policy without reference to the traffic passing through the system.

• Failover - Uses the order of the configured Remote policies in the group to signify priority. Always chooses the first Remote policy from the list of eligible Remote policies unless it is disabled or inaccessible, in which case it moves to the second, etc.
  
• Round Robin - Initially chooses an eligible Remote policy at random and then rotates through the list of eligible Remote policies in order, choosing the next eligible Remote policy for each new client request.
  
• Random - Chooses an eligible Remote policy at random for each new client request.
  
• Weighted Random - Chooses an eligible Remote policy at random for each new client
  request, using the relative weights configured for each Remote policy. The configured weights set the relative odds that each Remote policy will be selected if eligible.
  

Adaptive Load Balancing Strategies

Adaptive strategies gather statistics about current and past traffic passing through the system and choose a remote server based on the traffic patterns.

• Transfer Throughput - Chooses the highest performing eligible Remote policy. Performance is measured by the average transfer throughput of the last 100 requests, in bits per second.
  
• Active Requests - Chooses the eligible Remote policy which is the least busy, based on the number of concurrent requests the Remote policy is servicing.
  
• Response Time - Chooses the highest performing eligible Remote policy, measuring
  performance by the average response time of the last 100 requests. The Response Time strategy chooses the Remote policy with the lowest average response time.
  

XML Gateways, such as Forum Sentry are required to have sophisticated, flexible and dynamic load balancing capabilities within a corporate network.  Without such capabilities, scaling an XML/Web Services deployment becomes problematic.  A large number of non-XML, packet-based Load balancers are then used to work around the short comings of XML Gateways that lack sophisticated, content-based load balancing schemes.