2

I am going to implement a server application that should update client software remotely. Clients mostly use pull mechanism for receiving updated software.
As a beginner I am looking for architectures to implement this application. And I know that Life Cycle layer of OSGi would give such service.
I want to know is there any other architectures that give similar service to clients?

Reza
  • 2,058
  • 3
  • 20
  • 33
  • How do you want to do that without turning the client to a server itself? The client has to accepts inconming connections or maintain a persitent push connection. I'd rather do then directly in the client – Michael-O Jul 30 '11 at 19:46
  • The client will request the server for new version details in periodic schedules. Also the client is off my authority! – Reza Jul 30 '11 at 19:50
  • Deducing from that, you description is wrong. You do not want to push from the server to client but pull from server to client. You should maybe consider Eclipse's p2 which has an appropriate mechanism. Maybe Maven's Aether will fit too. Combine both with Quartz scheduler and your are maybe done. – Michael-O Jul 30 '11 at 19:54
  • It is not the same for all clients. But mostly it is pull mechanism. – Reza Jul 30 '11 at 20:11
  • Then you should try p2 and see how far you can go. Implementing a custom update mechanism is a lot of work. Which OSGi runtime are you using? – Michael-O Jul 30 '11 at 20:17
  • I have not stated yet. But I had Knopflerfish in mind. – Reza Jul 30 '11 at 20:34

1 Answers1

1

If you're writing an Eclipse based application then p2 is the probably the simplest way to go. But if your application is either maven built or you're intending to run more generically on other OSGi containers (Karaf, Felix etc) then you should consider an OSGi Bundle Repository (see standard spec) such as the Felix implementation. If the OBR doesn't quite do what you want, then is API is exposed so you can manipulate it.

The OSGi lifecycle you refer to will give you true hot-deploy (as well as other "perks" of modularity) but the automatic update functionality is much more high level and not part of the framework core (container don't have to implement a remote update mechanism to be compliant).

Where I work we're using Karaf XML features (sets of versioned bundles constituting functionality or an entire application) which are created as part of maven build. From the OSGi shell we can use commands to instruct the OSGi container to find and install these features. This is really neat from a controlled deploy point of view, but if you want fully automatic updates then an OBR is what you want.

If your question refers to alternatives to OSGi as the basis for an update mechanism, then you're looking at things like webstart (JNLP) etc - which will only give you updates at start up time.

IMO OSGi is worth investigating as it's very pleasant to code with and deploy to. As an update/plugin mechanism it cannot really be beaten and you can embed the framework or customize it easily.

earcam
  • 6,662
  • 4
  • 37
  • 57
  • I'm not much familiar to JNLP! would you please give me some references? – Reza Aug 01 '11 at 15:13
  • Wikipedia sums it up nicely here: http://en.wikipedia.org/wiki/Java_Web_Start - basically your users would start the application via a browser link (initiates download of application, with the webstart mechanism checking against it's own cache). The file format is horrid http://download.oracle.com/javase/1,5.0/docs/guide/javaws/developersguide/syntax.html so build tooling should be used (e.g. for maven see http://mojo.codehaus.org/webstart/webstart-maven-plugin/). I'm not a fan of webstart, have seen issues with stale caches in the past, but if you just want simple remote updates it might do – earcam Aug 01 '11 at 15:42
  • It is not only a simple remote update. It may be something like firmware update. So I think the architecture should be component-based to make development of the server, easier. – Reza Aug 01 '11 at 20:17