This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
There are best-case and worst-case situations for just about everything, but as a general rule, RMI's virtues are the relatively small amount of work required to translate and transmit data between endpoints and the relative simplicity of the server. By comparison, you can do binary transmission using JMS as well, but JMS carries a lot of extra freight to support its extra features.
Customer surveys are for companies who didn't pay proper attention to begin with.
I had not heard of RMI since college in the class of distributed systems.
For sure SOAP web services are widely adopted and the wizards / frameworks / api have evolved to ease the development
(see minimal effort required with Spring JaxWsPortProxyFactoryBean and SimpleJaxWsServiceExporter).
I still remember the days when an expert in web services had to be required every time the term (ws) appeared
(ant tasks, lack of documentation, hard to configure security, ...) was a pain in the ass.
It seems that the RMI is alive and kicking under the hood of java2java distributed systems as Jini (Apache River) and improved from 1.5 jdk release
Carles Gasques wrote:I state that the development teams don't see ws as some obscure tool to use in the projects.
Like everything else in programming nowadays. Long time ago the programming was technically hard (punch cards, etc,), right now anyone can fire up an IDE and run a program with pushing only one button.
I mean ws became more automated, but if one need something sophisticated the expert is still required. Just look at the amount of WS-* specifications.
Joined: Apr 19, 2013
surlac surlacovich wrote:Long time ago the programming was technically hard (punch cards, etc,)
Well not so long since I've worked with a project manager who explained the anecdote how she once had thrown all the project source code (punched cards) to the face of the manager .
I have posted this on some previous areas, but on this topic I think it is fair to repeat it here ... its not a traditional solution that many Java types think of, but it is definitely worth looking at:
It is a standard based solution that standardized the APIs as well as the data format for marshaling the data. The marshaled data is binary which makes it extremely fast.
It can be used within the same box or across different boxes just by changing the configuration
It is a many-to-many publish-subscribe paradigm
It is scalable to many publishers and subscribers. Adding extra publishers allows a fail-over capability, adding extra subscribers allows for the data to be used differently by each subscriber. Multi-subscribers can be done in unicast or multicast for efficiency.
It can be configured for durability (i.e., store data to a DB)
It supports logging and playback which is great for regression testing
It can be configured to reliable deliver messages allowing asynchronous publish-subscribe
There are over a dozen vendors including open source providers that have demonstrated interoperability between themselves
It works on multiple hosts OSs (UNIX, Linux, Windows)
It works with numerous languages (Java, C/C++, C#, etc) so it can be used to connect differed codebases
There is a developing standard (i.e., summer of 2013) for support of RESTful interfaces
There is support for Microsoft Office including Excel, PowerPoint) which allows you to use the published data from within these products too
It is extremely fast and can support real-time solutions (i.e., 100,000+ messages a second)
You simply link in a .so or .dll to your code on each publisher and subscriber ... NO SERVERS REQUIRED
Joined: Apr 19, 2013
DDS seems worth to take a look.
PD: LoL it uses a subset of IDL! Back in the time :-)
Joined: May 18, 2013
Yes, DDS does use a subset of IDL. Recently, the OMG has made a non-CORBA, stand-alone version of the SPEC referred to as IDL 3.5. Work is underway to create a new version of IDL 4.0 which will be backward compatible with CORBA/IDL 3.5 but will allow the language to evolve new features that are not part of CORBA.
There is also a new Java API which is much more natural for Java programmers. It uses native Java collection instead of its own, which makes using the results in other Java paradigms easier.
Also note that IBM now offers a DDS product on WebSphere. This product abstracts some of the DDS complexity away by supporting JMS API and then providing a separate mechanism for mapping Quality of Service (QoS) to the topics. This allows IBM WebSphere to obtain the benefits of a standard for data marshaling and consequently, they can work with other DDS vendors allowing them to participate in the DDS interoperability demos that are done every March.
Another new aspect coming out of the OMG is a standard that allows for DDS topics (i.e., a name, a data structure, and a set of QoS parameters) in UML/SysML allowing architectures and design to be shared across companies (this also means you don't need to write any IDL ;-) ).
If you have any question, let me know.
We (the OMG) welcome everyone to participate in the standardization process.
Risking to be the dissonant voice, I just wanted to chime in here... As Tim already said, remote EJBs are using RMI, and EJB is hardly dead. I work with remote EJB's daily, and in my previous project using Websphere and its eXtreme Scale caching mechanism, pretty much everything under the hood was using RMI.
I don't understand people who claim SOAP is the way to go. If performance is one of your primary concerns, SOAP is quite probably the last option for internal network data transmission and caching.
If you have a reverse proxy taking care of security and your application has one or more Java dependencies, an RMI-based solution is generally the best way to go, even if you will rarely come into contact with the RMI interfaces yourself. Since RMI/IIOP, your client doesn't really even have to be a Java one.
So I don't understand most of the "reasons" given for the supposed "death" of RMI. JMS is about the same age, but is it dead? Absolutely not. Same for RMI. Most of the existing solutions allow you to use an interface on top of RMI so you don't have to do the dirty work yourself... But don't mistake that for it no longer being there. It's still there, and you probably use it more than you think.
kri shan wrote:We can use RMI over SSL for avoiding any attacks.
It's not possible to avoid attacks, you can at best prevent attacks from being successful. The best encryption means nothing if an attacker uses a DDoS to prevent access to the service (which may or may not be worse from your perspective).
Also, SSL prevents some classes of attacks from being successful, but certainly not all. And if recent events have taught us anything, it's that even SSL is limited in what it can protect against a determined attacker.