多层结构与tuxedo

N层组件

今日世界，越来越多的应用系统采用分布式模型。然而，很少的管理人员、设计人员及开发人员能在成功的设计、开发、管理中完全理解分布式应用的底层组件。

本文将首先对N层结构的各个组件进行描述，进而讨论如何加以利用以提供完美易扩展的策略。 

N层组件：模式

一个成功的系统的开始通常依赖于对工具及管理方法的选择。一些方案提供者并不真正了解专业的、企业级的需求，更糟的是，他们会有意无意地向用户推荐专有系统模式，使得将来对应用系统的修改变得痛苦不堪或根本不可能。在这种情况下你只有两种选择：重新构建你的系统或购买更多的硬件。然而--，你是否有足够的财力允许你这样做？

也许你会问：“为什么我要修改我的系统？”，很简单，因为我们生活在一个剧烈变化的经济时代，如果你不能及时调整以适应商业的变化，你将很快被淘汰。然而，只要你拥有一个好的设计及清晰的模式，修改并不总是意味着你需要重新构建自己的系统。

N层结构的前提是一组网络、数据、应用的集合，Client和Server可以动态地建立或断开连接以响应用户的需求。在这种模式下，用户可以在任何时间、任何地点存取数据及应用逻辑-无论是Internet应用、Client/ Server应用或基于主机的应用。 

这种模式的优点是无论何时需要对组件或子件进行简单或复杂的修改时，都不会对其他组件造成影响。 

CHUI/GUI (字符或图形用户界面)- 表示层

CHUI/GUI作为人机界面，是应用分析员/程序员设计的窗口界面，指导操作人员使用已定义好的服务或函数，以获得希望的结果。 

理论上，表示层并不拥有任何商业逻辑，但是考虑到有少量应用逻辑不会出现经常的变化(如复合利率计算)，可以把这部分应用逻辑放在表示层。 

商业逻辑

这是你公司的至宝，包括公司的规则及运作方法。商业逻辑所做的，通常是接收输入、处理、返回结果。 

我们以一个描述了支票帐户的取款过程的商业逻辑为例。对于这样一个交易，某家银行可能规定如果用户帐号中没有足够的资金时，这样的取款操作将不予执行。然而，另外一家银行可能以允许用户有限透支为前提，接受用户的取款请求。如果你的系统设计足够灵活的话，将足以应付这样的应用逻辑变化。这样当公司的策略调整时，相应的应用逻辑的修改将简单而完整。所谓的“完整”，指这样的改变将针对所有的用户而非其中的一部分。

数据处理逻辑

将数据处理逻辑与商业逻辑分开的一个显而易见的理由是大多数的DML (如 SQL) 代码是相同的。数据处理逻辑与商业逻辑的分离将有助于数据处理逻辑的可重用性。

当然，你可能已经认识到数据处理逻辑是商业逻辑与数据库系统间的主要部分。

应用变得越来越大，越来越复杂，分布越来越广。同时，因为公司将更多的关键应用扩展到intranet，extranet和internet上，使得对应用可用性的需求提高。管理服务必须提供从开发到分布、到维护的全面支持。运行状态的管理(动态地)，集成性能监测和管理支持，使对大范围增长的分布应用的修改和维护成为可能。 

安全性不仅限于用户的登录检查，还包括网络检查、系统检查、用户帐号检查、应用和数据检查和数据的保密。例如，应用的安全性指通过存取控制表限制某类用户对某些应用的存取：一个银行的用户不能通过Internet请求外部资金转帐，因为他受到安全性控制。

数据存储库

存储库是一个软件机制，存贮、管理组件，包括应用服务和商业逻辑。存储库也存放一些关键信息，如对象设计(UML)和数据库定义。

没有一个恰当的数据存储库，你无法发现哪些应用逻辑是可用的，何人何时将修改它们？

存储库将有效地帮助你的开发队伍更快地理解应用，去发现已存在的可用组件而无需重复开发，以有效控制开发费用。因此，任何在应用中的修改，都应修改存储库使之保持同步。

