Is Spring Appropriate for Client-Server?

[cyboc]

The application I am currently working on requires a Java Swing client (yes this is a real business requirement not a "phantom" technical requirement). Unfortunately for me, the "J2EE Development without EJB" book focuses on web applications (i.e. application with web clients) and only briefly mentions Java Swing clients / rich clients.

My question is, how suitable is the Spring framework for use in a two-tier (i.e. client-server) application where a Swing GUI plus the Spring framework are the client and a database is the server (i.e. I do NOT want to use remoting)? I believe the sample application in the Spring Rich Client project calls this a "standalone" architecture.

Note that our application would have, at most, 50 concurrent users and would be deployed on a virtual private network. In other words, it won't have a lot of users and it will NOT be deployed on the web.

Cheers,
Cyboc

PS - "J2EE Development without EJB" is an excellent book so far!

[Ben Alex]

You might find this gets more exposure in the RCP forum next time, but anyway...

Keith Donald (the RCP project lead) has implemented a data mining application which is two tier. ie the Spring application context + Spring RCP GUI are run on the client, using JDBC directly to the RDBMS.

Petclinic RCP with the Java Web Start version demonstrates three tier. ie the Spring client application context + Spring RCP GUI on the client, the Spring server application context on the server, and a separate RDBMS.

With 50 clients you'll need to be mindful of connection pooling. One reason for the popularity of three tier architectures is so all those clients don't separately connect to the RDBMS.

So to answer your question, yes, Spring RCP can be used with either two or three tier models.

[cyboc]

You might find this gets more exposure in the RCP forum next time, but anyway...


Sorry, I thought it might be relevant to this forum too.


Petclinic RCP with the Java Web Start version demonstrates three tier. ie the Spring client application context + Spring RCP GUI on the client, the Spring server application context on the server, and a separate RDBMS.


Okay, I just got the latest Spring Rich Client code from CVS. It has two versions of the Petclinic: 1) petclinic-clientserver and 2) petclinic-standalone.

Petclinic-clientserver appears to be a 3 tier app where tier 1 = Spring Rich Client GUI, tier 2 = Spring Framework running inside a servlet container and exposing remoting facade and tier 3 = database. (As an aside, I find the use of the name "client server" for this version to be confusing. To me, client server usually means thick client + database server -- i.e. 2 tier -- someone please explain the naming convention they used...).

Petclinic-standalone appears to be a 2 tier app where tier 1 = Spring Rich Client GUI + Spring Framework and tier 2 = database. Perhaps this version answers my original question of whether Spring Framework can be used in client-server mode (i.e. "standalone" as the sample app calls it).

My followup question is: Is anybody actually using Spring Rich Client + Spring Framework in a client-server (i.e. "standalone" as the sample app calls it) application in PRODUCTION????


With 50 clients you'll need to be mindful of connection pooling. One reason for the popularity of three tier architectures is so all those clients don't separately connect to the RDBMS.


Correct me if I'm wrong but I think I can deploy the Spring Framework on the client AND use connection pooling (if I choose to do so). The advantage of this is that I do not need a remoting facade to let the client access the business logic.

Cheers,
Cyboc

[oliverhutchison]

As an aside, I find the use of the name "client server" for this version to be confusing. To me, client server usually means thick client + database server -- i.e. 2 tier -- someone please explain the naming convention they used...

I guess we are using the more general definition of "client server" in that it covers the case where one program (the Spring Rich client) makes a service request to another program (the Spring web application) which fulfills the request.

My followup question is: Is anybody actually using Spring Rich Client + Spring Framework in a client-server (i.e. "standalone" as the sample app calls it) application in PRODUCTION????

Yes. But I'm a committer which helps a lot ;-) At the moment the API is still in a state of flux. Keith rearranged quite a bit of the code base yesterday which will hopefully be one of the last major API changes. There is still quite a bit of functionality missing with regards view handling but the action, form and binding APIs are quite well developed and there is a lot of really helpful classes for building well behaved and good looking Swing apps even if you didn't want to use the full framework.

