What Is The Proper J2EE Architecture For This Project?

A brief description of a national defense project I am looking into is that the system being developed is supposed to verify the "smartcard" of the card holder together with his/her fingerprints against the Defense Department database. The system also reads in information about people (name, facial features, height, weight, etc.) and stores the information in the database, and then issues new "smartcard".
1. People involved in the project already decided to use swing for the client tier.
2. The problem is the Defense Department database. It is a flat file database and this database cannot be touched. It is a black box for Java developers. The Defense Department may provide a jar as an outer layer of this database.
Question 1: Is the web tier essential for this defense project?
Question 2: What is the proper J2EE architecture for this project?
Question 3: How to deal with the data problem? Especially it looks that entity beans are not applicable.
Question 4: How does the system handle very heavy load? It is possible that tens of thousands of people will use the system at the same time.
[ June 28, 2003: Message edited by: JiaPei Jen ]

The database tier is where I would start the questioning. Mainly - how is it accessed, and is it relational.
Hopefully there will be an API available to access it as you say.
Are you interested in using an Application Server for this project, or will the client tier communicate directly with the "database"? The Application Server would host Session Beans providing business tier access to the information.

I thought that I have stated clearly in my original post that
1. It is a flat file database. But, software developers cannot touch this database for it is a top secret.
2. People incline to use swing to interface with users.
3. Of course, there is an application server.

Question 1: Is the web tier essential for this defense project?
Ans: No.
Question 2: What is the proper J2EE architect for this project?
Q: Architect or Architecture?
Question 3: How to deal with the data problem? Especially it looks that entity beans are not applicable.
A: Session Bean
Question 4: How does the system handle very heavy load? It is possible that tens of thousands of people will use the system at the same time.
A: Yes, it is possible if database support multiple user accessing.

Hi,
your task a great challenge.

good architecture is critical.i think three problems we should take for consideration.

1.where fingerprint and facial feature's eigenvector can be distill. i think database perfer storing fingerprint eigenvector to whole fingerprint image(too large).
2.how large amount of data of fingerprint or facial feature can be transfered to app server.
3.how can we make database query much faster under heavy load.

eigenvector distilling of fingerprint or facial feature are all heavy calculation involved, since app server is not so good at heavy calculation under heavy load, you should balance it on
your SWING clients.
now, you can tranfer them to app server. but data is still large after distilling, and rmi or iiop is not suitable for large data transfermation, so maybe you need a http
front end by which data can be transfered by http protocol using standred code format(base64?).you know http is good at transfer files with little overhead.after query, many result data may be returned to SWING client, then client will make confirmation through
further comparison of returned data and cached fingerprint.
app server is designed to handle heavy load, so you can use whatever facilitor it offered to improve you performance.connection pooling is good idea.pooled stateless session bean is nice too.entity bean ....may not suit, since no reason in this application for data cache, dist transaction and o/r
mapping, use jdbc access directly.

maybe what i conceived is not right, comments welcomed!

Finger prints will have to be read by an interface program, and Java interacts with the interface using JNI. There should be vendors who provide the interface plus JNI.

Originally posted by JiaPei Jen:
2. The problem is the Defense Department database. It is a flat file database and this database cannot be touched. It is a black box for Java developers. The Defense Department may provide a jar as an outer layer of this database.
>>>> If they provide a jar file, that would be
great. You do not need to care about whether
the data is a flat file or something else, you
just use this propriatory API the jar file
defines.
>>> You might use another abstraction layer of DAO
object and gets data from DAO objects.

Question 1: Is the web tier essential for this defense project?
>>> If it is not a requirement, why would it be?
Question 2: What is the proper J2EE architecture for this project?
>>> You can still use EJB for the transaction
management part, security, etc. However,
it seems to be that you app is a read-only
application, so EJB is kind of overkill.
If performance is a issue even if you only
use stateless session beans, then you can
use RMI directly, in case you do not need
transaction.
Question 3: How to deal with the data problem? Especially it looks that entity beans are not applicable.
>>> Entity beans are being perceived not
very necessary now because of performance issue
(some would disagree). You can use session bean
to call DAO object which in turn calls
the jar file API you get from you client.
You swing calls session bean as EJB client.
Question 4: How does the system handle very heavy load? It is possible that tens of thousands of people will use the system at the same time.
>> for heavy load, you resort to clustering
that application server shall support.
Here, EJB frees you from concurrent control again.
For security issue, if you are behind firewall,
then you might use SOAP (which is slow),
or RMI tunnelling. You have to encrypt data too.

[ June 28, 2003: Message edited by: JiaPei Jen ][/QB]