软件体系架构模式在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
相关文章
关注我们
