选择应用程序架构.doc

将软件应用集成到企业现有的IT环境的重要性和复杂性正逐步增长。企业的信息系统（IS）部门及向企业出售解决方案的应用程序供应商都面临着架构解决方案方面的艰巨任务，因为架构解决方案既要满足当前的需求，还要满足将来的需求。
　　本文探究了用于将数据驱动的应用程序与企业集成的常见数据交换模型，并讨论了所选的数据管理解决方案将如何影响集成的难易程度。您还将了解数据库同步、企业消息传递、Web services，以及作为应用程序集成的一般模型的XML。
　　没有别的办法。大型企业的IS部门和应用程序供应商面对的的IT环境非常复杂。他们通常必须处理企业内的各种架构模型，以及实现每种模型的多种技术。例如，对于大型企业来说，部署来自多个供应商的数据库并不罕见，同样，使用企业消息传递来集成Web应用程序与ERP系统也是常见的。
　　架构师面临的两难问题是，设计的解决方案要与当前的某个系统集成，但是以后可能还要与其他的架构或系统集成。由于IT产业有许多不同的发展趋势，因此这是显然会发生的——客户/服务器应用程序以前是合并到带有基于Web的应用程序的数据中心的，而现在移动解决方案则促使智能客户应用程序被部署到最终用户，而其数据则同步到数据中心。
　　这种形势对面临如下情况的应用程序供应商将更具挑战性：不仅仅是同一个客户的架构不断发展，不同客户的IT配置也往往不同，或者他们用不同的技术来实现该配置。
进一步的要求
　　应用程序架构师总是必须设计与当前的IT系统集成的解决方案，而且还要将成本降到最低。然而，IT环境固有的易变性意味着架构师必须设计足够灵活的系统，以便与其他IT架构集成。
由于企业使用了许多不同的系统，并且从方案评审到方案的全面部署之间的时间跨度也在不断延长，这就意味着，在能够与之集成的系统方面，应用程序要更加灵活。新的应用程序不仅必须与当前的IT环境集成，也必须能够与将来的IT环境集成。
　　考虑到人们要求IT部门使用更少的成本来完成更多的任务，尽量提高集成的灵活性这个需求将变得更加强烈。据估计，集成几乎占用了新应用程序总成本的三分之一。选择一个能够广范地进行企业集成的应用程序架构是一个行之有效的方法，它有助于将集成工作当前和以后所面临的挑战降到最低。
数据管理如何影响集成
　　数据管理与应用程序集成密切相关。应用程序中数据的管理方式会影响与各种系统集成的难易程度。怎么强调这个观点都不为过：您所选择用来管理应用程序数据的模型决定了企业集成的难易程度、灵活性和成本。
　　不同的数据管理格式具有不同的数据存储和通信的结构层次。从某个角度讲，存储在数据库中的数据位于表、行和列中。每段数据都有特定的类型，而且所取的值也可能有一定的限制。与之相反的是平面文件(flat file)，文件中的数据所代表的内容没有任何规则。尽管存在大家都认可的指导原则，即基于文件的扩展名判断文件中包含的内容，但是开发人员必须给文件中的数据加上结构。在各种数据管理和集成方法中，都有相对的结构层次（参见图1）。

图1.各种数据管理和交换模型的结构层次
　　XML提供了一种高度结构化的方法来将数据编码，但是现在还没有控制XML内容如何管理和存储的标准。此外，XML没有预定义的数据模式；它仅仅指定如何定义数据模式。创建XML模式以将应用程序数据编码是开发人员的责任。这就是说，任何两个给定的系统使用的XML模式都可能不同，这往往导致不同的系统之间难以通信。结果是，XML数据的编码是高度结构化的，然而XML数据的总体管理却不是高度结构化的。
　　通常，新部署到企业的的应用程序需要与已经处于生产中的现有系统集成。因为修改生产中的系统的配置不是明智的办法，所以我们通常选择更容易的方法来实现集成，即修改应用程序的配置。
　　因此，从结构层次较高的应用程序中获取数据，并与使用较低的数据结构层次的企业系统交换，这是很容易的。而从应用程序的数据上去移除不必要的结构要比在它上面另外加上结构容易得多。考虑如下两种场景：
　　假设企业XYZ拥有收款机(point of sale，POS)应用程序，它需要与ERP系统交换产品库存量。在第一种场景中，POS应用程序使用数据库，而ERP系统使用企业消息传递。针对这种情况，只要数据库中的库存量改变了，就需要将企业消息发送给ERP系统。这将会要求POS应用程序查询数据库以获得产品库存量，并将产品ID和库存量置于消息中的不同属性中。同样的，每当POS应用程序接收到来自ERP系统的新消息时，它就要读取正确的消息属性，并创建一条新查询来更新数据库中的值。
　　在第二种场景中，ERP系统使用带有同步服务器的数据库，而POS应用程序使用企业消息传递。这种架构为集成这两种系统提供了两个选择。第一种方法，这种架构可以为POS应用程序部署一个数据库。POS应用程序向本地POS数据库发送消息，然后本地POS数据库与ERP系统的同步服务器进行同步。毫无疑问，这不是最简单的办法。第二种方法，这种架构可以在ERP系统上配置一个消息传递接口，但是这需要改变生产中的系统的配置。
　　正如这两种场景所显示的，所选的应用程序（本例是一个POS应用程序）数据管理解决方案将会直接影响到与当前以及以后的企业系统集成时的难易程度和成本。通过选择跨企业范围的数据库来嵌入到应用程序中，企业架构师可以将集成的成本降到最低，并且可以确保新的解决方案能够继续与不断发展的IT环境相集成。
数据库同步
　　数据库同步技术实现数据库之间的数据交换，并确保保持所有数据库中数据的完整性。特别的是，在两个数据库失去连接时，同步技术能确保数据库的事务完整性，还能提供数据交换冲突的解决方案。
　　数据库的同步架构定义了一种层次型或非层次型的关系。对于以层次型方式配置的数据库来说，每个数据库均有一个惟一的父数据库，只有主数据库（master database）或合并数据库（consolidated database）除外，这二者没有父数据库。每个数据库都与主数据库中的某个数据子集同步。在层次型配置方式中，对于任何两个直接共享数据的数据库来说，其中一个数据库总是在层次中处于另一个数据库的上面或下面（参见图2）。

