Right now I have brief overview of the project.This project involves a company ,which has various production lines of different type of chips(potato etc).Now,for each production line data will be entered,by engineer, in respect of various inputs used for making chips,the number of chips produced etc.Then,the software will have to calculate vaious efficiencies.Also,every two hours the data will need to be cumulated,and the results shown.Then,at the end of 8 hrs(end of a shift),all of the data will be combined to produce graphical display in terms of efficiencies. One thing is for sure,it will be a client-server application.But I am confused as to whether EJB is right choice for the middle-tier,can something else can be an option? In future version,the user wants that the information relating to each shift will be displayed on large screens(what these screens can be?any suggestions)Also,the lates data should be available to GM(production),and shift engineers,on their computers. please guide me Also,i want to use swing UI,rather than web-interface?And a free server like Jboss or Resin? thanks
My hands-on experience with EJB is limited, but on the most recent project we concluded that we required exactly one EJB to present a public interface for remote clients. The rest of the app server was (or should have been) Plain Old Java Objects. If you make your public interface web services (XML over HTTP) you might choose zero EJBs. I'd look real hard at Glue if I had to provide or consume web services today. Of course you might need more EJB stuff. Look at the services they offer and see if you need them. State mangagement for session beans, remote interfaces, managed persistence, transaction or security management, etc. Re web or Swing client - let the user interface and client integration requirements drive. My current project's primary users have strong requirements to integrate to other desktop applications and a desktop telephony component, so they get Swing. Other users have no integration needs and believe "zero deployment" is important, so they get a web UI.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Hi Vishal- I wrote this sometime back replying to some other email from you. Repeating again... I went thru the link. Your "chip factory" GUI doesn't look so overwhelming. Why don't you stay with only J2EE, with HTML/DHTML/JSP as the front-end view, and EJB for the business methods ? I have worked with Swing and I know it can result in pretty GUIs, but I am not at all sure how to interact a Swing client with the EJB backend. Someone said that one has to use RMI. Will it be then that the Swing client, ALSO acting as a RMI stub, has to call the RMI skeleton/server method which, in turn, will act as a client to the EJBs? I want to know more about this. Also I was reading somewhere that Swing should be avoided with the app server beans code (to avoid implicit multithreading), but then may be it is ok on the client side. I have personally found Swing to be very slow on Solaris (I had a large menu/submenu hierarchy, it was with Java 1.3). Bottomline, design with JSP will be easy to implement and it'll be very efficient too. By large screen, it may be that they are thinking of some projection device, projecting on a large screen from a computer. Clarify this at your end. That should not be a problem. Thanks, Sudd
Hi Vishu, There r 2 ways of looking at the solution and man, real simple ways. 1.U need a global or a local access.Global access, go for web.Local access go for swing as it wuld give a better look and feel. 2.Job security, U need a job security... go for swing as it would easily take double the time for development.Else if you wish pace, go for Jsps.And if Jsps surely go in for Ejbs. 3.Thinking of future purposes i think EJbs wud be a better shot.