Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I need an interface to a back-end service, mostly for control commands (stop, status, cancel, reload config). The service might be in Python, Perl, Java, or whatever, and runs continuously. The interface will let me send infrequent commands to the running process.

A signal handler can tell a process to stop, and USR1 and USR2 signals let it do two more things. Tomcat sets up a special listener on a fixed port number to get it to shutdown, perhaps due to limitations of Java signal handling.

But I'd like it to respond, not just react. And I'd like to use this for a service written in any language on any platform. I'm hoping to avoid middleware or databases to communicate, since it's a simply request/response (Q: "how are you?" / A: "I have been running for 3 hours at peak efficiency").

I glanced at these but they seem like overkill for a simple control interface:

  • dBus - general interprocess message bus
  • UPnP - device communciation
  • Avahi - DNS queries to find services
  • Hadoop YARN - Distributes work across a network, parallel processing

Each seem compelling, but they feel heavy weight or else require special software to be installed ahead of time, or aren't for every language or every platform.

If I wrote my own, I could write a single-threaded TCP listener with JSON requests/responses. That seems about as lightweight and universal as you can get, and is small enough for a "hello world" service, and big enough for speaking to any service. JSON over TCP would be very command-line friendly (curl or netcat), and therefore easily scriptable. Lots of languages already have a JSON library (C++, Java, etc), in any platform.

A harder approach is adding HTTP semantics to the JSON request/response so you could browse to your application or use curl to control it. But embedding HTTP seems like a lot of space and complexity when it will only support a few resources (PUT text/plain "true" to /stop to shutdown your app, GET application/json from /status to see how it is running).

Frankly, I'm surprised nobody invented a standard service control interface for simple things like basic control commands. At work we used CORBA and registered in a naming service and then had to deal with Java/C++ ORB connection issues and it seemed like tons of code for something that should be simple.

share|improve this question

1 Answer 1

TR;DR: Consider Node.js with an app framework that serves JSON

Might seem daunting to learn something new, but I chatted with a 10-year Java programmer at a MeetUp last month, & he said it took him 2 days to learn Node from scratch & had a working test server that gave him JSON data his Java clients. He was amazed; he confessed in Java it would take him 1-2 weeks in Java to do the same. Some interesting tutorials & overviews:

(BTW; I am NOT trying to start a Node vs Java war; Java is very good. Simply passing along another idea from another Java programmer; pick what suits you.)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.