Friday, July 31, 2009

Qualifying your XML Gateway Horsepower

Often in our tech industry there is a penchant to spout off performance numbers without qualifying the metrics and conditions under which these numbers are derived. The XML Gateway community is not immune to this indulgence. I have to admit, even I am guilty of committing this sin sometimes.

In the XML Gateway world, performance cannot simply be defined in terms of transactions per second (TPS) due to complexity of a message transaction and the task policy of the gateway. As a result, XML Gateways today always specify a specific task (i.e XML transformation, WS-Encryption) and the associated TPS. However, this type of metric still falls short of fully expressing the true performance metric of a SOA Gateway. For example, a common task that is staple of every XML Gateway is schema validation. This task validates the the structure of incoming and outgoing SOAP/XML messages. The performance of a XML Gateway when performing validation is often expressed in terms of Schema Validation TPS.
This is simply not sufficient. Further qualifiers that should be applied to schema validation performance numbers are as follows:

  • What is the size of the message?
  • What transport protocol (HTTP 1.0, HTTP 1.1, MQ etc) was used to derive the numbers?
  • Was the deployment in proxy mode or was it in service mode?
  • How many clients were used in generation of load?
  • Was the validation task performed on both inbound and out bond messages?
  • How complex was the message structure and its associated schema (i.e n-dimensional arrays, abstract types).

The last bullet is a real challenge and it really affects the validation performance of a gateway.
Unless, these qualifiers are resolved, the numbers are subjective at best. Maybe one day we will learn some lessons from the automotive industry to really define a true metric in defining performance of each task in a XML Gateway.

Monday, July 20, 2009

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.

Monday, July 13, 2009

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.

Thursday, July 9, 2009

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.

Wednesday, July 8, 2009

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.

Tuesday, July 7, 2009

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."

Wednesday, July 1, 2009

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.