I need to have a service program (windows daemon) run in the background to collect data from my devices. In JAVA I guess I would run two JREs one as a SERVICE and another for a GUI to the user. Is there any way to communicated between the JREs besides using a file for the service JRE routine to write to and for the USER GUI JRE to read from? Thank you. Alvin...

I think you're over-thinking the Java architecture. Just think of the application(s) as programs/processes, and use whatever interprocess communications API is appropriate and supported on the target architecture. Shared memory would be one of those, on Windows. On Linux, there are other methods as well: message queues & sockets being the most prominent. Each has its particular virtues and limitations. Control systems tend to be very event-oriented, and sometimes the existence of new data is as important as the data itself. Message queues tend to be appropriate for such scenarios. I don't know specifically what is available on Windows. Using files as an interprocess communications channel is almost certainly a suboptimal choice.

--- rod.

Sockets, MQs, RMI, CORBA, I think all were already mentioned as generic/Java-specific standard technologies to use for IPC. Just forget there's the JRE, it's just a wrapper or part of each running program, there's no single VM all the apps are living in, you don't care about it, it's just the abstract standard that allows each OS to be exposed as exactly the same system so that the compiled-once byte code can run anywhere.

Java is a closed system that is why it is portable. Sun stopped supporting javacomm for windows. RXTX has taken over the comm role but that makes java less portable. I am even thinking of using C for the SERVICE running in the background for windows. At least C could deal directly with COMx: ports. Then use a file system to transfer the information to the java gui. The info for the gui operates at human speed so the file system should be fast enough. The problem comes in in getting the information into a database. Java can have its own database which would be good as I can't force the user to install MySQL. One job of the SERVICE routine is to collect data from the boxes and put it in a database so it can be analysed and plotted. The SERVICE also acts as a go between with the gui and the devices to translate the gui human interface to packets the devices can understand. I will mostlikely try to use javacomm and RXTX to talk to the devices just as a learning experience to see if it will work as java would give more portability to the software than C.

You can use SQLite, which is simply a library that is linked with your application. You don't need to install any third party database server. Speed is not the issue with using a filesystem for a database.
The application talking to your field bus should be simple and easily written in a way that is portable across OS's. C would be appropriate for that.
Have you looked at existing software packages, such as data acquistion or SCADA packages? You're re-inventing a lot of wheels here.
--- rod.

Will SQLite also work with java or do I need an interfacing C program?

Reading http://stackoverflow.com/questions/4...ava-and-sqlite
I'd noteWhich echoes what's on the wikipedia page for itAlso note the suggestion of http://hsqldb.org/

1 members found this post helpful.

That simply means that the work of locking on a file-based database has been looked after, and probably better than one could do on a roll-your-own basis. I doubt that the OP's application is going to be either very busy or sensitive to brief lockouts. Still, good to know the constraints.

--- rod.

1 members found this post helpful.

SQLite will work just fine with Java. You'll use the standard JDBC interface - meaning that the *same* Java code will run - with no source changes or any recompiles - with *any* database.

Here's a tutorial on JDBC (it's easy):

http://en.wikibooks.org/wiki/Java_JD...ple_base_class

There are several JDBC drivers for SQLite to choose from. Here are a couple:

http://www.zentus.com/sqlitejdbc/

http://freshmeat.net/projects/sqlitejdbc/

1 members found this post helpful.

WHAT I am leaning to now is writing my own flat file database primatives. I don't need all the bells and whisels. Just a file containing the database fields and types and maybe an ISAM file for the database. It is all internal anyway and could run as a SERVICE detached from the SERVICE accessing the devices and detached from the gui that the single user would be using to update the various variables used in controling the device that he/she is currently accessing.

Don't reinvent another wheel, just use something like SQLite and move on to the specifics of your device & the problem/solution it's for.

My point about the locking is that I think you'd need one instance of your system to be engineered to the gatekeeper to the DB, aka the DBMS, whereas something more fullblown like my/postgreSQL come with that and a bunch more. With them your remote sensors could insert their data rows directly whenever and the DBMS manages things, the tradeoff being the extra storage and running resources cost of a relatively small instance of them, rather than the possibly slimmer integrated SQLite + hand-rolled wrapper. But I could be wrong with how you want to structure your system's interactions, maybe you always want your sensor devices to talk to your central service and send their data via that anyway. I could be wrong about SQLite and multiple db clients/users. But all I think you'd need to do is read which solution is right and then use it, not rewrite one of them to be the other.

1 members found this post helpful.

If I did use SQLite I would most likely need to run it as a SERVICE in ist own right with maybe one file into it and one file out-of-it just like the device SERVICE routine That wouild serialize the access of the database and I would only have to lock the file in-to-it so that the device SERVICE and the GUI routine could only access the input file one at a time. I would include a username of DEVICE or GUI so that the device SERVICE routine and the GUI would know who the output record was for. Not that this database would be in C and not be as portable as java. I could use HYPERSQL which is java based though

Why would it have to be in C?
Why can't you put MySQL or PostGreSQL or some other DBMS with your installer rather than recreate your own?

1 members found this post helpful.

I thought that SQLite works like a library that you program uses, and does not run as a deamon.

1 members found this post helpful.

I think we're going in circles now. Yes AFAIK it's an integrated part of your program, which is fine assuming you have one instance trying to use the database. For a system with a central server, many remote nodes reporting to the database, and a GUI reading it, something needs to manage things and I don't think SQLite is strong at this. So one must either work with the limitations (possibly just having to wait and try again for inserts/updates), write your own managing service, or use something with a pre-made DMBS. I could be wrong.

1 members found this post helpful.