Support for both Web and Desktop front-ends [Architecture]

[Warren Tang]

I'm about to develop an application which needs to support both Web
client and desktop client. Is there any existing tools/practices I can
use? Or any suggestions?

Recently I've done a project with Google Web Toolkit(GWT) + myBatis.
Newly shifted from .NET Framework to Java, my current knowledge set is
limited to core java, no Java EE or Spring experience (though I have
plans to learn them).So lightweight is preferred.

Maybe I can use GWT + Spring + myBatis? For the desktop front-end I
should use Swing + Spring + MyBatis? The Spring MVC can handle the two
front-ends and make sharing business logic easier?

 

[markspace]

For the desktop front-end I
should use Swing + Spring + MyBatis? The Spring MVC can handle the two
front-ends and make sharing business logic easier?

As far as I know Spring is web only. Its MVC frame work is aimed
strictly at web applications; it won't integrate with Swing.

I've not actually used Spring (though I've investigated it) but I'm 90%
sure that's right. Check carefully before you assume otherwise.

Spring in general seems to be in disfavor in this group. It depends I
suppose on what sort app you are planning, but you might look into
something a bit newer at least. MyBatis at a glance did not look
superior to JPA or Hibernate. I'd prefer one of those two before using
something that seems less standard, like MyBatis, in the Java world.

 

[Tom]

I'm about to develop an application which needs to support both Web
client and desktop client. Is there any existing tools/practices I can
use? Or any suggestions?

Recently I've done a project with Google Web Toolkit(GWT) + myBatis.
Newly shifted from .NET Framework to Java, my current knowledge set is
limited to core java, no Java EE or Spring experience (though I have
plans to learn them).So lightweight is preferred.

Maybe I can use GWT + Spring + myBatis? For the desktop front-end I
should use Swing + Spring + MyBatis? The Spring MVC can handle the two
front-ends and make sharing business logic easier?

The issue is you need client and server (where these terms are
used in their general sense) that are agnostic of one another yet
support both web/desktop. In our products we started with desktop
apps but now we want web versions too.

You don't say what your desktop platform would be but as you've
posted in the Java group..... we developed our own server
implementation and c/s architecture for (desktop) clients. We
jettisoned the whole idea of object-relational mapping and indeed
anything to do with /implementing the application/ using OO, preferring
to regard all data as just a tree. After all, this is what the
document object model is so why introduce all the OO noise?

Anyway, our desktop client is swing and uses serialisation to/from
the server. There is no soap/rmi, just sockets. Events are both
ways so the client is sync'd as the server sees fit. Because all data
is just trees, MVC with the desktop is automatic (you don't have to
code that). We have transactions, locking and so forth.

When we came to consider web front ends, our data model
lends itself to the generation of json so we wrote a simple servlet
that processes service requests from the browser and generates
the tree in that form (rather than serialising it to the desktop
client as it would normally). We looked around for a suitable
browser framework and chose qooxdoo:
http://manual.qooxdoo.org/1.4/pages/introduction/about.html
(Its not html/css etc so not sure if that is the sort of
web client you want)

This means that we can use the same server-side code for both
types of client (with a little use of modularisation). Deep link:
http://www.inqwell.com/examples/petstore/myorders.html#serverstruct

The qooxdoo/javascript integration work we have to do is still in
progress but we've got trees/tables etc working and we're free
of J2EE/JPA/Hibernate etc, which we don't want.

 

[Arved Sandstrom]

I'm about to develop an application which needs to support both Web
client and desktop client. Is there any existing tools/practices I can
use? Or any suggestions?

Recently I've done a project with Google Web Toolkit(GWT) + myBatis.
Newly shifted from .NET Framework to Java, my current knowledge set is
limited to core java, no Java EE or Spring experience (though I have
plans to learn them).So lightweight is preferred.

Maybe I can use GWT + Spring + myBatis? For the desktop front-end I
should use Swing + Spring + MyBatis? The Spring MVC can handle the two
front-ends and make sharing business logic easier?

A few points. First, don't scramble this question up with persistence.
Whatever you end up using - straight JDBC, JPA with Hibernate or
EclipseLink, or the MyBatis framework - is irrelevant at the moment.

