I know to some of you it might sound ancient but I am currently developing an fat client using Swing for the user interface and Spring as a framework behind the scenes.
Is there any good tutorial explaining how to launch, initialize and shot-down a Swing application?
I saw there is a JSR 296 but it seems to be very old and not maintained any more.
Is there someone who could help me?
As you correctly guessed JSR 296 has failed its purposes and since 2009, when it was announced that it wouldn't have been included in JDK 7, its development has been put on hold. Several forks emerged, and I've worked with most of them, including projects based on a Swing/RESTful architecture.
The best option IMHO is currently represented by Netbeans Platform, a generic framework for Swing applications that can leverage most of the components written to build the Netbeans IDE itself. The documentation is really complete and if you're already familiar with desktop development you'll find it pretty easy to learn.
For what concern the interface with a server component I would create a set of RESTful API using Spring, or even a set of simple servlets. I recommend you to use an ORM like JPA or Hibernate; you'll get caching, pooling and schema flexibility for free. On the fat client side I usually build a REST client using Apache HTTPComponents. The use of HTTP make it easy to overcome firewalls, and security mechanism that are usually built to allow at least internet traffic.
The last hint I can provide is to use JSON for the payload you intend to exchange over the HTTP connection between the client and the server. JSON is compact, text based, and it can be converted easily from and to POJOs (Plain Old Java Objects) using GSON.
Related
First am not sure if this question fits here well. However couldn't think of a better place to get help. I've been tasked to list the Pros and Cons of each of these {JAX-RS, Playframework scala, MS Web Api}. I've done some research but couldn't conclude as I've not used all three to great extent. Have used playframework to create simple REST app. Have read the Web Api tutorials but have not implemented anything. Did research on JAX-RS but haven't implemented anything either. Also most of our developers are familiar with C# and introductory Java. I am more inclined towards playframework due to Scala,Akka,no server restart and scalability etc but not clear about the cons. One thing am sure is JAX-RS is standard Java EE and Web Api is standard MS stuff. Below are some of the app requirements:
Purely REST backend.
Proper authentication and authorization.
Online secure payment {Paypal etc}
Single front-end for both mobile and desktop
{angular/backbone/knockout..}
Allow users to subscribe as companies or part of companies.
Be able to connect to different databases without App restart.
Code maintenance and readability. Other members should be able to pickup without hassle.
Scalability
This is a partial answer because I worked only with playframwork 2.0 and JAX-RS.
Playframework is a MVC framework, you can use it to create some REST services but it's not focused on this kind of applications, so at least in version 2.0 it wasn't easy to add complex behavior like interceptors, etc. and you should manage authentication by yourself, I don't know if this has been improved in most recent versions of play framework.
JAX-RS is a specification to create REST services, there are several implementations like
Jersey, RESTeasy, Restlet between others. So JAX-RS implementations are built specifically to provide REST services in java. Most implementations have support to several authentications mechanism like OAuth, etc.
In my experience, JAX-RS is better to provide RESTful web services, and the code generated is in general more maintainable than the code generated in playframework, also playframework has a lot of things that maybe you don't need to use, but it will be loaded in memory when you start the server anyway. Akka it's a cool technology, but you can use it if you want it in any JAX-RS implementation.
If you want to build REST services using Scala, you could try Scalatra http://www.scalatra.org/
If you prefer java, take a look at http://dropwizard.io/, it's an embedded server that has Jersey (An implementation of JAX-RS) and a lot of cool things to provide RESTful web services, like metrics, etc, also it's easy to learn. If your team doesn't have an advanced java knowledge, this is a good option.
Playframework is great if you want an easy to learn MVC, specially for non java programmers but definitively it's not the right tool to build RESTful webservices based applications in my experience.
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.
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.
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.
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.
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.)
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
Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
Already have Java expertise, can be leveraged with DWR
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.
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.
How can I interop easily between WCF and a Java app.?
WCF is a web service framework. Java also provides its own web service frameworks. They should be able to interoperate quite easily, although you'll need to ask a much more specific question if you want a better answer.
edit: The ProjectTango link you ask about says it all in the first paragraph:
... to ensure interoperability of
enterprise features, such as security,
reliable messaging, and atomic
transactions.
These are fancy additions to basic web services, and the specifications alone are not enough to ensure compatibility.
Basic web service interaction, which is all 99.9% of us ever need, will work just fine between WCF and Java.
Short Answer, Yes.
Long Answer, the interoperability depends on several factors. Basic interoperability is very easy. Only when you throw in factors such as security that things get complicated. We did some research on availabe Java web service frameworks and found out that the best suited one for our scenario is the metro stack along with netbeans 6.5 IDE. We achieved message secuity which has mandatory for the project using client/server mutual certificate authentication.
Some gotchas discovered in the process are:
- You have to add the webservices-rt.jar library from glassfish directory in netbeans project. (doesn't need glassfish to be running, just the jar file)
- WCF generates multifile WSDL files and netbeans cannot use them to generate proxy, although if netbeans is configured to use the URL (http://../?wsdl) it can generate the proxy.
- You have to put [IsRequired=true] on all datamembers in WCF. Java's handling of optional datamembers is quite complicated.
- Dictionaries as datamembers comes out as list
We have done this successfully on several projects. We use WCF basicHttpBinding, it is the simplest option if you just need to get it to work.
One of the things that can be a show stopper is if a service uses a platform specific datatype, like a Java vector or a .net dataset.
You can use JAX-WS services on the Java side, and then use WCF in .NET.
First create the JAX-WS services (glassfish libraries will allow you to do this). Create your POJO's, add the JAX-WS annotations, and deploy your WAR. Then, get the WSDL generated by your server and give it to VisualStudio. VisualStudio can generate the client for you.
That is the simple way, but your mileage will vary of course.
I am embarking on a new RIA project with Java on the backend. I'm the only developer, and the app is a line-of-business application. My current stack looks like this:
MySQL || Spring(JdbcTemplate for data access) || BlazeDS (remoting) || Flex(Cairngorm)
My question is: what changes can I make to improve productivity? Manually coding SQL, server-side entity objects, client-side value objects and all the Cairngorm stuff is obviously a drag, but I'm not sure what higher-level frameworks to introduce.
What Flex/Java stack has served you well?
Manually coding SQL
Hibernate is an option to cut this out.
One thing that may be of interest is Grails with the available Flex Plugin. It's built on Spring, Hibernate and BlazeDS, so it's all there for you. It was unbelieveably easy to get it remoting stored objects and responding to AMF calls. I was using this and then moved over to a RESTful E4X implementation as I found it a lot easier to debug and tweak as I could inspect the server output in a browser and have tighter control over exactly what I returned to my Flex app (lazy loading problems in collections using BlazeDS were a headache at times).
Here is a quick tutorial showing how easy the whole Grails + Flex Plugin stack is: BlazeDS in Grails
I would seriously reconsider using Cairngorm. In my opinion it's a pretty bloated framework that introduces a lot of abstraction you'll never use. Check out:
http://code.google.com/p/swizframework
http://www.spicefactory.org
Both introduce the concept of dependency-injection into your Flex app.
Also +1 for Hibernate. I would use the standard JPA annotations on a Java class and extend that with Hibernate Annotations as you find you need additional functionality.
Check out springsource.org's new Spring BlazeDS Integration Project
Spring BlazeDS Integration is a new
addition to the Spring portfolio, and
a component of the complete Spring Web
stack. This project's purpose is to
make it easier to build Spring-powered
Rich Internet Applications using Adobe
Flex as the front-end client. It aims
to achieve this purpose by providing
first-class support for using the open
source Adobe BlazeDS project and its
powerful remoting and messaging
facilities in combination with the
familiar Spring programming model.
As alternative to hand-coding sql, aside from hibernate, you might wanna consider JPA/Toplink. And since you are already from a Spring camp, check out Spring ActionScript (formerly known as Prana), it's an IOC framework for Flex. It solves many inherent problems in Cairngorm. Also a good IDE that supports Flex/Actionscript like IntelliJ IDEA 8.
Whats missing between Flex and BlazeDS is, it doesnt have any sort of landing page where you have a listing of all the available services by just typing a url on the browser (similar to webservice endpoint).
You can try GraniteDS. It's an alternative to BlazeDS, with an actionScript generator, Spring integration (an Spring security), and if you use an JPA implementation, help you with the Lazy Initialization (in a transparent way).
I'm looking for a light version of REST for a Java web application I'm developing.
I've looked at RESTlet (www.restlet.org) and the REST plugin for Struts 2, but I haven't made up my mind. I'm leaning towards RESTlet, as it seems to be lighter.
Has anyone implemented a RESTful layer without any of the the frameworks or with the frameworks?
Any performance issues that you've seen because of the new web layer?
Did the introduction of REST added unmanageable or unreasonable complexity to your project? (Some complexity is understandable, but what I mean is just plain overkilling your design just to add REST)
I'm a huge fan of JAX-RS - I think they've done a great job with that specification. I use it on a number of projects and its been a joy to work with.
JAX-RS lets you create REST resources using POJOs with simple annotations dealing with the URI mappings, HTTP methods and content negotiation all integrated nicely with dependency injection. There's no complex APIs to learn; just the core REST concepts (URIs, headers/response codes and content negotiation) are required. FWIW JAX-RS is quite Rails-ish from the controller point of view
There are a number of JAX-RS implementations out there - see this thread for a discussion.
My personal recommendation is to use Jersey as its got the biggest, most active community behind it, has the best features at the time of writing (WADL support, implicit views, spring integration, nice REST client API); though if you are using JBoss/SEAM you might find RESTeasy integrates a little better.
I'm a big fan of Restlet, but I usually use it to implement apps whose primary role is to be a RESTful web service. It sounds like you're looking to add a RESTful API to an existing application. If that's the case, JAX-RS's (or Enunciate's) annotation-based approach might be a better fit for your project.
As for Restlet, I can tell you that I've been very impressed with the developers and the community; they're very active, engaged, responsive, and committed to a stable, efficient, reliable, and effective framework. My single favorite aspect of the framework is that it is a ground-up implementation of the REST paradigm; therefore there is no impedance-mismatch between a Restlet app's external API and internal implementation. I also really like how flexible it is - it can run inside a Java application container/server such as JBoss, Tomcat, Jetty, etc, or standalone, with an embedded HTTP server library.
Well, I've used Enunciate quite a bit. It uses simple annotations to provide either REST and/or SOAP endpoints.
http://enunciate.codehaus.org
Plus, Ryan Heaton has always provided top-notch support for things, too.
You know there is a new JCP API for Accessing RESTful Services, also:
JAX-RS JCP311
https://jsr311.dev.java.net/
The open source version is called Project Jersey
I am working on a REST API for gliffy.com and we ended up rolling our own. We didn't want to have to bring in Struts 2, Spring, or any other framework. I looked at RESTLet and found it incredibly confusing and over complicated.
Apache has an implementation of the JAX-RS spec, but it is not finalized and also has some oddities to it. We're tentatively planning to open source our solution, but that's not for a few months.
Rolling your own is easy, though. The Servlet Specification gives you everything you need, and you can easily connect to a database via Hibernate (see http://www.naildrivin5.com/daveblog5000/?p=39 for how to set up JPA without using EJB3).
I found restlet to be a really elegant architecture. I'm working in the .net world so it was not an option for me, but I was able to build my own framework following the same basic principles of restlet.
I have found the conversion of our WCF contract-based SOA application to REST based one has significantly simplified the application,