Develop Update Server in Java

Dear all,

I am looking for ideas, patterns, practices to develop a client/server
architecture that can be used to update clients when a new release is
uploaded to the server. Does anyone know any web resources considering
this topic? (WebStart is not what I want.)

(Yes, I know Google, but "update sever java" is not a good query string )

Cheers,
Simon

Simon

In article <>,
Simon <> wrote:

> I am looking for ideas, patterns, practices to develop a client/server
> architecture that can be used to update clients when a new release is
> uploaded to the server. Does anyone know any web resources considering
> this topic? (WebStart is not what I want.)

I recall this project having a very simple scheme: java.net.URL for a
quick version check and java.awt.Desktop to navigate to the project's
download page for updates:

<http://sourceforge.net/projects/jmcad/>

Why not WebStart? It conveniently integrates digital code signing. The
approach can't tell me whether I should trust your code; but, once I
decide to accept it, I'll know it's the code you intended:

<http://www.ibm.com/developerworks/java/library/j-webstart/>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

John B. Matthews

> You haven't provided much information. What kind of "client" are
> you talking about, and what do you mean by "update?" Or, turn the
> question around: What is it about your situation that makes Web Start
> inappropriate? What do you want to do that Web Start doesn't (or
> what does Web Start do that you'd rather it didn't)?

I want to do what almost every consumer software product does these
days, e.g. Firefox, Adobe Reader, etc: When it starts, check whether
updates are available, if they are, annoy the user with an "Update Me
Now!" dialog, and download and install the update.

Regarding WebStart, there are four issues I see:

- Our application comes bundled with a JRE which also has to be updated.
I cannot bundle a download version with a JRE with WebStart, because
WebStart requires the JRE to be installed.

- Part of the application requires a license key to authenticate the
download.

- The software must also be able to display a list of "Available
Extensions" among which the user can choose.

It might be that all of the above can be addressed by WebStart, but I'm
afraid the most important reason is this one:

- People are not used to WebStart. They easily become irritated by
things they have never seen. They want to download an EXE file and run
it. (This is not my opinion, it's just whart I observe, and it *is* a
reason, although we may not like it.)

Best,
Simon

Simon

Simon wrote:
>> Regarding WebStart, there are four issues I see:
>>
>> - Our application comes bundled with a JRE which also has to be
>> updated. I cannot bundle a download version with a JRE with WebStart,
>> because WebStart requires the JRE to be installed.

Eric Sosman wrote:
> You can, however, specify what Java version(s) the application
> requires, and tell the user to install it if it's not already present.
> (Note that he may have obtained Java from some site other than yours;
> why push him a redundant copy?)
>
> There's probably a way to give some assistance, but I don't think
> you can automate it altogether. (Note that you can't completely
> automate the other upgrades you mention, either.)

Why must you bundle the JRE?

Why can't the user use their own?

--
Lew

Lew

Simon wrote:
>> You haven't provided much information. What kind of "client" are
>> you talking about, and what do you mean by "update?" Or, turn the
>> question around: What is it about your situation that makes Web Start
>> inappropriate? What do you want to do that Web Start doesn't (or
>> what does Web Start do that you'd rather it didn't)?
>
> I want to do what almost every consumer software product does these
> days, e.g. Firefox, Adobe Reader, etc: When it starts, check whether
> updates are available, if they are, annoy the user with an "Update Me
> Now!" dialog, and download and install the update.
>
> Regarding WebStart, there are four issues I see:
>
> - Our application comes bundled with a JRE which also has to be updated.
> I cannot bundle a download version with a JRE with WebStart, because
> WebStart requires the JRE to be installed.
>
> - Part of the application requires a license key to authenticate the
> download.
>
> - The software must also be able to display a list of "Available
> Extensions" among which the user can choose.
>
> It might be that all of the above can be addressed by WebStart, but I'm
> afraid the most important reason is this one:
>
> - People are not used to WebStart. They easily become irritated by
> things they have never seen. They want to download an EXE file and run
> it. (This is not my opinion, it's just whart I observe, and it *is* a
> reason, although we may not like it.)

JWS has the core functionality you need.

I find it very likely that it will be faster to develop the
bells and whistles you need on top of it than to start developing
the core functionality from scratch.

Arne

Arne Vajhøj

On Oct 29, 6:01*am, Eric Sosman <Eric.Sos...@sun.com> wrote:
> Simon wrote:
> >> ..What is it about your situation that makes Web Start
> >> inappropriate? *
....
> > Regarding WebStart, there are four issues I see:
>
> > - Our application comes bundled with a JRE which also has to be updated..
> > I cannot bundle a download version with a JRE with WebStart, because
> > WebStart requires the JRE to be installed.
>
> * * *You can, however, specify what Java version(s) the application
> requires, and tell the user to install it if it's not already present.

Sun supplies the deployJava.js - which will work even
if no Java is currently installed. It will check for
a suitable JRE and if not found, either guide the user
through installing it (Windows), or drop them onto the
Sun download page (Linux).

See
<http://java.sun.com/javase/6/docs/te...s/guides/jweb/
deployment_advice.html>
for further details.

> > - Part of the application requires a license key to authenticate the
> > download.
>
> * * *I don't know how to do this, but I'd bet its do-able.

See the ExtensionInstallerService. Demo at
<http://pscode.org/jws/api.html#eis>

