Service prototyping is still a young topic when it comes to cloud services, web services or other network services. Researchers are concerned with defining the topic more accurately and finding out which metrics matter, for instance time, quality or cost. New definitions, methods and tools will result from this process.
In a previous blog post, we have discussed the process of automating service and API prototyping tools on the scripting level, ensuring that all commands to install dependencies and to configure the software are executed properly, in order and without omission. The tool in focus has been Ramses which turns RAML web service descriptions into executable prototypes. The focus of this post is to take this idea further to the SaaS and web application level. A convenient web application, accessible from every browser, should offer a guided prototypical service generation based on just the service interface description which specifies its resources, methods and data types.
We call this new class of tools transducers. This term may or may not make sense depending on how much philosophy is allowed into the research. To give a definition: A transducer is a (software) device which converts one representation of a service into another one. This definition is flexible enough to cover other methods such as representing the same executable service in two different hosting technologies.
The quantitative goal of transducer construction is the reduction of time and effort it takes to build a service which realises a new idea for functionality. In the figure below, the two axes represent time (t) and effort (e). A prior phase not shown in the diagram is needed for finding the right idea. In the first phase in the diagram, a service description then needs to be authored to capture the ideas. This usually requires a high cognitive investment for manual creation and still a high to moderate one when using tool support such as graphical API modellers. In the second phase, this description is turned into a service. This part should be completely automated, taking close to zero effort and likewise close to zero seconds of time.
We have implemented the first transducer based on the previous automation work. The focus is on speeding up the process, hence it is called Rapid Interface Transducer. As proper service offering, an online version is available, as is the source repository. The complexity of the transducer is made apparent by the software packages it uses (ramses, elasticsearch, sqlite, docker, python, virtualenv, flask, bootstrap, javascript) and the various browser interaction constraints (CORS, mixed content) which are counter-intuitive from a service-oriented perspective.
The sequence of interaction between the user, the web application, the web service and any tools behind is shown in the next figure. Step 1 is mandatory whereas step 2 is only required in certain cases and is skipped otherwise.
A first timing comparison estimation is reflected in the figure below (mind the logarithmic axis). Due to the high technological complexity of the used tools and frameworks, the original time needed to turn a web service description into a service easily exceeded the one-and-a-half hours available in a lab or in general in between other important work. Following the instructions of our blog post, this was reduced to about half an hour. Still, for quickly trying out a service idea, this may be too high. Finally, with the transducer, all it takes is copy-and-paste of the declarative files and pressing a few buttons, all of which fits comfortably into a single minute. Therefore, the transducer concept has significantly reduced the time needed to prototype a service.
(Note that following the notion of paper prototyping, the figures in this post have been made on actual paper and are not meant to be fully correct.)
Our online instance runs distributed across two providers. The frontend web application is hosted directly on Github and the backend service executes on Azure. For such a deployment, the configuration of the virtual machine, basic operating system and network security groups needs to be considered beyond what is documented in the README file and in the provided installation scripts. As there is a lack of portable cloud provider configurations, the following documents the actual setup on Azure as textual screenshot from the provider’s portal.
Priority | Name | Source | Destination | Service | Action 1000 | default-allow-ssh | 160.85.0.0/16 | Any | SSH (TCP/22) | Allow … 1010 | transducer | Any | Any | Custom (Any/5000) | Allow … 1020 | transducer-services | Any | Any | Custom (Any/10000-10200) | Allow …