1

I created a command line interface on a small java application I created for personal use. For the moment the cli is resided in the same project as the original application but I'm planning to extract it into it's own project, effectively building 2 separate executable jars enabling me to start the cli as needed and query the other running program for information.

I'm trying to figure out the easiest and most lightweight solution to call a remote service, on the same machine. I looked at spring remoting but many of the provided solutions such as HttpInvoker, Hessian/Burlap, JAX RPC web services are based on HTTP or SOAP and therefore not suited for the job. JMS also seems like overkill.

This leaves me with RMI, which looks rather heavyweight, and possibly JMX? Suggestions?

nkr1pt
  • 4,691
  • 5
  • 35
  • 55
  • 1
    my question http://stackoverflow.com/questions/6121990/pass-string-as-params-from-one-java-app-to-another – mKorbel Oct 06 '11 at 13:37

3 Answers3

1

I'd say it depends very much on where the project/functionality is heading. JMX is easy enough to set up, and you can make use of existing clients/guis to query and set parameters - this may save you a lot of work. It may also allow you system to integrate with monitoring tools out there.

If, on the other hand, the functionality has little to do with managment/monitoring, and more along the lines of pumping data in and out, one option may be Apache MINA. I've used it in the past with great results. But you'll effectively be creating your own protocol ! I doubt that MINA will end up being "less heavyweight" than simple RMI though.

andypandy
  • 1,117
  • 7
  • 9
1

JMX would use RMI underneath for remote access. JMX is meant for exposing admin apis (monitoring / management) - not intended as a general purpose remoting api.

RMI with the spring remoting support is fairly lightweight from a development point of view. Even runtime it is the option that adds least overhead compared to the other options you have listed.

Also with spring remoting support you can easily switch over to a different option if required later.

Take a look at this artcile, that compares / benchmarks performance of the above options.

gkamal
  • 20,777
  • 4
  • 60
  • 57
  • I'll use RMI then. 1 of the main reasosn I wanted to avoid RMI was because I remembered from some years ago that you needed an extra compilation step with rmic with stubs and skeletons, but it seems that as of the J2SE 5.0 release, stub classes for remote objects no longer need to be pregenerated using the rmic stub compiler, unless the remote object needs to support clients running in pre-5.0 VMs. Thats a big plus – nkr1pt Oct 06 '11 at 14:01
0

In an app for personal use, I'd go with JMX because it should be the path of least resistance. I've had great experiences with this in the past. You'll be able to get it up and running in minutes, and you won't have to think about what message format to move data in (as long as your beans are Serializable, that is).

Put an interface in front of the remote call, so that later you can drop in another implementation later if JMX turns out to be inadequate.

jtoberon
  • 8,706
  • 1
  • 35
  • 48