Our Business Requirement is Large file transfer across the network and saving the files in the local file System and Sending the files to different source based on some criteria.
I Want to know how this requirement can be solved with ejbs?
I have the following concerns for using ejbs because
1.With Ejbs we can't write to local file System
2.We can't use Sockets in EJB to forward the file to some other location.
Any ideas and suggesions helpful.
You _can_ read a file using an EJB, but you are breaking the spec. on one point. This means you really have to know what you are doing when working with files. Important issues are:
What you definitely should avoid is an EJB writing a file and another process checking for files in that directory. Always communicate "file is complete" using an asynchronous message!
Time to go home, but I can continue this discussion later if you want.
Actually, you can write to the local filesystem. It's just against the specification. If you really think about it, it's all about drawing the line for the boundary of EJB and the rest of the world.
If you write directly to the filesystem, everyone says you're breaking the spec. If you write to a database over JDBC (or using an entity bean), nobody is saying that you're breaking the spec -- regardless the fact that your file ends up on the same physical disk as before...
Basically, you could argue that if you put enough layers between the EJB and the filesystem, you're not breaking the spec. One solution could be putting the file into a JMS queue and let some other process write it into the disk. I won't say anything about the feasible/reasonable that solution would be, but I doubt that anybody would claim your breaking the holy spec.
IIRC some reasons why file IO is not allowed:
In a cluster of machines, issues come about WRT which machine will have the file.
The IO package in general is not suited to EJB, something to do with the way it mucks with threads.
As Lasse mentioned, dealing with a DB is not a problem. Perhaps if there was a way to access files without using IO and without delaing with the loacl filesystem, eneryone would be happy. LDAP springs to mind.
Thanks For Your Feedback.i am giving the complete Current Architecture developed With COM components,we are looking at J2EE Architecture For the Replacement of Central Server.
Our System Arch Looks like this
The Current System
Source---Central Server--|--MiniServ2 --Clients
------ Bidirectional Link
Central Server --With database about all the transcations through the System
Mini Serv*--with Storage info of teh files came to that Server
Where Source / End Elients are Windows Based Clients(Developed in VC++)
The File Size Transfering across different Sources is of Size around 0.5 MB.At the Central Server these Files Will be Stored on the local hard Disk.At Centarl Server based on Some Rules it will be routed through different Mini Servers(Mini Serv*).Mini Server Will Send the file to different Clients. After Working on the files the files will be send back to the central Server via the Mini Server*.At the Central Server we have the latest Copy of the File
Currently Entire System Based on Windows and Central Server Built using COM Components Running on Windows 2000 Advanced Server.
We Want to port the existing Sytem in java with out touching the Source and End Clients.We thought of replacing the Central Server with J2EE Application Serevr and COM Components with EJBS.But in Ejb we can't write to Local System and can't use sockets to send the files to MiniServers.
Is there Any Work Around for the mentioned problem using java?
An RMI or CORBA service would be more appropriate for what you try to achieve. Sockets, threads and files are all safe with such a service. If you have a technology specific goal of "going for J2EE", I suggest you redesign your Central Server in two parts: a file management part on RMI/CORBA, an information management part on EJBs.
Thanks For The Feedback.The Main Intention for looking at J2EE Application Server as Central Server is its Builtin Support For Load Balancing and Connection Pooling.thats way we are looking a Solution From EJB Side.