client/server app - help with design needed 2

[frag]

Hi folks,

I have a design related question for you:


We need a client/server application, which helps us administrating and maintaining our project.
The user should be able to make some entries in a database and it should be possible to start some shell scripts on the server within the client. It would be very nice if the server could return the exit code of the shell scripts and display the log-file. All of this in a nice GUI.
More features are not planed at the moment but I am sure that they will be demanded once the application is running. ;-)
My problem here is that I don't know which technology I should use. Available technologies are JSP, a JBoss-based approach (J2EE) or a self written client/server-application in pure Java. The latter should be avoided if possible because I think that this would need too much time and would end up in a slow monster of an application (sockets, threads, etc).

I am tending to give the JBoss-based approach a try because I think that it would be easier to handle the execution of shell scripts and notification of the client if the jobs finish/fail (keyword: messages).

What do you think a nice solution would look like?

Regards
frag

real_firestorm@gmx.de

 

[Diancecht]

Well, there's a big difference between a J2EE application, that is executed through a browser with HTML presentation and a pure client/server application that is executed at client side, needs to be distributed, consumes client resources ...

I don't think one is better that another, it just depends on your needs.

Cheers,
Dian

 

[frag]

Hi Diancecht,

I forgot to mention that the JBoss-approach would include a fat client application as frontend, not a webapplication.

frag

real_firestorm@gmx.de

 

[Diancecht]

Well, not sur about how are you planning to communicate a fat client with a J2EE application, but once you plan to distribute a program, why not build an standalone server application and communicate with RMI?

I must confess I know nothing about JBoss features.

Cheers,
Dian

 

[frag]

Good question! I must confess that I only know some Java basics and have little knowledge about JBoss and J2EE.

RMI is a good point. I will try to make myself more familiar with this technology. I just stumbled over RMI while chasing information on the internet.

Is it possible to have a communication in both ways client/server and server/client with RMI. I will need to have the possibility to send unrequested messages from the server to the client.

About the communcation issue:
You are not forced to use a webclient if you want to use an application server but I guess that in 99,9% people are using webinterfaces.

real_firestorm@gmx.de

 

[Diancecht]

RMI stands for Remote Method Invocation. I'm not very familiar with RMI, but AFAIK it invokes remote methods in server's object, so in order to serve unexpected messages, the client should be a RMI server too.

Another thing that can be worth looking at in this case is JMS (Java Message Service), that allows you to send messages from one application to another.

Cheers,
Dian

 

[timw]

... self written client/server-application in pure Java would end up in a slow monster of an application (sockets, threads, etc).

I would have said that this approach has the potential to show the best performance of the methods you propose. It would be tailored exactly to your needs. The others add extra layers / overhead to the solution and are all based on sockets and threads in any case.

Tim

 

[frag]

timw,

you might be right. I guess I will give this approach another try.

Could you just give me a hint regarding sockets and RMI. When using RMI, will I have to take care about the sockets or will RMI do this for me? I have read something about rmiregistry and nameservices and I am a bit confused at the moment.

real_firestorm@gmx.de

 

[Diancecht]

You don't have to take care about sockets, using RMI you just work with objects.

http://java.sun.com/docs/books/tutorial/rmi/overview.html

Cheers,
Dian

 

[timw]

RMI is built on top of sockets. If you do your own socket comms, you can forget about things like RMI. If you use RMI, you're using a higher-level approach. The RMI implementation layer will handle all the underlying socket stuff behind the scenes.

Anything which adds layers to the implementation model will slow things down. RMI is build on top of sockets and so is slower.

If you want to play with RMI, have a go at

http://java.sun.com/docs/books/tutorial/rmi/index.html

I followed this tutorial successfully a few years back and it worked first time (unlike a prior encounter with Microsoft DCOM which I NEVER got working EVER). It might help you to decide if RMI will suit your needs.

Tim

 

[timw]

Ah Dian. You beat me to it

Tim

 

[frag]

No problem, I gave a star to both of you. :-D

So, thank you very much for your input. That made my day.

real_firestorm@gmx.de