Keywords

1 Introduction

Machine translation (MT) systems are one of the scientific workflows which are extensively used by the researchers and industry; and they comprise of multiple components such as NER Engine, Lexical Transfer, Transliteration, etc. However, the existing systems follow a monolithic design that are not only static in nature but are difficult to debug.

We introduce a service-oriented architecture (SOA) for building scalable, distributed MT systems using composable distributed objects— microservices hosted in easily deployable containers. Our approach exposes components in these workflows through a simple API allowing the end users to easily construct and experiment with new systems. Our architecture builds on the approaches AnnoMarket [3], LetsMT! [5], and NLPCurator [8] by exposing microservices that not only allow access to intermediate results within a workflow, but also allow their modification. Moreover, our approach does not restrict microservices to a specific set of tools as they can be dynamically added at any point of time, during MT’s life-cycle. Besides this, our proposed is not only limited to MT workflows, but can be easily adopted to any generic workflow.

In this paper, we describe our architecture and demonstrate its application to existing MT pipelines for a certain set of Language Pairs from Sampark [1]Footnote 1.

2 System Design and Architecture

The existing MTs’ design are inspired from monolithic architecture that use well-factored, independent modules within a single application. However, these modules are tightly coupled to a code base [7] and in most cases, are not amenable for reuse. Further, it may not be possible to build new workflows using existing modules developed by different sources due to software dependency conflicts and incompatible interfaces between them. We take a service-oriented architecture (SOA) based micro-distributed approach (microservice [4]) that bundles multiple independent tasks that are easy to deploy, scale and test. For example, in our system, the Urdu POS Tagger is one such microservice. We thwart the problem of monolithic approach by encapsulating the modules inside containers, which run as microservices and interact via the RESTful API. These microservices can be deployed on a cluster of inter-connected machines either in a public or a private cloud. Resource allocation and load balancing can be done at the granularity of microservices leading to a truly scalable distributed architecture.

2.1 The RESTful API

REpresentational State Transfer (REST) is an architectural style inspired by the web. This architecture provides many implementation options [6] including HTTP which uses verbs to easily state and formulate microservices as resources. We expose a simple, yet powerful API to end users where, whatever the translation task, queries are represented as HTTP POST requests of the form:

figure a

For example, to get the output up to running the Shallow Parser in our Hindu-Urdu pipeline, the POST request is structured as http://$a/hin/urd/1/10. If additional parameters are required, we pass them as additional POST parameters. Information about available language pairs in the entire system is exposed at http://$a/langpairs. The number of modules for a particular language pair are accessible via a simple GET request to http://$a/$b/$c, and the sequence of modules is available at http://$a/$b/$c/modules. A simple GET request to http://$a/$b/$c/translate should suffice, if the user wants a translation without the knowledge of submodules. All responses by the serverFootnote 2 are in JSON format.

Fig. 1.
figure 1

An overview of the system architecture

Full size image

2.2 Architecture Walkthrough

Our system architecture comprises of containers. We deploy our system using Docker Swarm Footnote 3 with the help of a multi-host Overlay Footnote 4 network. Each node in this cluster is either a microservice, or a load balancer for multiple instances of a single microservice (Fig. 1). For example, for an MT system with X well defined, isolated modules, we use at least \(X+1\) containers in the setup. The additional container hosts the public API end point. This container also holds the information about the next set of pre-defined/default modules of that scientific workflow. But the system is flexible enough to allow user to override the sequence with the route /translate/graph. All other microservices are oblivious of their position in the workflow sequence. Inside each container, the developers can write the submodules in any programming language, which are glued together and exposed as a single microservice using an HTTP server created using a REST wrapper (we use the Mojolicious FrameworkFootnote 5). A generic, minimal working setup has been further explained at https://github.com/nehaljwani/ddag-sample.

3 The Client

We built a browser-based clientFootnote 6 for querying exposed pipeline components. After sending the input text to the tokenizer, the JavaScript callbacks asynchronously process each sentence in parallel. The client auto-detects the input language, maintains the ordering of input sentences, and provides two key features: direct editing of target translations using JQuery IME; and direct modification of intermediate pipeline outputs and resuming the pipeline which we call ResumeMTFootnote 7. This open sourceFootnote 8 client can be used for any language pair and is not necessarily limited to Indic Languages. The proposed APIFootnote 9 has also been integrated with Kathaa [2]Footnote 10, in a fashion where the Kathaa backend acts as a REST aggregator for all services, where, each node is processed independently.

4 Conclusion

We demonstrated an API with a browser based client as well as with a framework for creating workflows in NLP. Our approach is built on cloud-based services and an architecture that is not only easily deployable and distributed, but also resilient and composable for other NLP applications, and easier to maintain. In future, we will introduce a shared docker repository to host independent modules and a meta-language to automate the distributed setup based on a given configuration.