Mohit:Yes the application in its current form is just a standalone application and to be deployed in an application server.
Actually, what i meant by a standalone application(also what people generally mean by standalone) was that the application runs in its own separate JVM. Which does not look so in your case.
Mohit: In the delegate I have to make a decision whether to call the standalone app via direct invocation(synchronous) depending on the input received or route it to the batch manager which invokes the standalone app as a batch job (asynchronous).
Ok, but that does not change the form in which the delegate is exposed to the api clients.
Mohit:
Does it have to be a remote interface. I mean can it be something like local interface (something like EJB local interface or any other viable alternative).
Providing a remote interface (ejb or plain old RMI) facilitates a client to call the api from a different JVM from the one running your delegate.
Okie, so, if you are deploying your application in an application server, then it is better to make the delegate as ejb with a local and remote interface.
That gives you a flexibility to scale your application i.e. choose to deploy the app in the same application server or a different one. Also, it will give you the facilities of transaction (more so if you want to club two api calls into one in the delegate, etc.), security and failover.
So, i would vote for the delegate as an ejb.