REST, JSON, And DB2 – Some Initial Thoughts

(Originally posted 2018-01-30.)

I was fortunate enough to spend last week in IBM’s Silicon Valley Lab (SVL), both in formal sessions and talking to developers.

One topic – which isn’t really all that new – is DB2’s REST support, which is pretty comprehensive and good.

The basic idea with this support is you can call DB2 via a URI¹, with a JSON payload, and get JSON back. It’s possible that only one acronym means anything to you in that past sentence. The one that really might need explaining is “JSON”.

JSON stands for “JavaScript Object Notation”. (As with so many acronyms it’s malformed and should really be “JON”. Just to make all those Jons out there feel special.) 🙂

REST stands for “Representational State Transfer”, another malformed acronym. So it goes. 🙂

This is where having played with JavaScript comes in handy. If you were assigning an object in JavaScript you might do it with syntax like

var a = { "x" : 1,
          "y" : 2 };

There’s nothing mysterious about this: Parameter x has value 1 and y has value 2.

The JSON representation is just

{ "x" : 1,
  "y" : 2 };

Anyway this isn’t really the point of this post, but it gives you some idea of what you can pass into DB2 via REST, using standard HTTP methods such as GET, POST and PUT. (Making “HTTP” a live link to the Wikipedia article wasn’t really gratuitous as it contains descriptions of these methods.)

I’m more interested in how it shows up in DB2, and particularly in the instrumentation.

So what follows are a couple of topics I discussed while in SVL. But first something I should mention. Otherwise the rest² won’t make much sense.

REST Support Sits Atop DDF

It’s best to think of REST as a special kind of DDF work, with all the usual attributes. So it runs under an enclave in the DIST address space. And now we’re on familiar ground:

• We have the WLM controls we expect.
• We have the instrumentation – SMF 30 and SMF 101 – we need.

Two Topics

So let’s dive into the two topics.

Service Names

When a service is invoked it is invoked by an externalised name. It’s a two-part name: Collection Name and Service Name. Unsurprising, but I want to confirm it to you, Collection Name maps onto Package Collection Name and Service Name maps onto Package Name.

These appear in the SMF 101 IFCID 239 Package Accounting record. So you can spot the use of specific services in Accounting Trace. And you can tell where the requests came from. Of course, you might want to identify “high CPU” services, and all that jazz.

Some time ago DB2 added support for 128-character Package Names which, of course, broke my code. At the time it might not have seemed all that significant but can you imagine being constrained to having 18-character REST Service Names? Of course the format of the IFCID 239 record was enhanced to handle this³. So you can see the long names.

CPU

JSON can get quite complex, with the example I gave above being about the simplest one you can get. More realistic JSON is a non-trivial tree structure. So parsing it might be non-trivial, or so I feared.

Unlike System XML, there is no “System JSON”. Furthermore JSON parsing isn’t necessarily zIIP-eligible, precisely because of that.

So, if parsing JSON could be complex, isn’t that going to be expensive?

So I spent a nice hour and a half talking “of cabbages and kings⁴ and REST and DDF” with my favourite DDF developer.

The important point is this: The JSON parsing happens entirely on the Enclave.⁵

Two things flow from this:

• Keeping DIST up with DBM1 and MSTR is not a threat as the Enclave work should be classified lower.
• Because the work is on the Enclave I’d expect it to have the same eligibility for zIIP as other DDF work.

There is one element of REST work that is at the DIST address space’s dispatching priority: reading in the JSON. Imagine a video 64-Bit Encoded. In principle that’s perfectly valid in JSON. It could be gigabytes of payload and quite expensive to read in.

We discussed measuring this – to see if it’s an issue. The best way to do it is to subtract the Enclave CPU Time from the Total CPU Time – in the SMF 30 Interval record for the relevant DIST address spaces. Without REST I see this number as small – in all the customers I’ve ever looked at. But if it’s large it’s worth thinking about.

These Are Early Days

I’ve not seen any real data from a “REST into DB2” situation yet – and I’d love to. But I’m pretty sure some of the above will help me (and should help you) understand it and its effects. Certainly I have code that will do a decent job of analysing both SMF 30 and SMF 101 IFCID 239.

I’ve seen quite a lot of material on this topic, but it really helps if you already understand things like REST, JSON and JavaScript. (At first I wrote “terms” instead of “things” but I think it needs to go deeper than just being familiar with the terms.) I got my understanding of these by messing with lots of web-related technologies – for fun and profit – quite a while ago.

It’s early days for this technology – but already I like how DB2 supports REST. More when I get it.

And sorry folks for the, ahem, “brevity” but I was trapped on yet another long flight with only you for company… 🙂