Opinions on application design?

[Davey]

I am planning on developing an application which will involve skills that I
have very little experience of - therefore I would appreciate comments on my
initial design thoughts.
Overview on system:

I'm not going to divulge the exact aims of the application but the purpose
of it is to allow multiple client applications to retrieve data from a
database (on a db server) and feed this data into another Windows
application using it's C++ API (already provided to me). There could
eventually be thousands of client apps connecting to this server, and the
database could have millions of rows. Each row of data retrieved would
typically have around 5-10 fields of information and rows would only be
retreived one at a time ie each transmission between server and client would
be only one row of data.
Rough design plans:

I plan on having the following major components:-
- The source database
- The server-side application
- The client application which will run on Windows and will use an API to
control another Windows application on the same machine
- The database driven web application

I am planning on making the source database using mySQL due to the obvious
licensing benefits. This side of things is easy to me as I specialise in
databases (although primarily MS SQL Server).

The server side application will be written in Java and will use JDBC to
connect to the database. I am planning on implementing a cache into this app
so that database reads are relatively infrequent in comparison to data
requests from the client apps.

The client-side application will potentially run on thousands of client PCs.
It will request data from the server-side app which it will then feed on to
the other Windows application using the API. I am planning on writing this
in C++ as the API is in C++

The web application will connect to the database and will allow users to
manage the data. I will probably write this in PHP.

Issues/questions:

- What is the best method to allow the C++ client app to speak to the Java
server application (e.g. request, send and receive data) - what about SOAP?

- Will a Java server-side app cope efficiently with for example 10,000
simultaneous client connections with each requesting data roughly once every
10 seconds?

- In these plans I have given the web application a direct connection to the
source database. Is this a serious security risk and if it is what steps
should I take to minimise this risk?

- Is it easy to encrypt the data transmission between the C++ client app and
the Java server app?

- Should I consider any different approaches to the ones mentioned in my
rough design plans?
Please bear in mind that I have almost no experience of writing cient-server
applications so any comments, advice, tips or pointers to relevant reading
material would be greatly appreciated.

TIA.

[Stefan Schwetschke]

Davey <da***@hotmail. com> wrote:
[...]

- Will a Java server-side app cope efficiently with for example 10,000
simultaneous client connections with each requesting data roughly once every
10 seconds?

[...]

People might flame me for posting this to a database group :)

Perhaps prevayler (1) is an option for you. Prevayler is a framework,
that can be used to replace a database. Prevalyer holds every object in
memory, thus it is much faster than a database. It supports clustering
and persistent. To some extend it can replace a database with ACID
properties. It is NOT a real database, it doesn't really support
transactional isolation; but it can be fast as hell.

Geggo

(1: Prevayler)
<http://www.prevayler.o rg/>

F'up to c.l.j.d

[Stefan Schwetschke]

Roedy Green <my************ *************** ***@munged.inva lid> wrote:
[...]

another possibility is a serialised object, possibly compressed.
Another is RMI.
I thought the OP wanted to have Java at one end and C++ at the other
end. But you're right, this is not perfectly clear from his post. So
Java specific IPC might indeed be an option.
another custom binary format messages on a raw socket
Designing an IPC mechanism from scratch needs some serious experience
with distributed systems and their error semantics. One must be
expecially careful with endianess, field lengths and protocol versions,
otherwise one gets some nasty bugs that are very hard to track down. It
is alos very hard to design a protocol that can cope with network
failures. No offence, but I think the OP lacks this experience. Hence my
hint to preexistent solutions that could fit his needs.
See http://mindprod.com/jgloss/remotefileaccess.html
for a catalog of possible connection techniques.

WebDAV is another intresting file transfer protocol. It can be easily
implemented using servlets. There must be a modular WebDAV
implementation somewhere on the Apache Jakarta site.

Geggo

[Roedy Green]

On Tue, 25 Oct 2005 10:15:52 +0200, ne*****@schwets chke.de (Stefan
Schwetschke) wrote, quoted or indirectly quoted someone who said :

I thought the OP wanted to have Java at one end and C++ at the other
end. But you're right, this is not perfectly clear from his post. So
Java specific IPC might indeed be an option.

Even if he does, he can still do a link with C++<->C++ or Java<->Java
and then bridge to the other at one end with JNI, sockets etc.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On Tue, 25 Oct 2005 09:17:47 GMT, Roedy Green
<my************ *************** ***@munged.inva lid> wrote, quoted or
indirectly quoted someone who said :

I thought the OP wanted to have Java at one end and C++ at the other
end. But you're right, this is not perfectly clear from his post. So
Java specific IPC might indeed be an option.

Even if he does, he can still do a link with C++<->C++ or Java<->Java
and then bridge to the other at one end with JNI, sockets etc.

This clumsy-looking solution might have special appeal if your link
has to be encrypted, needs custom protocols, has fancy authentication,
when C++ end is little endian, when you have a large number of custom
message types...

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.