Ollie

[Keith Donald]

Cyboc,

As Ben and Ollie have alluded to, I and my team have developed a data mining and reporting application using Spring Rich Client that is "in production". It builds on standard J2SE Swing, and leverages other rich-client related libraries Spring Rich integrates with like JGoodies forms and looks.

As Ollie mentioned, the rich client API has been in flucutating over the last few days, but we anticipate this to be the last major API change for the command, data binding, form, validation, and dialog/wizard APIs.

In general, Spring Rich really goes to structuring your standalone or client/server app appropriately, with the core Spring container facilitating a lot of that.

It's great to see the interest in Spring for rich clients! :-) Spring is quite lightweight, supporting deployment and management of business objects (as well as ui objects!) in nearly any environment with little change.

[gpoirier]

Correct me if I'm wrong but I think I can deploy the Spring Framework on the client AND use connection pooling (if I choose to do so). The advantage of this is that I do not need a remoting facade to let the client access the business logic.
If you have 50 users using you application at the same time and there's no server between the client and the database, then you'll need at least 50 database connections, unless they open a connection when needed, and close it when done. Pooling won't help you either way. I'm not saying it would necessarily a bad thing though.

[cyboc]

If you have 50 users using your application at the same time and there's no server between the client and the database, then you'll need at least 50 database connections, unless they open a connection when needed, and close it when done.

What I'm saying is that I could put a server between the client and the database and make that server responsible for only serving up pooled connections via a JNDI DataSource. I could use WebLogic or any other server that is capable of this task. In this scenario, I could choose to put the business logic inside a Spring container and deploy that container on the rich client (instead of deploying to the server). The advantage of this is that I can avoid using remoting but still enjoy connection pooling.

Having said that, I don't see what's so wrong with skipping the server (and connection pooling) altogether and just letting the rich clients have a dedicated JDBC connection because my application will only ever have a maximum of 50 users (the current number is about 20). In my testing, I have found that my database server only needs about 177KB of RAM per connection, so I'm not likely to run out of memory! :)

Anyway, I think the beauty of Spring is that I could start off with dedicated connections and then scale up to using a connection pool later on without having to change code.

Cheers,
Cyboc

[mjeaslea]

Hi,

With the Eclipse RCP project providing an excellent platform to develop Rich Client Applications, i was wondering if anybody has any experience connecting Eclipse with Spring.

Basically the Goal is that Spring would generate Content Providers that the JFace (eclipse SWT) components consume.

[bsdwork]

Web clients scale better, and are easier to maintain (because they are only installed on the server), but have a less rich user interface.
Swing clients have more functionality, but they can be more difficult to maintain, because a change in the client means you need to redistribute the code to every client machine. Tools like Java WebStart can improve this.
Also, in my experience, Swing clients are harder to write, because so much time and energy has been spent in the last 8 years on web client development. Of course, this is my personal bias, because I write web applications. A GUI developer would feel differently.

[al0]

Web clients scale better, and are easier to maintain (because they are only installed on the server), but have a less rich user interface.
Swing clients have more functionality, but they can be more difficult to maintain, because a change in the client means you need to redistribute the code to every client machine. Tools like Java WebStart can improve this.
Also, in my experience, Swing clients are harder to write, because so much time and energy has been spent in the last 8 years on web client development. Of course, this is my personal bias, because I write web applications. A GUI developer would feel differently.

Really, thick clients (if designed and written properly) may scale much better then Web-clients as they are much less limited by resources of the server.
If you are concerned about DB-connections, to many high-end databases (like Oracle) have built-in connection pooling which is absolutely transparent for clients and quite effective. And if you are not GUI developer then for you it should be irrelevant which presentation layer is used (Web, thick client etc.).

Regards,
Oleksandr