Java server - jumping in head-first

[Bruce Juntti]

Hi,

I am new to Java and have been taking Sang Shin's Java Passion course and reading Herb Shildt's book "Java 2 - The Complete Reference" cover to cover. Still wading through both the course and the book, but now I have a project at work. I am a system admin and we have hundreds of servers using homebrew perl backup scripts that run on both a client and a netbackup server. Diagnosing backup problems is sometimes a nightmare so I've added some networking to the perl scripts that sends status info (like breakpoints) to a central server. I want to use a Java server on this central server that listens on a port and opens a file for each machine doing a backup. Then I was thinking of using an applet that would read each of these files (essentially "tailing" the files) and show each machine's backup progress in real time with the applet.

I'd like to ask for some ideas for the multi-threaded server since the Java server will have to keep track of each machine and put the right status message for the right machine as it receives them on the network port. I've found some code on the InformIT website that looks good, but was wondering if the code for the "robust Java server" is overkill.

Being a Java newbie, I'd like to see what other approaches there are.

Thanks

Bruce

[Jelle Klap]

You could run a Servlet container (e.g. Apache Tomcat) and use a simple communication protocol like XML-RPC - a SOAP web service seems like overkill, although Java does offer some excellent API's - to post status updates from the perl scripts directly to the server. The server could keep this information in-memory, or perhaps persistently store it in a (lightweight) database. Using Servlet/JSP technology you could dynamically display this status information on a plain HTML webpage - no need to include an Applet. Should be easy enough to implement.

[Campbell Ritchie]

Welcome to JavaRanch

That question looks too difficult for "beginning" so I shall move it. Now that Jelle has replied, I know where to move it

[Bruce Juntti]

Thanks Jelle for the reply. What you are saying makes sense...sorta.... me being new to all things Java. I'm starting to get the deer-in-the-headlights look since now I need to investigate Tomcat, JSP, and servlets. BTW, is Glassfish the same thing as Tomcat? I looked briefly at Sun's website for Glassfish but it seemed that it was loaded with yet more acronyms. But I digress...

Thanks again for the suggestion. I want to take best route for this little project...even it makes my head hurt.

Bruce

[Mathew Lee]

Glashfish is open source application server for java EE platform from Sun. It can do similar job as tomcat server does.

[Bruce Juntti]

Thanks Gudim for the reply - that's sorta what I figured. And thanks again, Jelle, for the idea. I think I'm going to study up on servlets. I don't know at this point if I need to implement Tomcat (or Glassfish), but I guess I will find that out.

Thanks

Bruce

[Jelle Klap]

Bruce Juntti wrote:Thanks Gudim for the reply - that's sorta what I figured. And thanks again, Jelle, for the idea. I think I'm going to study up on servlets. I don't know at this point if I need to implement Tomcat (or Glassfish), but I guess I will find that out.

Thanks

Bruce

A Servlet container like Tomcat would be quite sufficient, there's no need to run a full-ledged JEE application server like GlassFish.
By the way, if you decide to go for XML-RPC as your communication protocol, I'd recommend taking a look at the Apache WS XML-RPC library.
It's pretty straightforward and it ships with a ready-made Servlet that can handle incoming XML-RPC requests, which should be sufficient for your needs.

[Bruce Juntti]

The Java greenhorn is back. Well, I've got Tomcat set up and I've been doing some reading on servlets and JSP - got the book "Murach's Java Serlets and JSP". Here's what I'm trying to do: we have roughly 1200 systems here at my work, mostly Sun Solaris, which run a Perl script that sends information via email to a central system. Right now it's kind of a kludge of sendmail, procmail, Perl, and PHP on the central system that gets the info, updates a MySQL database so users can query the database from a browser. I want to make the whole thing cleaner by (hopefully) using Java, servlets, and JSP to do the same thing. Jelle suggested using XML-RPC, and I just did a little poking around and it looks to me that there IS an XML-RPC module for Perl, but I'm trying to keep it as plain vanilla Perl on the clients as possible because loading special modules on 1200-plus servers is a PAIN! Plus, being a large corporation with change control and all the bureaucracy, that would make it even more painful. So, what I'm looking for is a method of using my current Perl script to connect to a port on the central server and use a servlet on the central server to get the information from our systems (in a simple XML format). My (little) understanding of servlets is that they only listen to HTTP requests, so I'm wondering if there's a way I can make a servlet listen on a plain ol' TCP port and get the information from the client Perl scripts. Did I explain that satisfactorily?

[Ulf Dittmer]

If the communication doesn't use HTTP, then a servlet container would not be a good starting point. If you do decide that you need one -maybe because there is a web app that presents the results of the processing- then it is possible to open ServerSockets for any port in a servlet container (maybe in a servlet context listener at web app startup time). That would not use the servlet API, though - it would be regular socket server than just happens to run in the same JVM as the servlet container.