We Keep Coding

Java MVC and Rest Server and JavaScript Heavy Client

I am in the process of beginning development of a web-based user interface and am looking for some expert advice on the right direction for my project.
Since our server-side is to be developed using Java, I am planning to use scriptless-JSP and an MVC framework called FrontMan. FrontMan is a lightweight Java-based MVC framework similar to Struts. I have played around with it and like it. The plan is to use scriptless-JSP assisted by JSTL and JSP tag files. I worked out some prototypes using these technologies and I liked what I had.
Now I am in the process of planning out the client-side stuff. My plan is to use JavaScript, jQuery, jQuery UI to build the front end. During my investigation I came across a very nifty JavaScript MVC framework named JavaScriptMVC. I have to say I really like it. It is not just a client-side MVC framework, but also includes tools for testing, documenting and deploying.
The more I engage in figuring out the client-side plan, I realize that I think this is going to be more of a JavaScript (client-side) app. I am leaning towards doing as much of the work in JavaScript rather than on the backend via Java. The backend will exist mostly for communicating with the database and responding to requests from the client (frontend) for manipulating or retrieving data.
I am rather new to RESTful web services, but in the little I have read about them, I think this might be a good direction to take this project.
I am wondering how I can employ both an MVC framework and REST framework together? Do they make sense together?
I am using Jetty as my web server, so I think that lends itself to using Restlets...?
Anyway, I am not sure how much sense I am making in this post, so I will stop it there for now.

As the previous poster mentioned, it makes perfect sence. MVC let's you separate concerns such that you can keep your application logic separate from your presentational logic.
Your REST controller serves the request you need, populates the model, and exposes it in a REST like manner, typically by returning an xml view to the user. This can be aided by a number of libraries such as xstream, jaxb, castor, xmlbeans, which all provides routines to marshall an object into xml.

Exposing a REST API on the server-side will be a perfect fit for your JS front-end. Your resources will have to expose JSON representations. You will even be able to reuse this web API from other clients such as mobile phones.
As the lead for the Restlet Framework, I can only recommend it for this purpose. Integration with Jetty is very stable :)
Cheers,
Jerome

A quite extensive discussion on this can also be found here:
Separate REST JSON API server and client?
For me it was very helpful.

Yes! It makes sense as Johan Sjöberg said! You can use Spring MVC for example. I like it a lot and think it is very simple and easy to learn. You have an example here.
By the away, for the frontend maybe you would like to check this presentation.

Current core technologies for AJAX w/ Java?

Looking to implement a RIA using AJAX with Java on the backend.
I was looking at DWR for an RPC style approach, but the project hasn't been updated since 2008.
I was also looking at DOJO and GWT.
Can anyone recommend a core set of technologies that works best for a Java based back end, that contains a rich set of client side widgets and backend integration with Spring WebFlow/MVC?
thanks

I would recommend Spring 3.0. It's up to date, lightweight, easily configurable, supports dependency injection, annotated classes, and is a great framework.
It supports REST, so it's easy to implement classes that return JSON to your HTML pages. This will help keep your content, behavior, and presentation all separate while still enabling you to build a Rich Internet Application.
Although outside the scope of your question, I'd suggest you use JQuery on the frontend as I've had really good results using it to transfer JSON back and forth from the server.
I would stay away from DWR. They merged with Dojo, which in my opinion is a better choice than DWR. DWR sounded good, but in practice it was buggy and difficult to use. Dojo was much cleaner and more modular. But unless you're using Comet (aka Reverse Ajax) just stick with Spring and JQuery.
Spring 3.0 is also supported on Google App Engine... just worth mentioning as Platform as a Service is in our future.

My recommendation is a RIA framework like SmartClient or ExtJS + a REST-based backend (built on Jersey, for example). I have also found JQuery to be extremely helpful when combined with these frameworks. Together. this allows you to build your GUI right on top of a REST API, which itself could be reusable for programmatic integration.
These kinds of questions are always religious ones, but FWIW I am personally not a massive fan of GWT, for multiple reasons. One of those reasons is because I don't want server side folks constructing GUI-targeted data structures (I'd rather have them stick to pure data and let me GUI folks handle the GUI stuff). So I actually don't appreciate that capability of GWT, but obviously many other people welcome that aspect, so again it's a religious choice.

