There is some confusion all around on terminology--and opinions vary. But the easiest way we found to clarify this is to think about the EJB Server as a logical collection of "services" required by EJBs (for example, Naming Service, Transaction Service, etc). Physically the services need not be collocated in the same address space although that is possible. The Container is a specialized service in which beans get deployed and their lifecycle, transactions, security, naming, persistence etc. are managed according to a specific contract and constrained model that is the EJB specification. To do this, the Container uses the generic services provided by the Server. An EJB server is an environment for running EJBeans, including at least one naming service, at least one transaction coordinator, possibly a few databases, and at least one container. A typical server configuration will have exactly one of each of these services.

In IAS, when you say:
prompt% vbj com.inprise.ejb.Container ejbcontainer beans.jar -jns -jts –jss -jdb
It is a simplified view of the above where what you launch is a Container that itself starts up the generic services in-process .

You can logically think of this as a Server with 4 generic services (in same address space) with a 5th "special" service - EJB Container - that hosts your beans in beans.jar.

In contrast when you do
% vbj com.inprise.ejb.Container NS -jns
% vbj com.inprise.ejb.Container TS -jts
% vbj com.inprise.ejb.Container DB -jdb
% vbj com.inprise.ejb.Container ejbcontainer beans.jar
% vbj com.inprise.ejb.Container ejbcontainer beans.jar

You now have exactly the same application with a vastly distributed execution structure. Now your "EJB Server" is a logical collection of generic services and a replicated Container (for fault tolerance and load balancing).