Other Things They Didn’t Teach Me in School: Pseudo-Conversational Programming
I spent three months studying COBOL, wrote eight challenging batch programs, and then took my first assignment, which involved writing online transactions that I learned nothing about before taking the assignment. Since I had no training in real-time programming (i.e., online transaction processing (OLTP) applications, I needed some tutoring by the analyst assigned to be my mentor. Although he never called it pseudo-conversational that is a good label for the constraints I was asked to operate within. Let me explain.
Pseudo-Conversations
The idea of pseudo-conversational programming is this: when the user is looking at an input device even if entering data, there’s no program holding resources waiting for the input from the user.
This seems odd—if no program is waiting to receive the data then how is it processed? The answer is simple—the programmer has returned control to the system including memory, processors and exclusive holds on resources—almost everything to the transaction-processing monitor that’s in control. The programmer has also told the system where to “pick up” when the user’s device generates an interrupt. The where to pick up part can involve some artful techniques on the part of the programmer.
Sure, it’s more programming to do things this way, but it’s worth it in the massive number of transactions that are possible in a day of processing using this method. Time hasn’t changed much because, even though processors are faster than ever before and memory models are expansive, transactions rates seem to easily fill the gap with even greater volumes. And of course, new workloads come along to consume available resources. When I first read about RESTful web services, I saw a number of characteristics that reminded me of pseudo-conversational programming. Let me explain.
RESTful Web Services
The idea of RESTful web services is this: use RESTful web services when building applications in the web. This is the main context for REST but it can also be used for internal company applications that use web technologies behind a firewall. Sounds a bit like OLTP (just using web technologies)?
There are other uses as well: wherever there is a context where you can make use of the conventions like Uniform Resource Identifiers (URI) and the robust web methods like HTTP. RESTful web services require the use of hypertext, which scales very well since the client and server are very loosely coupled. With RESTful web services, the server is permitted to change the exposed resources at the request of the client. The client needs only to know the initial URI, and subsequently choose from server-supplied choices to direct or perform actions. Additionally, a server may download code to the client, which aids in navigation and state representation.
There’s so much flexibility and existing functionality that can be exploited by using RESTful web services. It’s standard to use well-defined URIs that “represents” some kind of resource, such as “posts” on a blog representing the blog posts. With REST, you use HTTP methods with its verbs to perform actions on that resource like GET for read operations and POST for writes. Finally, the ability to access multiple format representations of the same data (e.g., a JSON and an XML) representation of a blog post, can be very useful.
All that is required is an application need that can be satisfied using a web context. REST will serve you well and provide significant programming support through the use of web standards and related open web tools.
Next Week
Next week, I want to explore something else they didn’t teach me in school—using a careful and complete process to automate the start up, shutdown and recovery of an entire software system.