you can try GWT.That supports Spring well.
http://www.springbyexample.org/examples/simple-gwt-spring-webapp.html

If you use a Spring MVC back end, you can use any AJAX frontend there is.
And if you are going to develop a RIA, I would suggest either Prototype with Script.Aculo.Us (Killer GUI effect library) or MooTools (which is either an extension or a re-write of prototype, that also includes many GUI tools).
The great thing about both ProtoType and Mootools is their Object-Oriented methodology (MooTools Class() docs, Prototype Class.create() docs), but the extension mechanism that gives additional methods and properties to DOM elements (How Prototype extends the DOM, MooTools Element reference). Of course this mechanism is exactly what the JQuery guys loathe about these libraries. But the nice thing is that because of these extensions, you hardly ever have to resort to browser-specific programming, the abstraction handles that for you.

I choose JSF for RIA applications.
It is J2EE 6 standard
it built-in in J2EE application servers (glassfish, jboss),
it has several implementations - if you have problem with one, you can switch to another
I has at least 4 (richfaces, myfaces, icefaces, primefaces) independent, big components libraries.

Spring can work well, but my personal preference is for simplicity, and Spring is bit heavy platform. So I prefer deploying services on JAX-RS containers (like Jersey); Guice for wiring things together, and in case I want to override or change data bindings, Jackson for JSON handling.
Other useful pieces would be jDBI for database access (much simpler than hibernate or other full ORMs), async-httpclient for doing calls to other web services.
Best of all, these all work nicely for many other kinds of uses.

Java Component based vs Request based frameworks

I was recently asked in an interview - In java, how do you compare component based frameworks to request based frameworks? I explained EJB as an example of Component based framework and Struts as a request based framework but was not convinced if I did justice to the question.
Any ideas on what interviewer meant and what should have been compared??
regards,
avajurug

They were most likely looking for examples of web frameworks - for example, JSF is a component-based framework, and Struts is a request-based framework.
Request-based frameworks generally make it clear through their APIs that they're working with parsing an HTML request / generating an HTML response, while Component-based frameworks attempt to abstract this away and treat the application as collections of components with renderers and actions to do things.
In my opinion, component-based web frameworks are more trouble than they're worth - their main purpose is usually to make the development of a web app "easier" for developers unfamiliar with web development, and closer to traditional desktop development. However, in practice, when something goes wrong, you need to develop custom components, you need to customize the framework for something that isn't "out of the box" functionality, etc. you need to understand both underlying "traditional" web development and how the component-based framework abstracts it - and if you're an experienced web developer and have existing solutions, utilities, libraries or snippets that worked in "traditional" web development, you'll waste time re-implementing them to work within the component-based framework.

Request based framework is a web framework that gets user's request then determine what the system should do and give back the response back to the user. So the flow is pretty much linear. You're thinking in actions: what does user want (request) -> what user will get back (response). An example of Request based framework is Struts. The modern Grails is pretty much a Request based framework too.
Component based framework is not like that. There is actually no clear sense of the flow from front to back. An example of it is not JSF, because in some way JSF is pretty much quite the same with Struts (since the creator of Struts and JSF is the same). A good example of Component based framework Tapestry and Wicket. The paradigm in these two framework is different. You don't think in actions or request-response, but components and components. You define a component in your application, and you tell what the component does. But the flow does not have to be linear as in Request based framework.

JSF is component based java API, as said Nate, Struts is an action based framework, the Http requests are parsed, while processing the actions in the end the controler Servlet forwards the request to the JSP that will be responsible to generate the response. While in JSF which became a standard for component based web frameworks, there is actually no need to process the requests and the responses as all we need is to write JSP or XHTML pages, bind the components used in the page or the value they should render to properties in backing beans or managed beans and the FacesServlet (controller) does all the job to care about request parsing and redirecting to the JSP that will render the response based on navigation rules specified in faces-config.xml . So as you can see there is a big difference between Struts and JSF as JSF brings a component-event based approach while Struts is more close to the classic JSP/Servlet model. Another thing jpartogi have said the creator of JSF and struts is the same, I just want to mention that Struts is a framwork owned by Apache community while JSF is an API specified by JCP in the JSR-127 for the version 1.1 and JSR-252 for the version 1.2 and has different implementations (SUN-RI, Apache MyFaces...)

