The primary reason for making the move to Ice was the cross-language support, though there were some general usability issues with JBoss remoting. While using RMI for Java-to-Java communication in production, we tried using
Hessian as well. The support (at the time) for non-Java languages was limited at best.
In moving away from JBoss, the main thing that had to re-written by us was the session handling / login framework. We removed our JBossLoginModule:
https://github.com/openmicroscopy/openmicroscopy/commits/8fdd2614e6dcd8450c975944fc2cdd904e1f747cand replaced it with an Ice-based SessionManagerI and PermissionsVerifierI (see the
fire package). This integrated tightly with a new "session facade" (in Ice terminology) that's called "
ServiceFactoryI".
The smooth migration was helped by the fact that we had a
Spring Framework context configuring all of our EJBs, rather than relying solely on the EJB3 mechanism itself. The Ice objects are configured for the Spring context via
BlitzConfiguration (Blitz is the name for our post-JBoss server).
We currently only support Java, Python, and C++. The largest barrier to our supporting more Ice languages is that we must code-generate concrete implementations of the slice objects serialized by Ice. This is required if your slice objects specify methods. If you can at all avoid this, I'd suggest doing so.
If there's anything you can share with us about your architecture, the more we should be able to make suggestions / draw parallels.
Good luck with the migration.
~Josh
