软件体系架构模式在J2EE中的应用（上）
【IT168 技术文档】
1-1 概述
层架构模式组织成一个层次结构，每一层为上层服务(Service Provider)，同时也作为下层的客户端。在一些层次系统中，除了包含一些输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）机制。层的调用通过决定层间如何交互的协议来定义。这种风格支持基于可增加抽象层的设计。这样，允许将一个复杂问题分解成一个层堆栈的实现。由于每一层最多只影响两层，同时只要给相邻层提供接口，允许每层用不同的方法实现，因此为软件重用提供了强大的支持。
1-2 问题
层结构是最成熟的软件体系架构模式，它起源于早期的系统设计，由开始的函数调用，作为函数库，供其他程序进行调用。一般在系统设计时，由一系列高层模块和底层模块处理构成，并且高层的模块依赖于底层。因此为了完成系统的设计必须要考虑一下因素：
·源码的修改会影响整个系统，应该被限定在一个部件内部而不影响其他模块
·接口应当稳定，甚至要被规范化
·系统的架构应该灵活，可以更换
·系统的开发需要被划分为多个部分，比如团队开发或者异地开发
1-3 模式结构
从系统高层的观点来看设计方案比较简单，它把系统进行分为几个层次并且把它们叠加起来，最下面的抽象层称为第一层，它是系统基础。依次类推，把n层放在第n-1层上。其结构如下图：
（N层结构图）
1-4 非软件描述
层模式在现实生活中很常见。特别在中国的封建社会的等级森严的制度下，把人分为几个等级，其实就是分层，上层可以指示下层。不过现在有的企业管理制度，与这种管理理念相适应的管理体制是垂直的自上而下的泛官僚体制结构。其结构设置表现为自上而下的单向层级制，这种结构有利于政令的传达和执行，保证管理的效率，但是官僚特性也很明显。如下图：
（制度管理图）
层模式在现代物流也很常见，如下图的，在自行车在运输的过程，首先在自行车厂进行出厂，有人员进行打包，然后进行装运，最后再有相应的分销商，进行组装销售。
（自行车销售管理图）
1-5 优点与缺点
层架构模式是最常用的一种软件体系架构模式。从它的实现和结构图中，我们可以得出，该模式具有以下优点和缺点：
1-5-1 优点
·层次的复用性。如果每个层次有很好的抽象接口，那么它可以被其他环境复用
·支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解，使系统更容易模块化
·支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层
·可替换性。因为独立的层次设计很容易被功能相同的模块替换
·但是在实际的项目中，该模式也有相应的不足
1-5-2 缺点
·低效率：分层结构通常要比单层结构的效率低。因为有时高层过分依赖底层的服务，因此必须穿过许多中间层进行数据的传送，甚至多次。
·改变行为的连锁反映
2-1 J2EE层架构模式的背景
也许下图大家都比较熟悉，它介绍了软件从两层体系架构方式到三层的架构模式。
（两层体系架构到三层体系架构模式图）
由于2层的架构方式，存在以下几点缺点：
·软件部署开销很大
·每个客户端数据库驱动都需要进行安装和设置，一但程序发生改变，就需要重新部署，这意味巨大的开销
·改变数据结构的开销很大
·客户端应用程序一般通过JDBC，ODBC，ADO等直接访问数据库，这表明客户程序直接与底层数据结构交互。如果改变数据结构来处理新的过程，就需要重新部署每个客户端。
·改变数据库的类型的开销很大
·由于客户端直接使用特定数据库的API，和特定的存输过程，触发器等，因此数据库类型的改变，会引起很多的修改。
但是通过把业务逻辑从存储过程和本地的业务逻辑进行分离，独立为一层，这样就是应用层架构模式最经典的应用之一。
2-2 J2ee应用的概述
J2EE平台为设计、开发、集成和部署企业应用提供基于组件的方法。这种方法不但能降低成本，还能对整个设计和实施过程进行快速跟踪。J2EE平台能提供多层分布式应用模型，能重用组件，能为用户提供统一安全模型和灵活的事务处理控制。在J2EE规范中进行了以下的分层：
·应用客户端组件
·Servlets和Java Server Pages（JSP）组件（也称为Web组件）
·Enterprise JavaBeans组件
·基础服务和与其他系统(如数据库等)的交互
（J2EE规范）
2-3 Architecture and the Cube
软件体系架构研究者，把软件系统架构进行总结和分析，提出了Architecture cube理论。它把一个软件系统架构进行分解成三维进行分析，分别从Tier，layer，capabilities角度进行考虑。
（Architecture cube）
其中Tiers定义为： A logical or physical organization of components into an ordered chain of service providers and consumers. Components within a tier typically consume the services of those in an "adjacent" provider tier and provide services to one or more "adjacent" consumer tiers. Within a tier, services are grouped to like requirements, such as functionality, security, or load distribution.
Layers定义为：The hardware and software stack that hosts services within a given tier. Physical, network, and software platforms and standard API sets support the components that provide a service. Layers, like tiers, represent a well-ordered relationship across boundaries that are mediated by interfaces. Whereas tiers represent processing chains across components, layers represent container/component relationships in implementation and deployment of services.
Systemic Qualities定义：The strategies, tools, and practices that deliver the requisite QoS (such as availability, scalability, security, and manageability) across the tiers and layers.
大家都知道，再考虑评价一个软件体系架构是否先进时，我们经常要从"非功能属性"的角度去评审。我们首先进行区分功能属性和非功能属性的区别。
功能属性(function property) 用来描述整个系统的功能特性(feature)，并且通常与特定的功能需求相关。功能特性可以通过特定的功能使用户可以直接看到的应用功能，可以通过实现来进行描述。
非功能属性(non-function property) 定义为解决一个软件系统的可靠性，兼容性，性能，易用性，可维护性等。
我们的开发者过去习惯于专心提供功能属性，然而今天，非功能属性变得越来越来重要。
在实际系统架构上，可能是每一个Tier上由不同的layer组成， 或者说每一个layer都涉及不同的Tier，组成一个交错的系统，并且Capabilities又和这两者交织，如下图：
（Run Test Suite）
2-4 J2EE架构的Cube
2-4-1 Tiers
2-4-1-1 概述
如果按照Cube理论把J2EE进行分析，从它的Ties层的角度进行考虑，把它分为以下几个Tiers：客户端层，表示层，业务逻辑，集成层，资源层。每层都是按系统中业务逻辑而划分的，它具有唯一的职责。每层与相邻层都是松散耦合的。还可以把整个系统表示为层的堆栈。
（Tiers分析图）
客户端层
该层代表访问系统的人员，应用程序，或系统的客户端。它是整个系统的对外接口，可以是Web浏览器(IE)，Java应用程序(Swing)，Java Applet，WAP，其他设备或者是批处理程序。
表示层
该层封装了用来服务访问本系统的所有客户端的表示层逻辑。该层解释客户端的请求，提供单次登录，实现会话管理，控制对业务的访问（权限检查），构造客户端的回复(response)，以及把回复传递给客户端。一般Sevlet，JSP驻留在该层。
业务逻辑层
该层提供业务服务，包括业务数据和业务逻辑。通常应用程序的大多数业务处理集中在本层。同时它管理事务。EJB驻留在该层。
集成层
该层负责与外部系统和外部资源通信，它有多种方式，如与数据库连接使用的JDBC等。
资源层
该层包括业务数据源和外部系统资源，如Oracle数据库，JMS server，其他遗留系统等。
2-4-1-2 实现
在实现上面的Tier时一般我还需要结合实际情况进行分解， 如果大家对<J2EE core patterns>熟悉，可以了解到web层我们使用MVC模式，当然结合Filter，FrontControl，ViewHelp等模式，客户一般访问JSP(为了进行表示和业务的分离大多使用Taglib)，然后由Control层进行处理，如果需要进行复杂的业务逻辑处理并且已经有后台实现(如EJB等)，推荐经过Business Delegate层，访问后端业务逻辑(BP)，一般业务逻辑使用Facade模式进行封装成统一的接口，业务逻辑层实现复杂的事务处理，如果需要访问资源层，再经过DAO层访问资源(目前多数是RDBMS，有时是遗留系统如Coraba，JMS，WebService，SAP等)。具体见下图：
（具体实现方式图）
关于Intercepting Filter，Front Controller，View Helper， Business Delegate，Facade模式请参见<Core J2EE Pattern>。
2-4-2 Layers
2-4-2-1 概述
在开发J2EE应用时，我们一般把它纵向分为以下几个层，最下层为OS，JVM，network，层，它们负责系统的底层操作和网络数据的传输，一般我们开发人员不用关心运行在什么具体操作系统上，什么样的网络环境下。它的上层为J2EE服务层，一般由J2EE服务器(如WebSphere，WebLogic等)提供各种基础服务，如事务的管理(JTS)，命名目录服务(JNDI)，负载均衡(Load Balancing)，容错(failover)，安全(security)等，其次是通用业务层，它一般完成与具体业务无关的基本操作，包括如基础的框架(Framework)，commons组件，如通用的数据库处理组件，系统错误处理组件，字符处理和数值处理组件，日志(log)处理，数据转化和编码维护等核心层。最上层才是我们的具体业务逻辑模块，它完成具体的业务逻辑。具体见下图：
（J2EE开发应用分层）
2-4-2-2 实现
结合J2EE实际环境，最底层一般不需开发人员关心的操作系统和网络环境，并且不同J2EE服务厂商都提供了相应J2EE所必须得基础服务层，我们开发人员一般只需关心上面两层的实现，应用服务层经常使用类似于struts，webwork，waf等的web application framework，log服务一般选择log4j。commons log等，其他具体的数据处理，数据的转化等操作我们需要进行开发，不过这些一般与具体项目无关，可以在公司内部不同的项目之间共享。其实Jakarta Commons提供的功能一般可以使用在该层。 最上层才是我们的具体业务模块。见下图：
（具体实现方式）
2-5 层模式实现讨论
·为把任务分组成层而定义抽象准则。
·根据抽象准则定义抽象层数。
·给每个层命名并指定它们的任务。
·指定服务
·细化分层
·为每个层指定一个接口。
·构建独立层。
·指定相邻层间的通信(或者调用)
0
相关文章
关注我们
