Tuesday, February 14, 2012

Using Search and Replace with the Vordel Gateway

Recently I set up a simple Search and Replace policy using the Vordel Gateway. Here is how I configured this. For the purposes of this blog post, I'm replacing the text "Monday" with "Tuesday".

The string replacement is achieved in a small number of filters, and the main work (the actual search and replace) is done in the "String Replace" filter. Let's look at this in action:

Starting from the top, I am using a "Retrieve from Message" filter to read the whole message into a variable, which I'm calling "ReplacementExample". I am reading the entire message, using a "/" XPath Expression.





Next, here is where I am using the "String Replace" filter, to simply replace the text "Monday" with "Tuesday". You can see that if I wanted to use a Regular Expression for a more complex scenario, I could configure this here too.

Finally we see the policy in action. I'm using the free SOAPbox tool as the client. You can see that the day information in the message is automatically replaced by the "String Replace" filter.

Saturday, February 11, 2012

Recommended reading: Dan Geer

Anything Dan Geer writes is worth reading. His draft "People in the Loop: Are They a Failsafe or a Liability?" is no exception. Two standout parts, to whet your appetite to read the whole thing, are:

On healthcare privacy:
We installed at a major hospital. There, the Chief of Medicine
demanded that under no circumstances could our product block access
to patient data since who knows what sort of emergency might be in
progress. At the same time, the General Counsel demanded that under
no circumstances could our product permit a breach of regulatory
controls on data handling. The solution to this standoff was that
whenever someone asked for data that was nominally forbidden, a
popup window would appear which said "Against policy. Click here
to proceed." With that, no data was denied but at the same time
no person could deny having intent. This finesse represented the
well-placed insertion of a tiny bit of sentience in an otherwise
fully automated protection regime.

On cars:
...consider the manual transmission versus the automatic
transmission. To describe the manual transmission:

. feedback from engine and road to hand and brain
. can be push started
. get to neutral from any gear directly
. coast hills at no shifting risk (overrunning N -> R)
. solid, not fluid, coupler so no power loss there
. downshift braking including when brakes have faded
. simplicity, per se, including less required repair skill
. focus: one hand on wheel, one on stick, none on {burger,phone,dick}
. still operable if only clutch works but shifting is lost
. still operable if only shift works but clutch is lost
. manual transmissions weigh less
. non-sequential shifting possible
. know what gear you are in, including not having to look to see
. learn neutral thrust by learning to shift clutchless
. parking brake failure is of no concern
. ignorami can't steal your wheels

Now there is no one in this room with insufficient sentience to
gain the advantages I just listed. If you prefer the macro view,
consider that at the time of its construction, the total energy
output of the Trans-Alaska oil pipeline was approximately equal to
the efficiency loss due to the then prevalence of automatic
transmissions in the US auto fleet of the era.

Friday, February 10, 2012

Pro Tip: Kerberos Service and SPNEGO Token Authentication

Prasad Bopardikar from Oracle has written a very detailed and useful guide to Kerberos Service setup and SPNEGO token authentication. (SPNEGO is a way in which desktop apps like browsers authenticate to servers like IIS or Sharepoint). I definitely suggest you check it out if you need these capabilities setup in your organization.

Thursday, February 9, 2012

Free your data and the apps will follow

It's often said that in the cloud, apps really are just a conduit for data. It's all about the data. If you free up your data, exposing it to JSON and XML feeds, then this enables apps to consume that data. It enables a whole ecosystem of developers who will write apps based on it. But this imposes management and security concerns about how that data is exposed. I've written more about this over on ProgrammableWeb: Free your data and the apps will follow.

Wednesday, February 1, 2012

Pro Tip: Replicated caching across Vordel Application Gateways where TCP Multicast is blocked

Vordel Application Gateways support a replicated caching mechanism which enables features such as proactive request throttling. Multiple gateways replicate their cache across a cluster, with no single point of failure. By default this uses TCP Multicast, but what if TCP Multicast is blocked (as it is on Amazon EC2 for example)? In this case, there is another option, quite easy to setup. It's documented here: https://extranet.vordel.com/service/wp-content/uploads/2011/02/vordel-gateway-distributed-caching.pdf (email info@vordel.com to get an Extranet login). The specific details are:
"Alternatively, it is possible to configure a manual peer discovery mechanism, whereby each peer definitively lists the peers that it wants to communicate with. This should only really be used in networks where there are problems propagating multicast datagrams. To use a manual peer discovery mechanism, make sure the peerDiscovery setting is set to manual. The list of RMI URLs of the other peers in the group must also be specified, for example:
peerDiscovery=manual,rmiUrls=//server2:40001/sampleCache|//server3:40001/sampleCache|//server2:40001/sampleCache1|//server3:40001/sampleCache1"

https://extranet.vordel.com/service/wp-content/uploads/2011/02/vordel-gateway-distributed-caching.pdf

Edge of the Cloud

Steve Coplan from 451 Group tweeted today that "A 'cloud edge’ device could provide some ability to manage bidirectional flows between on-prem and off-prem infrastructure".

'Cloud Edge' is an excellent way to describe products which links on-premises infrastructure to cloud-based infrastructure. I'd add that as well as managing the data flows in each direction, it's also important to manage identity in either direction. One of the most exciting products to enable linkage of on-premises and off-premises infrastructure is VMware's Horizon App Manager. Chris Hoff from Juniper has written a really useful "Quick Ping" piece about HAM (yep, that's its acronym), explaining that:
What’s “new” with VMware’s Horizon App Manager is that we see the convergence and well-sorted integration of a service-driven federated identity capability that ties together enterprise “web” and “cloud” (*cough*)-based SaaS applications with multi-platform device mobility powered by the underpinnings of freshly-architected virtualization and cloud architecture. All delivered as a service (SaaS) by VMware for $30 per user/per year.
http://www.rationalsurvivability.com/blog/?p=3116
I've been using HAM a lot recently, and today I was setting up the Vordel Application Gateway as a Cloud Edge device with VMware's Horizon App Manager to provide single sign-on from HAM's SAML and OAuth based model into an on-premises behind-the-firewall app protected by enterprise identity management. From a user's point of view, they simply click on the app logo, and they are logged in. The user is not aware that the app is on-premises, while other apps they see (e.g. SalesForce) are cloud-based. In fact, the user should not be aware of where the app physically is located. All of this is exciting, and fits well with the vision of "Applications Anywhere" here at Vordel.

It is exciting to see all this convergence. Using a Cloud Edge device to link on-premises to the Cloud, to deploy apps "anywhere", seems like the future to me. Once users truly do not have to care where their apps are located, on-premises or in the Cloud, then we are beyond the Cloud era and into "applications anywhere". Cloud edge devices are what makes this possible.