Tag Archives: standards

Using URI Templates on XML Security Gateways

Earlier this fall, Anil John put out the following Twitter challenge:

“@Vordel, @layer7, @IBM_DataPower If you support REST, implement support for URI templates in XML Security Gateways”

Somebody brought Anil’s tweet to our attention this week, and Jay Thorne, who leads our tactical group, put together a nice example of just how to do this using SecureSpan Gateways.

URI templates are a simple idea to formalize variable expansion inside URI prototypes. A receiving system can then trivially parse out substituted components of the URI and use these as input. There’s an IETF submission here that describes the approach. It turns out that it was co-authored by my old friend and ex-IBM colleague Dave Orchard. Another co-author is Mark Nottingham, who I worked with at the WS-I. I guess I should have looked into this earlier. Sorry guys.

Here’s a real example of how URI templates work. Let’s begin with the template:


The braces represent variables for run time substitution. Suppose these variables equaled:


The result of the substitution would then be:


Which is pretty easy to parse up and process by a web application residing at http://somesite/Template

URI templates are also very easy to process on a SecureSpan Gateway. Here’s a policy that demonstrates how to access the variables in the URI. Basically, all this policy does is parse up the URI, audit the results, and echo the content back to the sender:

I’ll bind this policy to a particular URI range on my SecureSpan gateway virtual instance. This happens to be running with an HTTP listener on port 8080 on my Macbook Pro:

Now let’s walk through the policy in detail. The first assertion uses a regular expression to parse the URI.:

It places the content of the expansion variables Noun, Verb, Object into Vars[1] , Vars[2] and Vars[3] respectively. The next two assertions in the policy simply audit the resulting variables into the SSG audit subsystem; this can sink to cluster storage, or go off box. Finally, the policy populates a template XML document with the contents of the variables and echos this back to the original sender:

When I fire up my browser and hit the REST service http://scottssg:8080/Template/Dog/bites/man I get:

Obviously in a real policy, you would do something more interesting than just echoing parameters, such as route the message to a particular internal host based on template content. And you can certainly compose outgoing URIs using existing variable substitution capability in SecureSpan. The take away is this is very simple to implement, and I think that it highlights that here at Layer 7, we think that supporting RESTful services is just as important as supporting SOAP.

NIST Perspective on Cloud Computing

Earlier this month, NIST went public with their perspective on cloud computing. This is important because NIST is a well-respected, public standards organization, and there is still a lot of confusion about what cloud really is (the *-aaS affect).

They released only  a short, two page document and a longer, 72 slide PowerPoint (you can find their main page here). They are offering a broad definition based on essential characteristics, delivery models, and deployment models:

Essential Characteristics:

On-demand self-service

Ubiquitous network access

Location independent resource pooling

Rapid elasticity

Measured Service

Delivery Models:

Cloud Software as a Service (SaaS)

Cloud Platform as a Service (PaaS)

Cloud Infrastructure as a Service (IaaS)

Deployment Models:

Private cloud

Community cloud

Public cloud

Hybrid cloud

There’s not really anything new here, but that’s fine; it’s more important as a validation of the emerging models and ideas from a public standards body. I do like the three pronged approach, acknowleding that cloud is a lot of things but at the same time keeping it simple and concise. Brevity is the soul of great standards.

It’s worth keeping an eye on this effort.