Simply, If the framework has objects in java side for each web element so you can change attributes of it or add some functionality, it is component based framework but If framework does not provide objects and you have to put the response value of web element between its tags it is a request based framework.

Which Java based MVC framework is most similar to ASP.NET MVC?

I have been learning ASP.NET MVC in the last few months and I think it is a great improvement over ASP.NET. For me personally, it is a joy to use (as opposed to ASP.NET WebForms :)) I started wondering how the .NET world managed to live so long without any such framework (at least not wide spread and supported by Microsoft as there may be .NET ports of Java MVC frameworks, like Spring.NET).
I know Java folks had such frameworks for a long time and there are many Java MVC frameworks available.
If a web developer was thinking about switching from Java to .NET, which Java framework can be the easiest to switch from, and vice versa, if an ASP.NET MVC developer is thinking about broadening his skillset and learning some Java MVC (web) framework, which would be most similar to ASP.NET MVC architecture- and feature- wise?
Which Java MVC framework is most similar to ASP.NET MVC?

SpringMVC, VRaptor, Grails (Not Java, but somewhat relevant on the Java world)

Play Framework seems to me. It has controllers as classes, actions as methods, Razor-like view engine, object binders and almost everything looks the same.
Even routing seems almost the same.

If I were looking for the simplest framework, I'd dive into Struts. Struts 1.0 was written in a day, and is possibly the most valuable hour-per-hour effort ever spent by a programmer.
If I were looking to broaden my knowledge and/or skills, I might lean towards Spring MVC. If you need some functionality for Java web development, odds are other people wanted it too, and that Spring already has it. (Spring is larger than just Spring MVC; you can simply use Spring MVC, but it integrates nicely with much more, if you choose.)

Wikipedia has a list of a bunch of frameworks here:
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
and of those based on Java technology, about half are component based (that's what you don't want) and the other half MVC. If interested, you could follow the links on some of those to get more information.
In general,
the more mature of them will have more detailed writeups - both in Wikipedia and in the wild. There will also be more documentation, sample code, tutorials,...
The younger ones may be simpler, more fun, more versatile, as they build on the older ones, eliminate known shortcomings and add new features. JSF and Struts, for instance, are "big" in the industry but are considered by many developers (citation needed, I know) to be dated, clumsy, bloated, etc.
You'll probably have trouble getting an answer from people with enough experience to directly compare products on the .Net and Java side; most developers tend to stay on one side of that fence.
While I'm not knowledgeable about similarities with ASP.Net, I submit that Struts and JSF are the workhorses of industry on the Java side, and would be the kind of thing to be useful to have in your CV, even though or perhaps because they're not modern or sexy. Of those two, I think Struts has more of an MVC feel to it.

Apache Struts :
Apache Struts is a free open-source framework for creating Java web applications.
Web applications differ from conventional websites in that web applications can create a dynamic response. Many websites deliver only static pages. A web application can interact with databases and business logic engines to customize a response.
Web applications based on JavaServer Pages sometimes commingle database code, page design code, and control flow code. In practice, we find that unless these concerns are separated, larger applications become difficult to maintain.
One way to separate concerns in a software application is to use a Model-View-Controller (MVC) architecture. The Model represents the business or database code, the View represents the page design code, and the Controller represents the navigational code. The Struts framework is designed to help developers create web applications that utilize a MVC architecture.
The framework provides three key components:
A "request" handler provided by the application developer that is mapped to a standard URI.
A "response" handler that transfers control to another resource which completes the response.
A tag library that helps developers create interactive form-based applications with server pages.
The framework's architecture and tags are buzzword compliant. Struts works well with conventional REST applications and with nouveau technologies like SOAP and AJAX.

Technologies required to build an end to end web application?

