So it sounds to me like like a session bean is conceptually identical to a bunch of static functions or plain old stand-alone non-member functions in C. There is no object! Just functions.
Not really. Session beans are components that provide business services. The key is, since they are shared components, somehow the container( runtime environment) must be able to service multiple concurrent client requests using fewer object instances. Now, that's another difference, unlike C++ where one runtime process hosts all objects, we are talking about distributed processes here. The concept of container is that it is some kind of an infrastructure that will create and manage the shared distributed service components.
I can call these functions at any time -- I don't need an object. I don't need to call new.
Yes, you don't have to call new, but that's not because of C++ anology. Remember everything in
Java( well, everything that has behavior) is an object and you will need to instantiate the object before calling any (non-static) method. The only difference in the EJB scenario is that these objects are created by the container so you( the client) don't have to. You will simply "get to" the container, get the reference to one of the shared objects and invoke a method. Think in terms of other component technologies such as COM/DCOM, if you are aware of them.
So if was going to implement Stateless session bean pooling for my own EJB implementation, I'd create a linked list of Session beans that were not currently in use. But what would each element of my pool point to? NOTHING! So what is there to pool?
The linked list will contain the actual object instances. The container will manage dynamically linking a remote object reference the client has, with one of the free objects in the pool.