Energize Web Services with Redaction Action

Web Services, those discreet re-usable pieces of code we find everywhere nowadays, are becoming even more ubiquitous within Information Technology Departments for a very good reason, Because they work. Also, in theory, they go a long way towards reducing application development costs. The challenge that Web Services has is that they aren’t very intelligent. Let me provide you with a quick example that will illustrate the problem.

Let’s say that you’re an information service provider and your customers access information through a Web Service that you’ve built. It’s a pretty straightforward process: build the web service, make it available, (validate identities and access – I won’t get into that right now) and let the good times roll. The challenge begins when you want to add intelligence to your Web service. For example, if the customer is a Platinum Subscriber then make all of this information available. However, if they are buying a single report without an Annual Subscription, then you want to only make section 1 & 3 available. Without intelligence, you quickly realize that every possible permutation will lead to the need for a new/modified web service. The inevitable proliferation of web services will become a challenge to keep track of and a nightmare to manage the difficulty of applying code revisions or updates to each web service.

Wouldn’t it be more efficient if you could just build a single web service and simply apply rules that would remove or redact information that fell outside of the rules. Come to think of it, that almost sounds like the kind of capability you would find in some government conspiracy spy novel. Well, as is usually the case, the truth is stranger than fiction; if you place a Gateway in front of a Web Service you can do exactly that. A Gateway is really a high performance Input/Output device that gives you ability to apply rules to network traffic going into and out of the Gateway. Given its capabilities, you can apply everything from simple to sophisticated rules to redact information based upon whatever criteria you define. It’s a very simple and elegant way to solve a vexing problem, and a Gateway will energize your web services without a whole lot of effort.

Reprinted with permisson from blog Demystifyit.com




Application Gateway Buyer’s Guide

What to look for when buying an Application/ XML / SOA Gateway.
This comprehensive Buyer’s Guide  provides you with hype-free information to help you evaluate an application gateway (also known as XML gateway, SOA application gateway, and SOA appliance). This guide assesses important technology, product, deployment, and cost considerations that may not be obvious to buyers of application gateways. The Guide does not contain any Vordel product information.

To view this document please






Extending the Gateway using Maven

From Blog xmlgateway.blogspot.com

One of the strengths of the Vordel XML Gateway is the ability of the product to be extended using Java. You can do this in two ways: JavaScript and through writing custom Filters. The really clever part about how the XML Gateway is engineered is that the underlying XML layers are written in native code so the product is really fast even when you have to use Java to customize it
Recently, I had a customer ask “How do I build filters using Maven?”. This is obviously a person after my own heart. I had spent a lot of time last year working with Maven, in particular for the OES/Spring/JBOSS/AOP integration I did. So, these are the steps for building the Example Filter using Maven.

Continue reading