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 a UI technology, rich and complex UI requirements were the most common. At that time, the Enterprise Java ecosystem hadn’t developed a UI technology like JSF, and Ajax technologies weren’t on the horizon. However, things developed rapidly, and web technologies and web applications have since become dominant in this area. Nowadays, apart from having difficulties finding qualified people to maintain those Swing applications, integrating them with newer web applications is also a problematic task.
Applications don’t live in isolation within enterprises, and integration requirements among applications with different architectures arise at various levels. Some integrate at the database level, others at the business or API level, and some at the user interface level. Integrating a web application and a desktop Swing application at the UI level is particularly challenging due to the architectural differences between the two application types. In this article, I will analyze some limited integration approaches.
In our case, a web application at some point needs to pass data to a Swing desktop application, and the active scenario will continue execution from the Swing application’s side. Moreover, authentication information must be propagated to the other side. After some thought, I came up with the following approaches:
Client-Centric Approach
In this integration approach, an applet is developed to work on the web application side. The Swing application, on the other hand, is made to listen to a well-defined port. The applet, triggered from the web application, passes the necessary message to the Swing side, and the user scenario continues execution in the Swing application. In this approach, the user must start the Swing application before integration requests are passed from the applet.
Server-Centric Approach
For this approach to work, you will need to develop a web component for the Swing application. A servlet is developed to handle integration requests coming from the web application. The servlet processes these requests, dynamically generates a JNLP, and returns it as the response. The necessary input for the Swing application to execute the related user scenario is included in the JNLP. Afterwards, the Swing application is launched via the dynamic JNLP. The downside of this approach is that a new Swing application instance is launched every time an integration request is sent to the JNLP-generating servlet. If you need an already running Swing instance to handle incoming requests, you will need to develop a hybrid solution explained below.
Hybrid Approach
In this approach, there is a web component similar to the previous approach. This web component tracks the address information of the client system where the Swing application is started. The Swing application continues to listen to a well-known port for incoming integration requests; however, this time, requests come from the server side. First, an integration request is sent to the web part of the Swing application, and then the web part propagates the request to the Swing side via socket communication. Before propagating the request to the Swing side, the web part checks whether a Swing instance is already running on the client side using the tracked information mentioned above. This information can be generated by the Swing application at its main window creation and destruction phases and passed to the web part. If a Swing instance is already running on the client side, the web part propagates the request via a socket call through the well-known port. Otherwise, it dynamically generates a JNLP, adds the request’s input arguments to the JNLP, and the JNLP triggers a Swing instance.
Authentication
To ensure secure communication, authentication information must be shared between the two parties. The solution for sharing authentication may vary depending on the source of the identity information. Both parties might share a common identity realm for authentication, or they might have separate sources. If they share a common realm, they can use the currently logged-in user’s information to make and process integration requests. Otherwise, you will need to provide the web application with a user valid on the Swing side to make requests.
Shared Secret Key
The shared secret key method can be used in all the approaches mentioned above. The web application or applet includes the username and a hash of the authentication token (generated with the shared secret key) along with the integration-related input arguments in the request. The hash token content can simply be composed of the user’s password and the secret key. The other side of the integration request retrieves the user’s password and generates another hash token. If the generated token matches the delivered token, the integration request is allowed to proceed.
SSO
This method can be applied to both server-centric and hybrid approaches. The web application sending the integration request and the web component of the Swing application both delegate their authentication to an SSO service. When a request flows between them, the SSO service handles the authentication propagation transparently.
Basic/Digest Authentication
This method can also be applied to both server-centric and hybrid approaches. While applying this method, ensure that the communication channel between both parties is secure (e.g., using HTTPS). The web application includes authentication information in the request headers when sending integration requests, and the other side extracts the authentication information and processes it similarly to the other methods mentioned above.
Conclusion
In this article, I analyzed possible ways to integrate a web application with a Swing application. Three integration approaches and authentication context propagation are the solutions that came to my mind; however, I am sure there are other integration approaches as well. Have you encountered a similar requirement? What other possible solutions can you think of for such an integration problem between applications with different architecture models?