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.
Related
I have whole business logic along with its integration to database written in Java. Now I have two options: either I can write a Restful webservice to access it or I can follow the standard servlet approach to access it from UI... What are the advantages and disadvantages of both?
In fact, you try to compare things that are different.
REST is a style of architecture targetted distributed systems in the context of the Web technologies. Whereas it doesnt depend on the HTTP protocol, the latter is particularly suitable to implement these concepts. Implementing a RESTful service with HTTP means that we will leverage all its features and use them for the right thing. Those principles can be implemented with different technologies and in Java with different frameworks.
This link could provide you some insights about the REST concepts: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
Servlets correspond to an API and a container to handle Web applications. The container is responsible of the transport layer and let you focus on the way to handle HTTP requests and create responses. But you are free to them to build you application and use HTTP like you want. Most of time a framework is used on the top of them to implement applications. You can even implement RESTful applications with raw servlets if you want with a bit of additional work.
There are several frameworks like that:
Restlet (http://restlet.com/projects/restlet-framework/) that allows to create and / or consume RESTful services in Java. They can be executed in a standalone application or within a servlet container.
Spring MVC that provides a support to configure Web applications within lightweight container with dependency injection. The framework also provides REST support.
Hope it helps you,
Thierry
Webservice going to help you to communicate between two application which may be having different platform(for example communication between java and .NET possible using this).
But servlet can bind u to talk within one application which is bind with java platform. you can able to talk with two java application using servlet also but for that u have change server configuration. So please understand your requirement and use it
As Thierry said, they are diferent things, and its up to you define the need of REST implementation. I would suggest an article: http://martinfowler.com/articles/microservices.html
Its a very reusable way to isolate and expose your business logic.
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.
In our system we have a legacy standalone java application which we are trying to made available for new webapps we are developing all together running in a server (f.e. Tomcat)
In order to made requests to this app lighter we thought about made them directly to the same vm using jndi instead of developing a webservice interface.
I would like to start this application environment in some webapp context and make some API available to other webapps and invoke interfaces' methods.
I've not been able to bind this objects by JNDI in the Tomcat's read-only Context without adding the app in the Common lib, when I get more problems due to incompatibilities between dependencies versions. Maybe the best solution is to deploy these interfaces as EJBs so I'd use a Java EE Server instead of a servlet container. Or maybe I'd use some other framework such as Camel or something.
Thanks in advance and any suggestion will be helpful.
I would suggest to wrap your legacy java interfaces in REST. When you expose them as REST APIs, they will become available for any client, not only java. Also you don't need any Application Servers for that, all you need is a jar file for your REST reference implementation.
From performance perspective, well, I know theoretically JNDI should be faster, but in the real world the difference in performance becomes significant ONLY for very very performance intensive applications.
However, if performance is your primary requirement then wrap your legacy interfaces in EJBs.
Manual JNDI/RMI lookups are going to be the fastest, BUT and this is a rather big but, unless you are well experienced in network programming and multi threading, I would advise you to steer clear of that, and use a container. There are a lot of nitty gritty details that the container takes care of and you can concentrate on implementing your business logic.
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)
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.