基于TUXEDO的设计原则[转帖]_MQ, Tuxedo及OLTP讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MQ, Tuxedo及OLTP讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3992 | 回复: 0   主题: 基于TUXEDO的设计原则[转帖]        下一篇 
luqunfang
注册用户
等级:少校
经验:1219
发帖:74
精华:0
注册:2012-6-25
状态:离线
发送短消息息给luqunfang 加好友    发送短消息息给luqunfang 发消息
发表于: IP:您无权察看 2012-7-12 9:56:37 | [全部帖] [楼主帖] 楼主

1. N-层应用组件化设计原则
         三层客户/服务器设计包含三个逻辑的和物理的应用代码组织。它们是:
·         表示层(和相关的表达业务层)
·         组件层(也称为应用层或业务层)
·         数据层
         应用逻辑经过这些层次的分离使应用得实现松耦合的概念,松耦合使得应用逻辑被分割为TUXEDO服务,这些服务可以根据系统当前或未来的分布需求,如用户数、容量和数据分布的需求进行部署。

1.1 表示层
         客户机上的表示层包括两个子层:
·         表示层
·         表示业务逻辑层
表示层提供应用的用户交互接口,即主要是图形化用户界面,这一层不应该包含任何业务规则或数据访问。
         表示业务逻辑层,用于为表示层提供一个业务逻辑抽象。表示业务逻辑层只包含需要通过访问组件层完成的业务逻辑,或完成本地业务决策逻辑。
         表示层与表示业务逻辑层的划分能够提供:
·         表示层与表示业务逻辑层划分清晰
·         为表示层提供业务抽象
·         在表示业务逻辑层实现面向对象的运行方式,而不影响图形用户界面的程序逻辑和开发环境。
·         在所以的GUI逻辑实现中可访问可重用的业务逻辑。
·         能够适应GUI开发工具,开发语言和操作系统。
注意:不要把交易控制置于表示业务逻辑层,把它们组织在组件层。

1.2 组件(或应用)层
1.2.1 组件框架原则
         应用层从面向对象的观点来看通常是指组件层。组件层只包含业务逻辑,在这一层中不应该包含任何GUI或数据库访问方法(SQL,存储过程)。数据访问通过数据层服务访问实现。组件层包括所有的应用业务规则,而不依赖于数据层和表示层。
         组件体现在TUXEDO应用系统中就是服务。组件根据请求者的请求运行,并可请求必要的数据层消息服务。组件可以调用其它组件,并自动成为全局交易的一个组成部分。
         各层之间的通讯由TUXEDO消息传输机制来实现。采用XA接口,所有与其它组件或数据层的通讯均自动包含在全局交易中。
         在组件层进行交易语义控制。不要在表示层或数据层实现交易语义控制。
1.2.2应用服务设计原则:
·         信息隐藏原则:定义服务以及从客户到服务的数据流尽可能独立于服务的实现。服务程序中不要嵌入客户机有关数据采集技术等信息。反之,客户机也不应该意识到服务器程序的实现细节,如数据库结构以及记录格式。
·         分层服务原则:尽可能每个服务只完成一项任务,而不是多项任务。不要在一个服务函数中包含过多或过少的功能。努力定义一组简单服务来实现业务的基本功能,通过这组服务的组合,可以实现复杂的应用服务功能。
·         业务对象原则:围绕业��对象设计并使用服务功能。以一组相关的对象或公共对象将服务组织成为服务进程。

1.3 数据层
         数据层包括所有访问数据库或信息库的所有逻辑。这层包一包括数据存取方法,如SQL、存储过程、ISAM文件存取以及与数据存取相关的业务逻辑。
         组件层与数据层服务的划分为TUXEDO应用管理员在应用系统部署阶段提供了极大的灵活性。而在开发阶段对数据层服务、组件层服务和GUI业务层的重用,必须给予足够的重视。

1.4 N-层组件部署原则
         应用部署的灵活性对应用管理员非常重要。在高度松耦合的N层组件化系统结构下,可以依据系统生产环境,如用户数、交易容量、数据的分布以及外部系统经互联网对应用的访问或企业其它应用的访问等要求,灵活改变应用的结构。

2. 应用域划分原则
         TUXEDO应用域即是一个自治的、可独立配置管理运行的TUXEDO应用系统。根据应用的规模和企业组织的策略,将一个大的应用系统划分为独立的应用系统,不仅能够满足组织管理的需要,而且能够独立调整监控,使系统性能达到最优。影响应用域划分的因素:
·         应用规模
·         企业组织策略
·         应用安全范围
·         共享资源和服务的用户组
TUXEDO/DOMAIN为各应用域之间提供了互操作的基础框架。应用域机制也为应用系统提供了与其它OLTP应用系统的互操作手段(通过OSI-TP标准协议)。

3. 性能设计原则
充分利用TUXEDO系统提��的通讯机制,采用:
扇出式并行、管道式并行机制等。
负载均衡配置
事件发布/订阅机制
大数据量传输
批处理

4. 故障恢复设计原则
         TUXEDO为应用提供故障清理和恢复机制。在系统部署时,保证应用过程单点故障对整个系统造成影响。
         客户进程故障:本地客户程序由BBL进行监控。BBL将对故障的客户进程或未正常中断连接的客户进程进行清理。工作站客户进程由WSH进行监控,并对客户进程进行超时清理。
         服务进程故障:TUXEDO提供服务进程故障自动清理和重启功能。MSSQ自动服务请求迁移功能。
         超时控制:服务超时与交易超时回退处理。
         计算机硬件故障:
                   备份机
服务组迁移

         网络故障:
         交易过程故障

5. 高可用性设计原则
         非HA环境的HA设计
         HA环境的高可用性设计

本篇文章来源于 中间件技术社区(http://middleware123.com) 原文链接:http://middleware123.com/tuxedo/dev/125.html




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论