 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / JavaBeans / October 2004Manipulating files within j2ee
Hi! I'm trying to develop an cliente/server aplication using j2ee. But the aplication specification needs to send and receive files, etc.. basicly I need I/O acess and Socket acess. If I understand correctly the is no way to do this inside a J2EE Application Server (I'm trying to use JBoss), and the only way I can manage the problem is implemeting connectors as if I was using a Database, to delegate this tasks to a program out side the Application Server. Is this true , there are no other simplier alternatives ? Another problem is this. I need to implement a message network , similar to msn, icq , etc... between the server and the client. Sending a message is easy, but how do I get the answer? As I see it, the J2EE envoirment has a pull driven arquitecture (the cliente can get info from the server and do actions on the server, but the server, cannot do action on the client) Is this true, or I'm missing something ? Any help will be apreciated has I'm trying to decide If I shoud let go j2ee and create my own specialized server (but by doing this I will have implements things like security, socket management , transactions, etc... algthouth there are some interesting options on the persistence layer like OJB or JDO...) Well, what say you ? ... > Hi! Hi, > I'm trying to develop an cliente/server aplication using j2ee. But the > aplication specification needs to send and receive files, etc.. basicly I [quoted text clipped - 4 lines] > Application Server. Is this true , there are no other simplier > alternatives? For file access on the server, you do need a JCA connector. But I'd first look if there isn't any ready-to-use implementation available (as open source or for purchase). I can't see though why you need socket access for this. Use the normal J2EE protocols to transport the files, e.g. via Servlets and HTTP or via EJB method calls. > Another problem is this. I need to implement a message network , similar to > msn, icq , etc... between the server and the client. Sending a message is > easy, but how do I get the answer? As I see it, the J2EE envoirment has a > pull driven arquitecture (the cliente can get info from the server and do > actions on the server, but the server, cannot do action on the client) Is > this true, or I'm missing something ? This cries for JMS (Java Message Service, part of J2EE), an asynchronous messaging system. > Any help will be apreciated has I'm trying to decide If I shoud let go j2ee > and create my own specialized server (but by doing this I will have > implements things like security, socket management , transactions, etc... > algthouth there are some interesting options on the persistence layer like > OJB or JDO...) > Well, what say you ? ... This depends how critical and large your application is. If it is just a straight-forward message and file exchange system, you won't need much transaction and persistence support. In this case I'd go for a specialized custom server. If this is only part of a larger system, you have a complicated software project anyway, and learning the relevant J2EE technologies will probably be worth the effort. Rainer Hi Rainer, thank you for awsering > > I'm trying to develop an cliente/server aplication using j2ee. But the > > aplication specification needs to send and receive files, etc.. basicly I [quoted text clipped - 10 lines] > access for this. Use the normal J2EE protocols to transport the files, > e.g. via Servlets and HTTP or via EJB method calls. Well, I thought of that, but I'm not interested in using Servelets. Via EJB methods, is the solution, but I didn't come with the best form to do this. Do I create a DTO(Data Transfer Object) named File with a field of type bytes[] ? This seams the more strait awser but is it the best one ? Is not best to pass a stream ? Usig the DTO I must read all the file to memory and pass it to the other side , them save it. Using a stream I can pull the file and save it at the same time. But is "legal" to pass a stream ? (is a stream serializable ?) > > Another problem is this. I need to implement a message network , similar to > > msn, icq , etc... between the server and the client. Sending a message is [quoted text clipped - 5 lines] > This cries for JMS (Java Message Service, part of J2EE), an > asynchronous messaging system. Well I understand that , but do I need the adaptor ? How about JXTA ? > > Any help will be apreciated has I'm trying to decide If I shoud let go j2ee > > and create my own specialized server (but by doing this I will have [quoted text clipped - 9 lines] > you have a complicated software project anyway, and learning the > relevant J2EE technologies will probably be worth the effort. Yes, the project is quite complicated. I'm trying to learn but is dificult deciding wich tecnology to use. I need DB acess so I use the Application server EJB , transactions, etc... , but I need a lot more. Another thing I need is class dynamic loading. Another proibited thing in j2ee. (because is file access and because of security issues ...) Can't I use a SecureClassLoader of some sort ? These things make thing if using j2ee is the right way to go.... (I thing yes, but is much more dificult than j2se) > Hi Rainer, thank you for awsering Well, it seems you have an interesting project. I have to say that I'm a little out of practise right now, and don't remember all API and semantics details. > > For file access on the server, you do need a JCA connector. But I'd > > first look if there isn't any ready-to-use implementation available (as [quoted text clipped - 10 lines] > pull the file and save it at the same time. But is "legal" to pass a stream > ? (is a stream serializable ?) No, you can't directly pass a stream. What files are we talking about anyway? Existing binary or text files? On-the-fly generated files? Data that could be represented by objects and only be saved to a file on client side? For fixed files I'd still go for servlets, as they provide the framework for that (including transfer of meta information like content type, text encodings and so on). IMHO it makes more sense to use the technology that implements the required functionality best than saying "I'm only interested in technology A, but not in B". You'll need a server that supports servlets anyway (as you'll need a complete J2EE server). For on-the-fly data, it really depends on the content. Tell us more if you want more specific advice. > > > Another problem is this. I need to implement a message network , similar > to [quoted text clipped - 10 lines] > > This cries for JMS (Java Message Service, part of J2EE), an > > asynchronous messaging system. (BTW, could you please try to fix your quoting - these line breaks look extremely ugly) > Well I understand that , but do I need the adaptor ? How about JXTA ? What adaptor do you mean? JMS is integral part of J2EE. I don't know JXTA at all, so I can't give any recommendation, but as far as I understand, it is more low level networking than JMS. Another possibility could be JAXM (XML messaging) Message Driven Beans (new in EJB 2.1). > > This depends how critical and large your application is. If it is just > > a straight-forward message and file exchange system, you won't need [quoted text clipped - 9 lines] > file access and because of security issues ...) Can't I use a > SecureClassLoader of some sort ? Why do you need this? J2EE is supposed to be an architecture that relieves you of such low-level techology. > These things make thing if using j2ee is the right way to go.... (I thing > yes, but is much more dificult than j2se) I guess no one can answer this without knowing details of your project. In the end, you'll have to decide that yourself. Rainer > No, you can't directly pass a stream. What files are we talking about > anyway? Existing binary or text files? On-the-fly generated files? Any file, including office documents, images, reports, special files to comunicate with 3th party systems, legal files, etc.. > Data that could be represented by objects and only be saved to a file on > client side? For fixed files I'd still go for servlets, as they provide > the framework for that (including transfer of meta information like > content type, text encodings and so on). This files are needed for three primary functions:exporting data to other systems, compiling data , like reports. In the end the system would have to mimic a FTP. The goal is to develop a ERP system, but this system must be able to do things like document signature and document manegement. That is the theerd reason. IMHO it makes more sense to > use the technology that implements the required functionality best than > saying "I'm only interested in technology A, but not in B". You'll need > a server that supports servlets anyway (as you'll need a complete J2EE > server). I'm not aware that Servelets implement FTP. I understand that I gould extend a Servelet for that purpose or transfer via HTTP. The reason I don't like this aproache is that the server must be able to send file to another computer on is own, without a request from a client of any kinf, like a ftp upload. I'm not aware this is possible using servelet tecnology. But, if it is please give some advices or site to beging with on this subject. Is it possible to create a ftp server using j2ee ? > For on-the-fly data, it really depends on the content. Tell us more if > you want more specific advice. The problem is that I do not know what content it will be. That why i'm aiming for a generic solution. > > Well I understand that , but do I need the adaptor ? How about JXTA ? > > What adaptor do you mean? JMS is integral part of J2EE. Yes, but to make a message aplication, like MSN - read : real time chat : - how do I send the response to the user ? Example user A write "Hello" for user B The Client program used by A do somethi like get remote stateless bean post message the bean can send the message to a JMS queu of another system , let's call it the Message Service Engine. this engine needs to send the message to B at some point. How do I send it ? The server side cannot (? i thing it can't) get a remote bean on the cliente and post the message. This Listener part of the service I do not know how to implement. Another this is: I see that there some project out there that comunicate with establish message networks like msn or yahoo, or icq, using java. So the obvious step is to integrate my home made chat service with that one so the other end may be able to comunicate with me without using my sistem. Example, a representative traveling thought the country my enter a cyber cafe , pop up msn or yahoo or icq or another and chat with some people back on the office , even send some files ... So , once I resolve the listening problem I need to integrate with these other sytems using some type of plug-in. I thing I need to extenalize this task to another program outside the AS (aplication server) using jca. But if there is a chance to implement it inside de AS the better. I don't know > JXTA at all, so I can't give any recommendation, but as far as I > understand, it is more low level networking than JMS. Another > possibility could be JAXM (XML messaging) Message Driven Beans (new in > EJB 2.1). Well that one is new to me, I will check it out. > > Yes, the project is quite complicated. I'm trying to learn but is dificult > > deciding wich tecnology to use. I need DB acess so I use the Application [quoted text clipped - 5 lines] > Why do you need this? J2EE is supposed to be an architecture that > relieves you of such low-level techology. The server applies rules on dynamic entities , meaning the fields on the entities are not constante, can be added or removed. For each field I need to validate the entry of date - this is only an example- so I use a Validator. This is an interface. Some factory spits a real validator for each particular field. I only need to do this once. But, this validator is implemented a class , and the validating rule lies inside it. So if the rule changes I change the validator or the logic inside the validator. Simple validations will be distributed with the system, and extentions will be programmed by the system end users or some 3th party. This work like a plug in, but for this to work I need dynamic class loading. I load the class using it's name that exists in some description file. Well, how do I do this in j2ee ? Or there is another way ? > > These things make thing if using j2ee is the right way to go.... (I thing > > yes, but is much more dificult than j2se) > > I guess no one can answer this without knowing details of your > project. In the end, you'll have to decide that yourself. Quite true. But in the end my decision will be made using all information I can gather, and I would like to thank you for helping me. > > No, you can't directly pass a stream. What files are we talking about > > anyway? Existing binary or text files? On-the-fly generated files? [quoted text clipped - 13 lines] > things like document signature and document manegement. That is the theerd > reason. Will you develop client programs yourself, or will you have to use standard explorer/ftp/office programs? If you develop the clients, you can use any (even self-defined) protocol that has ftp-like functionality. Have you thought of using WEBDAV? > I'm not aware that Servelets implement FTP. I understand that I gould extend > a Servelet for that purpose or transfer via HTTP. The reason I don't like [quoted text clipped - 3 lines] > But, if it is please give some advices or site to beging with on this > subject. Is it possible to create a ftp server using j2ee ? Well, IIRC you didn't mention FTP before. What other computer sill you have to transfer files to? Another instance of your J2EE app? The client's computer? An existing or new file or web server? As long as it doesn't already run an ftp server, you wouldn't be able to upload without any software installation on this remote computer. If it will run any client or server component of your project, you could even use JMS for that. It should be possible to code an ftp *server* with J2EE, but why bother? Use an existing FTP server if you want to transfer and store files (FTP stands for File Transfer Protocol, after all). Use any J2EE protocol if you need integration in your J2EE context. But if you want to transfer files from your J2EE server components to another computer, you'll need a *client* for FTP or whatever protocol you want to use. There is a ready-to-use SMTP client available as JavaMail implementations inside JBoss. You can integrate other protocol *clients* in J2EE components *if* you handle socket creation with a J2EE compliant resource factory (don't know if J2EE or Jboss provide anything, but it should be possible to implement with JCA). > Yes, but to make a message aplication, like MSN - read : real time chat : - > how do I send the response to the user ? [quoted text clipped - 11 lines] > bean on the cliente and post the message. This Listener part of the service > I do not know how to implement. You don't need to implement this. If you want to communicate *between* clients, you simply establish JMS queues ot topics, and configure your clients to subscribe to those. You can use temporary queues of 1-to-1 communication, and persistent topics for IRC like chat channels. There are no EJB involved. The clients don't get remote session beans to post their messages, but they use the JMS session instead. The JMS implementation then is responsible to transfer the message to the other client(s) who are subscribed (at least when communicating over internet instead of local network, this will probably involve some polling mechanism for the client, but this is part of the JMS implementation, you don't have to program this yourself). Message Driven Beans come into the picture, if you want to communicate with the server. You use them, if you want the server to react on messages from the client - like storing messages into files or database or doing actions when messages of a certain kind are received. They are themselves just normal JMS message listeners. > Another this is: I see that there some project out there that comunicate > with establish message networks like msn or yahoo, or icq, using java. So [quoted text clipped - 7 lines] > the AS (aplication server) using jca. But if there is a chance to implement > it inside de AS the better. It really depends on who will use this messaging system - just people with your J2EE client program installed, or other people who have only yahoo or msn messenger programs. You can look for java clients for these protocols and see if they can be used inside a J2EE container. Then you can use Message Driven Beans as a bridge between JMS and those services. [...] Rainer Hi, Rainer Thank you again for your answer , it was most enlightening. > > This files are needed for three primary functions:exporting data to other > > systems, compiling data , like reports. In the end the system would have to [quoted text clipped - 5 lines] > Will you develop client programs yourself, or will you have to use > standard explorer/ftp/office programs? I will devepol the ERP clients , the user must be able to manage the documents using the ERP client , but it does not require to open the documents inside application. Only the documents produced by the system would be read inside the erp client. >If you develop the clients, you > can use any (even self-defined) protocol that has ftp-like > functionality. My problem is not the protocol, is the possibility the server to pull a file remotly. Imagine the user create a file. This file is created localy , but at night the system makes a back up collecting all file and sending them to a fileserver elsewhere. The client may request the file from the server. This is one problem. I must read the file and send it in a object , like we spoke earlier. Or I make a to back-to-back system where the erp server and the erp cliente act as a fileserver - fileclient alternatly. Your solution using JMS seams more interesting, but a problem remais, how do I read the file ? >Have you thought of using WEBDAV? I do not know waht WEBDAV is... > > I'm not aware that Servelets implement FTP. I understand that I gould extend > > a Servelet for that purpose or transfer via HTTP. The reason I don't like [quoted text clipped - 5 lines] > > Well, IIRC you didn't mention FTP before. It was only an example , does not mean I nead to use the real FTP , is more an ftp-like protocol. But, if FTP is available, the better. With that I could download and upload files from 3th party sources. >What other computer sill you > have to transfer files to? Another instance of your J2EE app? From and to the : clients, file(servers (they only gather and manage files) , and other J2EE servers implementing my aplication. (In the future even applets running in browsers ) The > client's computer? An existing or new file or web server? As long as it > doesn't already run an ftp server, you wouldn't be able to upload > without any software installation on this remote computer. Yes. But is my entension to provide thouse other clients. The fileserver is realy a J2EE AS dedicated to manage files. sort them, avoid saving duplicates, etc.. but at the same time, provide security and failover (if a file in a server is deleted a copy must exist) ...etc.. If it will > run any client or server component of your project, you could even use > JMS for that. It should be possible to code an ftp *server* with J2EE, > but why bother? The inicial question is: how is possible to code an ftp server in j2ee if you have no control of raw (not RMI) sockets ? Use an existing FTP server if you want to transfer and > store files (FTP stands for File Transfer Protocol, after all). Transfeinr the files is not the top problem , the top problem is how to read the file from the disk. Using a JCA adpator ? Ok. That is the only way to do it ? (Shoul'd I implement a standalone fileserver and comunicate with it the same way I comunicate with the clients ?) > You can integrate other protocol *clients* > in J2EE components *if* you handle socket creation with a J2EE compliant > resource factory (don't know if J2EE or Jboss provide anything, but it > should be possible to implement with JCA). Well that was the question. How can I gain access to sockets ? > > How do I send it ? The server side cannot (? i thing it can't) get a remote > > bean on the cliente and post the message. This Listener part of the service [quoted text clipped - 6 lines] > are no EJB involved. The clients don't get remote session beans to post > their messages, but they use the JMS session instead. I think I'm beginning to understand. > Hi, Rainer Hi, > > If you develop the clients, you > > can use any (even self-defined) protocol that has ftp-like > > functionality. > > My problem is not the protocol, is the possibility the server to pull a file > remotly. That's what I call a protocol - means to transfer files remotely. > Imagine the user create a file. This file is created localy , but at night > the system makes a back up collecting all file and sending them to a > fileserver elsewhere. How would you do that outside of J2EE? How about having the client store the file to the server? > The client may request the file from the server. This is one problem. I must > read the file and send it in a object , like we spoke earlier. Or I make a > to back-to-back system where the erp server and the erp cliente act as a > fileserver - fileclient alternatly. > Your solution using JMS seams more interesting, but a problem remais, how do > I read the file ? Do you think the answer will be any different if you keep asking? Use JCA. > >Have you thought of using WEBDAV? > > I do not know waht WEBDAV is... Well, then would you care to look it up? Never heard of google? I'm trying to put you on the right track chosing adequate technology, but I won't do basic reading for you. Hint: http://www.webdav.org/ > Yes. But is my entension to provide thouse other clients. The fileserver is > realy a J2EE AS dedicated to manage files. sort them, avoid saving > duplicates, etc.. but at the same time, provide security and failover (if a > file in a server is deleted a copy must exist) ...etc.. I still don't get your project structure. I thought you wanted file server functionality inside your J2EE application. Now you want a dedicated server for that? I'm not sure J2EE is the best solution for that. > Transfeinr the files is not the top problem , the top problem is how to read > the file from the disk. Using a JCA adpator ? Ok. That is the only way to do > it ? (Shoul'd I implement a standalone fileserver and comunicate with it > the same way I comunicate with the clients ?) I guess you should first make clear to yourself what your functionality will look like. File management as an additional task, or as integrated functionality inside your main ERP workflow? Then you decide whether to implement it standalone or integrated. > > You can integrate other protocol *clients* > > in J2EE components *if* you handle socket creation with a J2EE compliant > > resource factory (don't know if J2EE or Jboss provide anything, but it > > should be possible to implement with JCA). > > Well that was the question. How can I gain access to sockets ? If I were you, I'd search for information about this. It is possible for mail and HTTP, so try to find out how they are doing it. They do need sockets somewhere, too. > > You don't need to implement this. If you want to communicate *between* > > clients, you simply establish JMS queues ot topics, and configure your [quoted text clipped - 4 lines] > > I think I'm beginning to understand. So apply this to your fproblem described above. For instance, have the client write the files not only to their local disks, but additionally to a JMS queue to which the server is subscribed. The server then stores the file in its backup / versioning / sharing system. Rainer > > Imagine the user create a file. This file is created localy , but at night > > the system makes a back up collecting all file and sending them to a > > fileserver elsewhere. > > How would you do that outside of J2EE? How about having the client > store the file to the server? The problem remains. The server must be able to acess the file system to store it. I know I do this using JCA, the question is how to do the transfer. To load the file to memory in object and transfer the object to the other end and save it back to a file ? or to pass a simple port adress and file name, delegating to another system the transfer (this time using a raw socket based protocol or manipulating the streams ...). The secound solution is better since the file is not loaded to memory. So, since the best solution is to have a file transfer especific cliente and server > > The client may request the file from the server. This is one problem. I must > > read the file and send it in a object , like we spoke earlier. Or I make a [quoted text clipped - 5 lines] > Do you think the answer will be any different if you keep asking? Use > JCA. JCA is to delegate outside the AS the task of reading the file. But once the Adptor has the name of the file it opens a inputstream to it. Do I pass that stream inside the AS ? I can't do that. So , reading to memory is out ... what remains ? > > Yes. But is my entension to provide thouse other clients. The fileserver is > > realy a J2EE AS dedicated to manage files. sort them, avoid saving [quoted text clipped - 3 lines] > I still don't get your project structure. I thought you wanted file > server functionality inside your J2EE application. Yes. > Now you want a > dedicated server for that? I'm not sure J2EE is the best solution for > that. A J2EE dedicated server. > > Transfeinr the files is not the top problem , the top problem is how to read > > the file from the disk. Using a JCA adpator ? Ok. That is the only way to do [quoted text clipped - 3 lines] > I guess you should first make clear to yourself what your functionality > will look like. Well the especification is only: be able to create , read and manage files File management as an additional task, or as integrated > functionality inside your main ERP workflow? Integrated. Then you decide whether to > implement it standalone or integrated. > [quoted text clipped - 8 lines] > for mail and HTTP, so try to find out how they are doing it. They do > need sockets somewhere, too. But that is manage by the Aplication server who's is impowered to use sockets , load classes dinamicly and acess files. Once again, thank you for discussing this with me, Rainer. Hi, first of all sorry for top-quoting this time, but I'm not referring to a specific part of your message, but to our whole discussion. As far as I understand, you have the following tasks / problems to solve. 1. A J2EE based ERP system with transactions, database and all, to be implemented with EJB (the clearest part). 2. A File server for documents that are to be used in connection to the ERP system, to be implemented sonehow with J2EE but, as I understand, as a separate J2EE application, deployed on a separate server. 3. A messaging system similar to yahoo/msn messenger integrated in this system. 4. An application client with access to the systems / functions above. I have some questions about your structure so I can give some more suggestions. Does the core system in 1. need to access the file server in 2.? Or the other way round? Is this completely separate, or is there a common transaction context of ERP and file operations? Is 3. meant to be a 1-to-1 or a many-to-many system or both? Do messages nees to be persisted, or included in transaction context? Is there a need of message based communication between clients and the ERP server, or only among clients? From what I understand now, I'd use this architecture: 1. A standard transactional J2EE EJB application deployed in application server A. 2. I'd use a WEBDAV repository as file server. Check out Apache Slide (http://jakarta.apache.org/slide/), this is a servlet based WEBDAV server which has a file backend. Deploy it in application server B. Do you absolutely need the server triggered backup process, or would it be feasible to require the client to store the file on the server? Or at least store it to a JMS queue which is configured in the application client? In that case, have the server B subscribe to this queue and read the files at the time when it is feasible. Either implement JMS on application server B for this, or configure B to be a JMS client of A, which needs JMS anyway for 3. This way, you avoid file access in EJB completely, as well as raw socket access. Clients can use any Java webdav library to access this server. 3. Use JMS. In which way depends on the communication requirements (see my questions above). Deploy and configure it in application server A. Please correct me if I misunderstood your requirements or made wrong assumtions. Hope this clarifies things a bit. Rainer > > > Imagine the user create a file. This file is created localy , but at > night [quoted text clipped - 87 lines] > > Once again, thank you for discussing this with me, Rainer. Hi Rainer, (...) > 1. A J2EE based ERP system with transactions, database and all, to be > implemented with EJB (the clearest part). [quoted text clipped - 12 lines] > Or the other way round? Is this completely separate, or is there a > common transaction context of ERP and file operations? Imagine this, scenario1 the user X runs some report. The ERP server will consult the DB and respond with the report. The user then saves the resport for other users to have acess later. scenario2 : the user Y set some timer service that every day at 12pm runs a report and saves it for some users to acess the following day. scenario3: user Z needs to consult an existing report. scenario4 : user W runs a catalog buil operation that results in a PDF document that will have all products description and foto. The fotos are in the file server , the result PDF will be created and send to the file server. (and also send by mail for all customers in a mailing list) So, does core system have acess to files server 2 ? yes. The file server is a repository, there is no inteligence there , so it never tries to acess server 1. So, also there is no common transaction, unless you count "save file to file server" as a common transaction. > Is 3. meant to be a 1-to-1 or a many-to-many system or both? Do > messages nees to be persisted, or included in transaction context? Is > there a need of message based communication between clients and the ERP > server, or only among clients? Instant Messages are meant to be 1-to-1 at iteration 1, then also many-to-many in a later iteration.(I think is possible to make many-to-many the fist time if the model is good enought, is a question of relay and adminstration of users and contacts.Even better, a question of chat room admistration: it should exist a send and a receive topic , per room.) Messages do not need to be persistente, but must be saved to later delivery if the user is off line and also must be possible to save the conversation log. This is usefull for remote client suport. Users comunicate with each other inside the ERP, i.e. they use the ERP main client to iniciate chat and track people on-line. Also the ERP server uses messages to alert users of something they must do or some workflow event or exception. This is particulary inportante in the case of the adminstrator user, something goes wrong with the system, he is notified using messaging. (at this point maybe message persistance is a good idea, but the log could do that, I think...) The ERP Server is a "person" for messaging purposes that only sends messages and all people in the sistem belong to its contact list. > From what I understand now, I'd use this architecture: > 1. A standard transactional J2EE EJB application deployed in [quoted text clipped - 3 lines] > (http://jakarta.apache.org/slide/), this is a servlet based WEBDAV > server which has a file backend. Deploy it in application server B. > Do you absolutely need the server triggered backup process, or would > it be feasible to require the client to store the file on the > server? Both client and server must be able to save files on the file server. Also a secound file server must be able to read a first server, for back up proporses. Arquitecture (client1) (client2) <---|----> (ERP server) -------> (main file server) -------> (backup file server) (client3) |------------------------------------^ > Or at least store it to a JMS queue which is configured in > the application client? In that case, have the server B subscribe to > this queue and read the files at the time when it is > feasible. Either implement JMS on application server B for this, or > configure B to be a JMS client of A, which needs JMS anyway for So, you are saying , make a special client that only handles files. Register it at the AS (aplication server = main ERP server). The normal client will ask the ERP server for a file, the AS will delegate to the file server ... also the ERP server can comunicate with the file server using the same JMS registration. I think it is fine but: 1) file consulting must be synchron. 2) how to transfer the file information , in an object the incapsulates a byte[] ? in other words how a Value Object will be for tranfering the data in the file ? (the file may the binary like an image or a pdf ) > 3. This way, you avoid file access in EJB completely, as well as raw > socket access. Clients can use any Java webdav library to access > this server. > > 3. Use JMS. In which way depends on the communication requirements (see > my questions above). Deploy and configure it in application server A. JMS is good, I have read some about it, but I have problems figuring out the connections Say , for the instante messaging part : user A logs on. The client A is using registers it self as a subscribes to a Topic named <incomingmessages> and as publisher to <outgoingmessages> topic In the server there is a Message Driven Bean that relays messages from incoming to outgoing. user B long on. It does the same regestry. A sends a message to B, so A sends a message to the publisher topic, then the MDB relays to the incoming topic and B receives it. Is this how its done ? If it is I have problems undestanidng : a) how A know B is online ? the event of B regestring must fire a message on the incoming topic like <B as longged on> , but only people how have B in the contact list must receive this message. b) how the relay system only dilevers messages to they rightfull onwers ? Since all users are subscrib in the same topics all users wil lreceive all messages. I do not what to make a IRC where every one gets every one's messages. For security reasons is important the message is only delivered to people how should read it. I think that for this to work each client must create its own listening and posting topics, the message caries the source and destination of the message (can be multiple ones) . the relay system only reads this params and sends the message to the right topics. This time, only the rightfull onwers of the message will get it. Of couse the message must always be sent to its sender for feedback. But, the same question How the event of user being online/off line is capture using JMS ? I think the Loggin mecanhis should trigger this, but i'm in the way of understanindg all the details and how to implement them in jms. One thing to create topics I need to use the AS console , in my case JBoss'es console so I can create the topics, but I need dynamic Topic creation (two for each user) to this to work or use two premade topics.... Well I think I very new at JMS to understand how this is done... The requirements are: a) users should have a list of contacts b) contacts in the list must be informed that the user is online after the user loggins in (or after he changes is status to on-line. He could enter the system in invisible mode, for example) The same is valid when the user goes off- line. To make it more interesting, the contacts must be informed when the user changes status. c) the user A must send the message M to users B and C and only these three users should read the message. d) messages send when destination is off-line should be keeped for later delivery e) the ERP server acts a message sender , he cannot receive messsages , he sees all users. f) In later iteration , integration with other instant messaging systems must be possible. I know I have to use JMS + MSB to make the Instant Messaging Server because is the natural way, but the topic-subscriber-publisher is keeping me confused... As for the file server subject, the AS must work as a JMS provider , both the file Server (FS) and the user client (UC) aplications must connect to the AS. The better solution is to make the FS a JMS provider it self an then the AS and UC will connect directly. However, the UC are dumb , they must only know here to find the AS, right ? Also, JMS is asynchron, how do I get my files synchonously? Above all that, the problem of holding the files data in a object ( now a JMS message) remains. thanks you for your interest. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.