Future-proofing your apps

Remember the Ziff socket? It was this nifty idea that when you bought a desktop computer containing such a socket, you could upgrade your CPU later by plugging in, uh, something to this socket, and you would be another few MHz more powerful. You wouldn’t have to keep buying new desktop boxes for years. Turns out, well, that didn’t work so well.

And do you remember the original promise of C? Write it once, and it’ll run on anything. You might have to recompile it on different platforms, but you wouldn’t have to rewrite it. And yeah, that didn’t work so well either.

Well, I think I’ve finally found my solution to keeping my apps usable, through myriad changes in my environment.

I deal a lot now with the Oracle API Gateway (OAG), an unfortunately-named thing (formerly called the Oracle Enterprise Gateway). It does a lot more than protect enterprise APIs. It’s sort of like calling your Lincoln Towncar an Adequate Trunk Space. But I digress.

Starting out as an XML gateway, OAG does very much more. Sure, it still inspects XML for bad payloads, but it can also handle many other protocols, checking for poisoned packages, evil documents, and other kinds of attacks. It can redact data in both directions. It can also enrich that data, adding values en route. It can perform intelligent routing.

OAG can be registered as a web agent for Siteminder, or an AccessGate for Oracle Access Manager, thus enforcing authentication and authorization policies that have already been created. Why reinvent the wheel?

OAG can also throttle traffic, to prevent DOS attacks as well as enforce SLAs for subscribers.

Here’s where I think the real value in this thing will be in the coming years: serving up and protecting enterprise APIs. So do the product managers at Oracle, which is why they slapped that name on it. If you want to make your web services available, but in the securest possible way, you can publish them through OAG in virtual form. Much like Oracle Virtual Directory lets you show to the world only the LDAP schema you wish, rather than the actual schema or database or web service (or combination of same) the data actually resides in on the back end., OAG provides the ability to expose only the plumbing you wish.

So again, just as you can map changes on the back end within OVD, you can map changes on the back end within OAG. If your web services now require an additional parameters specifying origin of request, you might have OAG fill in that parameter, provided it can identify that origin. Now those requesting clients don’t need to make any changes to how they make calls.

And here’s perhaps the biggest way OAG can protect you from having to change how you do things on the other side of the app server. It can modify protocols on the wire as well. A few very short years ago, we were all talking in SOAP as a common protocol. But with the explosion of mobile devices, the heavier SOAP has given way to the skinnier REST and JSON interfaces.  But wait, all my back end stuff still expects SOAP. Fine, so have OAG transform those REST or JSON calls to SOAP on the fly (after it’s checked for any possible badness, that is). Your web services get the same old request types, without the need to retrofit them to new models. In fact, because of the ability to transform messages, multiple clients might still come to you with multiple protocols, and you can translate all of them.

When somebody invents a new protocol that actually gets adopted (I’m currently working on JAML, or Jeff’s Asinine Markup Language), you simply have to fit OAG with a new filter that understands that protocol, so it can receive those calls, then return responses in that same language. The logic, the policies, the security, all remain in place.

Whether it comes by plane, by truck, by wife, by visiting relatives, beer still gets cold in my fridge. The protocol changes, but the back end remains the same. That’s my metaphor, and I’m sticking to it.