I need to build a desktop application for internal users for certain business. It also needs web based GUI for external users. I know, with web GUI both internal and external users can access it, but there are certain factors which are outside our control - due to which, desktop application is really unavoidable. For the purpose of this question, I would like to focus on the way to support both Desktop client (Swing) and Browser client.
Are there any best practices to be followed? I could think of below:
Expose service classes as web services and use these from both Swing client and web client
Expose service classes as EJB (business is into Java EE techs) and use Swing client as EJB client. Web client can use controller classes to interact with EJB
Are there any known benefits of using either approach, apart from technology agnosticism offered by web services?
Also, for swing client, I am thinking of using Java Web Start for easy distribution. I have never used it before, but from what I understood, it can support automatic version check at startup and update the client when required - is this correct?
If you need to avoid dependency to Java/JVM on the browser (which you most likely at least want to), you should definitely go with mixed Swing-Vaadin approach. Build the internal application with Swing or JavaFX and web part with Vaadin. The programming model in Vaadin is so close to typical desktop UI library that it is really easy for the same developers to work with both code base, and naturally you'll use exactly the same backend.
See the example application I recently built to demonstrate a setup like this.
Related
i want to know if it is possible to create GUI for java desktop based application in Adobe FLEX.
or any other powerful framework to make rich GUI interfaces for Java desktop applications.
Please share your valuable views on this.
i want to know if it is possible to create GUI for java desktop based
application in Adobe FLEX.
Yes, no and sort of. Flex is primarily used in client server applications. If you have a java server that exposes functionality via web services there is no reason you can't write a Flex GUI on top of that. And there is no reason that GUI can't target a browser (with Flash Player) or the desktop (with AIR).
There is also no reason that the client and the server cannot be the same machine. It will however present a significant installation challenge in deploying this application. I'm not sure if these challenges outweigh any benefits that Flex may bring to the table.
Ignoring the client/server nature of Flash/AIR, you can use Native Extensions or NativeProcess to include and execute Java Code as part of an AIR application. This is probably the approach I would take if I really wanted to use Flex and Java together in a desktop application.
We have a desktop java application (image-processing) that is working great, now we have to add a client/server architecture using Java EE plateform.
We must use also MVC, and interacting with many other libraries like JDOM, JMatlink(MATLAB), and calling some exe files.
Based on your experience what is the best choice to do that (framworks, ... )
Correct, you must use an MVC framework to design a flexible and reusable web application on the Java EE platform.
I suggest the following design:
Use JSF (Java Server Faces) to design the front end. As you are migrating your desktop application then it will better suit you becuase it's Component and Event driven framework.
Middlware: EJB 3(or EJB3.1) This will provide best available flexibility, performance and security to call your Business components directy from JSF Beans or any other remote application.
Over here you can use various design pattern to encapsulate Library and database access i.e. DAO (Data Access Object).
Use DTO (Data Transfer Objects) to transfer your request/response.
Hope it will give base to start your research.
If you can abstract the layers that talk to the backends such that your frontend (Swing?) doesn't need to know where those service are located, you are half-way there.
The key should be a good module concept. Frameworks like the NetBeans platform help you with that, and they can easily integrate non-visual modules that handle the backend code.
I'm not sure what you mean with "We must use also MVC"
MVC is a design pattern not a library or framework.
But if you use something like the NetBeans platform, you'll be applying that pattern anyway, because it forces you to think in modules. Each module will have a defined responsibility and during startup it registers itself with the application.
Take an application that allows you to manage people (e.g. for a human resource department). One module is responsible for displaying a form where the user can look at a single employee. That module in turn looks for a provider that can load or list all employees. How that provider gets the data is invisible to the front end. It could use a flat file, a relational database or a call to a remote EJB server (this is were you could plug your JavaEE stuff in)
The application could even download the modules from the server if correctly configured.
The key is to make the modules independent from each other. This is true for any large scale application regardless of the technology used (web application, a server side daemon or a desktop application)
Does anyone know of any tool that can facilitate/ease porting of an app to both Java Swing and GWT?
I've got a few "screens" that makes complete sense to have both in a desktop app and in a browser and I was wondering if there was some kind of common API that could be targeted that would facilitate creating these two different "views" (see my comment)?
I think it's entirely possible, but it would mean a different take on the server side of things.
If you do interface-based POJO development of the server-side components that the UI communicates with to do the work, you leave yourself the option of either an in-memory implementation or one that acts as a proxy to a remote component. The Swing desktop UI might use the in-memory version of the server-side, while the GWT version talks to the distributed version.
If you use Spring, it's easy to inject the appropriate implementation for each UI. Both only know about the interface and are oblivious to the implementation details.
I imagine a single code base that might be packaged in different ways. The Swing desktop app would be packaged and delivered as a JAR file. It wouldn't include the GWT or web tier controller classes. The GWT code base would include web configuration and controllers, because controllers are really part of the web tier.
The service interface and everything behind it would remain the same for both. The only difference would be that the Swing desktop configuration would inject the in-memory service layer implementations of the service interface. The web configuration would inject the web-based implementations of the service interface.
Whether my attempt to read your mind for requirements is correct or not, this approach has value regardless of how you decide to implement the service and client tiers.
I'm a Spring fan, so I'd recommend the use of Spring.
I have designed a GUI connect to DB button using Swing in java now i want to make it webapp application I need to host it on my website. Do i need to replace all my coding as swing is only for desktop application. Or is there any other way?
It will partly depend on how well you've structured your application. If there's no layering involved - if the GUI classes connect directly to the database, for example, then yes, you'll need to rewrite the whole thing.
If, however, you already have a separate data access layer, business logic layer and presentation layer, then you may only need to completely rewrite the presentation layer - while checking the other layers for things like concurrency safety.
The stateless nature of web applications - aside from session-based state - may mean you need to redesign the application significantly, of course. This may in turn mean that your existing "backend" layers aren't quite appropriate. While the theory is that they'd be presentation-layer-neutral, in my experience it would be quite unusual to manage to write an app targeting a single UI technology without some of the usage assumptions leaking through into underlying layers.
Check GWT, its a great framework that allows you to code in java...
If I'm getting it correctly, you need to reuse a database connection code. In that case:
You need to remove only the code that references Swing components. The ones that start with J. More accurately - the ones that are in package javax.swing or java.awt. The rest of the code can stay.
However, if your database connectivity code is too coupled to the GUI code, you'd better start that from scratch and just copy-paste of the parts in your Swings application.
In case you have a big Swing application, then you might want to use an automatic converter to web (ajax) application instead.
One such solution is AjaxSwing. There may exist others as well.
Take a look at AjaxSwing. It is a web deployment platform for Java Swing applications. It allows companies that built Java desktop applications to run them as web applications. Because it produces pure HTML/JavaScript you can also run Swing application on iPhone, iPad and Android phones.
Yes you need to replace all the GUI layer with web-app stuff (jsps, controllers etc). It should be relatively easy if you kept the business layer separated from the GUI layer. I suggest taking a look at Spring Framework, it is very useful for developing web apps.
If you want a Swing like application on the web, you can use an Applet.
You can turn your swing application into an applet, then it will run in a web browser, provided a JRE is installed on the client machine.
What can be reused depends upon your architecture. Look at Wicket, which offers a programming model very similar to Swing. That would not avoid rewriting of the GUI but makes the "mental mapping" easy.
I want to write an application that runs entirely locally on one machine - there is no need for connection to the internet or to any external machines.
I was thinking that it would be a good idea to use a web browser as the platform for this application so that I would not have to mess around with lots of UI stuff - I could just knock together the web pages fairly quickly and take advantage of CSS to get consistent styles throughout the application.
However I want to interact with a MYSQL database on the machine in question. With this in mind I was thinking that I could somehow use Java to process the information that the user inputs from the application and communicate it to the database via JDBC.
I know that I could use an applet to do this but the downside to that is that I would like the user to be able to save files to the local machine - and I have read that applets run in a sandbox which prevents them from gaining any access to the local machine.
I also know that I could use PHP but I would like to take advantage of object oriented design which Java is perfect for.
Does anyone have any thoughts, suggestions or links to tutorials/webpages which could help me to decide how best to go about this.
Any thoughts are very much appreciated..
I know you said you don't want to mess around with GUI stuff in java, but have you looked in to java web start? It does almost exactly what you need; a user clicks a link through a web browser and your application is deployed on their machine, it even checks to make sure the right JVM is used. Because it is a full application and not an applet, your app won't be sandboxed, and you don't have any access restrictions in your program (other than the normal java stuff..), and for example, it would be easy to do what you mentioned and talk to a mySQL DB. The only downside, is what I mentioned earlier, is that you would have to design a UI in java.
Web Start Wikipedia Page
Sun FAQ on Web Start
Grails may be a useful starting point. It'll provide you with a web server solution that's standalone, and it'll look after the JDBC requirements and the CRUD (create-read-update-delete) capability via dynamically generated web pages. It should take minimal effort to put together an app providing your database interfacing via web pages.
(fyi. Grails is the Java equivalent of Rails)
If you feel comfortable with Java EE-based web development, you could probably just bundle your application with Tomcat or Jetty.
If you do not want to run standalone servlet container just for one application, you can also embed Jetty into a runnable Java application (see documentation here).
Either way you can leverage existing Java EE frameworks (Spring JDBC, Hibernate, all those web frameworks) for abstracting away technical complexities, although with embedded Jetty, you'd probably need to write some kind of integration layer for the web application framework of your choice.
I think you should give Restlet, a lightweight rest framework a try. The tutorial shows you how to start a local webserver, and by that deliver a "Hello World" through the browser within minutes (no joke!), and there's plenty of extensions for any kind of need.
In combination with Java Web Start by which you can deploy and start the application to the local host this should be what you need.
as someone suggested already you can use embbeded jetty server on your application and just let your user to start it using somekind of shell script or batch script. You only need to make your layour directory complaint with a Java Web Application and your on it. ie:
MyApplication
app/
WEB-INF/
lib/
classes/
web.xml
start.bat |
start.cmd - depends on your client OS
start.sh |
Then you should only need to take care of launching Jetty in your start.[bat|cmd|sh] with your app as your webaplication context and your done!
Using JDBC doesn't mean that you have to write an applet, you can use JDBC in any kind of application: a desktop application, a web application, EJBs, MDBs, etc.
You want to use a browser and Java on the server side? Then go for it and use Servlets / JSPs. Consider maybe using an presentation framework (Wicket, Struts2, Spring MVC,...), Hibernate for data access and Spring for other facilities and wiring. Grails is a good idea too.
BTW, I'm not a PHP specialist but PHP has object-oriented capabilities (introduced in PHP4 , enhanced in PHP5) so you won't sacrifice everything if you choose PHP.
So it really depends of what you want to do. If you want to write some Java (webapp or desktop app): choose Java. If you want to put quickly a few web pages in place and have an apache server, choose PHP. If you look for really high productivity, go for RoR or Grails.
You can try GWT + Google Gears
GWT is a GUI toolkit similar to Swing for the browser. Google Gears is a browser side database. Your app is completely in Javascript in a single HTML file and cross-browser compatible.
GWT app can make Server calls and Gears can sync up with a Server database. So you need not restrict your app data completely to the local desktop.
If you're interested in some experimentation, like new stuff and would like to reuse the plethora of Java libs (including JDBC) then you might be interested in the lift web framework, which is Scala-based.
If you want to do it as an applet you can. Sign the applet and give it permissions to the local network (to connect to the MYSQL server that way)... that should be possible. Here is a tutorial on it.