I want to develop a web application, like an online scheduler. (Yes I know it's been done a million times.)
Most of my experience is in Java, so I want to leverage that when considering technologies.
I've primarily been a systems developer with little exposure to UI programming, so I think this is where I will need to do most of my learning.
Do you have any suggestions on the technologies I should focus on? I want to focus on technologies that are marketable and easy to learn.
So far this is what I think I need for a 3-tier architecture (from the ground up):
Database (likely MySQL or PostgreSQL) - SQL, JDBC
Back end server - Java
Web server (Tomcat) - JSP, Servlets
Web Framework - Tapestry (weak on this, any better alternatives?)
Browser technologies - HTML, Javascript, CSS (need to learn)
I've heard about "Rich internet application" development tools such as Flex and Silverlight, but I'm not sure about the market for such technologies.
Edit: Seems like there's a lot of mention of Spring/Hibernate, so I'll look into that. I appreciate the feedback.

I think you've got your bases covered pretty well.
You'll probably want to look into some frameworks / libraries to make it easier on you.
Web Framework - Wicket / Stripes / JSF / Tapestry (component vs request based frameworks)
Javascript Library - JQuery / YUI / Dojo
As for your template language you could use JSP / Velocity / Freemarker.
Just study up on the frameworks and tools maybe try a few out and see which ones work best for you.
Just FYI I'm currently using.
Apache - web server
Tomcat - servlet container
MySQL - database
Stripes - request based web framework
YUI - for ajax
Spring - dependency injection
Hibernate - Object Relational Mapping
jsp - to dynamically generate html

I'd personally add Spring to this list. Dependency injection is definitely a great technology to learn, and Spring lets you use it as much or as little as you like, in my experience.
You haven't explicitly mentioned unit testing, but that should certainly be part of the mix - I don't have much experience outside JUnit as an actual testing framework, but there's also EasyMock and JMock (amongst others) for mocking of dependencies.
None of that's web-specific, but still important stuff IMO :)

I would have to disagree that there isn't a market for Rich Internet Application. There is actually a growing trend in enterprise size applications being made as RIAs. The advantage with RIA over normal web applications is usability. You get all the advantages of web application but still are able to keep the desktop-like user interface.
You say you come from a Java background and haven't had much experience with web technologies. Well, I have to say that you really sound like an ideal user candidate for either GWT or IT Mill Toolkit (based on GWT). Both are frameworks which allow you to create rich internet applications purely in Java! No HTML or JavaScript skills required. You will have to learn CSS to make your own theme for the application.
Both the frameworks are open source and suite very well for commercial use. What separates IT Mill Toolkit from GWT, is that it is server driven, meaning business logic is implemented and ran on the server rather than as JavaScript in the client browser (which is the case with GWT). This server-driven architecture makes the application much safer from a software security point of view. The advantage of GWT over IT Mill Toolkit is the larger user community.
What comes to the ORM frameworks, Hibernate is quite popular. However, I'm not very fond of it, because even though it technically implements Java Persistence API, it doesn't always behave as expected and you'll have to use a lot of hibernate specific annotations, which ties your application pretty hard to hibernate (bad thing!) and you cannot just easily swich to another JPA provider if you'd like to. Antoher ORM framework implementing the JPA is EclipseLink. I haven't personally used EclipseLink in enterprise size applications (because I still haven't had the chance to), but I'm using it for a smaller project and it seems to be quite nice. EclipseLink is open source and its lisencing is friendly for commercial use. EclipseLink is continually developed by Oracle, so its backgrounds are solid. It is actually based on TopLink, which is Oracle's closed source JPA implementation.
Hope this helps :)

Asked basically the same question some time ago, with some pretty useful answers:
Tools for website development

If you are going the with a Java back-end, I would recommend Hibernate for your JPA, JSF with RichFaces (AJAX/skinning) and Facelets (view rendering/templating) for your front-end, and Seam to put it all together. It's a wonderful combination.

If you go with Spring, then you may just use Hibernate going to mysql, and you can have everything you need there.
After you write it, and you want to start improving on it, then perhaps start looking at doing more on the browser side, but, initially, you may want to just have it be without ajax calls.
The Spring Framework documentation may be helpful, as there are many parts to Spring that you can use, optionally, such as Spring MVC, Spring Framework, Spring Webflow and Spring Security, if needed.