由于遵从MVC（著名的模型-视图-控制器软件架构）整合了若干编程措施，Java 2 Enterprise Edition（J2EE）为高度复杂和可伸缩的因特网应用程序提供了基于组件的的强大开发功能。同时，J2EE开发层次的不同满足了各个方面的需要：某些开发者采用Enterprise JavaBean实现软件的模型；某些企业则利用JSP实现软件的视图；还有些开发商则专门通过Java Servlet实现软件中的控制器。一切都层次分明，井井有条。不是吗？
但是层次划分的技术复杂性却在实际开发中给开发人员带来了不小的压力和负担。多层开发模式有时会令J2EE成为庞大的、难以超越的技术集合。了解各类层次技术的特性是要花时间的，而且J2EE项目还过分要求小型开发团队的技能资源。充分理解现有J2EE应用程序的体系结构和实现令开发人员的学习曲线非常尖锐，尤其是在考虑到开发周期的时间限制这一方面上更是如此了。结果就会导致技术开发团队试图“躲避”合理的J2EE实现，很有可能在将来的开发或维护中引发问题。
为了避免出现以上问题，开发者们可以根据自己的实际需要分别采用不同的J2EE技术，这样可以更好地利用开发者的技能并让他们更关注于任务本身。
JSP 首要的而且也可能是最早单独运用的J2EE技术恐怕该算是JSP了。开发者们采用JSP可以创建具有HTML的表示页面和脚本小程序、JavaBean 乃至定制标签等功能。这种联合多种技术的JSP编程建议似乎是对单纯编程技术的诅咒；J2EE教义上说的是应用程序的逻辑和显示层从来都不应该混合起来。
然而，在有的时候，合理地唯一采用JSP会给项目开发带来莫大的好处。鼓吹表示层和功能层分离的争论观点实际上会给编程带来更大的负担，尤其是在单一JSP用在超过两个显示页面的情况下。但是体积更小更单纯的JSP项目却可能工作得更好。为了达到适度的工作量，像简单时钟这样的编码任务就变得非常容易了（参看程序清单A）。
这个例子说明了若干问题。以上程序中的代码提供了一个用户界面（虽然很基础），这个界面接受用户输入并做出动态响应，而这就是因特网应用程序所有的基本要素了，该程序连同注释在内只有33行代码。要编写一个JSP时钟程序的更有用实现所需要的代码就更少了：
<%
Date d = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("d MMMM yyyy, h:mm:ss a");
TimeZone zone = TimeZone.getDefault();
sdf.setTimeZone( zone );
%>
Current date and time in the <b><%= zone.getID() %></b> time zone: <b><%= sdf.format( d ) %></b>
只用JSP开发项目的另一优点是：JSP的学习和使用都相当方便。JSP采用了Java的语法，但在上下文环境中则完全可以用于其他服务器端开发环境——例如ASP或ColdFusion等。这样在没有多大技术变迁的情况下就可以充分利用JSP了。
servlets 只用到Java servlets的应用程序开发是另一种区分对待J2EE模型的方式。事实上， servlets完全具有它们自己的信息记录。许多人都没有认识到这一点，几年前，servlets还不过是服务器端Java开发技术的唯一选择。CGI风格的直观API大大减少了软件开发的周期。采用进程内内存管理最大化服务器性能的能力赢得了开发者和系统管理员的注目。链式servlets的集中对功能的提高更增加了这一技术的优势。同样的优点使得servlets成为当前相当受到欢迎的开发平台。集成其他的Java技术，比如通过JDBC的数据源等以及针对中小型项目的稳固解决方案也出现了。
传统思想较重的人可能对在servlet中包括数据连接不感冒；按照J2EE规范的说法，这种复杂设计应该驻留在Enterprise Java Beans（EJB）上。当然，这种观点对大型项目而言是正确的，但是，对那些简单的servlet，比如显示报告产品可用性图表的纲要程序（示例见程序清单B）却并不需要额外的处理。虽然以上示例访问数据库并动态创建图表，但是，数据库连接池的使用和开发者设计的资源管理却给给予了servlet以出众的运算速度和稳定性。产生同样结果的完整 J2EE实现在计算上的成本却大得多。
非Web浏览器式的应用程序采用servlets自有其优点。象Tomcat这样的Servlet容器在这种情况下可以实现低成本乃至免费的开发舞台，供开发人员营建和部署最新的无线信息平台。Servlets通过输出XML并且即时应用风格表单保证了用户能在他们的移动电话或传呼机上收到正确的格式信息。
EJB EJB被认为J2EE应用程序中对业务逻辑的编程实现，EJB最为复杂。从表面上看， EJB代表了实体bean形式的数据库存储信息或者会话bean形式的服务请求。这种简单的定义却恰恰掩盖了特别需要注意的幕后众多方面；陡峭的学习曲线使得EJB项目开发进展缓慢。开发者们必须小心对付EJB容器的怪癖特性。另外，代码的微小变化或调试经常会转变为特别耗费精力的任务。
然而，EJB在应对大型项目开发的时候却绝对是个好东西。由J2EE所保证的EJB容器所具有的内存管理、线程模型和交易能力允许开发者把更多的时间花在业务逻辑与代码处理的映射上。大多数EJB容器都允许经由XML文档对编译后的代码进行简单修正。根据UML图表为EJB产生Java源代码的工具也有，从而简化了从概念到实现的转变过程。
在单独采用EJB的时候，客户环境的选择也会发生变化。浏览器将不起作用，由于已经脱离了J2EE上下文环境，EJB此时不能引导基于Web通讯。而且客户程序也变得更丰富：应用程序、Java和非Java、企业信息系统甚至其他的EJB。在受控环境下的项目部署——便于更新客户应用程序的环境，比如公司内部网——是单独采用EJB的最佳条件。
