Dirt-simple D3 activation – and Web Services

I don’t know how many people know this but activating D3NT is a real breeze in v7.5.x because activations are provided transparently over the internet. Hmmm, this seems to dove-tail with the Web Services blogs.

1. Open the D3 License Activation utility.
2. Go to menu>File>Clear
3. Go to the Manual tab and enter your SystemID
4. Go to the Automatic tab and enter your email address
5. Click Activate

That’s it. A connection is made to a TigerLogic server, the proper data is retrieved, and your system is activated. If something goes wrong you can go back to the Manual tab, call TigerLogic on the phone, and manually enter the key(s) that they provide.

Technically this could be called a Web Service, but honestly it’s not. A Web Service is an interface to an application which is exposed to the public and/or trading partners. Web Services have a published definition against which developers write client code. Such a definition is also called an API (Application Program Interface), and for Web Services the API is published using WSDL. (I recently defined WSDL here.) In this case, I’m sure TigerLogic does not publish the definition, nor do they wish for anyone to use this service. So like most interfaces this particular one was created with a proprietary definition, the transport mechanisms are completely hidden, and TL can change anything they wish at their own discretion.

I happen to know that in D3 v7.5 TigerLogic embedded cURL into the D3 installation so that they can do activations like this. It’s in the NT platform as well as *nix. I have an action item open that requests more information about this, so that D3 developers can take advantage of this mechanism to implement similar functionality for themselves – where D3 is a client to other environments. I have written utilities that allow D3 to FTP out, Telnet out, and make other outbound connections, but I’m always relying on cURL or some other comms software already being available on the system – otherwise I have to ask the end-user to install it. If TL embeds cURL in D3 then we have a ready-made pipe to the outside world, and I think that’s worthy of some documentation.

Technically, again, in this case D3 is not a Web Services client. It’s the Activation utility, not D3, that’s making the call to the TL server. But in Linux and AIX I believe they are making a direct call.

The new Web Services product that I’ve discussed recently here in the blog allows MV DBMS apps to function as servers for inbound Web Services. In this case for activations, D3 functions as a client to an external server.

Some people may ask for the ability to call remote Web Services which return the results to their MV application. I’ve done that too, but rather than going directly from MV to the outside world, I prefer an indirect approach, similar to the D3NT activation. I’ve blogged on this topic before in my “MV to Anything” posting. I don’t go direct from MV out to the world, and I really prefer not to use MV platform-specific tools. I use a common pipe to get data out to a middle-tier, and then use common tools to do communications with the rest of the world. It’s sooo much easier to do it this way. I discussed this indirect approach in yet another recent blog. Some people might want the Web Services “server” product to be enhanced with “client” capabilities. No, the server will not become a client. That is separate functionality and I don’t want to make the offering confusing. If someone wants outbound WS calls to a remote server I can certainly provide that but it will have to be with custom development as a service engagement, or I’ll consider productizing something new.

So this blog posting has two purposes – first to tell D3 users how simple the activation is (or can be), and second to dove-tail the point with other recent discussions as an example of how Web Services can be used with Pick / MultiValue DBMS applications.