I believe that Mike is defining a non-Web app as "one in which HTML is not involved at all" -- i.e., a fat-client or true client-server application. EJBs and J2EE are so much about drop-in, interchangeable, plug-and-play, click-to-configure, that good old-fashioned custom client-server definitely is generally not mentioned much. Most of the time when people talk about Java client-server, they tend to be talking about direct RMI or CORBA apps, not about J2EE.
Yup, i'm talking about actual Swing GUI apps, that do not in any way involve a browser.
Something along the lines (as I understand it) of what you'd be writing for your SCJD exam.
I'm thinking if it has nothing to do with web or web services, then J2EE is out of the picture. But there's several useful services that an EJB container can provide, I'm wondering if there's a way to have your cake and eat it too. [ November 07, 2003: Message edited by: Mike Curwen ]
Mull on this, an application like Zoe ( an application that indexes your own email box and provides it's interface through a personal webserver) is now just a few keystrokes away from any other desktop application. The desktop application is now the web application and vice versa! Taken from a Blog here
Some times the user experience requires a fat client and there is no reason not to call EJBs from a fat client. The "remote object" features of EJB make it a useful protocol for such things. You can think of your EJB server as a public service that can be used by fat clients, thin clients or anything in between. That said, the times a fat client are absolutely necessary are few. "XInternet" technologies that change the browser from a thin client to a "chubby" client by downloading their own UI management give pretty good user experience with no client installation.
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
Ahh, my favorite subject. Well we tried to go to a J2EE solution with Swing on the front end. Now this was almost 4 years ago. However, the problem wasn't EJBs and version 1.0 of them. It was Swing and printing reports. Well the biggest problem was that it took at least 5 minutes for any of the reporting tools out there to render our report. Now, Crystal Reports does have a Java class now that you can use, and this should solve the problem. Now, unfortunately because of the Dot-Com world, everyone thinks in Web Pages, HTML static or not Static. They don't understand that there is a huge market for Business Applications that have rich clients. There are other products out there that can work to. There is always VB, which for Windows is the best GUI environment for Windows, however, it is Microsoft, and you will be stuck in Windows. There is a product called Jintegra, which is a COM to Java bridge that could allow you to build GUI's in VB and use Java objects in there so you can have them use EJB's on the middle tier. There is also Oracle Forms, but well, I won't go into that. All in All, I don't think that Sun has really attempted to reach this Rich Client business applications well. And I don't think they will in the near future. Which is a bummer. I never found any documentation of best practices for this type of environment. However, most of them are the same for Web and Non-Web application. 1. Keep network traffic to a minimum. 2. Use Stateless Session more than Statefull Session Beans as much as possible, this will increase Performance. 3. Keep you code in the closest tier that will need it. for instance, if you have simple validation, that doesn't need to go to the database, keep that code on the client. If it is a business process, keep that in an EJB, and if it is data intensive, have that on the backend database, like a stored procedure. 4. Check out theserverside.com
Mark, I did the J2EE tutorial about 2.5 years ago. It had that "Rich Client" section, which didn't work (and I couldn't get to work). And since then, I've never heard of it again.
I really *want* to do webapp, because it's frankly what I know best. But there do seem to be certain situations that call for something more 'robust', 'fast' and 'full featured'.