Technology choices can make the difference between meeting the customers’ immediate needs and failing to complete a project on time. No can do if you’re using IIOP. If you’re still stuck in CORBA or IIOP, and trying to get remote objects talking to one another – don’t expect RMI-IIOP to help do what pure RMI does – DGC. Stub downloads and DGC are never going to be supported across technologies – it’s not possible to standardize it.
Think about refactoring to expose encapsulated business services instead. Use HTTP – it is connection based and stateless. Alternatively think about using messaging architectures, if you are at the systems programming level – IP Multicasting can be used of TCP that can serve as an unreliable messaging infrastructure – but it can also have layers of high speed health checks and retry mechanisms built. Virtual channels like queues (p2p) and topics with durability attributes can be used as well.
If a non-EJB Java application requires integration with your CORBA system, Java IDL is officially recommended – the communication protocol then is native IIOP. CORBA clients needs to talk to Java, Java IDL on the client end don’t make sense. If you want to integrate with the mainframe, and all you need is some fancy GUI, but the mainframe source code is unavailable – guess what? Screen scrapers via terminal emulator inputs may be recommended. Depends. If the goal is to meet the customer’s need quickly – don’t forget to do a trade off analysis and make target state recommendations. An architects job is to accelerate business not make perfect solutions at all costs. Judging trade offs is where we make money for the clients. Know when where and how to make short cuts if needed. Use a reverse proxy to target different servers for servicing different types of requests. Have failure management systems up to the wazoo. Avoid EJBs if you have no need for transactions and business logic in the solution. KISS.
If you must use CORBA and RMI-IIOP (for EJB type communications), and Session Beans provide good memory management like Pooling and Passivation (SLSB & SFSB). If you must integrate with existing native C++ code/business logic, it is advisable to wrap that with JNI calls, and remote it via RMI. Don’t over use web-services if you don’t need a business service. SOA isn’t API over the web.
All in all, Java IDL is business as usual for CORBA programming. Use RMI-IIOP is for Java programming over IIOP, it can interoperate with CORBA objects but those interfaces must be available as Java RMI. If you must use pure IIOP – then you have existing CORBA objects in play that can’t have Java interfaces – so you must use Java IDL. CORBA provides lots and lots of nice services; Naming Services, Security, Transaction Service, Event and Concurrency Control.
Regardless of how you meet your customers’ expectations – plan to leave them with an awesome build/deploy strategy & matching execution.
