This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Ok, I am not entirely sure if that is a right forum to post my question. It has many aspects (I think), it is rather a question of architectonic nature. Please correct me if I am mistaken posting it here. I am trying to decide on architecture of a solution that has rather complex UI in the back office component. This app will be hosted in one place and accessible by clients from all over the world. It will have to be accessible trough firewalls with not or minimal configuration at clients firewall settings (port 80 using https). I am trying to figure out if it is feasible to use applet swing client. I have not seen many projects using this approach as a mater of fact just one. It was rather complex time tracking/accounting system. I was not very impressing with speed of the interface at times (dual processor). I could not see any prohibiting risk when I thought about this yesterday. I am starting to suspect that this whole HTML interface (APS/JSP) thing is web designers conspiracy . Risk: -Java Swing performance (I am not sure it that is still the case), -Maintainability (client code will be on client workstation how to manage updates and version control WebStart?), -Proprietary protocol over HTTPS and in case of use of XML considerable stress on client�s workstation resources ergo performance drawback, Benefits: -Sending just data not interfaces over the network therefore lower traffic (not sure if that is very important when using proxies on client side), -Event driven interface with well defined and proven components therefore more intuitive, consistent and maintainable, -Productivity tools available, Any thought ideas, pointing out my faulty logic or misinformation will be greatly appreciate! Best!
Fat clients are appealing because you can do a genuine stateful business object model and some very sophisticated things with the user experience. And as you said, you can keep data in the client and work with it all day without calling the server. The big negatives are all those deployment and configuration problems. Avoiding conflicts with other apps on the desktop, pushing releases, etc. I see people using more and more thin client even in the corporate setting where we own and control the user's desktop machine. Total Cost of Ownership is a big deal.
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
Guys, Thanks a lot for your valid suggestions. It seems that WebStart mentioned by Thomas takes care of problems with deployment aspect of maintainability (run time environment and versions) therefore TCO should not be affected here. I intentionally used �fatter� instead of fat client. That might be a crazy idea, but I intend [not sure exactly how yet] to use it as a stateless client just for sake of benefits [is that proper English sentence ] that Swing gives in GUI development over HTML derivatives. Thanks again.
just an aside really. i like doing everything on the server when i can. the app looks the same to everyone, and no browser problems. of course, as you mentioned, you have an intensive interface and many simultanious clients. in some ways its nice to have a record daily user rate of 20. :roll:
And don't forget that there are a whole range of options between a wholly-client application and a wholly-server application. For example, I've seen a few fairly impressive applet clients where most of the processing, and even the UI configuration, is on the server. A generic UI applet recieves instructions from the server about which swing UI components to lay out, where to put them, and what to do with the events generated. The advantage of this is that it's easy to use regular HTTP as the client/server transport. I recently saw a demo of a pre-built RAD framework like this from Mart Technology, but it's also possible to "roll your own".
Thanks! Specially thanks to Frank for Mart Tech link, must check it out ASAP. I see three aspects to this decision. Maintainability I will need to have HTML base interface no matter what. This app has front and back office. Front office is traffic intensive but with simple interface. So using load balancer and web container + sending messages to (MDB) search and submitting loads of data should work like a charm on front office side. While back office is transactions, processes and basically used by a user throughout his entire day of work. Deployment seems o be not a problem when employing WebStart although it adds to complexity and managing complexity, specialty the more complex ones is not easy. Keeping it simple Introducing two different sets of tools for developing UI is not wise. Needs more resources and discipline and in result is costly. Productivity : I need productivity TOOL that kicks [Three character word]. I can much easier get it done with Swing applet then designing HTML with GUI artists and such. Their designs needs to be redone with JSP/Struts/Sofia guys. It takes time and is tricky but looks prettier and my users are used to HTML interface, I still suspect they would love Swing, this must be validated with prototype. I cannot make up my mind! Thanks again!
Originally posted by Frank Carver: A generic UI applet receives instructions from the server about which swing UI components to lay out, where to put them, and what to do with the events generated.
Well this is what I thought I should do to have a cool dynamic client GUI, but it was for a Midlet (j2me) so I though this is infeasible, because of the constraints imposed by the mobile device (memory and CPU speed), and I will end up having an �interpreter� of my own language running in a mobile device on top of KVM which is interpreted to the underlying OS all running on a slow CPU Is this feasible, or it would not even run?
MIDP vs. WML. I had this dilemma on my last project it went down to MIDP not being easily deployable and maintainable on all kinds of phones (it could be anything but my app was for phones). WML is totally client independent but lacks well defined interface. Exactly same problem with swing and HTML. MIDP is of course the choice for all off line capabilities. Ok. Lets get back to my problem! I cannot put my finger on it put there is some problem with Swing Web based clients, perhaps it is this proprietary protocol that needs to be developed for communication with the server. BTW I remember seeing something in the vision document [or somewhere else] about enabling my users doing work off line. Is it really necessary and good idea to spend money all this hassle with keeping data up in sync. IMHO if you are at a place that dose not have net hookup you should not be working anyway. Best and thanks again for all your help. BTW I came across this little thing called WebCream http://www.creamtec.com/webcream [no it is not a porn outfit] it lets you port Swing apps interface to web with no effort and there is something called XUL (XML UI Language). I must investigate. Best! [ February 21, 2004: Message edited by: Michal Harezlak ]
Joined: Dec 30, 2003
Thought about xHtml, Symbian OS Epoc, windows CE, Brew , wap and chose J2me.