1

I have 2 processes that need to communicate over the same PC and different PCs. In the local case the process communication is among different processes e.g Process A and Process B.
In the remote case it will be among 2 instances of Process A running in different PCs.
I will create them from scratch and I am wondering what is the best approach. I am aware of RMI and sockets but I was wondering for my case as described, and taking also into account that the messages exchanged are small and the number of APIs really small, if there is a standard approach/library for this.
Any suggesstions are highly welcome

Update after @EJP comments:
My interest is 1)to implement the requirement for communication in a light manner since the API exposed will be really small and the messages as well 2)use and learn a new popular framework if possible (I already know RMI and sockets)

Jim
  • 18,826
  • 34
  • 135
  • 254
  • Given that your number of APIs is small it's hard to see why you would need to look any further than RMI, especially as you haven't actually provided a motivation. – user207421 Jan 11 '13 at 07:37
  • @EJP:I thought that since this is a new project it would be nice if there was some new library I could learn if it fits.For example I have heard of JMS but never used it and I don't know if it is in my scope.That is why I asked – Jim Jan 11 '13 at 07:41
  • Well you need to define your scope, don't you? JMS isn't an IPC mechanism for example, it is a messaging interface. – user207421 Jan 11 '13 at 07:50
  • @EJP:Ok!Updated OP.Hopefully now it is more clear – Jim Jan 11 '13 at 07:56
  • Take a look at Apache Camel – kaos Jan 11 '13 at 09:43

5 Answers5

4

If you are just looking for messaging frameworks, there's a bunch available out such as

But when you use a 3rd party framework, you are then adding an additional dependency to your application. If it is something very simple like your case, perhaps writing a TCP client/server would be sufficient for a client/server paradigm or if you are looking for publisher/subscriber paradigm then you can look into using UDP multicast. You just need your data class to extends Serializable if you want to be able to marshal and unmarshal your data to buffer and send it over to network using typical JAVA socket API.

beyonddc
  • 1,246
  • 3
  • 13
  • 26
2

I strongly suggest having a look at Thrift. From all the technologies I've used (web services, RMI, XML-RPC, Corba comes to mind) it is currently my favourite. Essentially the steps involved are:

  1. Download the Thrift compiler.
  2. Add the Maven dependency (make sure it is the same version as the compiler!) I currently use 0.8.0.
  3. Write your Thrift IDL (incredibly easy, google for it as there are plenty of examples).
  4. Compile it for Java.
  5. Writer your server/client.

In general, you can whip together a server and a client in about 30 lines of code. In terms of speed and reliability it has never failed me before.

Jaco Van Niekerk
  • 4,180
  • 2
  • 21
  • 48
  • Why would this be faster/better in relation to sockets or RMI? – Jim Jan 11 '13 at 07:33
  • Hi Jim, it's not necessary faster; but it is definitely not slow (it's definitely faster than XML-RPC since it is a binary protocol). I preferred it to RMI because it supports backwards compatibility better, the protocol choices and scalability. I found this which may help you choose: http://jnb.ociweb.com/jnb/jnbJun2009.html – Jaco Van Niekerk Jan 11 '13 at 07:40
0

JMX is a good alternative .

Example :

http://www.javalobby.org/java/forums/t49130.html

IMB JMX Example

http://alvinalexander.com/blog/post/java/source-code-java-jmx-hello-world-application

BenMorel
  • 34,448
  • 50
  • 182
  • 322
SANN3
  • 9,459
  • 6
  • 61
  • 97
  • 1
    JMX is just a reflective layer over RMI. Given that his number of APIs is very small it's hard to see why you would recommend JMX instead. – user207421 Jan 11 '13 at 07:36
  • RMI is also very easy to implement: easier than JMX, IMHO; and it also has no need for third party APIs. These are not valid reasons for your recommendation. – user207421 Jan 11 '13 at 07:47
  • Here the comparsion why JMX http://stackoverflow.com/questions/5100793/difference-between-jmx-and-rmi – SANN3 Jan 11 '13 at 07:56
  • 1
    @EJP:Isn't RMI considered nowadays "deprecated"/old-fashioned? – Jim Jan 11 '13 at 10:04
  • @Jim No it certainly is not. It is the foundation of J2EE, for a start. – user207421 Jan 11 '13 at 22:47
  • @EJP: Please do explain how RMI is the foundation of J2EE? I find this statement a bit strange..... – rjdamore Jan 22 '16 at 20:25
0

You might have a look at Versile Java (full disclosure: I am one of the developers), it satisfies at least your criteria #1. From the API documentation, here are some examples of writing remote-enabled objects, running a service, and connecting to a service.

Versile
  • 308
  • 1
  • 4
  • 1)Is this on top of RMI?2)How big is your library in size? Do you have any dependencies? – Jim Jan 11 '13 at 10:12
  • 1) It does not use Java RMI; it implements another documented standard 'Versile Platform', 2) current JAR is 911k (downloadable from web site, AGPL license), 3) no dependencies – Versile Jan 11 '13 at 10:39
0

If you want to learn something new then I'd look at OpenSplice. The reason is pretty simple, among the technologies suggested above is the only one that provides you with Data-Centric abstractions.

The cool thing about OpenSplice is that gives you the abstraction of a Global Data Space, yet the implementation of this global data space is fully distributed and very high performance.

Take a look at some of the slides available at http://www.slideshare.net/angelo.corsaro and I am sure you'll get in love with the technology.

Finally OpenSplice is Open Source.

Happy Hacking.

A+

kydos
  • 71
  • 4