图2.层次型与非层次型同步架构
　　对于数据库是在上面还是下面，以层次型方式配置的数据库没有明确定义。非层次型模型主要用于实现故障恢复处理，而层次型配置更常见于应用程序的集成中。
　　各种同步方法并不是同等的。架构师应该要知道，实现数据库同步的各种方式有很大区别，这将对架构的可伸缩性以及同步技术支持不同集成场景的的灵活性产生极大的影响。
　　当两个或更多的关系数据库之间的数据子集需要在各个数据库之间实现持续复制时，就应该使用同步。
　　寻找一种能完成如下任务的同步系统：
· 支持多个数据库供应商，确保有较大的集成灵活性。
· 直接与第三方数据库服务器同步。一些解决方案需要在服务器上安装中间数据库，这样开销会很大。
· 如果同步过程需要穿越防火墙或者Web服务器，可以使用TCP/IP、HTTP和HTTPS协议来实现同步。如果要创建移动解决方案，那么就使用Palm HotSync和Microsoft ActiveSync。
· 可以使用强加密(strong encryption)来加密同步数据。
· 提供检测同步冲突的机制，并可以对解决方案进行编程。理想情况下，可以使用SQL、Java或者.NET语言来开发同步逻辑。
· 允许通过表、行和列来构造数据子集，确保只有必要的数据才会在数据库之间复制。
· 只针对数据的更改进行同步，将传输的数据量降低到最小。有些系统也允许对要同步哪些数据以及何时同步进行优化和控制。如果网络连接不是始终相同，那么这种方法就很有价值。例如，在移动应用程序中。
· 能够通过不同的访问控制列表进行同步会话的验证，包括第三方系统，比如LDAP（轻量目录存取协议）。
企业消息传递
　　企业消息传递是一种模型，该模型使用消息通过数据异步交付来连接一组不同的IT系统。企业消息传递技术包括Java Message Service（JMS）、TIBCO、IBM的WebSphere MQ（MQSeries）和Microsoft MQ（MSMQ）。有了企业消息传递，人们通常将消息置于中心消息传递服务器的队列上或者远程系统的队列上，从而实现系统之间的信息传递。每个队列都有一个或多个应用程序来消费置于其中的消息。
　　企业消息传递在许多方面都与数据同步不同。首先，该架构与层次型同步场景相比，结构化程度明显弱得多。很多不同的系统可以很轻松地与其他系统交换消息。该架构可以有一个中心服务器，它可以像集线器一样，将多个系统互连起来，或者系统可以直接与另一个系统对话（参见图3）。