Two: do you know why you want to use Spring? Quite frankly, before
Spring got all bloated up, which is roughly coeval with the period when
use of Java SE/EE could somewhat benefit from Spring (prior to JDK 1.5
and Jave EE 5, basically), there was a reasonably good argument for
Spring. That core argument, with recent/latest Java SE/EE, has
evaporated. Learn Spring if you must, but as a Java novice (and Java EE
total tyro) do it in isolation on some other project for the sole
purpose of learning Spring: don't mix it up with other decisions or make
the use of Spring - to you an unknown puzzle - part of this decision.

I'll also add that you said you preferred "lightweight". It's a cruel
joke that Spring people still bandy that word around. Believe you me,
nothing but nothing - not library load, not design complexity, not
coding complexity - is "lightweight" about Spring. Not anymore. That
team lost their way many years ago.

Fundamentally, though, learn about Spring, when you have time, in
relative isolation. You'll end up pretty frustrated if you try to do
desktop+web+Spring+persistence all at once.

To address the basic concern, sharing of business logic, let me first
establish one common language by introducing a 4-layer architecture:
Presentation/UI layer, Application/Services layer, Domain/Model/Business
layer, and Infrastructure (technical services like data access and
logging) layer.

We assume, and should strive for, the same Domain layer and the same
Infrastructure layer for both of your scenarios. Those layers shouldn't
care one whit what the clients are, whether web or desktop front-end.

Having said that, your use cases tell you what your
domain/infrastructure layers need to do, without reference to client type.

Your web presentation layer will be GWT or Spring MVC or JSF or Wicket,
for example. Myself I'd go with JSF 2.x, but I won't discount the
others. In particular note that my concerns wrt Spring are towards the
entire Spring framework, not Spring MVC in isolation. If you want to go
with GWT I won't tell you not to. I will however recommend at least
looking at JSF 2.x.

To clarify the purpose of the Application/Services layer in the 4-layer
architecture, keep in mind what the Domain and Infrastructure layers are
doing for you, and also consider that the Presentation layer (Swing and
web-something, say) is solely concerned with presenting. The glue
between Presentation and Domain is Application - this is conceptually
where your "controller" type logic goes. For example, state that
reflects user progress in completing a task is the responsibility of the
Application layer, and so is logic that identifies and invokes domain
logic in response to events like user gestures and input. This layer
will not be the same for all clients, because the HTTP
request-response/requestScope-sessionScope breaks up your workflow
differently than a desktop does.

In other words:

1. Proper design from good use cases will give you business and
persistence logic that can be shared by all clients (throw WS endpoints
and WS clients in a SOA architecture into the mix, and divide web
clients into desktop browsers and mobile browsers...it still doesn't
affect the domain and infrastructure layers);

2. For each client the presentation layer is independently developed
(GWT, Swing etc). No sharing is contemplated. Stuff in this layer,
because it's inherently concerned with UI only, is also quite modular;

