As others have pointed out, File , InputStream and many other IO-related objects cannot be serialized and therefore cannot be stretched over the connection between the client and server (without additional functions). In the context of J2EE, a container should terminate processes as quickly as possible in order to minimize resource use and allow parallel processing. Prior to Java NIO , I / O operations are usually blocked (waiting for data to be read or written), which causes threads to hang (i.e. temporarily stop at best, forever at worst).
I was working on a project when some of the developers, who were fairly new to Java, opened FTP connections to remote servers from EJBs - against my warnings and J2EE docs. When the remote server did not respond, the only way to unleash our server is to kill and restart it!
Therefore: capture the contents of the file in the client and send it over the connection as a large string or array of characters or bytes or something else. Thus, your EJB process will have all the data ready for processing.
If the amount of data is too large to do so in a reasonable amount of memory, this is not a viable solution. The recommended solution in this case would be for the client to write data to the database (possibly BLOB) and read the EJB from the database.