I have a rather large (80k loc) java desktop app that talks to a database. We're now looking at exposing some parts of the database via a web application, using the existing codebase and preferably not having to modify it.
I have good separation between the data access, business logic and presentation layers, but we haven't used enterprise java beans or anything like that (if that's important).
What's the best way forward? Which of the java web frameworks will be best suited to the problem? Learning curve isn't terribly important, since I haven't done any java development on the web...
To be true, it depends what you already have, and how well is the design of your current desktop application. You might not be able to use any or may be minimal of your existing code without modifying it, if its designed badly, and everything is tightly coupled.
Assuming that you are having a system with a good design, everything is de-coupled well enough. You can look into Stripes to make your presentation for the web, and use your existing data access and business code. I wish you all the luck.
Few other goodies to look into are, Groovy on Grail, Wicket.
I don't recommend anything like Seam and Spring they are more of a container and sophisticated large frameworks, which give you almost everything, solution for almost all of your problems. As you mentioned that you already have a complete system, and you just need to make a web interface to publish it for the web, these are not recommended, IMO.
JSF, is a good framework, but it might drive you nuts and has a big learning curve, according to few folks.
The two frameworks I would recommend would be Grails and Struts 2.
Grails comes with a whole bunch of stuff that it configures under the covers including Hibernate and Spring. It makes generating dynamic pages to send to the browser ridiculously easy. What you are probably going to need to do is set up controllers that call Grails services which reference your existing code as you probably don't want Grails managing your database interactions. The disadvantage with Grails is not so much that it is written in Groovy, which is easy to learn for Java programmers, but that the IDE support for Groovy is still maturing. Still if you want quick productivity this is the route to go down.
Struts 2 offers a clean command pattern framework implementation that talks to JSPs (or velocity or FreeMarker templates) on the front end. To use this you would configure actions to call your existing code. You may want to investigate adding Spring to the mix depending on what you need to do.
There are other choices but these are two that I have had some success with.
Related
I'm starting my research on web application frameworks and according to what I've read, web application frameworks provide ORM and basic UI's through scaffolding. But I had ORM already done. What other benefits do frameworks provide? do I still need one? or in case not, What other technologies could I use?
I'm working on Java and was considering Grails and GWT. Thanks for your responses!
Depending on the framework you choose, they can provide a number of other benefits in addition to data access:
Simplified URL configuration
Templating system for page content
Security (authentication and/or authorization)
Methods to streamline Ajax requests/responses
Use of conventions to reduce/eliminate ugly XML configuration
Caching mechanisms
Some frameworks provide most all of these things in addition to data access -- Grails, Rails, Django and CakePHP come to mind. Others are primarily concerned with view and controller logic, and do not include a specialized data access component -- GWT, Struts, Spring MVC and Wicket, among many others.
But do you need a framework? It really depends on the scope and constraints of your project. If a framework can eliminate the need for you to custom-develop a few of the items listed above, and you have the time to pick it up and gain the productivity offered, I say go for it.
I'll also say that many jobs prefer or flat-out require experience in certain frameworks. Gaining at least a fundamental knowledge of more frameworks is always a good thing, opporutinistically speaking.
Just put a web front end on your existing persistence tier if you've got it done.
To preface I am new to web development. I am looking at creating a core set of RESTful web services around a valuable document library of sorts (initial CRUD abilities). In doing so I am theoretically creating a perfectly re-usable and scalable back-end to be used by unanticipated applications in the future.
My question centers around the best practice for doing this. My initial requirement has me also creating a unique front end. Would I make the front end and back end completely separate projects to enhance the re-usability. It would increase overhead.
Looking at using GWT, Restlet, and the Java EE technology stack if this influences the setup at all.
Most important is design a clean Java API - independent of REST, RMI, or whatever protocol you want to use. From a clean Java API, you can support any access method.
Unless you have a use case for these other access methods, don't build them now. You can build it when you need it.
The easiest interface to add initially is a web based interface where your web app runs in the same JVM as your core API. I'd do this if this works for your use case. Building a separate console application that accesses your core API via a REST (or whatever) protocol is a lot more work..
Martin Fowler wrote a very nice article about the basics of REST short time ago: Richardson Maturity Model. Found it very helpful to understand the principles of REST.
If you want to use REST based backend services, you should use the RestyGWT project which allows you you to use a GWT-RPC programing style to access your JSON based restful services.
The nice thing about using REST based JSON services over traditional GWT-RPC services is that those services can then be used by other clients or even in mashups more easily.
You may want to consider using GWT-RPC instead of REST if you know you're going to be using GWT for the frontend. More discussion here.
However, if you think you might want to eventually expose your data via a REST API, or use a different technology on the frontend, REST may be a better choice.
The gwt-rest project may also be helpful.
A colleague and I have written a GWT system using separate projects for front and back ends. It has been helpful to keep things quite clear about where the code is executing. But I'm not sure that I would bother separating things in a future system.
Also, given you're new to web development, I don't think you should be expecting to make a perfectly re-usable backend. You will learn lots of things as you go. I think that agile coders would recommend an iterative approach of (a) getting a small aspect working, and then (b) refactoring it to make it beautiful.
I work in a medium to small team ( 10 people ) developing and supporting several web enterprise applications.
We have a dozen of them built with a house-made framework with asp-classic working against ms-sql server.
We are evaluating the migration to a new development stack.
We'd like it to be open (free) and simple.
I've been looking around the java web frameworks, but all of them seem to be extremely overbloated for our needs (with the possible exception of http://www.playframework.org/, which I couldn't study yet...)
We are thinking about porting our own framework to this new stack, rather than adopting a whole new stack that we are unaware of ...
so far now, we though about the following possibilities
plain java - jsp - jsf
groovy - gsp (no grails at all)
jruby (no rails at all)
we feel really comfortable working with dynamic languages (well, as dynamic as classic asp can be) and with a lean and understandable framework...
I see no small and simple web frameworks for java, like there are for php or ruby...
I really like groovy, but I see no web implementations outside of grails... Besides the language documentation doesn't seem to be quite complete (I might be looking in the wrong place, perhaps)
php could be an option, but I think it would be hard to advocate for it in my current work...
any other option, advice, pros and cons?
thanks a lot
--
edit
some related link Can anyone recommend a simple Java web-app framework?
I'd suggest you take another look at Grails. It does use hibernate and spring under the covers, but for most situations, you don't need to know the details of those frameworks. There's a large community and lots of documentation/blogs/mailing lists for support, as well as a thriving plugin community with over 300 plugins solving pretty much any need.
If you're still put off by grails, you could look into the play framework. I don't have any experience with it, but there has been some traffic recently around it on hacker news and the like. I know it uses groovy for the templating language.
I cannot recommend anything, but strongly recommend that you consider these things:
Rapid development. Basically you want to save a page file, and reload it in the browser. Instantly! It can be done, do not settle for long deployment times.
Plain, readable text files!
Convention coding instead of explicit coding - big XML files will eventually drive one or more developers insane. The less, the better.
Good tool support (just having syntax coloring may be a big help)
Consider the long term support of your choice. You are basically remarrying with your software - will it still be maintained in 10 years? By whom? Will you have alternatives (JSR's are great - look at the amount of servlet engines)?
And WHEN you choose - get the source code for it, and ensure that it builds correctly. It will never be easier than now, and some day you WILL need to fix something inside. On short notice! (You may even consider allocating resources for donating documentation/patches/time to the open source project you are building your business on).
EDIT: A few more things:
You want to be able to verify things at compile time. One of the things that make it possible to build cathedrals in Java is that the static typechecking prevents a lot of nasty runtime errors. "Oh, THAT method? Well, it's not here, sorry. Boom!"
You want good error reporting. Built in! Try throwing a NullPointerException deep, deep down and see what 1) the user and 2) the developer is told about it. Anything that requires going to a log file to get the details WILL cause calls at 3 AM eventually.
Look into scalability from the start. Any non-trivial customer will need to and the world goes to multicores, so you might as well think about it already now. What will you do when all the magic pixie performance dust has been used and it just isn't enough: The application requires more than a single box.
And read this: http://www.pragprog.com/titles/mnee/release-it
You're forgetting about the other major player in this field: the LAMP stack (linux, Apache, MySQL and mod_perl). All components are free, there are many books available on LAMP development and each of these components, and there are vast numbers of libraries and components already available.
Apache: the Definitive Guide
Learning Perl: by SO's brian d foy
Practical mod_perl
If you are afraid of Grails and need Java, try Stripes and read the excellent Stripes book (http://www.stripesbook.com/blog/). You can buy the eBook pdf for $23. The book covers the framework in amazing detail. Stripes is a very strong, lightweight MVC framework that deals with all the common problems of web development (templates, url mapping, form validation, security, internationalization, testing) but it won't automagically create the database layer for you unless you want it to by using Stripernate. You can also use Groovy with it. You can use it standalone or with Spring.
I've had great success in simple web projects using Spring MVC with JSTL JSPs. Spring MVC is a framework that can be kept pretty darn simple (1 additional XML file used for configuration). You can eschew all the fancy options and just specify a set of JSPs that you want to associate with view names, then forward to those views by specifying their names in the controller.
Spring MVC can also easily scale up and be as complex as you need, letting you switch from JSTL to JSTL with Tiles, or Struts, or JSF, or Wicket. It can also handle complex web flows using the Spring Web Flow project. But for most projects I just keep it simple -- build a JSTL JSP, create a controller that provides the objects that JSP needs, and associate them by having the controller return that view. Once you get the project set up and you're familiar with the configuration, it takes maybe a couple minutes to wire a new page into place.
If you like Groovy but don't like Grails you could try Gaelyk, which is a lightweight Groovy framework. However, AFAIK you can only use Gaelyk if you're hosting the app on the Google App Engine
If your apps won't be hosted on GAE, and you really don't want to use Grails, another option is to use Groovlets, Groovy template servlet, GSPs.
However, personally I think it's a big mistake to dismiss Grails. It really is a great framework, and you can go a long way without knowing much about Spring and Hibernate. One of your complaints is a lack of Grails documentation. I think you must have been looking in the wrong place, because in addition to all the books available, there's a very extensive reference document and a lot of other documentation available on the website. Finally, there's a very active mailing list.
My platform of choice is JRuby - Rails (3) because of its very rich and powerful ecosystem, but mainly because:
* very easy to use
* many MANY libraries
* fast support via IRC
* deep documentation
You can also check out Scala + Lift Web Framework ( imho best static typed language, nice framework )
Alright, so I am a compsci college student who, being in college, has not branched out towards a certain specialization yet. I have been programming since I was a young teenager, certainly know my stuff - well versed in about eight different languages as well as compsci theory, etc. In addition, I have about four years of web programming (PHP mainly) behind me, having started freelance work in that area since web 2.0 became hot.
My summer job now as an intern of sorts is to write an application for an industrial, not software-related startup. This application will be used to manage production lines and logistics flow. I have chosen Java for my language because I don't want to shoot myself in the foot.
I am well-versed in the syntax of Java, in its data structures, language theory, and such, but I have absolutely no idea where to start. I can picture the program perfectly in my mind, I understand the problem clearly and got the solution's theory nailed. Namely, I have no idea what libraries to use, and am scared that they won't be well documented.
Here are some general outlines of what I'm going to make:
Two applications, one server and one
client (of which there will be many
copies).
The server and clients obviously will
communicate via (I don't know).
Both the server and the client
software will have GUIs.
The server software will have to
query a MySQL database.
The client software must be 'live' in
the sense that the GUI updates when a
change is made to the database. This
is one of the reasons why it can't be
a web application.
I'm not even sure if a framework is right for me or not. I've used MVC tons of times in my web freelance work, but I dont know how that will translate for desktop applications.
In short, I'm looking for the right libraries for the job, as well as advice on whether or not I should use a framework (and if so, which). Thanks.
This is a summer intern job? To be honest, this sounds more like a major project if you ask me. You say the start-up is not software related? Who came up with this idea? Do they have any idea of the (huge) scope that something like this might actually entail?
The business of software development is something quite different to language syntax and libraries. It's about requirements gathering, defining a spec, writing code, ensuring quality of that code, having it tested and so on. These are not things an intern should reasonably be expected to pick up. For something like this you should be under more experienced supervision, someone you can learn from, someone who has done this before.
That being said, unless there's a really good reason, I would probably do such a thing as a Website rather than a desktop app. Desktop apps are a lot more complicated in many ways. You need to code both a client and a server. Communication is a bit trickier. You have to worry about the issue of maintaining state in multiple applications, how to handle updates being pushed around and so on.
In short, it's a big job. Even a Web site is a big job but a lot of these issues go away. You could do this with Java. I've certainly coded my fair share of Java Websites but PHP might be a far simpler bet.
Also, desktop development on Java is, well, torture. Swing is (imho) tried and true but also incredibly painful to develop in. Other desktop libraries (eg Netbeans RCP, Eclipse SWT) are more modern but have other idiosyncrasies.
Desktop remoting libraries include things like Spring remoting, even Web services and other things like Burlap. For the server side, I'd be using either Tomcat or an application server (Glassfish is my preferred choice), servlets and Spring. Persistence can be done via Hibernate or Ibatis (or lots of other options).
But honestly, the desktop option is so much more complex than a Web-based one. You'd probably get a lot more done faster using PHP + jQuery + MySQL.
If you are doing this keep it as absolutely simple as possible. Try to define the absolute minimum you need to initially deliver and do that. Once someone has that they'll then have a better idea of what works for them and what doesn't. Basically it's easier to refine something that already exists vs define something that doesn't.
I recommend that you only build a web application. A web application can be 'live' in the sense you are describing it by using AJAX. It would be much easier to build just one thing. If you also want to have a rich client, then you need to build the UI in a technology you are not familiar with (like Swing or SWT) and design/implement the communication mechanism.
Have a look at Hibernate (ORM tool) and Spring (IoC framework). They have a somehow steep learning curve, but they will make your life easier at the long run. For the UI part perhaps JSF is easier for a beginner.
As a last note, I think you have an over-ambitious plan. What you are describing is not an easy project and requires expertise with a lot of technologies. Do not try to do everything in one shot.
Java Desktop 6 (JRE)
JDBC (built-in in any JRE)
MySQL JDBC drivers (freely downloadable)
for communication you have several choices: RMI (built-in) however this days I recommend
learning something like Java Web Services (JAX-RS)
Libraries?
JDBC for the database. You may want to look at ORM mechanisms like Hibernate
I would recommend the Apache Commons libraries for all your utility work (handling files, IO etc.). There's a lot of stuff there to save you reinventing the wheel.
A standard logging framework like Log4j will allow you to log in lots of different ways, filter your logs and plug into monitoring solutions easily.
You don't say whether browser-based solutions are acceptable for the client/server GUI, and that decision will drive a lot of the further architecture.
If you're looking at browser-based solutions, then I would advise a grounding in servlets regardless of any framework you ultimately choose (no doubt a lot will be recommended here).
By this stage it's getting to be a major project. Perhaps you need to concentrate on getting the fundamentals (client/server functionality) working, and worry about the GUI later. Otherwise it's a huge amount of work (and GUI work can draw an enormous amount of time).
Just one nitpicking:
Both the server and the client software will have GUIs.
I advice you to have a headless (in awt parlance) server, with an administration GUI, not a GUI-server.
Well this can go as wild as you can think of or you can go and do KISS.
If you would like something that is really simple (as in not using any frameworks):
* In the server side you can use RMI. This server side will use plain JDBC to connect to your MySQL database. But some said that this is kind of old, so if you want to get funky you can try JAX-RS which can return a JSON objects/XML to your client.
* Your client can be made using Swing (assuming you are developing desktop) or Servlet + JSP (assuming you are developing webapp) and connect to your server by calling the RMI objects/JSON objects/XML that is exposed by the server.
If you would like to get nasty which will help you in terms of code maintainability you might want to plug-in Spring + Hibernate into this application.
Good luck!
I've done lots of java web development using jsps and servlets, and I have found this approach to be straightforward and flexible. Some of the groundwork involved though - such as managing database connections - is rather tedious, and it takes a fair amount of work just to get a new web app off the ground.
I'm therefore considering using a framework for the first time, but my impression of frameworks is that they're mostly used for large J2EE applications and involve a lot of complex configuration. What I'm looking for is something simple that (after the initial learning curve) will enable me to get up and running with a new web app as quickly as possible.
So my question is - does it make sense to use a framework for a simple java web app?
Note that I'm not asking which framework to use (if indeed a framework is recommended), as it has already been asked here.
If you don't use a web framework you'll usually end up writing one - poorly.
It makes a lot of sense. My team has spent the better part of five years with our open source stack and no matter and we have a "seed" project (works like appfuse) that we use to create all new web apps. Even the simple two pagers from the pov of maintaining the app, it looks like every other app, just smaller.
The short is you won't get any return on the investment right now, but you will as the project evolves and you maintain it.
Yes, I would use a web framework for the following reasons:
Increased navigation capabilities and controls. Even though you may not need them, they are there for you to use should you require them at any time
As others have indicated, apps grow over time and you will feel the need for the framework at some point in time in the future. When you need to add additional pages and navigation
Features that allow you to plug into other frameworks such as security and DB access frameworks. Spring is a prime example in the Java world. You never have to use Spring but it plugs in so well with Struts, Spring MVC, Hibernate, Acegi etc. It ends up saving you the hassle of doing all of the plumbing on your own.
Support!!! Good frameworks almost always have a vibrant community to support them and ask and answer questions.
It may seem like too much hassle initially but definitely saves you much time in the future
I'd say it actually matters quite a lot which framework you go for. Something like Spring MVC is fairly unobtrusive in your code and allows you existing stuff to run quite a lot as-is. Other frameworks have much more specific ideas about how you should do things.
Yes it does make sense. Apps can grow and change and might require something a framework can provide easily in the future.
For example at my workplace we have simple jsp / servlet app. It needs to be rewritten just because of what I explained above. If someone would have taken the time to just get the framework setup we would be in better shape today.
Yes it makes sense. However implicit in your question is that the wrong (for you) framework can be more pain than it's worth - and that's true. There is a world of difference between some heavy J2EE framework and something light and cheerful like grails.
What's the alternative? Rolling your own? Embedding all the navigation and logic in the JSPs?
I agree with those who say that a web framework is worth it. There are literally hundreds now (e.g., Struts, JSF, Spring, Wicket, etc.). Pick one that suits you.
There are two kinds of applications:
1) the kind that you throw away and never use again, and therefore should not worry about modularity, maintainability and clarity.
2) the real kind.
It may sometimes seem that your app may never have to grow, scale, or service a larger feature set / user base than you currently are planning for....I assure you, that perception is always wrong.
Frameworks, specifically things like Struts for MVC in Java, Spring for MVC and Dependency Injection, Hibernate for Object-Relational Modeling are all extremely valuable tools that lead to modularity, maintainability and clarity in your code. So, to answer your original question.... Yes, emphatically.
No it doesn't unless:
you don't have any java experience
in your team
you are doing just a prototype that
must be ready in hours
you don't trust your developers
enough to let them write your
application
you don't plan to let your
developers learn and improve
Danger in using frameworks include but not limited to:
you'll get all framework defects on
top on your own
you'll be unable to do realistic estimates until you
know perfectly the framework
your team won't learn how to program a
web server
you'll find your team passing more
and more time on google instead that
solving problems by writing code.
The only thing that is worst that choosing a open source framework is having a separate R&D team in the company who should create the "big complete ultimate company framework".
but my impression of frameworks is that they're mostly used for large J2EE applications and involve a lot of complex configuration
Not necessarily true. The good frameworks are built to scale well so that they will take you from small apps to very large apps. Many of the frameworks today are moving towards zero configuration so you will find them easier and easier to use.
You are right that it does take an initial effort to learn the framework itself but that investment pays for itself in the very first application you build. And meta frameworks like AppFuse makes it even easier to get started since it pre-configures the frameworks for you.
Frameworks make sense for most applications. It may be necessary for you to build your own or adopt some other framework. The most important questions is the granularity of your data structures. What I mean by this is do you need to just enter data or do you need to parse, compile and execute dynamic code?
If you think of a frame works as a gauge and to the left is an all ready existing frame work open source or closed and to the right is all custom framework then super impose your code on top of that frame work where the level of complexity increases to the right. The farther right you go the more of a stuggle you will have with the frame work (IMO).
However, you can also slowly migrate from existing to custom framework.
There is also the question about your business. If you work for a business that does not look at software as it's core compentency such as a bank or hospital then you need to way that into how much of a frame work you want to build.
Bottom line a framework of some type will always be useful.
Using a framework may add some overhead to your web-app development due to the learning curve. However, depending on the framework you choose, you may be able to realize the following benefits:
Scalability
Maintainability
Clear Division of your model (e.g. MVC)
Out-of-the-box components(SessionManagement,authentication,etc )
Third party plugins
Modularity inherited from the framework
Many others.
Besides, the learning curve is a variable factor. Some frameworks may be easier to learn than others depending on your skills.
It definitely makes sense to look into using a framework even if for no other reason than it'll give you a new area of knowledge. If you've got the time to invest in learning a framework then you may well find in time that it's easier and faster to use that for new projects no matter how simple they are.
Also, if I could vote for SamBeran's post then I would. Getting started with a framework will involve several moments of "oh great! I don't need to write all that boilerplate again!".
I'd say use one - like you said, it's rather tedious to get stuff up and running for even a simple java web app. If the framework helps you get the job done faster and provides the services you need, I'd say it makes sense.