Discussions

News: EJB call a native Windows executable

  1. EJB call a native Windows executable (7 messages)

    Hi all, for some reasons we need to call a xy.exe from an EJB. As we don't want to violate the EJB contract we are looking for another solution instead of calling it directly from the EJB via Runtime.getRuntime().exec(). Alternatives: 1. RMI Server which calls xy.exe Runtime.getRuntime().exec() 2. WebService which calls xy.exe Runtime.getRuntime().exec() 3. Implement a JCA Adapter Reimplementing the logic in Java would be to expensive. Questions: 1. Any Comments? 2. any other ideas? 3. Did anybody yet implement a JCA Adapter for calling an executable or - even better - is there an open source implementation out there. Regards and thanks Frank
  2. I would suggest a JMS Queue. Then you can start a variable number of consumers for round robin load balancing. Thinks you get from JMS: guaranteed delivery and therefore execution of the job, monitoring of the number of outstanding tasks, etc. Dependent on the nature of "xy.exe" you commit the message before or after the execution of the child process (mostly afterwards). Unless the job must be executed synchronosly (which can be realized via a unique answer queue for each call), JMS is the best solution for executing native binaries in a cluster safe way.
  3. Almost always such a tae-kwon-do approach leads to problems, system misbehaviours and, at least, bad design with tight coupling and low possibilities for bug tracking. My point is to be exclusive about the matter - say no. No buts - say no. It's professional, it's wise and, if you created a problem, problem would arose later on in any way. Once I had such an issue and I sad no. We altered procedures for a concrete flow, creating a task of invoking such an executable manually. Even though I almost lost a job (ok, rather a position), executable itself was droped, rewritten in Java and I had a model I could work with. Dejan
  4. I would go for the RMI option . The reasons being 1) The requirement here seems more of a synchronous one . 2) The clustered server side gets completely isolated from the RMI server running the executable . The EJB should be the RMI client here . 3) Web service solves the above purpose with the overhead of on the wire XML documents . Not enticing at all . Cheers Debashish
  5. I think you can consider moving the function out of the EJB to call an exe. For example, move it to a Managed Bean (MBean). Try to make the exe a service inside the MBean, not a following task to the EJB. Best Regards, Tiger Chan
  6. JCA seems to win...[ Go to top ]

    Thanks for your comments, very interesting and confirming to insist on another solution. To complete the information basis: it is a fire and forget call, transaction does not matter. We did a proof of concept with a JCA-Adapter. Cost for the implementation was low (about 2 days). The way we see it this justifies the ejb contract, our current experiences in our lab with this approach is fine. One disadvantage of this solution is the platform dependancy as we use a "xy.exe" on the serverside. This is not an issue for us, as this ejb will run on an application server on windows. If this should change, we will think about switching to a RMI based solution. The RMI solution was not our first approach as we would need to run a separate process. Are there any concerns about using the JCA based solution? Do you have experiences with implemting your own JCA Adapter? Regards thanks a lot for the gread discussion and lets prepare for the german soccer european championship. Frank
  7. Hi alan, I have the same issue like you. I would like to know if you used JCA and also I would like to have your feedbacks. Any input will be much appreciated. Thank you very much. Alani
  8. Hi alan,

    I have the same issue like you. I would like to know if you used JCA and also I would like to have your feedbacks. Any input will be much appreciated.

    Thank you very much.

    Alani
    Hi all, Can someone please help me with the above? Many thanks for your help. Alani