3. The application/services layer is also client-specific (although
you'd have some sharing for browser clients of various types).
Understand this layer, and get it right, because a developed knack for
identifying what belongs in this "controller" layer is a valuable skill
for your scenario. Bear in mind that in a web app this layer will
probably live in the web tier: just keep the distinction between the 2
layers in the web tier in mind.

Since you've arrived from a .NET world none of this should be all that
new. You are basically identifying the business and infrastructure logic
that would be in the Model either in ASP.NET MVC or WPF
Model-View-ViewModel (MVVM), the application/services layer that
translates to either the Controller in ASP.NET MVC or the ViewModel (or
ViewModel+Controller) in MVVM, and the presentation/UI layer that
translates to the View in both ASP.NET MVC and WPF MVVM. You already
know how you can write common C# library code for business logic and
persistence that will work both in a WPF or WinForms or ASP.NET MVC app;
keep in mind that anything that would inevitably be different between
those client environments is actually application/services layer or
presentation layer code.

So this reply is really an overview of architectural practices with a
view to telling you that whatever you did right in the .NET world
carries over precisely into the Java world.

As a completely personal choice, I'd use Swing for the desktop
presentation layer, and JSF 2.x for the browser client. There are some
situations where I'd use straight JDBC or MyBatis-managed SQL, but I
suggest that you won't step wrong by considering JPA, which would be my
usual choice for persistence.

I would not use Spring in general. I do not tell you not to learn it,
because there are plenty of dev shops out there that are wedded to it,
and for purely professional reasons it doesn't hurt to be fairly capable
with it. I didn't much like CORBA either, but I knew how to use it.

AHS

 

[Stefan Ram]

The issue is you need client and server (where these terms are
used in their general sense) that are agnostic of one another yet
support both web/desktop.

This already is part of the normal MVC architecture:

M does not know VC, but only »observers«.

VC, however, knows M, which does not hurt here:

One would implement one M with two different VCs here:
one VC for the web, one for the desktop.

Of course, you could call M »server« and each VC »client«.

Anyway, our desktop client is swing and uses serialisation to/from
the server. There is no soap/rmi, just sockets.

Actually, a plain Java interface would be sufficient
(or a set of those). A socket is only neccessary for
the web client, not for the Swing client. However, when
the server socket is already there, it might be more
straightforward when the Swing client uses it, too,
but this might sacrifice some performance.

Because all data is just trees, MVC with the desktop is
automatic (you don't have to code that).

(I don't understand this. But never mind.)

 

[Tom]

Actually, a plain Java interface would be sufficient (or a set of
those). A socket is only neccessary for the web client, not for the
Swing client. However, when the server socket is already there, it
might be more straightforward when the Swing client uses it, too, but
this might sacrifice some performance.

I assume that OP wants a thin client, not a fat one, or if that was not
what you meant exactly, that a server of some sort would coordinate
the access of multiple clients to the underlying data. In our case
this includes pushing events about data changes to the (desktop) clients
asynchronously.

(I don't understand this. But never mind.)

All of the application data is maps, not instances of class MyFooBar
This means you do not need to write code that does the MVC for MyFooBar.
When (for example) a mutation event emanates from the map
path "p.q.myFooBar.someField" (possibly raised by the server and
pushed to the client) and because the GUI component has been
told it is rendering "p.q.myFooBar.someField" the client side of
the framework does the MVC for you. For tables/trees there is more
metadata but you get the idea...

 

[Roedy Green]

I'm about to develop an application which needs to support both Web
client and desktop client. Is there any existing tools/practices I can
use? Or any suggestions?

I write them all the time. I call them Hybrids. You write an
Applet/JApplet then append some code to instantiate the Applet to let
it be run on the desktop. Nearly all my Applets are hypbrids.

See http://mindprod.com/jgloss/japplet.html
http://mindprod.com/jgloss/applet.html

 

[Kristian Rink]

Hi there;

some quick thoughts on that:

Am Wed, 13 Jul 2011 11:41:40 +0800

I'm about to develop an application which needs to support both Web
client and desktop client. Is there any existing tools/practices I can
use? Or any suggestions?

Well. Honestly speaking: My first suggestion would be to carefully
consider whether (and what for) you really do need a standalone desktop
application, or if a powerful browser client might be a better choice
for both groups of users. Anyhow, maybe Eclipse RCP/RAP is an
interesting approach for you. The idea is to do "single sourcing" by
providing two frameworks (RCP for desktop, RAP for web) and allowing
for reusing as much code as somewhat possible. See [1] for a good set
of slides on that topic. Some sources claim they could re-use 95 . 99%
of their code and run their applications for the browser (RAP) and the
desktop (web) without notable changes. Personally, I distrust these
numbers. Conceptually, single sourcing stops right where there are
substantial differences between a desktop app and a browser app, in
example as soon as file transfer (browser: up/download) has to be dealt
with. And, all along with this, Eclipse RAP (so far) is not really
friendly concerning export and deployment of runnable binaries, though
things have somewhat improved the last couple of months. Maybe worth
checking out.

Recently I've done a project with Google Web Toolkit(GWT) + myBatis.
Newly shifted from .NET Framework to Java, my current knowledge set is
limited to core java, no Java EE or Spring experience (though I have
plans to learn them).So lightweight is preferred.

Personally, I'd go for Java EE instead of Spring as, as others already
pointed out, Spring these days is anything but lightweight and because
Java EE at least ideally leaves you with the choice of picking one of
many different Java EE implementations where there is "just one" Spring
framework. But that's another story. Basically, this decision IMO
doesn't matter much in your situation, as this is likely to be the
server sided logic.

Maybe I can use GWT + Spring + myBatis? For the desktop front-end I
should use Swing + Spring + MyBatis? The Spring MVC can handle the two
front-ends and make sharing business logic easier?

Yes, you can, but in general most of these questions are way too much
implementation-detail already. I'd go more or less down this road in
your situation:

* You should slice up your applications into a three-tier architecture.
This is a good decision in most cases, and in my opinion, it
definitely is a good starting point.

* You should eventually pick up a Java EE server where to place the
persistence and business tier. In your case, starting out with these
technologies, I recommend Glassfish all along with NetBeans IDE and
the Java EE learning trail in the NetBeans knowledge base [2] -
though this won't suffice if you are about to write real-world
applications, it will give you a good overall understanding or at
least pointers where to find more in-depth documentation.

* You should think about an interface to connect your user interface to
your business logic. This interface, of course, will have to meet
your business use case needs. But it also will have to meet certain
technical needs in your situation: A web user interface application
is pretty simple as communication between your "user interface" and
your "backend" always happen inside your own network, and, at best,
on the same application server / host / VM. If you need to attach a
desktop client running outside of your local network, in example on a
customer desktop, your interface at least (a) will have to be secure
to prevent people from abusing your service and messing with data they
aren't supposed to have access to, (b) will have to be performant and
easy in terms of set-up so an end user will be able to connect your
desktop client to your service across network boundaries and
firewalls (which will make you end up with some sort of SOAP,
REST, ... across HTTP in most cases) and (c) will have to be stable
and/or versioned (you don't want the desktop client of a dozen of
customers break because you need to change something in your service
interface, do you?).


Cheers and good luck,
Kristian


[1]http://www.slideshare.net/caniszczyk/single-sourcing-rcp-and-rap
[2]http://netbeans.org/kb/trails/java-ee.html

 

[Arne Vajhøj]

I'm about to develop an application which needs to support both Web
client and desktop client. Is there any existing tools/practices I can
use? Or any suggestions?

Recently I've done a project with Google Web Toolkit(GWT) + myBatis.
Newly shifted from .NET Framework to Java, my current knowledge set is
limited to core java, no Java EE or Spring experience (though I have
plans to learn them).So lightweight is preferred.

Maybe I can use GWT + Spring + myBatis? For the desktop front-end I
should use Swing + Spring + MyBatis? The Spring MVC can handle the two
front-ends and make sharing business logic easier?

First you need to decide on tiering, examples:

desktop app-------|
|--database
browser--web app--|

or:

desktop app-------|
|--services----database
browser--web app--|

Then you will need to decide on layering, examples:

PL1 BLL DAL-----------|
|--database
browser--PL2 BLL DAL--|

or:

PL1-----------|
|--SL BLL DAL----database
browser--PL2--|

And then you can decide on technology:

PL1 - Swing or SWT [or on the second case you could use .NET win forms
or WPF]
PL2 - GWT or JSF or Wicket or Grails or <insert 20 more options> [or on
the second case you could use PHP or ASP.NET]
BLL - plain Java
SL - something JAX-WS or JAX-RS compatible
DAL - something JPA compatible or maybe a non-JPA framework like MyBatis

There are plenty of options in Java.

Arne

 

[Arne Vajhøj]

I write them all the time. I call them Hybrids. You write an
Applet/JApplet then append some code to instantiate the Applet to let
it be run on the desktop. Nearly all my Applets are hypbrids.

And applets gives that nice 1990's feeling.

And who cares about those smartphone thingys anyway.

Arne

 

[Arne Vajhøj]

As far as I know Spring is web only. Its MVC frame work is aimed
strictly at web applications; it won't integrate with Swing.

I've not actually used Spring (though I've investigated it) but I'm 90%
sure that's right. Check carefully before you assume otherwise.

Spring is many things.

Spring MVC is a web framework.

But lots of Spring stuff is relevant in non web context as well.

Spring in general seems to be in disfavor in this group. It depends I
suppose on what sort app you are planning, but you might look into
something a bit newer at least.

Spring is extremely big.
The original Spring has added a gazillion sub projects.
The Spring people are always hyping their stuff ridiculously.

So a lot of people is pissed over crap that does not live
up the hype.

But I somehow doubt that many people have tried every single
part of Spring and found that there were nothing useful.

Arne

 

[Richard Maher]

So a lot of people is pissed over crap that does not live
up the hype.

Bit intemperate for you Arne

Arne

Cheers Richard Maher

 

[Arne Vajhøj]

Bit intemperate for you Arne

I can be worse.

Arne