Web tier: servlets, JSP, Web frameworks: Swing vs. JSPs: looking for feedback
Just looking for some feedback for people that have used Swing and JSP in an enterprise-wide system.
- Posted by: John Curley
- Posted on: July 01 2004 11:37 EDT
We have a number of systems we are developing -- early stages. Many integrated applications. The particular application I am an architect on has the following attributes:
* Mission Critical, 365/24/7
* Tens of Thousands of users and pc clients, also other potential clients (bar scanners, tablet pcs, pdas)
* Enterprise-wide system that will reside at 100+ sites
* Will be using J2EE for middleware and probably Hibernate to access back end to access very confidential and vital data
Some people want to use Swing for the front end, others traditional web application (jsp, html, etc.)
Can people give me the pros and cons of Swing and JSP in the above mentioned environment?
My experience in the Java/J2EE world has been traditional web/jsp/html/struts/n-tier design/programming (I was a Microsoft C and C++ engineer in a previous life).
Thanks for your help,
- Swing vs. JSPs: looking for feedback by Sohail Sikora on July 01 2004 12:23 EDT
- Swing vs. JSPs: looking for feedback by Roger Chung-Wee on July 01 2004 18:15 EDT
- suggestion by krishna kishore on July 02 2004 02:44 EDT
The fact that you envision usage of different devices, points to having to build multiple front ends.
PDAs can access web apps. However, with the lack of screen real estate and factoring in the use of wireless technology, you will have to build a front end rendering tier based on what the incoming request is.
Swing may not be a good choice. If you use WEB front end technologies, you maybe able to reuse some code across the various rendering mechanisms.
In addition to the above, the cost of having J2EE Developers and SWING developers on the project, would, in all probability settle the dispute in favor of the web.
You have asked for pros and cons of Swing. I am sorry but I cannot find a case for SWING based on the project info you have given.
One question though -- The PC clients and tens of thousands of users that you mention, will they be intranet, extranet, internet or a mix of all the three??
The PC clients and tens of thousands of users that you mention, will they be intranet, extranet, internet or a mix of all the three??It will be all 3: intranet, extranet and internet. With encryption etc. going across public lines/feeds.
Thanks for the useful feedback. I am agreeing with your assessment on Swing vs. JSP, however the org I am contracting for is a huge conglomerate in which I have no decision power at this level. The org is new to J2EE and most of the in-house technical people come from old school mainframe environments.
Presently, I am drawing up a case that I will eventually submit to the powers that be.
If making a case to a Mainframe audience, you must include the costs involved in maintaining, deploying and troubleshooting clients over thousands of users. Also, coming from a mainframe environment, I think it would be easier to emphasize the advantages of keeping the application hosted and maintained at one location.
You could also suggest the use of the existing Mainframe infrastructure to deploy and maintain the Enterprise application. There are instances of WebSphere being used on zOS and OS/390.
Do you have specific links to the cost benefit involved in swing vs jsp clients? I have a project where a subsystem is already developed in swing j2ee business tier type of architecture and we are investigating the possibility of changing that architecture to a thin client for the other two subsystems. Remember that the user population is intranet not internet. Can you think of advantages given that user group? Can you share any statistical information that you may have?
In an ideal world, you would do what it takes to meet the business requirements. I'm assuming that the internet users need a client which will be a browser. But will the intranet users need richer functionality which only a Swing client can provide? If so, then you have your answer. Otherwise, develop a web client and ensure that your presentation tier can cope with other clients which will be plugged in later.
Of course, it goes without saying that, regardless of the client, the business logic will be written once.
As a matter of interest, what container will you be using? It will have to be heavyweight, I think.
Oh, just another thing: don't underestimate how much effort it can take to get SSL authentication going. What can happen, at least in my department, is that you need to work with an awful lot of people who may not have all the answers ...
Based on the requirements listed so far, it sure sounds like a Web approach would be the best. You need to factor in not only the size and diversity of the user environments; you need to match the solution with the skill sets of the organization. I agree with the earlier comments about a mainframe company would find a web solution more natural. And assuming that the majority of the clients will be using Web Browsers, a web solution would obviously fit. Swing is a good technology, but requires very different skill sets and application architecture than a web app.
I disagree with the statement that if Swing-like richness is needed, Swing is the choice. There are solutions, including a product from my company Nexaweb, that can provide Swing-like richness deployed within a web browser, and using JSP/Servlets for middle-tier integration.
That said if your application doesn't require rich interaction or server side data push, you'd be much better served using vanilla HTML for broadest client environment support, and development tool support. For example, bar coders and scanners usually don't care about drag and drop user interfaces ;-)
If you can provide more information about the application's UI richness needs, communication restrictions (high latency or low bandwidth environments can be very problematic for interactive HTML apps), need for server-side data push or the client environment assumptions (web browsers, presence of Java, etc.); I'd certainly be happy to offer more thoughts.
Swing : I think swing re quires more amount of RAM on the client gadgets .. that cannot be possible on reality .
JSP on the other hand has some edge over swings ..