JavaEE容器为JavaEE应用提供了运行的基础环境。
Apusic 5.1包括三种类型的容器，Web Container、EJB Container和Client Container。
Apusic应用服务器5.1提供了一个全功能的Web容器，用于处理客户端发出的静态和动态WEB内容请求。Web容器首先接收客户端发来的Http请求，对于静态的Http内容请求，由Http静态内容引擎负责处理。对于JSP/Servlet和其它类型的动态内容请求，转发给JSP/Servlet容器进行处理。
JSP/Servlet容器负责解析JSP页面，以及执行和管理Servlet组件。Apusic 5.1兼容于JavaEE 5标准，实现了对Servlet 2.5和JSP 2.1的支持。
Apusic JSF引擎包括以下的特性：
独立的JSF引擎
不依赖于应用服务器，只需要将单独的jar包置于应用服务器类路径中即可使用。
容器级别的AJAX支持
在设计时，充分考虑对AJAX的支持，无需任何配置即可实现AJAX效果，开发扩展AJAX组件也更加容易。
简化的ManagedBean管理
使用JDK1.5的annotation，在类上标注@ManagedBean即可将一个POJO定义为ManagedBean，省去了维护faces-config.xml的烦恼。
扩展的导航机制
扩展了标准的JSF导航机制，除了允许使用导航配置规则中的view-id进行导航外，Apusic JSF也允许直接使用页面地址导航。
增强的布局和模板组件
Apusic JSF提供的布局和模板组件，提供了强大的页面布局管理能力。
扩展的富客户端组件
Apusic JSF提供了一组扩展的富客户端组件，包括DateField，TabBox，Menu，Tree，DataGrid等。
统一的资源和皮肤管理
Apusic JSF提供了统一的资源和皮肤管理机制，具有良好的扩展性。使用者可以根据应用需求制作自己的界面皮肤，将制作好的皮肤打包成jar放在应用中即可。
Apusic JSF的开源版本被称作OperaMasks JSF，关于OperaMasks JSF的更多信息，请访问www.operamasks.org网站。
Portlet是一种Web组件，为Portal页面服务。当一个Portal页面被访问时，通常会引发多个Portlet被调用。这些Portlet执行后生成的标记段组合在一起，被嵌入到Portal页面中。
Apusic 5.1对Web Container进行了扩展，提供了实现了JSR-168规范的Portlet容器。
虚拟主机是指能在单机上模拟多个主机的服务能力。在Apusic服务器中，我们能够将指定的某些J2EE应用与虚拟主机关联起来。当用户对虚拟主机发出的请求，实际上是对该J2EE应用的请求，同时该虚拟主机的资源无法通过其他的方式进行访问。从而有效实现了在共享硬件与软件资源的情况下，模拟多个主机服务用户请求的效果。
虽然Apusic 5.1自己可以处理静态Http内容请求，但在很多情况下，用户会选择使用其它的Http Server来处理静态Http内容请求。Apusic 5.1提供了一组Http Connector，可以很容易的将其它的Http Server产品，如Apache Http Server和IIS等，集成到Apusic 5.1应用服务器中。
EJB Container为EJB提供部署和管理需要的所有运行时服务。Apusic 应用服务器支持符合EJB1.X、EJB2.x和EJB3.0规范的EJB，包括Session Bean、Entity Bean、Message Driven Bean，以及EJB3.0中的JPA。EJB Container为这些EJB提供对象池、多线程、分布式、安全控制、事务支持和生命周期管理等底层服务，管理JPA、CMP的数据存储和提取。
Client Container是由一组Java类和XML部署描述符组成，它同客户端应用一起运行在客户端的Java虚拟机中，管理应用客户端组件的执行。像其他JavaEE应用组件一样，应用客户端的执行依赖于客户端容器提供的系统服务。客户端容器和Apusic应用服务器通讯使用RMI/IIOP。和其他服务器端的JavaEE容器相比，客户端容器可以说是相对简单的容器。
客户端容器提供的系统服务有：
创建客户端运行环境，负责和应用服务器进行通讯。
提供JNDI包装，使客户端能够使用java:comp/env名字空间。
认证客户端。应用客户端容器自动完成JAAS用户认证。
绝大部分web应用都使用session来存储用户相关的会话信息，Apusic应用服务器为Session提供了一系列管理手段。
当Session数量超过默认缓存大小，Apusic应用服务器会将内存中的Session持久化到存储介质中，并根据Session的活跃性对存储中的Session和缓存中的Session进行交换。
管理员可配置Session缓存池的的大小。Apusic应用服务器支持的Session持久化包括文件系统、RDBMS、BerkerlyDB，管理员可通过管理工具切换Session的存储方式。
如果Session中的数据非常重要，即使服务器失效，这些数据也不能丢失，那么建议采用数据库来持久化Session。
在集群环境中，当一个Apusic实例（Apusic Instance）失效时，它原来服务的所有用户的请求，将会由集群内的另一个Apusic实例响应。这个过程对用户来说要求是透明的，这意味着用户的登陆信息以及其它会话数据在此情况下不能丢失。由于web应用通常用HTTP Session来保存会话信息，因此，Apusic提供内存复制、Session迁移、数据库存储等多种技术来保证HTTP Session的失败恢复。
内存复制：Apusic集群中的任意Apusic实例可通过内部的复制技术，在网络中复制集群内另一个Apusic实例的Session信息，从而在该实例内存中形成另一个Apusic实例的Session备份。当某apusic实例失效时，另一个Apusic实例会接收此实例原来服务的请求，整个过程对用户是透明的，用户感觉不到原先对他进行服务的Apusic实例已经失效。
Session迁移：Session迁移是指在集群中使用Apusic负载均衡器来转发请求时，所采用的Session Failover技术。负载均衡器负责将失效的Apusic实例中的Session迁移到另一个Apusic实例中。
数据库存储：如果集群中的Apusic实例不使用In-memory Cache缓存Session，而使用数据库作为Session的存储中心。这时，由于Session不在Apusic实例中存储，因此，Apusic实例失效不会影响Session的使用。
Apusic集群中的负载均衡器，比如Apache或Apusic Load Balancer，在转发用户请求到集群内的Apusic实例中时，总是将一个用户的请求固定的转发到第一次响应他的Apusic实例中，这就是Apusic集群的Session Stick。这可以避免频繁的Session迁移，减小网络和服务器的负担。
在单个Apusic实例时，Stateful Session Bean的Session状态保存在服务器端的Stateful Session Bean对象实例中。而在Apusic集群中，采用创新的CSC（Client Session Cache）技术保存Stateful Session Bean的状态。CSC直接将Session状态保存在客户端，当服务器失效时将Session状态转移到可用的服务器上。Stateful Session Bean的特点决定了CSC技术是有效的，根据EJB规范，一个Stateful Session Bean仅限于单个客户使用，不存在共享的情况，因此只需要在客户和服务器之间共享Session状态，而不需要在服务器之间共享Session状态。CSC避免了Session状态发生改变时，在集群节点之间频繁的Session复制，提升了集群的性能。