开发完整J2EE解决方案的八个步骤
事务处理
国际化和本地化
群集和对象分布
Session管理
应用性能测量和描述
消息
工作流管理
入口和个性化管理
层到层通信协议
安全和防火墙
应用体系
应用体系建立在企业系统体系之上，指的是一个特别的项目或者应用。在架构完成后，体系建立人员就会研究如何建立一个专门的应用。如果你的企业体系只是支持一个旧的J2EE版本，你可能就需要首先升级你的系统。如果由于预算或者时间关系而不能做升级，那么就必须在旧版本的技术限制下工作。重要的是，要建立企业级的可重用组件。最终的目标是要满足客户的需要。
一个体系建立者并不是一个设计者;体系和设计是两件不同的事情。一个应用体系的范围是系统的主要结构、它的体系设计模式以及你可以在上面增加组件的架构。体系主要是涉及实现的非功能性方面，而设计是和商业的use cases有关，use cases是指你应用来转换域对象模型为一个技术对象模型的部分。应用体系是项目的结构，一个专门的应用。你通常在应用体系结构开发时要作出的决定包括有：
层间的功能划分
模型域对象
以前的系统需要保存的东西
购买的软件组件
需要建立的组件
如何集成第三方的组件
图3中的订单域对象解释了你如何做到模型化域对象。对于当前的Java技术，你可以将域对象分布在几个地方，包括有作为开发者管理的持续对象放在Web容器中，作为EJB放在应用服务器中，或者作为存储过程放在RDBMS主机中。
在宠物店的设计图中，我们将订单对象设计为一个实体bean、一个细节的对象和一个数据访问对象，如图5和后面的图6所示。当你看到这些时，你将会认识到其体系的重要性。你可以想一下为什么一个在分析模型的域对象被映射为这么多对象，以及如果改变该设计的`话，将会发生什么事情。你也许已经听到过EJB的好处，不过要注意的是不同厂家实现起来的性能是有区别的。当新技术到来时，在将其放在到一个系统之前，你需要做研究并且动手做一些测试。其实所谓体系的开发，就是将设计和实现域对象模型的垂直块转换为设计其它许多域对象。
在J2EE出现的早期，一些面向对象的设计者尝试将域对象映射到实体bean中，并且将它们在层间传送。他们拥有非常好的UML框图，不过得到的结果是一个慢的系统，这是由于不必要的网络通信造成的。由对象分析直接进入对象设计，而没有一个体系的设计，没有清楚地理解一个新技术，这样通常都会导致一个项目失败。
可交付的体系
由于J2EE体系是一个相对新的主题，因此一个可交付的J2EE体系并没有很好地定义。在宠物店的例子应用中，是很难看出体系在哪里结束和设计在哪里开始。文档由高级别的应用体系检查、Model-View-Controller设计模式的讨论和一个体系概览开始。低级别的文档就是源代码。没有UML框图。Sun的J2EE企业体系认证的委派部分要求所有的可交付体系都用UML表示。不过，这里仅表示为一个类框图、一个组件框图和一些对象交互框图，。这些对于一个真正的J2EE应用来说都是不足够的。要开始的话，体系规范和流程至少需要以下的方面：
一份系统体系文档，用来描述你现有的硬件、软件、网络拓扑和其它的组件。
一个应用体系文档，用来描述应用的主要结构，包括所有对于体系有重要作用的组件、use case组件和以前的组件的一个逻辑视图。
一个新组件设计指导方针，用来描述所有的设计方针和体系决定，解释全部这些决定，并且说明如果选择其它的选项会有什么可能的结果。这些方针应该包含所有重要的基本决定，以便进行新组件的设计时可遵从这些规定，以维持系统体系的完整性。
一个工作体系原型来评估新的技术;从开发和配置J2EE应用中获取经验;建立体系架构;通过测量性能、扩展性来预示所冒的风险;还有向客户证明你的方法是可行的。
在你开发过几个J2EE方案并且获得更多的经验后，原型将不再那么重要，这时一些UML框图和一些设计方针就可能已经足够了。
IV、对象设计
在体系规范的指导下，设计可在技术上扩展和适应分析的结果。分析阶段时，域对象模型化应该和技术的细节无关，而对象设计时则是和技术因素密切相关的，包括在体系开发阶段时，采用哪一类的平台、语言和厂家。理论上，你不要修改商业对象，除非是为了维护它们基本的属性和行为而必须这样做。
在体系决议的指导下，一个详细的设计说明应该提到所有类的规范，包括必要的实现属性，它们详细的接口和伪代码或者操作的纯文本描述。规范的详细程度应该达到只要和模型框图结合，就可得到所有必要的编程信息。在许多自动化的软件生产流程中，你可以从面向对象的框图中产生代码的框架。要注意的是stub和skeleton通常是无需在框图中展示出来的，因为它们对于设计者和编程者来说都是透明的。我在图6中包含它们只是为了说明EJB的基本点。
在你完成详细的对象设计后，你就完成了域对象的对象相关映射。这样做的原因是，虽然面向对象的方法论在目前是比较先进的，不过最流行和持久的商店都是关系型的。此外，一个客户的IT架构在许多方面都已经反映了现有的投资和商业RDBMS厂家的选择。因此将域对象模型转换为关系模型或者数据库表是非常重要的。有很多容器管理的工具，不过它们不能代替一个好的关系数据库设计。
V、实现
有了一个好的架构和细节设计，实现将是一个很清晰的任务。此外，由于我们在体系原型阶段设计和实现了系统的一个垂直部分，因此在实现阶段我们不会碰到很多麻烦事情。在许多公司中，开发者通常都是过早进入实现阶段，特别是当经理在监视他们的时候，因为对于他们，做其它的事情等于浪费公司的时间。
结果是，不再花时间来画UML框图，而是在代码开发中测试想法，这要花数星期和几个月的时间，在这种情形下，所有的体系决议和设计都是在代码阶段作出的，通常要在几个月后才会发现开发已经进入了一个错误的方向。