图3.企业消息传递提供无限制的配置
　　其次，同步结束时，两个数据库的某一部分数据完全相同，但是对于企业消息传递来说，队列只接受消息。换言之，通过队列的通信一般是单向的。两个队列不会为了使其状态完全相同而互相复制消息。
　　再次，队列通常不用于永久性存储数据；相反，它们用于临时存储，直到队列被某个系统消费（也可能被存储）。特定的应用程序消费特定队列中的消息。消费的数据是否存储，或者如何存储，架构中的其他系统都无从得知。
　　当需要与消息传递系统（如：基于JMS的系统、J2EE应用服务器、IBM WebSphere MQ服务器或TIBCO）进行数据交换时，应该使用企业消息传递。当企业的IT策略允许在数据库外部同步数据，而不允许同步数据到数据库内部时，企业消息传递也是很有用的。如果情况确实如此，那么可能同步和消息传递都适合使用，企业消息传递向企业中间件服务器发送数据，而同步则从数据库提取数据。
　　寻找支持企业消息传递的数据管理解决方案。具体来说，要寻找具有如下特点的系统：
· 提供综合API，以管理消息和队列，并且要支持多种编程语言和开发环境。
· 可以与各种不同的企业消息传递系统集成，保证系统能够支持不断发展的企业架构。
· 保证消息交付的一次性，以便在发生系统故障时消息不会交付两次。
· 允许将消息组织为事务组，以便组中的消息要么全部交付，要么一条都不交付。
· 可以创建控制消息交付的传输规则，大力支持开发人员优化性能、降低成本和消息交付带宽。
· 当传输消息以及在消息队列中存储消息时，可以使用128位强加密来加密消息。
使用Web services模型
　　Web服务为不同的软件应用提供了一种互相交互和交换数据的方法。每一个Web服务都有一个使用Web services描述语言（WSDL）描述的接口。其他系统通过HTTP，使用简单对象存取协议（SOAP）（基于XML）消息与服务交互。正因为如此，接受Web services请求的系统需要某种类型的HTTP服务器。
　　您将会发现，Web services、企业消息传递和数据库同步之间有很多重要的区别。首先，目前没有任何规范描述Web services数据是如何暂时地或永久地存储的——这与数据库和企业消息传递的情况相反，数据库是高度结构化的数据存储形式，而企业消息传递则使用队列。
　　其次，不会为了响应Web services请求而返回数据。Web services的通信可以是单向的或双向的，而同步一般是双向的，通过任何给定的企业消息传递队列发送的消息则一般是单向的。
　　再次，通过Web服务发送的内容没有预定义的格式，此外，它是用XML编码的。相反地，数据库有表、行和列；而企业消息通常有一组头信息、属性，以及特定类型的内容，比如二进制或者文本。
　　Web services的灵活性提供了一种交换结构化内容的方法，但是需要建立策略和规范，来定义内容的特定结构、存储方式以及内容交换的协议。
　　在以下的实例中，应该使用Web services：
· 企业系统已经有了Web services接口。
· 各个系统之间的网络连接持续可用。
· 部署额外的中间件服务器，以便用作接口来连接多个系统，而不可行。
　　当寻找支持Web services的数据管理解决方案时，要寻找具有如下特征的系统：
· 具有开发Web services请求的工具，最好支持多种编程语言。
· 可以轻松地在Web services请求中嵌入XML格式来检索数据。
· 具有内置的HTTP服务器来接收Web services请求。
· 同时通过HTTP和HTTPS协议，支持Web service请求的发送和接受，确保数据是安全的。
用XML定义自己的结构
　　XML已经成为对数据进行编码、交换和存储的通用规范。XML是一种以文本格式表示结构化数据的规范。像HTML一样，XML是一种简单标记语言，但是它也很灵活，这一点又像SGML。XML允许开发人员定义自己的数据结构。XML数据的结构定义可以使用文档类型定义或XML模式描述。
　　尽管XML提供了一种内容编码的格式，但现在还没有定义数据如何存储和交换的XML规范。这就等于给企业架构师一张白布，架构师可以在上面尽情发挥。但是，要构建管理并与企业系统交换XML数据的基础架构，所费的工夫会以几何级数增长。作为一种信息编码方法，XML已经取得了巨大的成功，但是千万不能认为它是数据管理和交换的完美解决方案。
　　应该在以下情况中使用XML：
· 解决方案需要使用Web services来发送数据。
· 外部系统不支持数据同步、不支持基于JMS的消息或者没有Web services接口，但是却具有导入或导出XML数据的工具。
· 数据要通过批处理与第三方系统交换。
　　当我们要寻找支持XML的数据管理解决方案时，应该寻找那种能导入导出XML格式的数据的系统，并且它应该能够使用XSL来将数据转换成不同的格式。
　　集成应用程序与企业系统的正确模型随具体的IT环境的不同而不同。事实上，可能企业架构师很快就需要使用同步、企业消息传递、Web services和XML。尽管对架构师来说，很难预料到哪些集成模型是必要的，但是应用程序的数据存储方法将会决定该应用程序与其他企业系统集成的难易程度。
　　通过选择使用跨企业范围的数据库来管理应用程序的数据，架构师可以最大程度地提高企业集成的灵活性。这样就能保证新架构的系统能随着IT环境的发展而发展。通过使用跨企业范围的数据库，应用程序供应商可以更轻松地将其软件解决方案集成到多种客户环境中，从而确保不会因为集成成本过高而丧失销售机会。
原文出处