[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 924
  • Last Modified:

Suggestions needed for communication between Java swing based rich clients and Spring-based application server

Hello experts,

I am planing a redesign of a (Delphi) client-server application to java ee 6. I would like to use Spring 3 / Hibernate as a middle tier. The middle tier should serve several types of clients, mainly rich desktop clients, but also mobile devices and keeping the possibility to add browser-clients later based on a single middle tier code base.
I am planning to use Swing-based Desktop clients.

My question:

What communication type would you suggest for rich desktop clients? RMI?
Is it wise to consider the desktop client as "just another type of client" that communicates with the middle tier like any other client.

This looks clean and nice on an architecture blueprint, but is it practical? Or should I use some more sophisticated construction especially for rich desktop applications? For example to keep up a nice performance?

I read that the best remoting strategy is "not to use distributed objects at all" (Martin Fowler)...

What are your experiences? Suggestions?

Many questions, hope my problem is clear for you.
Thanks a lot, Daniel
0
waeberd
Asked:
waeberd
  • 3
  • 3
3 Solutions
 
Dejan PažinCommented:

>> What communication type would you suggest for rich desktop clients? RMI?

We use EJBs - mainly stateless session beans. It works great with remote Swing application and Hibernate as persistence. Of course, you have to watch out for performance bottlenecks (lazy loading with Hibernate, caching objects on client side), but once you get that done, the structure works well.

>> Is it wise to consider the desktop client as "just another type of client" that communicates with the middle tier like any other client.

In a sence of remote client, yes. The web client tends to use much of the Hibernate session and lazy loading stuff.


>> This looks clean and nice on an architecture blueprint, but is it practical? Or should I use some more sophisticated construction especially for rich desktop applications? For example to keep up a nice performance?

That is a good approach. The performance bottlenecks are on the lower level, where you have to have correct solutions for them. Like I said: lazy loading on Hibernate and caching objects on the client side.
0
 
waeberdAuthor Commented:
Thanks Dejan (again :-) ).

How do you manage the "caching objects on the client side"?

By relying on EJB-mechanisms?

Regards, Daniel
0
 
Dejan PažinCommented:

In the end it turned out that the most simple caching works best in my case. I never found a real library for caching Hibernate objects on the client side, so I designed the simplest possible caching - whenever I need an object of some class with a given id, I check if I already have it in the client side map.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
grouper15Commented:
Hi waeberd

I suggest you go for web and mobile clients and also use web clients where you needed desktop clients. Desktop clients are only preferable if you need to communicate with peripherals or do I/O on the client side OR if you want to have substantial caching on client side or thick clients.

If your client is thin i suggest you go for presentation tier implementation in web and later on for mobile. it saves you a lot of time and cost.
0
 
waeberdAuthor Commented:
Hi grouper15,

Thank you for your suggestions.
Our clients are rather "thick":
It's a GUI-heavy planing and scheduling application that doesn't really fit well in a browser.

Now it's perfectly possible that this is my biased opinion, as I am working on this client-server application for years now.

But our strategy is to deliver "GUI-heavy rich clients" for the planning users while keeping the potential to add mobile / web clients later on a common middle tier.

So I would go for a swing-based rich client for desktop (using for example JIDE component packs etc) communicating to a middle tier based on Spring / Hibernate.

Would you still use a web client?

Thanks again,

Daniel
0
 
Dejan PažinCommented:

>> Would you still use a web client?

I would just like to add from my experience, that this is a crucial and very common question. We decided for the web client in one case and the cost of the decision was very high - a simple functionalities which are part of Swing for 10 years, are only emerging now on the web. That means they are difficult to implement, work slow, have bugs...

You should decide based on what you really need. If you need web, then go for it, if you need very intensive gui, then Swing wins hands down.
0
 
waeberdAuthor Commented:
Thank you folks.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now