> > - The software must also be able to display a list of "Available
> > Extensions" among which the user can choose.
>
> * * *Maybe I'm missing something, but that doesn't look like a problem.

See the DownloadService. Crude demo at
<http://pscode.org/jws/api.html#ds>.

--
Andrew T.
pscode.org

Andrew Thompson

On Oct 28, 2:13*pm, Simon <count.numb...@web.de> wrote:
> I am looking for ideas, patterns, practices to develop a client/server
> architecture that can be used to update clients when a new release is
> uploaded to the server. Does anyone know any web resources considering
> this topic? (WebStart is not what I want.)

The OSGi framework offers a flexible update mechanism. This is how
Eclipse does it. It also supports updating extensions separately from
the core elements of your app (actually it supports updating "bundles"
separately).

Several OSGi implementations exist: Equinox, Apache Felix and others,
have a look. It's very powerful but will require some adaptation to
your existing app.

HTH Phil

Philipp

One very good reason not to use JWS is that on OS X:

- users expects an app to be packaged the OS X way

- a *lot* of OS X users think that "Java sucks" (I don't
care about the reason for such thinking, I'm pragmatic and
want to make sales, not enter in some flamewar)

JWS screems "Java" everywhere... While a Java app bundled
using "Jar Bundler" and then put in a .dmg can "fly under
the radar".

These are two *very* good reasons to consider JWS unacceptable
and to 100% rule that option out.

cat flameswar > /dev/null

Another *very* good reason not too suggest JWS is that the OP
stated "WebStart is not what I want"


> I am looking for ideas, patterns, practices to develop a client/server
> architecture that can be used to update clients when a new release is
> uploaded to the server.

Patterns and best practice, I don't know, but ideas sure

I've got a client-side Java app deployed on a lot of systems
and at every app startup they contact a server (which is a Java
webapp server) to verify that their licence is OK and that
they're running the latest version.

I'm not automatically pushing updates that said but in case
it helps...

The client-side app simply does an HTTP GET into which we put
the infos in a Base64-like (URL friendly) fashion:

http://example.com/Z/43QYfqvPYT7wGOA...ousIw8 M0LiPa...

The info I send to the server are:

* version of our app
* JVM version
* OS
* proguard(ed) stack trace from last run if any
* etc.

Formatted in a way we have control over.

Then we zip/make-URL friendly and sent it using an HTTP GET.

The Java webapp server decodes the Base64-like then unzips
and we get all the infos we want back.

There's not limit on the size of an HTTP GET defined in RFC2616,
Tomcat by default accepts 8K GET but you can bump this up to 64K
if you wish (of course a POST would be fine too and would be more
'RESTful' but a GET is just sooo easy).

It's really amazing how much infos you can send using
zipped "strings" in a single HTTP GET request.

The client app reads the answer and there's a field that
contains the message to display to the user, if any.

If there's a message, the client-side app pops-up a message
to the user.

So it can be an automated "Version 1.07 is available" that
is displayed if user is running 1.06 or "Version 1.07 build 418
is available" if user is running "Version 1.07 build 316" and
was found affected by one of the bug that got fixed meanwhile
(we know this for stacktraces, if any, are send in that same
HTTP GET).

But it can also be message targetted to certain users. For
example we have a list of people who used to be beta-testers,
they tend to like to try "cutting edge" revisions, so we offer
them first the ability to download latest builds, etc.

You can simply drop newer builds on the server in a specific
directory and then the server chooses which message, if any,
to display to user, depending on the major/minor/build version.

Proguarded stack traces that comes back are automatically
'retraced' by our webapp server using the correct proguard-mapping
file and emailed to us as "crash logs".

New builds are simply 'dropped' on the webapp server and the
download page updates automatically as well as the response
to the HTTP GETs clients are making.

Once again we're not pushing updates automatically (but such
a scheme can be trivially modified to download latest .jar and
to use, at launch time, the latest .jar available)...

On the client side it's something like 30 lines of code, zipping,
Base64URlFriendly encoding and popping of the
JOptionPane.showMessageDialog
included

It may give you ideas

Alex

alexandre_paterson@yahoo.fr

Re,

I didn't read your second message before posting my first one...

On Oct 28, 4:37 pm, Simon <count.numb...@web.de> wrote:
....
> - Part of the application requires a license key to authenticate the
> download.

Same for our app... Amongst the info sent we sent the user's
product key and this influence messages send back by the server
(say "7 days left in your trial-version").


> It might be that all of the above can be addressed by WebStart, but I'm
> afraid the most important reason is this one:
>
> - People are not used to WebStart. They easily become irritated by
> things they have never seen. They want to download an EXE file and run
> it. (This is not my opinion, it's just whart I observe, and it *is* a
> reason, although we may not like it.)

Oh I hear you...

I gave the example about OS X in the other post.

There's no way, unless you want to loose 90% (guestimate) of your
OS X customers, that you'll be offering them a JWS app instead
of a .dmg file.

Pragmatism rules the day

As you said, it's a reason: it's not about liking that
fact on technical merits.

It's about that *fact*.

Alex,

alexandre_paterson@yahoo.fr

On Oct 30, 5:36*am, alexandre_pater...@yahoo.fr wrote:
> One very good reason not to use JWS is that on OS X:

I think you will find there are even more good reasons
not to 'use' an EXE on OS X.

--
Andrew T.
pscode.org

Andrew Thompson