@yangjiandong
2014-03-31T09:17:46.000000Z
字数 23026
阅读 1749
XXXXXXXX平台需依托现有 IT系统及未来信息系统建设的要求，规划部署公共服务及基础计算资源，要求对现有业务系统平台进行全面的统一规划和翔实的梳理，建立高可用性、高性能的业务服务载体，提供不间断的业务统筹水平和实施监管能力，符合现代 IT 建设运维要求。
系统多样化，采用技术平台也有其多样性，既有集中控管的业务系统，也有分布式运营的生产系统，从技术层面来看，存在多种异构应用服务，异构数据平台等多种计算资源。硬件层面涵盖了多中操作系统及主机环境的服务器和存储系统，网络交换及路由分布涉及到多种网络设备及核心汇聚。
新的公共服务平台应该是一个具备高可用性的业务环境，这种高可用表现在业务运行的高可用性，而非单一的数据库层面或服务器系统的高可用性。
新的公共服务平台应该是一个具备高性能的业务环境，这种高性能不但体现在业务响应时间和业务处理的速度，还体现在对业务并发控制及数据吞吐量的性能保障。
新的公共服务平台应该是一个具备松耦合架构的可扩展的技术平台，该平台可以提供统一的标准来保障异构系统的读取接口和其他业务横联及流程系统所需的开放协议，此架构易于实现，原有业务系统改造可在此架构上实现平滑的重构，降低系统迁移的风险。
新的公共服务平台应该是一个安全的、易于管理的、符合ITIL 运维建设思路的服务管理平台。
基于以上背景和技术要求，架构设计的总体思路如下：
由于这是一个新建系统且必须严格的考量其业务的高可用性、高性能，因此从设计之初务必考虑其系统载体所提供的服务类型及特征，比如此公共服务平台上运行的系统属于哪种性质的 IT系统，是计算密集型还是服务流转型，是高集中高频率的数据处理吞吐型还是并发访问控制型，是计算资源安全重于效率型还是为保证效率平衡系统瓶颈型，是总线服务入网即用的 ESB 类型还是面向服务流程保证高度统一的 SOA 类型，是分布式集中控管的私有云类型还是多层次的集中服务分发类型。根据这些我们有必要编制一个企业 IT 业务系统调查表并请用户方及系统实施方配合填写。
当我们确认了系统类型后，结合业务情况，比如考虑应用吞吐量、分发HTTP 请求数量、 session 持久性、数据处理形式（逻辑读写、查询）等确认系统的初始架构，并以业务系统数据流为轴线，划分每一个层次的架构分布，结合容量管理充分考虑硬件及服务器存储数量和负载均衡的模式。
涉及到数据库层面的东西我们还是要结合业务的特征，来确认在保证高可用、高性能的条件下，如何进行数据库的环境架构设计，是使用多库横联形成DW 便于使用 cube 查询并将其用于 BI 等业务，还是使用多实例同步方式保证性能和高可用，还是使用单实例多节点方式来保证性能，以上方式各有适合的方面，需要我们审时度势来分别考量。
本小节旨在描述技术架构，不涉及任何厂商产品配置，您可以使用任何厂商的产品来配置此技术架构的搭建。本技术架构适用用于目前的主流厂商和开源厂商产品。并已经过实际项目的论证。
业务的高可用性这一点上，我们以 2点设计来实现这个要求。
1、 我们将数据流向作为轴线，划分了几个层次，对每个层次中的应用服务提供HA/LB 的集群设计，用以避免单服务的单点故障，并在集群设计的时候考虑故障切换和负载均衡的设计属性，包括链接上级服务和下级服务的链路均衡并采用适合的链接方式，如采用 JDBC/OCI POOL 方式及含有 LB/HA 特性的连接字符串 XE 的驱动模式。
2、 我们从整个系统来看，对于业务流程，如HTTP 分发过程中，静态页面及 J2EE MDB 的 SESSION 会话、 Spring Framework 中涉及到的数据持久化设计中对于 HTTP 会话性能和应用服务器处理时的路由过程是不一样的，在前端页面中及时采用了 JSON 或其他 AJAX 方式的页面对于 webcache 的处理产生了业务响应速度的不同影响，因此在整个横向的轴线上，我们有必要对进入 HTTP 服务的数据进行 cache 的缓存设计，用以保证 HTTP 的高可用。对于应用服务层面，如何涉及到异步数据传输的层面的东西，为了考虑更好的可用性和可靠性，必要将 JMS 服务作单独的冗余设计，同理，如果业务系统中发现应用服务中涉及到的流程 BPEL 的服务占有率很高，那么单一的设计应用服务器的冗余和负载均衡已经无法解决业务流程上的可靠性了，那么有必要对流程曾面上的 BPEL 的处理进行冗余设计了，再进一步来看，如果这些应用层面的服务还涉及到了流程集成和页面集成是否还需要对异步响应发布订阅、页面集成等技术要点进行冗余设计都值得大家考虑。
业务的高性能这一点，首先不能为了性能而设计性能拓扑。这一点对于复杂系统设计来说不具备好的耦合度，很容易和可用性设计产生重复投资。架构产生冗余。因此最好的性能设计在设计高可用的时候架构已经考虑了性能的规划，如缓存服务的设计，集群设计等。
松耦合和高度开放的可扩展性是以架构设计之初就需要拿捏的，松耦合需要进行设计上的迭代和测试，优化才能满足。实践是检验耦合度的唯一标准，再次不作赘述。可扩展性这一点对于不符合标准规范的私有协议，我们设计的时候一概不采用，不考虑，必要有开源组件的兼容和替换使用，其次使用有标准支持规范的设计模式，最后使用具备API 接口调用的架构组件。以上三点保障可扩展性的成功实施。
易于管理监控维护是架构设计的必备考虑，标准化后的组件、流程、服务均有对应的管理方法、工具来维护，因此松耦合可扩展成为了易于管理维护的基础。
以上架构图是一个典型的应用数据流的系统流程图，我们可以看到这些标注了数字的部分所需的高可用性方式，一般来说我们可以从技术上考虑以下 cluster模式：
第一种模式（如图左所示）也称为 “ 青铜拓扑 ” 。 这种模式包含一个应用程序服务器集群，其中，形成系统集成总线（ SIBus ）的 WebSphere Process Server 业务应用程序、 CEI 和 BPC Explorer 等支持应用程序、以及托管消息传递引擎（ ME ）的消息传递基础设施全部驻留在构成集群的每个应用程序服务器中。
青铜拓扑适合这样的解决方案：只包含同步 web 服务和同步 SCA 调用，最好只有短期运行流。
第二种模式（如图中所示）也称为 “ 白银拓扑 ” 。这种模式拥有两个集群：第一个集群包含 WebSphere Process Server 业务应用程序和支持应用程序，第二个集群包含消息传递基础设施。
白银拓扑适合这样的解决方案：使用长期运行流程，但不需要 CEI 、消息排序、异步延迟响应、 JMS 或 MQ 绑定、以及消息排序机制。
第三种模式（如图右所示）也称为 “ 黄金拓扑 ” 。与前面的模式不同，支持应用程序被分隔到第三个集群中。
黄金拓扑适合其余的所有情况，其中，异步处理在解决方案中发挥举足轻重的作用。这种拓扑还为应该在这种环境中运行的业务流程应用程序提供大部分 JVM 空间。如果可用硬件资源允许设置一个黄金拓扑，建议使用这种拓扑模式从头开始，因为它是用途最广的拓扑。
构建 cache服务非常有必要，有效的网络 Cache 系统可以大大地减少网络流量、降低响应延时以及服务器的负载。但是，若 Cache 服务器超载而不能及时地处理请求，反而会增加响应延时。所以， Cache 服务的可伸缩性很重要，当系统负载不断增长时，整个系统能被扩展来提高 Cache 服务的处理能力。尤其，在主干上的 Cache 服务可能需要几个 Gbps 的吞吐率，单台服务器（如 SUN 目前最高端的 Enterprise 10000 服务器）远不能达到这个吞吐率。可见，通过 PC 服务器集群实现可伸缩 Cache 服务是很有效的方法，也是性能价格比最高的方法。 基于LVS 可伸缩 Cache 集群的体系结构如图 2.3 所示：在前端是一个负载调度器，一般采用 IP 负载均衡技术来获得整个系统的高吞吐率；在第二层是 Cache 服务器池，一般 Cache 服务器放置在接近主干 Internet 连接处，它们可以分布在不同的网络中。调度器可以有多个，放在离客户接近的地 方，可实现透明的 Cache 服务。
Cache服务器采用本地硬盘来存储可缓存的对象，因为存储可缓存的对象是写操作，且占有一定的比例，通过本地硬盘可以提高 I/O 的访问速度。 Cache 服务器间有专用的多播通道，通过 ICP 协议（ Internet Cache Protocol ）来交互信息。当一台 Cache 服务器在本地硬盘中未命中当前请求时，它可以通过 ICP 查询其他 Cache 服务器是否有请求对象的副本，若存在，则从邻近的 Cache 服务器取该对象的副本，这样可以进一步提高 Cache 服务的命中率。
对于是否有必要对于系统采用 SOA化，我们首先来归纳一下目前的 SOA 优点、缺点，如下表：
表 1. 优点、缺点、糟糕之处
SOA 的良好业务影响
SOA 的不良业务影响
SOA 糟糕的业务影响
那么我们的系统是不是一个适合做成 ESB企业服务总线形式的系统架构呢？回答是否定的。 ESB 有时被描述为 分布式 基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被 描述为 中心辐射型（hub-and-spoke） 。然而，这并 不是真正的差别。正在研究两个不同的问题： 控制的集中 和 基础架构的分布 。ESB 和中心辐射型（ hub-and-spoke ）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束 —— 有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可 能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。 如下图： 分布式 ESB 基础架构的集中控制
基于上的思路，我们按照以下关键字来定义我们的产品架构设计：
下图是符合我们的业务系统架构需求的一个产品架构图，该架构图采用的的 Oracle产品线，当然，开源和 IBM 厂商也可以提供此架构的产品，而且性能和价格会更便宜些。我来解释一下这个图：
自顶向下来看，我们防火墙以下首先 web请求需要通过负载均衡设备，此设备可以是硬件的 F5 等设备也可以是例如 IBM 产品中的 websphere edge server 服务，可以将此服务配置成为 HA 模式，第一条虚线表示此层次的 web 负载分发已经完成并很高效了，第二层，这里使用的是 10.1.2 版本的 Oracle web cache ，这就是缓存的作用，在 Websphere 中也有此产品，使用 HA 设计，第二条虚线表示此层将 HTTP 会话进行了分类和静态缓存，提升了性能和高可用，到了第三层， HTTP SERVER ，这里对应 IBM 的 HTTP SERVER ，提供静态页面解析，缓解应用服务器的压力，并提供反向代理的负载均衡。如果涉及到 OCI 和 proxy 方式的数据库操作，实时性高以及管理维护的需求，包括业务中涉及到数据库的事务 / 回滚段可以 PLSQL 直接操作数据库，否则就将请求交给对应的 servlet 交给相应的 javabean 去出去，这些 bean 可以去进行数据库读写，那么就走 jdbc/jdo 的路径去 oracle rac ，可以去关联某个流程 BPEL 处理 BPLM 的数据，那么就走 process server 去走流程，当然这里的 process server 也可以根据情况设计成 HA 方式，可以去关联某个异步文件传输同步服务，那么就可以管理 JMS 组件，如 MQ 服务，涉及到订阅和发布的就设计为 MESSAGE BROKEN 。应用服务出口可以有安全审计模块，对应 IBM TAM ， SSO 等组件，无此安全要求的可以去找 DB ，这里的 DB 可以设计为单实例多节点的 ORACLE RAC 形式。如果涉及到多个 RAC 形式可以考虑使用 gird 做，那就是管理层面的问题了。
大型互联网应用，例如门户网站、在线商城以及联机交易系统等等，往往需要处理大批量、高并发的用户访问请求，这对应用程序的性能提出了比较高 的要求。性能问题一般可以在开发和部署两个阶段加以解决。在应用部署阶段，通过增加软硬件投入的方式比较常见，但其费用往往较高；而在软件开发阶段如果能 够提前定位并解决性能瓶颈，则会减少大量成本。在开发阶段提升性能，一种常用的思路是降低瓶颈资源、业务模块的访问压力，因而在应用程序中加入缓存机制则 因成本低、实现方便等优点成为常见解决方案。
缓存（Cache ）在计算机科学领域指的是一些数据副本的集合。当原始数据访问速度较慢或代价过高时，可以通过使用在高速存储区域中保存原始 数据的常用数据副本，从而提升访问速度。常见的硬盘缓存， CPU 缓存，网页缓存等等都是缓存概念的应用。在企业应用开发时，开发人员也可以基于缓存的概念，使用应用程序级别的缓存，从而来提升应用性能。
常见的开发方式为在 Java 虚拟机里通过 Static 成员变量、 Context 对象或者用户 Session 中，保存常用的业务数据。一旦有访问需求，则先从缓存中尝试获取数据，如果尝试失败，再从实际模块获取数据并更新缓存。
此类方法实现简单，但容易遇到扩展性方面的问题：为了满足业务增长需求，用户可能需要在 多台 主机组成的 集群 中部署应用。此时 JVM 级的缓存会面临服务器间缓存同步的问题，处理不好，会导致数据不一致等严重错误。其他可能的问题还有：
针对这些常见问题，IBM WebSphere Application Server 则提供了一套动态缓存框架，能从不同方面加以解决。
IBM WebSphere Application Server 动态缓存机制介绍
动态缓存机制是 WebSphere Application Server 为应用程序开发人员提供的一套扩展服务，其主要功能组件如下图所示：
WebSphere Application Server 动态缓存的主要功能组件
动态缓存机制架构如上图所示。动态缓存机制的核心功能为：在内存中缓存 Java 对象，应用程序可以通过 API 来访问这些对象。为了减少内存消耗，动态缓存服务也采用一些缓存替换机制（例如 LRU- 最近最少使用算法）来实现。对应不同的应用类型，动态缓存机制为应用开发人员提供了不同层面的缓存服务：展示层的 Portlet 和 Servlet 缓存服务和业务层的 WebService 缓存服务、 Java 命令缓存服务和对象缓存服务。
动态缓存服务部署示意图
为多服务器环境下动态缓存机制的部署示意图。应用程序只需通过 API 来调用缓存服务即可，动态缓存服务会 自动 在不同服务器之间根据定义好的策略进行缓存数据同步。当收到应用程序缓存访问请求时，缓存服务会首先在本地缓存中查找相应对象提供服务。一旦被请求的对象 位于其他服务器时，动态缓存服务会通过数据复制服务（Data Replication Service, DRS ），来从其他服务上获取相应数据。如果对象在本服务器上有改动，如缓存更新或者缓存删除，动态缓存服务也会通过数据复制服务通知其他服务器。
以下为不同种类动态缓存服务之间的功能比较
缓存服务功能比较及使用 ： 动态缓存服务模块功能比较
应用场景分析 1
需求 ：
某网上商店应用访问速度过慢，经过分析，是由于产品列表和购物车处理模块由于逻辑复杂，执行效率不高引起的。
解决方案：
在优化相应代码外，也可以利用动态缓存机制，缓存一些常用页面的输出。动态缓存机制能够自动根据配置缓存某些页面的输出结果，这样该页面在下次访问时，Web 容器可以直接返回页面输出结果，而不用再次执行相关业务逻辑。
需要注意的一点是，一些页面的输出内容跟当时的某些数据和环境信息相关，例如：http://www.shop.com/products.jsp?category=books 中， products.jsp 的输出就与 Category 参数决定。因此，在进行缓存定义时，需要将相应的参数作为缓存 key 定义的一部分。
除了请求参数外，WebSphere Application Server 动态缓存的 key 定义还支持将 request 对象的属性、相应页面路径、 Session 值、 Http Head 信息、 Locale 和 Cookie 。
应用场景分析 2
需求 ：
假设在集群环境下的企业应用中，存在一系列 XML 格式的元数据，数据量为 100 条左右。由于该数据经常被访问，项目组希望能够通过某种措施，减少数据访问和 XML 解析的开销，进而提高系统性能。而且一旦元数据被操作员修改（例如访问 http://www.app.com/changeMetadata.jsp ），缓存内容需要立即得到更新。
解决方案：
在这种需求下，一种简单的做法是使用 JVM 级 static 对象来做缓存，具体做法为：定义一个 static HashMap 对象，应用程序读取数据时，首先检查该 HashMap 中是否存在缓存，如果存在，则直接从缓存中读取。在这种情况下，一些相应的缓存控制机制也必须被实现，比如缓存大小的控制、缓存过期等等。在数据被修改 时，通过修改相应的代码（如在 changeMetadata.jsp ）来更新缓存内容。
这种做法的问题在于，在集群环境中，操作员实际的访问请求是被某一个 JVM 上部署的应用所服务的。当操作员更新数据时，相应的更新代码，只会更新当前 JVM 上的缓存内容，而不会通知其他服务器，这样会导致数据不同步现象。而实现该数据同步，可能需要应用程序人员基于网络接口，开发相应的通知功能。
而在 WebSphere Application Server 中，动态缓存服务已经支持数据复制的缓存服务，我们只需要调用相应接口即可。而由于不同层面的应用程序模块，如前台用户界面和后台业务逻辑都需要访问该元 数据，因此我们只能在动态缓存中的 Java 命令缓存和对象缓存中选择其一。鉴于应用中已经有类似的命令框架，因此无法简单的扩展该框架以使用 Java 命令缓存，因此对象缓存可以被用来解决此类问题。
将开发完成的应用部署到集群环境，一般有以下几步：
注意： 只有在 WebSphere Application Server Network Deployment 版本中才支持服务器间的缓存复制。
服务器间缓存复制策略分析
在我的讨论中，将最大堆容量超过 2GB 的任何 JVM 都视为 “ 大型 JVM” 。
64 位 JVM 是否适合您？
在 IBM的 JVM 性能优化 中， 文章 指出：“请记住，很多从 32 位迁移到 64 位的人并没有实现性能的优势，相反带来了更大的内存占用，因为 64 位地址所占用的空间是 32 位地址所占用空间的两倍。 ”
占用较大的空间就意味着计划向服务器添加更多 RAM 的可能性极大。所需的额外 RAM 的具体量将取决于您当前所使用的 RAM 量以及当前具有的可用内存的量，但最后会毫不意外地发现，最终必须在服务器上使用双倍的 RAM 才能运行与当前 32 位 JVM 具有相同堆大小的 64 位 JVM 。例如，最近的一个客户以前在 RAM 为 2GB 的系统上运行正常运行最大堆大小为 768 MB 的 32 位应用服务器 JVM ，但过渡到 64 位 JVM 时，最终需要 4GB 的 RAM 才能使用相同大小的应用服务器 JVM 。
您可能会想 “最大堆大小为 768 MB 的 JVM 怎么会导致进程占用内存超过 768MB 呢？这完全没有道理嘛！ ” 堆 只是 JVM 的一个部分，另外还有解释程序；根据操作系统、 JVM 和堆大小的不同，解释程序在进程内存占用方面会在最大堆大小上增加 20% 到 50% 。因此，对于此客户，对于最大堆大小为 768 MB 的 32 位 JVM ，其硬件和软件配置所占用的内存约为 950MB ，而其对应的 64 位 JVM 所需的内存量约为 1.9GB ，而在只有 2GB 的 RAM 的情况下就没有任何内存供操作系统或系统上运行的其他进程使用。
除了添加 RAM （或至少确保拥有 64 位 JVM 所需的足够 RAM ）外，还将需要花时间调整所使用的 JDK 的垃圾回收 (GC) 算法。 IBM 为 WebSphere Application Server 开发的 J5SE 实现 (Java™ 5) （即在 Windows® 、 Linux® 、 AIX® 、 iSeries® 和 System z 上运行的 J5SE) 提供了两个 GC 内存模型，缺省为 “ 平 ” 内存模型，此模型一直在 IBM 开发的 Java 实现之前的版本（ JDK 1.4.x 和更早的版本）中使用；另一个模型为分代 GC 内存模型。
考虑到性能因素，在处理大型堆时，将要使用分代 GC 内存模型（在 Sun™ 和 HP 上， JDK 仅提 供分代 GC 内存模型） ， 此模型在 IBM JDK 上通过命令行参数设置：
-Xgcpolicy:gencon
之所以首选分代 GC 内存模型，是因为大型 JVM 必须尽可能减少执行 GC 的时间。在分代 GC 内存模型中，对象最初在年轻代 (young generation) 空间（通常称为 “ 保育室 ”(nursery) ）中创建，如果对象在多次 GC 操作之后仍然存在，然后会将其移动到年老代 (old generation) 空间中。另外，在分代 GC 中会涉及两种类型的 GC 操作：
正如您可能已经猜到的，正确地确定“ 保育室 ” 和年老代空间的大小是减少小回收或大回收操作所耗时间的关键；对于大型缓存的 情况，您会希望调整年老代空间的大小，以保存所有缓存内容和其他长时间存在的对象。年老代太小将会导致 GC 操作过多，甚至出现内存不足的情况。要确定年老代空间大小，最佳方法可能是在每次采用缺省模式进行 GC 操作之后查看可用堆的量（可用堆百分比乘以总堆大小）。还应该分析 GC 日志，以了解年老代空间回收的频率；最优的分代应用程序进行年老代空间回收操作的频率应该非常低。
年轻代空间的大小通过 -Xmn (-Xmns/-Xmnx) 设置，而年老代空间的大小通过 -Xmo (-Xmos/-Xmox) 设置。
大型保育室通常适合处理吞吐量较大的情况，而小型保育室通常能提供较短的暂停时间，而要获得较高的 WebSphere Application Server 性能（吞吐量）通常需要相当大的保育室。一种不错的做法是，从 512MB 开始，然后逐步向上或向下，以确定最优值、测定吞吐量或响应时间，并分析 GC 日志，以了解进行清除操作的频率及时间。
如果您需要为应用服务器使用大型 JVM ，则有必要认证考虑一下 ObjectGrid 。我在前面提到过，对于此讨论，我们将任何堆大小为 2 GB 及更高的 JVM 都视为 “ 大型 ”JVM 。这并不是说要从 ObjectGrid 获益就需要使用大型堆，远不是这个意思。任何大小的缓存都可以帮助提高性能和吞吐量，但是 ObjectGrid 能够存储大量数据，而且使用 32 位 JVM ，这就使其成为了一个非常理想的方案，不用过渡到相关内存开销大的 64 位 JVM 。
正如前面提到的，ObjectGrid 属于 WebSphere Extended Deployment （而且作为 Data Grid 单独提供）。如果您对其不了解，在此我对此作一下极为简单的介绍： ObjectGrid 是用于 Java 应用程序的启用了网格的灵活内存数据存储，提供了一系列部署和编程选项。最简单的选项是，将其作为内存内数据库使用，或作为 Java Platform Standard Edition (Java SE) 或 Java Platform Enterprise Edition (Java EE) 应用程序的缓存使用。每个 ObjectGrid 都由一个或多个映射组成，而每个映射又由一组键值对组成。在本讨论中，特别有意义的是两项 ObjectGrid 功能：
ObjectGrid 可以通过使用静态集群或动态集群采用客户机 - 服务器部署模型部署。动态集群使用目录服务来维护服务进程 JVM 列表， ObjectGrid 应用程序容器就承载在其中。目录服务为 ObjectGrid 部署提供多项服务（位置服务、放置服务、运行状况监视以及管理访问）。反过来，客户机可以与这些 ObjectGrid 服务器交互，以访问缓存内容（图 1) ，而这样又允许应用服务器 “ 客户机 ” 将缓存的主要内容分流到其他进程，而且同时仍然将访问最频繁的数据保存在本地缓存中。
ObjectGrid 能够跨多个 ObjectGrid JVM 对映射进行自动分区，此功能是维护大量数据的关键：将数据分散在多个 ObjectGrid 服务器上，每个服务器都在 32 位 JVM 中运行，而且没有 64 位 JVM 的巨大的内存开销。此外， ObjectGrid 还提供数据复制功能，消除了由于单个服务器而造成单点故障的情况。图 2 显示了分区和复制功能的情况。这些功能对于考虑将 ObjectGrid 作为 64 位 JVM 的企业级替代方案时非常重要。
图 2. ObjectGrid 跨多个 JVM 对映射进行分区
创建 ObjectGrid 集群的能力取决于应用程序客户机，而此能力支持在应用程序客户机之外部署 ObjectGrid 服务器层，如图 3 中所示。尽管图中显示了多种应用程序客户机类型，但在本文的讨论中，客户机将为 WebSphere Application Server ，此客户机将不再需要各自维护缓存的副本。而这将消除将应用服务器作为 64 位 JVM 运行的需求。此外，跨多个 ObjectGrid 服务器实例对 ObjectGrid 映射中的数据进行分区的能力可以作为 32 位 JVM 实现，而且每个服务器可存储的缓存内容量可达 4GB （总缓存量大得多）。这样可以节约大量的 RAM ，因为 32 位 JVM 并不会带来 64 位地址所带来的内存开销，每个应用服务器都不再需要维护整个缓存的副本（尽管可以在需要的情况下维护本地缓存）。
图 3. ObjectGrid 集群
对于当前维护大型缓存的应用程序，迁移到基于 ObjectGrid 的解决方案应该非常简单，因为 ObjectGrid ObjectMap API 与现有的基于映射的标准 API （如 HashMap ）非常相似。应用程序流通常可以采用任何缓存实现模式。实际上，使用 ObjectGrid 时，应用程序将按照以下顺序操作：
对于网络方面的安全问题，不同的开发者和设计者有不同的认识和见解， 我试图采用 和《 JAVA 探索者： JAAS 和 JSSE 的 JAVA 安全》相同的分类方法，将 Web 系统的安全问题分为三个类别：认证、授权和传输。认证和授权是任何一个应用系统中的基本安全问题，认证过程是首先通过各种形式的认证表单或途径获得使用者 认证数据，然后根据认证数据确定对方身份的过程，对于 Web 认证安全数据提交形式包括普通表单、证书等；授权过程则是对确认了的认证身份的主体进行判断的过程，判断认证了的主体是否有对客体实施某种操作的权限；相 对于传统的 C/S 应用系统， Web 应用系统采用 B/S 结构， B/S 得以广泛使用和迅速发展很大程度上依赖于其瘦客户端的标准化脚本解析和传输的标准化，然而标准化的 HTTP 协议传输方式一方面使得开发网络应用快速而简单，另一方面 HTTP 协议的网络传输问题也暴露很明显，因此传输过程中的安全问题成为亟待解决的 Web 三大安全问题之一。
上图 1 详细刻画了 Web 安全三个方面的问题，三者之间的关系可以表述如下：
首先，服务器端需要确认客户端用户的身份；其次，当客户端请求访问服务器端某一受限的访问资源时，服务器端需要根据客户端提交的身份确认其 是否有足够的权限访问该受限资源；最后，客户端和服务器端的交互访问方式需要通过网络完成，传输过程中的数据可能被非法获取、篡改，当然也存在不能确认传 输双方的身份等问题。
WebSphere Application Server（ WAS ）结合的计算机安全近 40 年的成果，在网络安全、操作系统安全、 J2EE 安全等方面提供了坚如磐石般的安全体系的同时，还保持了极其灵活的特点，成为 Web 领域解决方案的重要利器。本文接下来的章节，将从以上描述的三个方面为出发点，对 WAS 安全机制进行概述，包括 WAS 整体安全架构和各个层次上的安全解决方案。由于每个层次上的安全问题都是一个安全领域独特的知识，本文对每个层次的安全方案进行简介，并探讨其与其它层次 之间的关系。更深入的讨论将在本系列文章的其它文章中进行阐述。
对于 WAS 的管理，常用的管理方式包括管理控制台、 JMX 、 Java JNDI 等， 管理内容相应的包括命名、用户注册表、 JMX 管理资源以及常见的 Web 资源，包括 Html 、 JSP 、 Servlet 等，按照上一节中对于 Web 中安全的阐述的观点，这些资源为受保护的服务器资源，而对于这些资源的访问控制则为 Web 安全的管理对象，在图 2 中统称为 WAS 资源，在本节下面的篇章将依次介绍各个安全层次对于这些受保护资源控制。
从安全技术使用范畴的角度，将 WAS 的安全体系结构自底向上的划分方式分为，平台安全、 Java 安全、 WAS 安全，详细的架构体系层次关系如图 2 所示。
平台安全 包括两部分，即操作系统安全和网络安全。网络安全解决网络传输中的安全问题，包括网络传输中的 完整性交验，机密性保证等网络传输中存在的问题，在 WAS 中通常通过配置对 SSL 和 VPN 安全配置解决传输中的安全问题。对于操作系统层次上的安全，除了通常意义上的依赖于不同的平台本身的安全特点，对于 WAS 文件系统和进程等进行的安全访问控制， WAS 提供了基于操作系统帐户的 WAS 安全控制管理，大大提高了 WAS 的安全管理的便捷性和易用性；此外在不同的操作系统平台上，提供了具有平台相关性的安全特点，在影响着 WAS 的安全管理。
对于网络安全中的 SSL 安全和操作系统上的安全机制在以后的篇章中将进行介绍。
JAVA 安全 ，由于 WAS 是 J2EE 认证服务器，因此 WAS 遵从 JSR 社区的 JAVA 安全规范，从 JDK 到 Java2 安全体系结构， JAAS ，再到 J2EE 安全模型等等，因此 JAVA 中的安全管理也适用于 WAS 中。对于 Web 安全的三个问题中的认证与授权，《 JAVA 探索者： JAAS 和 JSSE 的 JAVA 安全》认为， JAVA2 安全体系结构主要解决授权问题，而 JAAS 主要解决认证问题。 J2EE 也提供了 class 级别的安全授权模型，并提供了对上层的 J2EE 资源的安全管理规范，因此对于 Web 的安全认证与授权问题本文主要介绍 Java2 安全体系结构、 JAAS 和类级别的安全授权模型。
对于这一层次的安全本文着重于 JAVA2 安全架构、 JAAS 和 J2EE 安全角色三个安全层次的介绍，这三个安全层次的安全策略为属不同的领域，可以相互补充使用，本文在其后章节予以介绍。
WAS 安全： 对于图 2 中 WAS 安全层上的安全主要是强制使用统一的安全访问控制方式对 Web 资源、企业 Bean 和 JMX 管理资源。可以理解为对于 WAS 服务器资源的访问时， WAS 安全层强制自顶向下依次调用安全架构中各安全层次进行访问控制，从而保证了任何一种资源的访问都采用了统一的完整的安全控制，此外配备了对于不同的安全层 次的管理具体控制选项设置，这些设置可以被运用于管理当中。在访问控制内容上，安全访问控制的内容包括 JMX Bean ， Web 资源等；在访问控制方式上则包括， JMX 访问、控制台、 WSadmin 、纯 JAVA 的 JNDI 访问等等；在访问控制的层次上，则对于不同的访问方式， WAS 安全提供了从传输到上层的用户角色等的自底向上的访问控制方式 。
从上下层的关系看，WAS 提供了自底向上的安全管理模型，在实际的应用中，使用者可以根据具体需求对安全层次的选取进行设定和管理，图 3 所示的为在 WAS 管理控制台中对于不同层次安全的管理控制设置，如 Administrative Security 中则主要应用 J2EE 角色安全的方式进行控制； Java2 Security 则是 JAVA2 安全体系； User Account Repository 则可选操作系统安全或者其他安全方式； Java Authentication and Authorization Service 为 JAVA 安全层次中的认证机制。
从 Web 安全三大问题的角度看，如图 3 介绍，对于 Web 安全授权分别由 JAVA 安全层次中的 J2EE 安全模型， Java2 安全模型来完成；对于 Web 认证则由操作系统用户认证方式、 JAAS 认证模型，以及 WAS 统一的 LTPA 等的认证机制；而对于 Web 传输则主要由图 4 中展示的 SSL 传输安全机制来完成。
在本章中将分小节对三个安全层次中的主要安全领域问题进行重点介绍，主要介绍内容包括，平台安全中的操作系统安全和网络；JAVA 安全中的 JAVA2 安全、 J2EE 角色安全和 JAAS 安全。
SSL 安全介绍
SSL 安全属于 WAS 安全体系中的平台安全层， 在 WAS 中，对于网络传输安全主要采用的是 SSL 协议，在 WAS 安全控制启动后，不论以 Web 控制台方式、 JMX 方式访问 MBean 还是对于 wsadmin 方式管理 WAS ，启动的访问进程都必须遵从 SSL 协议进行通信。
对于浏览器访问 WAS 管理控制台的方式， WAS 会完成自动跳转，启用 Https 协议进行传输；对于 wsadmin 和 JMX 则在正常的管理控制用户认证开始前进行 SSL 的握手过程，握手过程完成后，整个交互过程采用 SSL 握手时建立的安全通道进行通信。
SSL（ Secure Socket Layer ）即安全套接字协议， SSL 协议结合了对称加密算法和非对称加密算法进行传输过程中的数据加密、解密，保障了数据传输过程中通信双方的身份认证、数据的机密性和完整性等问题。
对称加密算法是较为最为经典且古老的加密算法，这一加密算法最大的特点是在实际的加密、解密过程中，加密、解密运算互为逆运算，这两个运算 过程中用到的密钥相同，这一过程可用图 5 予以解释。由于对称加密算法要求通信双方使用相同的密钥并约定加密算法，因此在实际的网络传输应用中对称加密算法面临着密钥传输和算法约定等问题，降低了 这种加密算法使用的可用性。但是这种经典的加密算法执行效率高，加密快。
图 5. 对称加密算法
非对称加密算法也称作公钥加密算法包含一对密钥，分别称作公钥和私钥，在加密和解密过程中，这对密钥互为反运算的密钥，即假设用公钥对明文 进行加密的密文，则只能用私钥密钥进行解密得到明文，非对称密钥的这一特性可以用图 6 予以解释。在实际的运用中，非对称加密算法的这种特性得到了很好的运用，将公钥公布、私钥个人保留，解决了传输网络过程中的身份认证问题，同时解决了公钥 的物理传输问题，不足之处在于非对称加密算法较为复杂，计算过程较慢，效率不及对称加密。
图 6. 非对称加密算法
基于这两种算法的特点，SSL 协议的安全网络传输协议应运而生，利用非对称加密解决身份认证问题、密钥传输、算法协商等问题，这一过程也称作握手过程，握手过程结束后，通信双方得到了 协商好的对称加密算法和加密钥，从而建立了一条安全的通信信道；安全的通信信道建立成功后正常的通信过程开始进行，这一过程中通信双方的请求与应答内容都 采用对称加密算法完成后进行网络传输。
在 WAS 管理过程中， WAS 服务器强制客户端（浏览器或者 JAVA 程序）与 WAS 服务器采用 SSL 协议进行安全通信，当然这一过程中涉及了网络传输安全中的认证授权、机密性、完整性以及不可否认性，采用的算法除了本节所讨论的对称加密算法和非对称加密 算法外还采用了不可逆加密算法，对于非对称加密算法引入了证书和证书授权机构等概念，这些不在本文进行阐述，将会在以后篇章中进行较为详细的阐述，并结合 WAS 对于证书和算法的管理进行阐述。
操作系统安全
操作系统安全也属于 WAS 安全层次的平台安全层，作为底层操作系统为 WAS 提供了安全基础设施，操作系统定义并管理着后台启动的任务，建立启动概要文件，并是访问底层的基础系统资源例如文件、安全套接字等的基本设施。除此之外， 底层操作系统为 WAS 提供了可信的认证服务用户注册表，这一部分内容将在本文后边的章节有所介绍。对于授权服务，本地底层操作系统提供了 SAF （ System Authorization Facility ）服务为运行在 WAS 内的控制台、应用程序等提供了授权服务，
由此可以看出对于 WAS 的运行管理，甚至于 WAS 使用时的认证授权都必须协调操作系统的安全配置管理来完成，例如对于使用本地操作系统的用户注册表时候，则需要登录用户或者启用用户具有相应得操作系统的 一定的管理权限来完成，否则会造成 WAS 不能正常运行，进而应用程序不能正常运行，因此对于 WAS 的管理一部分工作实际上是对于操作系统的管理工作。
对于 WAS 的管理在不同的情况下可能需要本地受限用户进行管理工作，因此对于本地受限用户操作 WAS 的管理工作就涉及到操作系统的限制和 WAS 的限制，充分了解操作系统的安全认证、与授权是管理 WAS 安全工作的一部分。从某种程度上讲，操作系统安全在 WAS 整个安全管理体系中相当于为其他安全和 WAS 本身的正常运转创造一个正常有序、合理安全的运行环境，而维系这中正常的运行环境在以 WAS 启动、运行、停止为周期过程为基本指导原则的，在充分考虑 WAS 运行声明周期中各个环节的安全特性，结合操作系统的安全认证、与授权的特点的前提下来最终完成。
JAVA 2 安全架构及在 WAS 中应用
JAVA2 安全属于 WAS 安全架构中的 JAVA 安全层上， JAVA 语言发展迅速除了其本身的面向对象的强大特点之外，其坚如磐石的架构设计理念也不容忽视的，强大的安全设计架构使其能够适用于企业级安全需求。 JAVA 的安全模型主要保护功能是保证系统资源不被非法程序所接触，这些系统资源包括文件、网络等资源，与此同时提供较为完善的访问控制模型使得得到授权的程序可 以正确访问资源，因此《 J2EE 探索者》的观点认为 JAVA2 在 Web 应用安全中解决授权问题的。
JAVA2 安全架构模型相对于 JAVA1 安全模型提供了更为强大的安全管理模型，如图 7 所示的 JAVA2 与 JAVA1 的安全对比模型。 JAVA1 的安全模型认为本地程序是安全程序可以自由的通过 JVM 访问受限的系统资源，而对于远程程序则要对远程程序进行签名验证，可信签名的程序可以和本地程序一样正确访问本地资源，而对于没有得到认证或者没有签名的 程序则会进入沙箱进行运行，进入沙箱的程序对本地资源访问受限，只能运行普通功能。
图 7. Java1 安全模型和 Java2 安全模型
JAVA2 安全模型在对程序可信方面做了调整。对于本地程序同样要进行签名验证和管理，对于不可信的本地的资源同样进行首先控制，使得本地非法程序仍旧不能访问本地资源。
JAVA2 提供了更为灵活的安全控制模型，开发者可以通过定制安全策略、安全类装载器从而保证了开发人员可以动态定制开发出更为灵活的安全管理架构。比如开发出使用时间受限的应用程序。
JAVA2 提供了更多的域概念，除了可信和进入沙箱的程序， JAVA2 安全模型提供了更为细分的安全域，不同的应用程序根据不同的应用签名和安全策略制定相适应的安全域， JVM 通过调度使得应用程序进入进入相应的安全域访问受到约束的部分本地资源，在保证了安全前提下，提供了更为细分的权限分配，满足了对于企业级应用的安全需 求。
从可信任层次上看， JAVA2 安全模型认为可信的 JAVA 代码是 JVM 本身的 JAVA 代码；从控制方式的角度来看， JAVA2 安全模型以交验 JAVA 代码的运行路径、 JAVA 代码本身的签名，因此 JAVA2 模型更多强调代码的所有权，从而保证系统的安全性。
基于 J2EE 角色安全介绍
J2EE 安全属于 WAS 安全架构中的 JAVA 安全层上。 J2EE 提供了基于角色的安全授权控制模型，基于角色的安全授权模型主要是提供基于角色的安全控制检查，确保只有足够权限的安全角色能访问相应的受限资源。角色是 一组权限的逻辑集合，这组逻辑集合可以被赋予真实用户注册表环境中一个或者多个合法用户或者组，在系统程序运行时，通过检查某一个真实用户所属的角色或者 真实用户组所属的角色来完成相应的安全检查。
对于授权检查方式上，J2EE 提供了声明型和程序型授权性安全检查策略，由于 J2EE 的安全保护对象为 J2EE 资源，因此声明型的授权模式对不同的保护资源通过不同的声明文件进行控制，常用的 J2EE 资源一般通过 web.xml 进 行控制，控制的标签为 和 等协作完成，对于 EJB 的控制则通过配置 ejb-jar.xml 来完成，通过这种配置方式从而达到保护指定的受限资源的目的。
值得一提的是 WAS 本身控制台的安全管理角色授权机制就是基于 J2EE 的安全模型管理机制的，如表 1 中所示，列出的为基本的 WAS 控制台角色以及相应的权限，这些用户角色可以根据不同的真实用户注册表情况映射到不同的用户和用户组。
基于 JAAS 安全认证介绍
JAAS 属于 WAS 安全架构中的 JAVA 安全架构层上，全称 Java TM Authentication and Authorization Service ，JAVA 认证与授权服务，故名思义用来解决安全认证与授权的问题。
PAM（ Pluggable Authentication Module ）可插拔认证模块，PAM 是一种认证授权框架，这种框架提供了一种认证机制，使得上层业务应用程序的开发使用不依赖于底层的认证授权机制， JAAS 正是 PAM 的 JAVA 版应用框架。
JAAS 的认证机制是通过检查 JAVA 代码的执行者身份，这些 JAVA 代码包括 Servlet、应用程序、Applet 等等； JAAS 的授权机制主要是用来检查并确保执行者有足够权限进行相应的动作， JAAS 可插拔认证模型关系如图 9 所示。
图 9. JAAS 可插拔认证模型
根据 JAAS 的运行机理，本文将 JAAS 的认证授权模型分为四个层次，自上向下依次为应用层、授权层、通用认证对象层、认证层。由于授权层是外部和内部结合的控制方式，因此跟上层业务应用程序本 身之间没有直接的耦合与调用关系，按照分层架构模型设计原理，在运行时，授权层通过访问安全控制策略只能访问通用认证对象模型，而通用对象层的认证对象凭 证是在运行势态动态生成的，跟底层的认证层没有依赖关系，因此上层应用对底层也没有依赖关系，从而达到了上层商业业务逻辑和下层认证模块之间没有直接耦合 的关系。
JAAS 机制与 JAVA2 安全模型相比，两者解决不同的问题，面向的侧重点不同。从保护对象角度来看， JAVA2 安全模型提供内嵌的系统资源保护模型，当然开发者可以开发更多的面向业务的保护对象，而对于 JAAS 则提供更灵活的认证授权控制，除了保护业务对象，也可以面向业务操作进行保护；从授权检查机制的角度， JAVA2 安全模型更多强调安全代码的所有权，而 JAAS 则强调的是代码的使用权；从检查形式来看， JAVA2 的安全模型属于声明型的管理模式，而 JAAS 的管理模型可以声明型和程序型相结合；从安全检查级别来看， JAVA2 安全模型属于角色级别的检查控制，而 JAAS 可以提供基于角色和基于实例的安全授权控制。因此两种安全认证模型可以结合使用，保证更为安全和灵活的管理控制。
WAS 开放认证授权架构介绍
前面介绍了 WAS 安全架构中的自底向上的安全层次，不同的安全层次有着不同的安全管理控制方式，然而这些安全层次之间如何交互，则需要从交互关系来看。 WAS 的开放认证授权架构如图 10 所示，在一个 WAS 中对于认证、授权是相应的 Security Server 和 Access Manager 两个模块来完成的，而其中对于认证模块又包括两部分 JAAS 登录和 User 注册表两部分组成，因此常规的安全登录实际过程是首先采用某种机制通过 JAAS 登录模块进行登录认证， JAAS 登录模块利用得到用户登录数据到相应的选定的用户注册表里进行验证。从而完成相应的认证工作，当然对用户进行一系列的映射动作，完成映射动作后用户如果要 访问相应的受限访问资源，则 WAS 对其角色进行验证，从而完成授权检查等动作。
图 10. WAS 开放认证授权架构
对于 JAAS 的常规实现是每个 JAAS 是一个认证方式，从而保证了业务高层和登录模块的分离，因此大部分的认证实现直接完成了对于某一个用户注册表的认证。而 WAS 对于这一问题进行了较为灵活的设计，对于每一种 JAAS 登录模块都是一种登录机制和映射机制，每种登录机制会控制登录的 Cookie/taken 等的格式，以及多个 WAS 间共享登录信息的格式等等，这些机制对于各种登录机制是不同的，但是对于同一个用户注册表管理方式可能会使用同一种登录机制。因此 WAS 的灵活认证架构设计在对于认证机制和用户注册表之间采用桥模式进行设计，如图 11 所示，保证了认证机制和用户注册表的选取之间的组合方式。
图 11. 灵活的 WAS 认证机制
WAS 安全体系的认证机制
认证在 Web 安全中主要解决是谁的问题，而对于授权则是解决有没有权限进行某种操作的问题，如图 12 所示，对于 WAS 中的认证与授权之间的关系， WAS 作为 Web 容器，是应用程序运行的管理和调度者，对于应用程序的认证则不能局限于 WAS 本身内部，因此对于认证问题委托给了用户注册表。同样对于授权方式，每个应用程序有着不同的授权方式，对于声明型的授权管理工作， WAS 通过读去应用程序的授权声明进行调度和监控；对于程序型的授权管理，应用程序通过与 WAS 进行交互得到登录用户的信息，进行授权管理。因此应用程序对于授权工作都要最终依托于相应的应用程序进行授权工作， WAS 作为容器提供管理和调度交互工作，最终的认证与授权的方式和具体内容细节则交由应用程序来管理和控制，一方面降低了开发难度，对于应用程序保证自底向上的 安全性的开发工作是复杂和庞大的；另一方面在使用 WAS 提供强大的安全控制时保证了安全性的同时，提高了开发效率。
图 12. WAS 中的认证授权
在 WAS 中的具体认证过程如图 13 所示， Web 客户端在得到服务器认证响应后进行认证数据提交，对于认证数据提交的方式一般的包括三种形式， Http 基本认证、 Https 客户端认证和自定义表单认证，一般的自定义表单认证具有自定义的界面，因此这种模式适用的比较多。
认证数据同过网络传输到服务器，根据前一节对于 WAS 认证架构的认识与了解， WAS 会使用一种在服务器中选定的认证机制进行认证管理，认证数据通过认证机制进行一定的处理提交到用户注册表进行验证，认证后的认证凭证存在 WAS 对于 JAAS 的扩展中，在登录用户访问需要进行授权时即从凭证中取得相应信息进行授权管理。
对于 WAS7 中使用比较多的是 LTPA 认证机制， LTPA(Light Weight Third Party Authentication) 第三方轻量级认证，对于 SWAM 则将在以后的版本中放弃使用。
对于用户注册表，目前支持的主要为四种类型。本地操作系统，如果用户选择本地操作系统的认证方式，那么用户需要有本地用户才能成功进行认 证，对于 Windows 的域环境，这种管理方式更是有其绝对优势，一方面对于任何本地用户不用分配额外的帐号易于使用和管理；另一方面由于不使用额外帐号，对于授权了访问操作系 统的本地用户，直接可以访问应用程序降低了管理成本。 LDAP 轻量级目录访问协议，通过 LDAP 的控制管理方式，保证了对于 LDAP 应用企业的应用的兼容性，大大改善了以往应用程序对于 LDAP 支持的难度。联合用户注册表提供了一种多种存储方式并存的管理模式，大大改善了对于多用用户注册表并存系统的集成和兼容。最后一种用户注册表是自定义注册 表，对于任何一个应用，如果前面三种用户注册表策略仍旧不能满足相应的需求，用户可以通过自定义注册表的方式，和系统中已有或者新开发的登录机制相结合完 成特殊的登录认证需要。
图 13. WAS 中的认证过程
WAS 安全体系的授权机制
授权主要是用来满足对于受限资源的访问控制问题，如图 14 所示的授权管理工作，当用户需要对受限资源进行某种操作时，操作请求信息会发送到 WAS 服务器中，根据上一节中所介绍的 WAS 服务器通过认证进程对用户信息进行管理和控制，如果用户没有进行认证，则按照上一节中讨论的方式进行认证管理，认证后得到用户认证凭证，用户认证凭证和请 求操作被转发到相应的授权管理进程，授权管理进程将用户认证凭证和请求的操作通过授权矩阵进行评估，从而判断用户是否有权限进行请求的操作。
图 14. 授权逻辑视图
对于基于 WAS 的应用程序的授权管理工作，依照上一节中介绍的观点， WAS 直接或者间接的委托于应用程序， WAS 在其中进行管理、协调和监控， WAS 对于授权管理工作遵守 J2EE 授权的管理模型，即基于角色的授权声明性授权管理和更为灵活的程序性授权相结合。那么对于授权的实施过程可以参考图 15 所示。
如图 15 所示的为从安装、使用的自左向右的顺序，但是先开发后进行安装部署的角度，则是从右到左的顺序。按照 J2EE 安全授权模型的设计思想，首先对于应用程序抽象出用户角色，然后对于抽象的用户角色进行声明性和程序性授权控制，因此程序具有很强的健壮性和兼容性，不依 赖于任何某种用户注册表，进行合理的配置可以应用于不同的用户注册表以满足不同注册表用户对于程序需求。对于部署阶段则是映射实际的用户到 J2EE 中定义的用户角色，依照 J2EE 安全授权模型的定义，用户角色实际上是一组权限的逻辑集合，这些集合可以是一个用户或者是一个用户组，因此对于映射工作实际上是角色的认定过程。
因此对于一个应用程序从开发到实际的运行环境需要至少需要经过开发和部署两个阶段，开发阶段应用程序对抽象用户角色进行依赖与交互，而对于 部署阶段则是将开发阶段预定义好的用户角色实际运行环境中的用户注册表进行映射，在完成了基于抽象用户角色的用户权限控制开发和抽象用户角色到实际用户注 册表中的映射部署才最终完成了应用程序的授权过程。
图 15. 授权实施
时间有限不作分析。
业务系统的架构分析需要深入的剖析，这个准备工作要早，对于项目管理人员来说，如何更早的知道这个系统的预期架构的全貌是重点。
Edge server的集群和 F5 设备的 PoC 测试中集群搭建的重点，动态扩展方面是项目经理在性价比上进行讨论的重点。
缓存设计是难点，难度在于如何降低开发人员的难度但同时不失缓存特性的优势。
WAS和同一层的 WVE ， MQ ， WPS 等集成是一个重点。
系统全局后的应用架构环境测试是一个耗时长的重点，需反复修正达到3 个要求，完全可用，高性能， webservices 高效。
运维监控匹配的IBM Tivoli 其他产品比较庞大，需专业匹配。
数据库层面的性能问题不能简单处理，可用性也不能单纯依赖RAC 来做，可以结合用户系统情况，充分利用 Oracle11g 中的新一代高可用性技术以及 RAT 来验证。需专业 DBA 。