I've got an application here that I wrote many years ago that consists of a heavy-weight front end that directly queries a database server. This application runs on about 7 dedicated workstations. There is also a web-based front-end that I whipped up that shares the same feature set, and a web-based administration too for managing and reporting on the data -- they all just hit the database directly.
The application is quite simple and I understand the problem it solves very well. It could use an update, and I don't even have access to the tools necessary to work on the GUI anymore. I've been getting into Java lately, and it seems like a rewrite of this app would be a good project to get started with.
So my question then is this:
The application will require a non-web GUI, I suppose in Swing. This is necessary for very particular reasons. The application will also require a web-based GUI with the same exact features as the Swing front that will probably be deployed as a JSR-168 portlet, and a web-based administration tool (portlet also). With my previous design I ended up with a lot of duplicate code because each component had its own code base, and I foolishly used stored procedures to help to ensure that critical calculations were at least consistent.
Where should I start? I'm having such a hard time wrapping my mind around how this should all work in the Java world. I guess what I'm having the hardest time with is how do I create an application that can have both a Swing (or whatever) front-end and a web-based front end with as little duplication as possible?
Edit: I know conceptually how this can work. What I'm asking is for advice specifically related to Java technologies. Which frameworks to consider, etc.
Build a Core that contains the business logic. Use JDepend or a similar tool to ensure that it nowhere references anything swing or anything web/jsp/servlet.
Build the two UIs: For the web version pick a webframework of your choice and call your business logic from there.
For the Swing framework you have two options: access the businesslogic through webservices (you could use RMI or whatever, but I wouldn't), i.e. the logic is on the same webserver that serves the webapp (I'd probably prefer that). The alternative is to ship the weblogic with a swing GUI. Makes the coding and debugging easier, but now you have multiple points that access the db which causes headaches when you want to use caching
In any case you should only duplicate the gui stuff, once in html/css/javascript and once in swing.
Congrats on that project it will teach you tons about design and software architecture
You should have a project with all business logic.
Then, 2 separated projects, 1 for the web access, and 1 for the Swing application. those projects both calling the business logic API.
in these 2 projects, have only presentation code
Use a middle tier server.
Swing Client -> middle-server with spring-remoting -> database
Web Client -> middle-server with spring-remoting -> database
Web Client write once any MVC framework will work stripes, struts, even grails if you are brave rememder to keep it thin....
Swing Client write once using miglayout, and glazelist.
http://www.miglayout.com/
http://publicobject.com/glazedlists/glazedlists-1.8.0/
take a look at this posting.....
Java Swing: Libraries, Tools, Layout Managers
Middle-server write once using jdbc cause you have the db already..
http://www.springsource.org/
database write once using whatever you like. It seems already have this....
Obviously start with a unified code base. You might also want to consider whether you really do need multiple interfaces.
You want to make sure that your code does not have unnecessary dependencies. For instance, make you UI as shallow as possible, rather than the usual ball of mud. Avoid singletons, as they cause dependency hell.
It may seem very enterprisey to have a middle tier, but it also adds a lot of work. For a small group it is entirely pointless.
Related
I want to make a Android Application of grocery stores. I have an existing Wicket Application deployed on server which I want to use in my Android Application for request handling. Is it compatible to use wicket application for android part.
There are 2 ways:
Use existing Wicket Application for request handling from Android Application. Can some one suggest me is this possible or is this the right way? If yes how can I achieve this and some tutorials are most welcome.
Second thing I thought about is integrate Spring with Wicket and migrate all my service classes to Spring and then use those spring service classes for Android Application. This approach is little costly and time consuming. But if first aprroach is not so good, I might think of opting this. So any tutorial on this part is also welcome.
Any help or advice appreciated. Thanks in advance !
I would definitely suggest to choose some sort of option 2. It doesn't really matter if you migrate your services to Spring, EJB or whatever, but the separation of services (or business logic or whatever you want to call it) and the view (or presentation or layout or...) would come in very handy in this case.
I firmly believe in the saying "premature optimization is the root of all evil", meaning that you should really skip any additional layer or indirection you simply don't need. However, if there actually is a use case which justifies a separation into different layers (or abstraction levels or...) you should tackle it as soon as you can. You will benefit a lot from it later on.
Just think of the Wicket application and the Android application as two different presentations of your grocery store. If you clearly separate the business logic from the presentation and make it accessible via HTTP (be it RESTful, SOAP or whatever way you prefer), you can easily imagine building an iOS, Windows Phone, you-name-it presentation of your grocery store without touching the core itself.
Hey,
i've a simple question.
Task:
Program a backup system which can be used by server-, or desktop-systems. The backup system should include a graphical configuration and status view. The programming language should be Java.
Question:
Would you use a web interface, which will solve these jobs or would you create a GUI in Swing?
My thoughts:
- The web interface has the advantage that is is accessible from everywhere (server - configuration made easy without any additional software on the client side).
- The GUI has the advantage that it is more responsive than a web interface and will maybe look more professional on a desktop-system than, the web interface version.
Which solution whould you choose?
Thanks!
The desktop vs. web app discussion usually depends on who would use the application, and from where. If it's always going to be used by the person sitting at their desk (or at the desk of the server), a desktop application is a good choice. If the user may be remote a web application is the way to go.
Another consideration is deployment. Is this going to be deployed on one or two machines, or does it need to be installed / available to 10's, 100's or 1000's of users? Deployment and updates across hundreds of machines can be onerous for desktop applications, but a non-issue with web-based apps.
Generally speaking, you can give a much richer experience with a desktop app. In this case, however, "rich" isn't really a requirement. You're going to have a few buttons, perhaps a window showing a log of some sort, and that's about it. So from a usability perspective you can probably create a compelling UI using either method.
If deployment and a rich UI don't really factor in, pick the one that either a) you know well, so you can do a good job, or b) want to learn assuming you have the time.
Since the actual question you asked was "which would you choose", personally I'd choose a desktop GUI based on the little information provided in your question.
Yeah Bryan is totally right. Choose the solution you prefer, since you are the developer :)
I'd prefer the web solution, because I love to play around with these nice Web 2.0 AJAX/JS things. Also there are at the moment a few new Browser Developments, which will make it possible to use an webapp as desktop app.
Basically, it's really no matter which variation you choose.
I did serious Swing work in the past but I see less and less the incentive to use "fat client" technologies with today's web based UI (Ajax, JQuery, HTML5 and efforts like html5boilerplate.com to make them work on older browsers). The browser is the present and future of rich UI, specially as more software makes the move to the cloud.
I want to start developing a little web-based game, and would appreciate some advice before I get into it. Hopefully this is the place to ask!
The game is basically a fantasy-football style game, where you create a team of players which compete against other users. Nothing fancy.
I haven't coded much since college, and am very rusty. I want to code in Java for a couple of reasons:
It is the language I am most familiar with.
What limited development work I have done since college has been in Java (I have some novice-level experience with Tomcat and Glassfish, i.e. I have got them running and deployed basic webapps I've coded from scratch to them).
I really like what I have seen of the GWT framework so I would like to develop my GUI with that.
The last time I did any programming was about 3 years ago when I wrote a web front-end for a crappy helpdesk system that only had a thick client and a web API. That was done in Java.
So basically, first up, I want to get a skeleton game up and running. Basically allow a user to log in, see their team, log out. So my questions start with:
Is there a particular development framework I should be reading up on? I've seen Spring recommended - is this a good choice? I've found this to get me started if it is the appropriate choice: http://static.springsource.org/docs/Spring-MVC-step-by-step/
What is the easiest way for me to handle login/authentication/authorisation without having to write a security system myself? Hopefully there is some kind of framework/library I can just drop in to the code? Or does Spring Security handle that?
I really like GWT - are there difficulties integrating that with Spring?
Many thanks for your time, I really appreciate it!
Spring is a good choice.
Check out the Spring security module. It's based on aspect-oriented programming ideas.
Looks like Spring does support GWT. It's relatively new (May 2010).
If you're rusty with Java, you might want to minimize the new technologies you introduce at one time.
Java's an object oriented language, so you can write the objects you need to model your game and get them running without any UI or database at all. That would allow you to focus on the game, the objects, and the use cases without getting wrapped around the axle with UI, security, persistence, etc.
Once you have that sorted out and fully tested you can turn your attention to the other features: persistence, UI, security, etc.
Maybe you can try basic authentication/authorization before you dive into Spring Security.
If you bite off too much at once you'll never get this done. Take small steps.
Spring is the par exellance example of what the cool kids don't like about Java. Many, many configuration files that make every aspect of the app customisable but is difficult to keep in your head where stuff belongs. If you are not a huge company this is almost certainly not what you need.
I would encourage you to look into the Play or Wicket framworks if you want to keep using Java. Both are conceptually simpler, don't throw in the kitchen sink and are heavily geared towards web sites. Spring MVC is just a part of the very large Spring ecosystem.
For the Inversion of Control (Dependency Injection) paradigm that Spring often is associated with, I find Guice way more awesome.
I'm about to start developing a large-scale system and I'm struggling with which direction to proceed. I've done plenty of Java web apps before and I have plenty of experience with servlet containers and GWT and some experience with Spring. The problem is most of my webapps have been thrown together just to be a proof of concept and what I'm struggling with is what set of frameworks to use. I need to have both a browser based application as well as a web service designed to support access from mobile devices (Android and iPhone for now). Ideally, I'd like to design this system in such a way that I don't end up rewriting all of my servlets for each client (browser and phone) although I don't mind having some small checks in there to properly format the data.
In addition, although I'm the only developer now, that won't necessarily be the case down the road and I'd like to design something that scales well both with regards to traffic and number of developers (isn't just a nightmare to maintain).
So where I am now is planning on using GWT to design the browser-based interface but I'm struggling with how to reuse that code with to present the interface (most likely xml) for the mobile devices. Using GWT RPC would, I think, make it relatively easy to do all of the AJAX in the browser, but might make generating xml for the mobile phones difficult. In addition, I like the idea of using something like Hibernate for persistence and Spring Security to secure the whole thing. Again, I'm not sure how well those will cooperate with GWT (I think Hibernate should be fine...)
There's obviously a lot more to this than I've presented here, but I've tried to give you the 5-minute overview. I'm a bit stumped and was wondering if anybody in the community had any experience starting from this place. Does what I'm trying to do make sense? Is it realistic? I have no doubt I can make all of these frameworks speak the same language, I'm just wondering if it's worth my time to fight with them. Also, am I missing a framework that would be really beneficial?
Thanks in advance and sorry for the relatively broad question...
Chris
I'll be pretty specific here since I have some related experience. Not all of what I'll write will apply, but I'm hoping something does.
My 1. advice would be to keep any code that's directly dependent on any framework as "stupid" as possible. If you can, consider such code more or less disposable (implementation wise, API contracts exposed to clients needs to be stable of course).
Focus on what makes your application unique, and try to make that independent of GWT etc. The facade pattern is something I can recommend - keeping the app-specific logic behind one and exposing it by wiring the presentation layer with it has served us well. If your back-end depends on third party infrastructure (via web services etc), decouple those dependencies from your code with the adapter pattern.
I have spent most of my working time during the past 5 years on building something that matches what you described in many ways. Today it's more an app framework then an app - it has a few different browser interfaces (WAP/standard web+ajax/Facebook app), an interface for 2-way SMS usage, and a REST/XML interface for thick mobile clients - BREW, iPhone, Android and Blackberry.
When it comes to frameworks, for persistence, we have used Hibernate. All the different pieces of code are tied together with Spring. The browser interfaces have been ported from Struts (1.x) to Wicket. The SMS and mobile client interfaces are built on top of Restlet.
Using multiple different presentation layer frameworks (such as Wicket and Restlet in our case) has not been a problem, as long as that code is kept lean and business rules are kept out of it (to the extent possible). There is nothing that says that your browser interface has to be packaged into the same WAR as your mobile client interface - with Spring you can easily wire several web applications with the same facade. This has been helpful to us especially in allowing multiple developers to work on well isolated pieces of the application.
In my opinion, trying to achieve maximal reuse of code in the presentation layer has caused more harm than good. That has always been the most volatile part of our application, beyond what we have been able to expect.
I posted this question: https://stackoverflow.com/questions/418597/java-and-net-for-php-programmer and the answers I was given didn't really help me out.
I read a few of the tutorials at sun.
The basic syntax I understand. The thing I don't understand and really need to (because I think my company is going to tell me start working with this) is to learn how to work with java for the web. I am a php programmer and I did some asp.net c# a few months ago. I am really not understanding how to work with java on the web.
I installed netbeans.
When I start a web project I also get asked what frameworks I want.
I don't know any java frameworks (I do know about spring but never really worked with it).
Is there no simple tutorial on how to do some java for the web??? I never had these much problems when I was first introduced to php :(
Someone help me out, or at least point me in a good direction.
You may find this question helpful.
All you really need to know is HTML, Java, and JSPs.
Creating dynamic content is very easy using JSPs and Java. You also need a webserver like Tomcat or Glass Fish.
As far as the back end Java code goes, there is no difference between that and a desktop application. The only thing that you are changing is the user interface. One of the biggest challenges with switching to a web interface is the fact that it is stateless by design.
The frameworks make web programming easier, they're not required. You can write web applications using plain old servlets and JSPs (with a web application container like Tomcat or JBoss) or even do all the HTTP I/O yourself (obviously that's pointless with Tomcat, etc, around).
A framework like Spring with Hibernate, etc, is similar to frameworks in PHP like CakePHP, they make development easier, they enforce sensible patterns (MVC) upon the programmer, the abstract code that is always going to be done the same way for this type of application. Yes, they limit your choices and abilities, and restrict the actions you can take, to varying degrees. Some are far more heavyweight than others. But there's a lot of choice in the Java world which is a strength, but you just have to spend time evaluating them, and picking one based upon your capabilities.
Take struts and tiles. You can simply use Struts as an MVC system and avoid all of the utility JSP tags it provides. It would take you a short time to rewrite the functionality you end up using yourself, but that's time you don't have, and then there's debugging, and specific domain knowledge and experience that you can't account for.
Are you familiar with MVC? There are multiple frameworks in Java that implement it. Struts is one of the more popular. It may help to start using Struts and work through a tutorial.
This tutorial is a good one that also will introduce you to spring.
This tutorial deals with struts in netbeans
By technical side, you can start downloading Tomcat and code the exercises and documentation.
By "architectural" sie, you code in Java the business logic, that is all the components that take the parameter by communication client-server (request), manipulate this and use this for create the result.
this result is give to communication server-client (response) and it appear, with presentation layer (JSP, etc) in the web page.
The explication is very preciseless and not very "orthodoxe", I know.
It's matter that you understand.
The programming model that is (in most cases) used when writing a Java web application is actually a subset of J2EE. Not a rocket science, but there's a need to know at least bits of it.
Get yourself familiar with concept of J2EE Web Container, J2EE Web application, it's descriptor (web.xml), Servlets (which are, in fact the basic "building stones" of any J2EE webapp) and, of course, JSPs.
Sun has many nice tutorials on their's web pages. Googling any of the above terms with "site:sun.com" usually brings good results (e.g. this one about the concept of Servlets: http://java.sun.com/products/servlet/articles/tutorial/ ).
I'd also forget about web frameworks first, and start with the J2EE stuff, then MVC as a design pattern. After that, go into the web frameworks. Use of a framework is usually of a great help, but even when using one, you still need to know the basics.
Since you're using NetBeans, start with the tuturials they have on their site.
http://www.netbeans.org/kb/docs/web/quickstart-webapps.html
Go through the simple tutorials on the site before you start going into the details on any frameworks.
Java webapps are pretty simple. You have your Java classes (.java) that handle your business logic and your .jsp files that handle the presentation. Try and keep them seperate. You also want to familiarize yourself with the JSTL tags and el (expression language) syntax