中间件是分布应用中的一个关键组件，它必须为N层组件结构中描述的服务提供完整的、部分的或基本界面。

中间件技术出现了多种走向，从而带来性能的问题。很多中间件因为没有把性能做为头等考虑因素而导致整个应用系统的开发陷入困境。

在选择中间件产品中容易犯的第二个大错误是选择的产品缺乏成熟性。你的关键任务应用是不能失败的，项目管理和系统管理不能依赖产品供应者每天送来补丁来弥补其产品中的缺陷。我本人无法给予一个经常来到我的开发中心来修改其产品原代码的中间件供应商以充分的信任，我不能使自己的应用冒这样的风险。

最后，对其他产品的开放性对于节省开发费用来讲是至关重要的。我的应用是否能连接到Internet上？是否能连接基于Corba IIOP的用户？是否能实现与其他平台的连接? (Windows XXX, Unix, OS400, MVS, …)

N层组件 : 拓扑结构

分析过N层组件结构中的各个组件，我们来看一下如何把各个组件结合在一起，以满足应用系统的需要。

理论上在开方的分布世界中有4种拓扑结构：集中型、数据分布型、数据集中型及高可用型。鉴于我们在前面讨论了中间件的作用，你可以选择其一，使得从一种拓扑结构到另一种结构的转变是透明的，至少是简单的。谁能保证我的程序能在另一种结构下正常运行？是什么造成从一种结构转变到另一种结构的困难？

下面是一些可能造成一些问题的根源：

· 硬件&操作系统可用性

你发现了更便宜的硬件或新的技术趋势(如Internet技术、主机等)

· 网络协议及速度

· 数据库

现在，在分析各种结构之前，我们我们假设表示层只拥有少量的应用逻辑，并放置在Client端或前台的Server上。同时，应用及商业逻辑放置在Server端，因为对商业逻辑的改变应简单便捷。

在这种结构中，Client程序连接某指定的机器并通过这台机器完成交易。数据库放置在同样的机器上，或指定一台专门的机器做为数据库服务器。

如果你的公司中只有一、两台主服务器，这种结构将给你带来下列好处：

· 集中式的管理 (用户, 应用服务器等)

· 安全

· 简单

下面一张图看起来有点困难，因为我们把数据库引擎放在了另一台机器上。这样做的一个好处是当大量的用户连接到第一台机器上时可以减轻这台机器的负担。前台没有任何变化，所有的变化都发生在后台。

数据分布型

数据分布型结构类似前一种结构，只是数据库分布在每台server的机器上。它据有下列优点：

· 无单点失败

· 独立管理

我们将这种结构用于数据分割，例如逻辑分割和地理的分割。逻辑分割包括属于确定种类的数据：姓名、帐号等。地理分割包括省份(广东、山西、北京…)等。

需要注意的是交易的执行可以由一台机器跨越另一台机器，因此使用全程交易是至关重要的。例如，如果我们有一个交易需要跨越两台机器(因此，需要两个数据库实体)，此交易在两台机器上，要么全部提交，要么全部放弃，否则，你将面临数据的不一致。完成全程交易的方法之一，是使用你的中间件(如TUXEDO)提供的源于X/Open组织的XA协议，来协调管理全程交易。

数据集中型

这种结构是对集中型的一个增强，由其中的一台机器作为数据存取服务器。我们现在在前台有更多的应用服务器，共享一个数据库服务器。这种情况下，必须使用数据库软件提供的并行处理功能及硬件厂商的硬件集群策略。

高可用型

现在，公司希望在硬件出现错误时的应用迁移更加简单，在迁移的同时希望系统继续运行并尽量减少人工干预。类似TUXEDO这样的中间件可以提供这样的功能。帮助操作系统自动迁移关键组件到正常的机器上。

在应用系统设计初期选择一个可扩展的策略可以帮助你由一种结构转移到另一种结构，并在系统扩展时节省大量费用(谁不希望如此呢！)。如果你的策略中的某个组件无法提供这种可能，或者没有这样的经验，为什么不去选择一个可以帮助你的！