J2EE首先是一种构架。它包罗了Java的多种先进的技术，最合适使用MVC的方法来构建系统，其表现层使用JSP，控制层可以使用Servlet或Session Bean，用于实现业务逻辑，Entity Bean则对业务实体进行抽象。此外它还使用JAAS实现安全机制，JNDI用于查询资源，JDBC和JTA访问数据库和管理事务；JMS实现企业的消息处理；JavaMail实现与企业外界的联系，不一而足。

要正确理解并设计J2EE的应用，应该树立以下的观念：

1.Professinal,每个参与者都应该是专业的专家。大的概念是容器提供商提供专业的容器及服务，部件提供商提供专业稳定的部件及服务，应用系统提供商对于单个的系统应提供专业的应用系统。从小的方面来说：JSP页面设计师是专业的，Servlet开发工程师是专业的，EJB开发工程师也是专业的，部署人员也是专业的。设计人员也是专业的。这是由于一个人的精力是有限的，一个项目是由团体人员通力合作的结晶，每个人应该对自己负责的部分非常专业，也可以这样说，J2EE并不太认同每个人都是通才、全才的想法，而是认为每个人应该是老老实实的软件蓝领，但在自己的领域中是出色的专业蓝领。

2.Configration，有人认为在项目中使用J2EE有n多的风险，说什么配置起来很复杂，很花费时间。其实，这种说法本身就是没有理解J2EE的一个重要的特性，即配置性。J2EE的配置主要由XML文件来完成，有ejb-jar，weblogic-ejb-jar，rdbms等等配置，正是由于这此配置，EJB的重用才成为可能性。而这些配置其实也有很多的工具可以用于辅助工作的。

3.任务简单化，真正在项目中运用过J2EE的人会发现，写EJB是容易的，而布署EJB应用也是容易的，写Servlet/JSP也不难。当然系统的设计是难一些的。这也正切合将大问题进行细分，符合分而治之的道理。

4.重用性。部件的重用一直是软件界的难题。J2EE的EJB如果设计得好，在以后的项目、应用系统中是可以重用的，这也包含供他人/自己重用，以及重用他人的商业化构件。

5.通力合作，沟通最难。在一个系统的实施过程中，什么问题最难，不是纯技术上的难，假以时日，当你的技术水平上升到一定程度时，您会发现，日新月异的技术专有名词不过是一些类似的、或似曾相识的名词的转换或迁移。我的一位同事很久以前就曾扬言，只有想不到的，而没有他做不出来的。我在一定程度上赞同他的话，如果不考虑时间限制，人力财力，诚然。什么问题难以解决？沟通问题是也。沟通包含客户-需求人员-分析人员-设计人员-编程人员-布署人员-计算机之间的迭代沟通。J2EE并不能解决这个问题，但是它要求参与的人员是Professional的，相互之间的沟通是有界限的，也就是设计中常说的接口界面。这在一定的程度上可以避免相互之间的紧耦合。