We have batch(windows command files) commands which we created for running batch processes(Client application). Our team is planning to use the same batch command for the web application also. This is the flow being planned for a web app:
browser --> web-server --> appserver -->Runtime.exec() on the batch command
So basically we are trying to achieve an asynchronous model using the batch commands. Is this a good idea?
NO, for so many reasons :)
You have to consider the following:
- transaction support (i.e. there is none!)
- concurrency support (what happens if two people run the batch process at the same time)
- platform independance, you are know stuck on Windows
- maintenance; your business logic is all over the place.
I would be looking to integrate them into your app server, unless there is a *really* good reason not to. If not, review the decision until it becomes yes ;)
1. Transaction support: Since our batch process calls a container session bean for business logic and transactions are taken care of at the session bean level , why should we worry about transactions.
2. Multiple users: Yes thats a valid point but what if we take care of that or what if we wont have such a situation?
3. How can you say that the business logic is not maintainable ? The batch process calls a Session bean as i mentioned in point 1. So the business logic resides there and nowhere else.
I am just trying to argue this idea .. hope you dont mind.
If all your batch process is doing is calling a method in your app server, and has no business logic, no probs.
I thought you had business logic defined in your batch file.
If indeed you are using a batch file and some external scheduler to "fire an event", then that is fine.
You might want to look at EJB2.1 for the new ejb.Timer API.
Also, check out http://theserverside.com/discussions/thread.tss?thread_id=31667
FWIW; I use JMS/MDB quite a lot, and they do work very well. The initial problem of course is how to fire the initial event which posts the message :) An external cron job which runs a shell script/batch file which "fires the event" seems OK to me. I would however move *all* business logic to the app server, so the batch server does nothing more than fire the event.
Hope that clarifies it :)
Thanks Colin once again for taking time to respond.
Yes our batch commands just invokes a Session Bean method.
That brings me to another question- since you have been using JMS a lot , you might be able to clear this . If we can do things like we are planning to do in our project(calling batch processes from web app to run a asynchronous process) then whats JMS buying me?
I appreciate ur time.
Primarily skillset and language independence. Batch files only run on windows ;)
Secondly, they are (can be) guaranteed to be delivered, so if the message is sent and there is a network failure, it will be redelivered when the network is back up.
I would suggest you look at ejb.Timer instead of JMS or batch files as it the "best fit" for what it sounds like you want to do.
Feel free to ask any more questions ;)
P.S. I have used JMS to implement asynchronous server side ops, i.e. instead of calling SSB which will take a long time, stick a message on a queue and have the MDB call the SSB. Once the MDB is finished, have it stick something on the temporary return queue, and have a client side MDB acknowledge the operation has completed ;)
Thanks again. What we want to achieve is not exactly a scheduled task. The actual business use case is to create some entries in the database based on the user input (from web app). This process will take around an hour (yes !!) and hence the need for an asynchronous process. I know this is a perfect situation for a messaging system. But then when i can do it the way we are planning to, who needs messaging??? :) I know its not a great design but its money!
Of course; practicality over academic "correctness" is always interesting :)
For the scenario you describe; JMS would be one way to go.
At the end of the day, if it works, everyone knows and understands it and it's consequences/limitations are well understood; why change? If it ain't broke, don't break it :)
Thanks Colin. Well as a developer i am more eager for technology(the job market needs skill set :) ) but its my manager who makes decision. And state of the art is not what his goal is. Its business at less cost. I wish i could come up with a valid argument against using the batch processes VS JMS.
It's nice discussion. But i have a doubt as am going through this discussion. If it is Batch Process , how could you authenticate the completeness of the event ??. ( Ex: Under the scenario you explained , how the applictions knows that posting are done successfully , with out doing some business logic of retrieving and validating the data ) !!
On the other hand if you have an MDB it would be much easy to authenticate the exact state ( Errors / Successful completion ). Also , i suggest to forecast the future demands and thus scalability of the design.
Gopala welcome to the discussion. Yes the design is not the best as i said before. The point is it works without losing anything that JMS could have done better.
Now to answer your question about verification of updated data, the user needs to come back to the web app and verify it.
Thank you George. So from the message processing point of view , the user won;t know till he/she logs into the application. This might be fine with the System requirements.Just a thougt.
Yes thats correct.A limitatiion the user is ready to live with. I started this discussion hoping someone would give me atleast 1 benifit of using a messaging system VS the batch process method. ALAS! :)