the question as what technology  to use needs more input and study.there are a few hints though, - The most important point that I can see in your email is that you are looking for some long term solution and the fact that users of your system will grow enormously overtime.You need to answer a few questions to clear more things.

i ) Is security important for your system?
ii) Do you need transaction based  conversations within the system? are they flat or nested? clearly you have DB stuff, so transactions are needs at some stage.

This might get a bit tricky if the answer to the above questions is "NO". I mean in that case you don't need to use EJBs much as if no transaction / security is needed, EJBs will only over kill the system.other questions would be:

iii) do you have much concurrent access to shared data? NO? do not use entity instances. try to use DAO instead for performace purpose
iv) is there user  session management involved? and how?

if your system is simple enough and only it needs to handle so many users, you might get benefit of using some web  server tech i,e jsp / servlets / web services with DAO to interact with DB. in this way you can also support possible transactions.

For increasing volume of traffic and user access, you might start  thinking of an architecture  that can scale well over time to multiple web servers. if you are looking for an answer as what persistence  methodology to use, no one can answer that for you. these things are keep changing all I can say is to keep it flexible. in fact it is not that much important now.
I have seen projects that where tightly coupled with a piece of tech, and later on they went through huge cost to replace it or introduce new stuff.

If you fear from EJB technology  (same as me) you
better fear from portal  technology. Creating a hello
world application  toke half month for me. There are
lots of discussions over web  which will make you
review your solution architecture  again. Like EJB
Application Servers, most of Portal Servers do not
work correctly.

We are using Jetspeed2 from Apache
(http://portals.apache.org). If you found a good, easy
to use and flexible portal server; if you are not a
witch, you are really so lucky.

Thanks for your attention and comment. Decision about using Portal technology  is our compnay managers decision not technology experts. But we (technology experts) decide to use JBoss Portal + Weblogic Application Server. Can you explain more about Portal technology problems.

Now its been a month that I'm tring JetSpeed2. Same as
you, it is not my recommendation to company manager,
but he is still insisting . . .

I completely agree with 'Ali Behzadian Nejad'. You
must be a JAVA SUPER EXPERT to write a simple hello
world portlet and should be a SUPER HERO to be able to
deploy it in a portal.

There are some documents over net which prefers 'exo'
and 'pluto'. But I myself suggest apache software,
because of its great integration, support, security,
performance and usability.

Arash, please let me know if you ever tried JetSpeed2.
Because I saw better review results from Jetspeed2
from other open source portal  Servers. Additionally,
JetSpeed2 is reference implementation of JSR168 and is
using standard open source software of Apache
(Velocity, Log4J, Pluto, ...). By all of this, if you
still thinks others are better, let me know to
migrate. It would be very much appreciated.

Just, please, review your requirements. If you
interested I could send you 100 links that recommend
using a simple JSP/Struts/MySQL approach instead of
dealing with Portlet/Portal/Servlet/Tomcat/Oracle
approach.

If you started using JetSpeed2, feel free to ask your
questions. I will help you if I could.

no it is Pluto, although JetSpeed2 is also using pluto in its core.

there are two big problems with JetSpeed, first one is it is even older than JSR 168 it self, and its architecture  is a little bit old, second is it lacks a big company supporting its development.

but there are also two good  thing good about it, first one is apache license and second is most of its portlet classes are extended from their similar HTTP classes, so you can cast them to the parent HTTP class and use them in frameworks that don't support portlet.

exo and liferay are also good portals but they have their own technical and non technical problems; and thats why I have started a new portal  project (I am currently searching for an sponsor company to sponsor the development)

> You must be a JAVA SUPER EXPERT to write a simple hello world  portlet and should be a SUPER HERO to be able to deploy it in a portal.

I don't agree with this one too, using Java Studio Creator (now Netbeans with web  pack) and pluto it is very very easy to develop a portlet and deploy it, it is as easy as dropping some JSF components from palette to page, and clicking on run button. there is no portlet knowledge needed here.

have your tried exo, liferay and stringbeans?
would you please tell us about your exprience with jetspeed and its problems?

Forget java  EE portal  servers. They are so complicated and so
heavy to run. I was traslating eXo portal into Persian. It was horrible.
Instead, try to use pure Java EE and JSP. These are standard, lightweight
and good  enough for all size of projects. If you want to use a framework, try
small and fast web  frameworks like Struts. It is easy to learn and easy to use.
And remember: Your app should support new technologies  like AJAX.
If I was planning new project  with Java EE, I will use these:
Pure JSP and Servlet,
Hibernate for persistence  layer,
Oracle Express (or SQLExpress) as DBMS,
JBoss App Server,
Eclipse+Ant as IDE,
A good framework for AJAX (I don't have any idea about them)
...
Another important issue:
"Will my app scale when millions of people start  using it?
Ya know what? Wait until that actually happens.
If you've got a huge number of people overloading
your system then huzzah! That's one swell problem
to have. The truth is the overwhelming majority of
web apps are never going to reach that stage. And
even if you do start to get overloaded it's usually
not an all-or-nothing issue. You'll have time to adjust
and respond to the problem. Plus, you'll have more
real-world data and benchmarks after you launch
which you can use to figure out the areas that need
to be addressed."

the idea of "wait until that actually happens" its a bit worrying and dangerous. what should be considered the simplicity in scaling well and not necessarily installing powerful and expensive servers right away. In some view I agree that he should wait until the system reaches that number of users, but he should be able to estimate that sooner than later and design the system and choose technologies  that are able to scale to higher number of servers easily

you're also listing technologies and IDEs to use without knowing much about characteristics of this system. one can end up with some of the items in this list, but this is too fast jumping into conclusing.