Migrating a 2-tier Java application to...?
Asked Answered
C

6

6

We currently have a 2-tier Java Swing application sitting on top of MS SQL Server 2005. All the business logic is in the database. The client is quite old (and not very friendly), and for reasons of performance and scalability, we've already started porting some services to a middle tier in Java.

However, we still have a number of short and long term goals:

Pick a technology stack for a new front-end

This isn't easy - I can see everything from a web app at one end of the continuum to a traditional desktop app at the other being viable choices. The current front-end isn't really complex (mostly form-based), so I can see web/AJAX fitting, but it's an area where we don't know what we don't know.

Stacks on my list are:

  • Eclipse RCP, Netbeans RCP
  • Flex/Flash, Silverlight, JavaFX
  • Pure Javascript frontends (Sprout Core, Javascript MVC, ...)
  • Java-based Web frameworks (Wicket, JSF, ...)

Find a way of making the current application perform acceptably in a remote situation

We have some clients who resale our app to smaller clients and need to be able to remotely deploy it. Due to the 2-tier nature of the current architecture this leads to terrible performance (for example, calling a stored procedure that returns 18 result sets). We've used a Citrix solution in the past, but no-one likes that approach. Tunneling JDBC through port 80 also sounds like a bad idea. I was starting to wonder if there's anything that could use a X-Windows like approach to remote just the GUI part.

Cuddle answered 5/9, 2010 at 17:51 Comment(2)
Do you currently deploy both the db & swing tiers at your client sites? Are there any constraints on hardware that may influence your choice of middle tier?Rickets
Hardware isn't really an issue. We have 2 different types of client: one who installs everything at their site and others who have the client but use a 3rd-party for hosting.Cuddle
P
2

If you want to easily redeploy your application, for an update, security reasons, etc. and if you want your application to be it to be accessed remotely, you should really consider a web based front end.

Plus, this way, only one app, your web app, will handle connection to the database, so no JDBC tunneling or whatever.

Concerning the best framework, it depends on your team knowledge, the way your application will be used (more or less javascript), etc.

Principality answered 5/9, 2010 at 17:58 Comment(5)
The web is attractive for the deployment and update perspective, but then there's the politics of which browsers to support. That's not easy as clients may have policies on which browsers are acceptable.Cuddle
Most of the time when you use web frameworks your web application will be compatible with most of (if not all) the web browsers. It also means that your clients won't need Java/Silverlight on their computers.Principality
You'll undoubtedly get stuck with supporting IE6, but you can always hire a web designer to give you a site skin.Rickets
Not all browsers are equal - while the Javascript frameworks might work on all browsers, the performance is VERY variable.Cuddle
It's also very variable depending on the hardware used. You can't really control that.Principality
H
2

To simplify development and leverage your experience in Swing consider using Vaadin for your frontend. It is a Java framework for building modern web applications that look great, and perform well. All the code is written in Java and looks very similar to Swing.

As far as overall application architecture I would advise multi-tier, service oriented architecture. The best way to do it is by using Spring framework with Hibernate for database access.

Hale answered 5/9, 2010 at 19:7 Comment(1)
Disclaimer: I'm a member of the Vaadin team. Agreed, your app sounds to be exactly what Vaadin was designed for. With Vaadin you get to concentrate on your business logic and not to worry about web technologies, templates etc.Individualize
L
2

We've just gone through a very similar evaluation process as we're migrating a legacy application.

For us the biggest deciding factor in what front-end framework to use was the prior knowledge of the development team. We wanted something that everybody would be comfortable with immediately. We had a couple of the senior developers that have worked with X or Y, but the framework that everybody knew was Swing.

In the end we decided on the NetBeans platform using RESTful webservice to communicate with an EE server.

As a bonus you can get your NetBeans platform application to deploy as a Java WebStart application, which means you get the benefit of not having to worry about individual installations.

Lulululuabourg answered 25/6, 2011 at 21:55 Comment(0)
P
1

If the frontend is mostly form-based, I would stay away from Flex. Flex is great for some applications (I'm using it for a canvas based application), but the form components of Flex has some usability issues. They just don't work like you expect from todays web. (like missing support for mousewheel, typing in dropdownlist only take first character into account etc.)

Prepossession answered 5/9, 2010 at 18:12 Comment(0)
R
1

Assuming that you are going to force all your clients to install a new middle tier, I can't think of an argument against making it a Java web app. As already mentioned you have the benefit of controlling all access into your platform over HTTP, which allows easy resale, just with firewall configuration. There's no reason you can't make use of Javascript within a web front end, you may be interested in DWR, which allows you to interact directly with Java objects via Javascript. I've used this before to add some simple Ajax interaction to a Spring MVC webapp.

The reasons I like this approach, you're already migrating code into Java middle tier, so

  1. Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
  2. Already have Java expertise, can be leveraged with DWR
  3. Can use as much/little Javascript as appropriate (I've used DWR with IE6, Firefox 3, Chrome)

I think you're right to be wary of pushing too much functionality to the client, I'd go for as thin a client as possible. The only reason I'd look at the first two stack choices would be if you have some developer expertise in a particular area, and not Java webapp/Javascript.

Rickets answered 6/9, 2010 at 7:4 Comment(2)
Is DWR still alive? The website is down and the last release was over a year ago.Cuddle
I don't know if its still in active development, but its certainly production ready, and there's a very good book about it - books.google.com/books?id=xORZWVLWu-8CRickets
I
1

I'd suggest to create a short list of candidate frameworks and create a small test application with all of them. This way you will get a sense of good and bad aspects from all of them and also get a picture what the community activity and documentation is like for each project (there is a lot of variance on those).

If you end up doing this I hope you'll include Vaadin in your short list, I think it would fit you very well. If you have any questions just come over to our forums and we'll help you to get started.

Individualize answered 6/9, 2010 at 9:38 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.