It was about 8 or 9 years ago when many enterprise applications were being developed using Swing for their presentation layer, and web start was the common tool to distribute and run those applications from a central location. Among the reasons for preferring Swing as UI technology, rich and complex UI requirements were the most common reason. Enterprise Java camp hadn’t developed a UI technology, such as JSF, and Ajax technologies weren’t on the horizon at those days. Anyway, things developed very rapidly, and web technologies, and web applications have become dominant in the area. Nowadays, apart from having difficulties for finding qualified people to maintain those swing applications, integrating them mainly with younger web applications is a problematic task as well.
Applications don’t live isolated in any enterprise and integration requirements among them with different architectures arise at different levels. Some integrate at the database level, some at the business or API level, and some other at the user interface level. Integrating a web application and a desktop swing application at the UI level is a bit difficult and constrained because of the different architectures of both application types. I will try to analyze those limited integration approaches in this article.
In our case, web application at some point needs to pass some data to swing desktop application and active scenario will continue to execute from swing application’s part. Moreover, authentication information must be propagated to the other side. After a thought process, I have come up with the following approaches.
Client Centric Approach
In this integration approach, an applet is developed to work on the web application side. Swing application on the other hand is made to listen a well defined port. Applet triggered from web application passes necessary message to the swing side and user scenario is made to continue executing in swing application side. In this approach, user have to start swing application before integration requests are passed from the applet.
Server Centric Approach
You will need to develop a web leg for the swing application for this approach to work. A servlet is developed to handle integration requests coming from the web application. The servlet processes those requests and create a JNLP dynamically and returns it as the response. Necessary input for the swing application to execute related user scenario is put into that JNLP. Afterwards, swing application is launched via dynamic JNLP. The downside of that approach is that a new swing application instance is launched everytime an integration request comes to the JNLP generating servlet. If you need already running swing instance to handle incoming requests, then you need to develop a hybrid solution explained below.
Here in this approach, there is a web leg similar to the previous approach. That web leg tracks address information of client system on which swing application is started. Swing application still continues to listen to a well known port for incoming integration requests, however this time requests come from server side. First, integration request is sent to the web part of the swing application, then web part propagates the request to the swing side via socket communication. Before propagating request to the swing side, web part checks if a swing instance is started on the client side using track information mentioned above. This track information can simply be generated by swing application at main window creation and destroy phases, and passed to the web part. If there is already a running swing instance on the client side then web part propagates request via socket call through the well known port, otherwise it generates JNLP dynamically, adds request’s input arguments to the generated JNLP, and JNLP triggers swing instance.
In order to have secure communication, we also need to share authentication information between two parties. The solution for the sharing authentication can differ according to from where identity information is fetched. Both parties might share a common identity realm for authentication, or they might have different sources for it. If they share a common realm, then they can use currently logged in user’s information to make and process integration requests, otherwise you will need to give a user valid on the swing side to the web application which will make requests with.
Shared Secret Key
Shared secret key method can be used in all approaches mentioned above. Web application or applet puts username, and authentication token’s hash generated with the shared secret key in addition to integration related input arguments into the requests and sends it to the other side. Hashed token content can simply be composed of user’s password and secret key. The other side of the integration request finds user’s password, and tries to generate another hashed token itself. If generated token is same as delivered token, then integration request is allowed to proceed
This method can be applied to both server and hybrid approaches. Web application which sends integration request, and web leg of swing application both delegates their authentication to SSO service. When a request flows from one request to the other SSO will handle the authentication propagation transparently.
This method can be applied to both server and hybrid approaches too. While applying this method, be sure that communication channel between both parties is secure (e.g. using HTTPS). Web application puts authentication information to request headers while sending the integration requests, and other side extracts authentication information and works similar to other methods mentioned previously.
As a result, I tried to analyze possible ways to integrate web application with a swing application. Three intgeration approach, and authentication context propagation are the things that come up with my mind, however I am sure there exist some other integration approaches as well. Did you have any similar requirement so far, what can be other possible solutions to such an integration problem between applications with different architecture models?