Architectural Patterns for XML Gateways

What a week! I didn't get stuck anywhere - except for snowed in at home - but it was really busy. I did have the pleasure of ending the week briefing a group of really smart architects and pre-sales people on the Vordel Gateway.

When talking about the gateway, it is easy to get into the weeds of does it support this crypto accelerator or this version of the WS-SecureConversation spec, or this version of some 3rd party I&AM product. For this particular audience I was trying to get to the essence of how customers deploy this technology. Here's my architectural taxonomy for XML Gateways.

• Super PEP - The super/uber policy enforcement point. This is the way that XML Gateways are traditionally deployed. The idea here is that it can enforce any type of policy you can image - WS-Security, Authorization (XACML), SLA Policy, Routing Policy, XML Threat Policy... This is of course a very solid model for the gateway, and the way that most people think of it.
• Security Services Platform - There has been a lot of talk about reusable security services for a long time. It was how we originally sold WLES/ALES/OES. The Oracle Platform Security Services - OPSS - has picked up some of that same flavor - and the concept is a good one. Let's have a set of security services that can be called from a central location. There are standard interfaces like SAML, XACML, WS-Trust, SPML etc, but how do you actually go build that into an enterprise? XML Gateway to the rescue. I think of this model as turning the gateway on its "side". Basically, the gateway has the ability to expose these WSDLs, and it has integration with all of these 3rd party I+AM vendors like Oracle/Sun, CA, Tivoli, RSA - as well as various LDAPs - that constructing these services is very straight forward. The gateway today has the ability to be an WS-Trust end-point, CRL endpoint as well as exposing an XML Encryption/Decryption and XML Signing/Validation service. Its a simple exercise to extend this model to any API - standard or otherwise. Furthermore, since the Vordel XML Gateway has very fast XML and crypto processing, the services will perform and scale.
• Cloud Service Broker - This is like you take the XML Gateway and flip it around. Mark O'Neill talked about this convergence between XML Gateways and Cloud Services on his blog. I like the architectural symmetry. By flipping it over, you mediate access to services in the cloud. The Vordel XML Gateway is really good at protecting things like API keys - to avoid the issue of having everyone in the enterprise have unfettered access to the company's storage cloud. The distributed caching capabilities of the Gateway can help in cloud scenarios in two way. First of all, caching boosts performance - no need to go to the cloud to get that file, if the gateway has a recent cached copy. The second is that it can save firms money by optimizing calls to cloud services. In the storage example, this eliminates unnecessary GETs. In a transactional example, some provides give better rates for bulk operations, so the requests can be queued in the cache, and then sent en masse, again saving money.

These three architectures provide a simple way of summarizing the capabilities of the Vordel XML Gateway. Like any pattern, they can be used in conjunction with each other. For example, you could put the Super PEP in-front of the Security Services Platform or have the Security Services Platform call the Cloud Service Broker (off site authentication via cloud). As I continue to work with customers, and learn more about how they are using the gateway, I'll be sharing more of these patterns.