Two applications sharing code.

[vcardona]

I am redesigning an application my company uses, and I was thinking of using Spring. The problem is that the application is really two applications in one, and they share a lot of code between them.

The first application is a webapp that mainly serves as a reporting tool. This is the easy part.

The second application is a stand-alone swing-based desktop application that is used to display and enter the data used by both applications.

Currently, both apps share the DAOs and service implementation. The stand-alone app took responsibility for creating its own connection pool, since it was not running inside Tomcat. My question is how do I configure the shared code? I know I need an application context at the service layer, and another at the persistence layer. How can I make those available to the UI layer (web or swing-based)?

I am not sure if my question makes any sense, so please let me know if you need any more info. I am also willing to look at non-Spring technologies if they might help.

Thanks!

[Martin Kersten]

Well I have difficulties to understand, what you are exactly up to, but I guess I got a good part of the picture.

First of all, you said you have two different user interfaces (web and a Swing based client application).

The stand-alone app took responsibility for creating its own connection pool, since it was not running inside Tomcat.

This is quite interesting. You mean your stand-alone app (lets call it Swing client for the moment) is writing directly to the database, which means the database is running within the same machine.

As you stated out, that both applications (Web and Client) are utilizing the same potions of backend code. So we need to think about a simple way to unify these potions in a single application.


A layered point of view might look like this:

User Interface <--> Application <--> Domain <--> Infrastructure

User Interface: Web Reporting tool and Client application
Application + Domain: Used by both but independently, DAO,
Infrastructure: SQL, Persistence solution + including Database itself

So to unify everything shared, it is very common to speak of a server and two clients. So all you need to do is setting up a single server, connect the web user interface with it and also provide a mechanism for remote communication between the Swing client and the server.

Usally using a single machine solution, the web user interface related code is processed by the same application server (e.g. Tomcat), also processing the server application.

A Swing client usally uses a kind of remote communication strategy (HttpInvoker, RMI etc) and connects to the server. So there is no need for the Swing client to have it's own DAOs or DB-connections. Just view the Swing client as an independent application using a 'User Interface' (or better 'Service Interface') the server provides.

More exactly speaking the web code is a user interface too used by the browser, which is the actual Html-client in this picture.

It depends on your domain model and the needs of both your server and the Swing client, if you are able to reuse the domain model objects (not shared but synchronized between the client and the server). This may lead in extracting a jar file containing the domain model classes and a Swing client including this jar in its classpath.

I am not sure if my question makes any sense, so please let me know if you need any more info.

Hopefully I made an adorable job on providing some useful hints ;-). Just keep questioning and I am sure, we will find a good solution, since this is a quite common problem with a vast of written literature thrown on it.


Cheers,

Martin (Kersten)

PS: If you havn't read the two books Evans: 'Domain Driven Design' and Fowler: 'Patterns of Enterprise Application Architecture', you might want to grab yourself a copy of each book. These books are very good reading stuff on that topic.

[vcardona]

You have the general idea, but what I meant to say it that we have two clients with very different functionallity. The web-based client only does reporting, and the swing-based client does data entryand provides access to more detailed information. The webapp is packaged as a war in Tomcat, and Tomcat is responsible for connecting to the database, and establishing a connection pool.

The swing-based client is a stand-alone client. It has a copy of the business objects and DAOs that is uses to connect to a database running on another computer. None of the service or DAO code contains anything that would force it to run inside a container like Tomcat. The only difference is that the DAOs need a connection from a connection pool in order to talk to the database server. So the swing-based client must create one on its own, and pass it to the DAOs.

I like the idea of using RMI I think that would definately solve some of my problems. So then if I use the approach you specified, I am guessing that I wouldn't need any Spring related code in my swing-based client?

Thanks!
Victor

[Martin Kersten]

but what I meant to say it that we have two clients with very different functionallity. The web-based client only does reporting, and the swing-based client does data entryand provides access to more detailed information.

That's ok. Usally you can through both solutions together and see some improvement. But it is on you to judge what kind of improvement you might see.

I like the idea of using RMI I think that would definately solve some of my problems. So then if I use the approach you specified, I am guessing that I wouldn't need any Spring related code in my swing-based client?

Quite right. The Swing client would not have any DAO related code in such a scenario. Actually DB aspect is absolutly transparent to the Swing client. Never the less you might still use Swing to wire up the internal components of the Swing client (like I like to do).

Never the less I favour solutions like HttpInvoker instead of RMI and maybe taking a look at Spring RCP would get you some additional ideas. But the usefullness of either particular partly solution depends on your actual needs and requirements, and I am not aware any of them.


Cheers,

Martin (Kersten)

[Ben Alex]

An old post of mine at http://forum.springframework.org/viewtopic.php?t=721 discusses why you would typically locate business logic in the server instead of a rich client.

In terms of RMI vs HttpInvoker, you should consider load balancing complexity as per http://forum.springframework.org/viewtopic.php?t=1864 and general comparison comments at http://forum.springframework.org/viewtopic.php?t=265

Good luck!

[vcardona]

I wanted to thank Martin and Ben for replying. Your answers gave me a great dieal of insight into how my application can be structured.