简介
一个三层或是多层信息系统架构的好处是，可将其焦点放在一些"信息"的处理工作上，另一方面，对于大部份信息技术专家而言，也是了解和体会此项新技术潜力的良机。然而，信息技术的工作人员在他们大量的信息系统产品中，常常会遗留一些令人感到惋惜的事实，例如：大部份产品里并没有运用"组件"的概念，或在无奈的压力下继续进行系统功能的加强，即使他们知道（这些系统）随着使用年限的延长已经出现了问题也是如此。这篇报告将对该项议题展开讨论，并且将会提供一些实际的建议，而不单单是将现有的系统进行组件化、多层架构化；另一方面也提供了如何以团队开发的概念，将某些信息技术转换到一个"以组件为基础"的新程序开发境界。
逻辑多层架构和实体分布式架构
在开始讨论之前，必须先了解逻辑多层架构和实体分布式架构两者的区别。了解逻辑多层架构和一个实体分布式系统的不同之处，将有助于说明移植现存系统的途径，可持续地进行系统增强，而这则不会产生一个令人生畏的学习过程。
逻辑多层架构
一个逻辑多层架构的设计是应用程序按逻辑工作，它可以分成三个独特的服务领域："用户服务"、"商务服务"和"数据服务"。这种区域分隔方式允许开发人员在数据库和用户程序之间，引入抽象的弹性分层。每一层都负责不同的工作任务，当将它们结合在一起时，会变成一个具有凝聚性、合作性的系统，且具备了弹性、坚固性，及可成长扩充等特性。
"数据服务"主要负责数据的配置和常态性。下面我们以数据库的关联来典型的说明范例，数据服务需要包含所有的储存过程、内含所有组件基本的数据访问，譬如对一个客户的搜索组件等。数据服务所处理的工作较为一般，例如：维护数据的常态性、恢复和保持数据完整一致性等工作，而并不是在数据中实际执行任何一条特定的事务规则。
此外，"商务服务"可以负责建立商务规则。它们在数据服务中"修复和保持数据的完整性"，但它们新增了可实际执行有关应用商务规则的功能。而典型的商务服务范例组件包括：税务计算，它运用了有用的商务数据，如：顾客、产品、订单或授权契约等数据功能，而且还运用了如传真与电话等商务功能。"商务服务"虽然是不可见的，但由于它们可以将商务规则独立出来，因此可以经常地更新商务规则。这些"商务服务"能让用户的工作内容数据具备有效性，或是在做计算和其它应用时，可以充分地运用商务规则。
在信息系统中"用户服务"是可见的。这些服务是将数据显示给用户，并允许用户对这些数据进行操作，并且可以通过商务规则与商务服务链接在一起，进而确认和产生所需的数据。"用户服务"的范例如：窗体、控制、图形及屏幕上所显示的讯息。
上述这些服务的好处是众所周知的，由于不在此篇报告的范围，这里不再赘述?要了解关于多层设计优点的更多相关资料，请参阅在Visual Basic 4.0到6.0企业版的文件集，其中记载了有关建立客户端与服务器端的应用范例?。在这个可反应商务变化的系统中，以上所述功能足可以带来更多的可维护性、分层性和可成长性。
这些层次基本上是按逻辑区分的，并不表示在实际运作时，那些服务就一定会被分类的位置。其中必须注意的是，观念上可将它们摆在"特定的分层"的设计里，在这里存放着所有可以被执行的服务。也就是说，这种方式允许共享和重复利用所有组件的设计技术，它是系统开发组件化中一项吸引人的优点，此项优点也意味着你将不再需要深入到组件的世界里，即可获得多层设计的好处。
实体分布式架构
当一个系统在逻辑上被分成几层时，它会被组件分化。组件是一个OLE项目，它提供OLE自动化接口的集合，可以使任何OLE自动化的用户应用程序重复使用。这项组件是以二进制的格式进行编译的，加以形态库的包裹，最后以组件来呈现用户接口。组件可以供许多客户端共享，允许重复使用，并且可在任何一种支持OLE自动化服务器的计算机语言中进行开发。
组件以下列以三种方式的产生在客户端上：内部进程服务器、外部进程服务器或是远程服务器。"内部进程服务器"是动态连结?DLL?，并且在客户端应用程序里使用同一个进程及位置空间。"外部进程服务器"则是在客户端应用程序里，使用不同进程和位置空间。"远程服务器"则是在完全分开的机器上执行，执行时使用其它机器的CPU和系统资源。以上每一种选择均有其优缺点，而且在系统中每一个组件可选择不同的分布式模块。
"内部进程服务器"是在客户端与服务器端之间，理想中高效率的重用组件模式。它们可以快速加载，并且由于占用相同的位置空间，因此在传递给客户端应用程序或是从客户端应用程序传回数据时速度相当快。理所当然地，由于它们同样为客户端的应用程序，并且同属于一个进程空间，因此它们必须位于同一个机器上，然而更新组件却有潜在的困难。在Visual Basic中建立内部进程服务，也必须在相同的线程中执行客户端程序，但如此一来，使它们不能同步执行客户端程序代码。如果在Visual C++中建立内部进程服务，则可产生如背景工作般的多重线程。
"外部进程服务器"是一种组件概念，其需要在分别的进程空间，或是线程中执行客户端的应用程序。虽然这些服务器将会降低加载速度，当在客户端和服务器端之间传输数据时，从一个地址空间传输到另一个地址空间将会造成延迟。但是外部进程自动化服务器仍具有可行性，因为外部进程服务器可以像一个独立的应用程序方便了组件的使用。而且它们是在属于它自己的线程中执行的，那是与客户端应用程序不一样的线程。在这个时候，外部进程服务器可使用定时器来配合背景或可执行异步的工作。
"远程服务器"同样也具可行性，因为它们在与客户端应用程序不同的进程中执行，而且远程服务器也可以在完全不相同的机器上执行客户端应用程序。这是一个非常具有威力的特性，正如它可以让你从客户端机器中，从许多功能强大的服务器上脱线下载，特别是像广域网中的另一个客户端或像慢速连接的Internet。调用或执行"远程服务器"的对象是上述三种方法中最慢的，而且数据传输和函数调用也是三者中最慢的。然而，当在远程机器执行函数调用时，则客户端的CPU将可以释放系统资源，以让其它工作使用。
幸运地，Visual Basic的类模块是完全独立的。但它们会令人混淆，并且会让你浪费时间来学习哪一种实体分散架构最适合现在的系统，通常我们需要一再尝试，并且在内部进程、外部进程及远程服务器之间移动类。有一则好消息，在实体分布式模块间移动类时，客户端程序和服务器端程序无需进行联系。实际上，客户端应用程序不须随时使用，甚至开发人员可在执行时，将组件从外部进程服务器移到远程服务器中，反之亦然。此项配置可独立设置此种状况，其目的是为了更容易将现有系统移植到一个多层架构的设计中。
移植的步骤
如上所述，在真实的世界中，信息科技团队持续地推动、维持和加强现存的系统，但是他们也了解到要延长其使用寿命，有赖于将这些系统移植到一个多层架构或是一个以分布式组件为基础的系统中。在下一节中将会讨论一些实际的建议，有关如何将现存系统朝向多层架构发展，却不必将现在的项目完全拆开来等的问题，都有详细讨论。
逻辑化设计
在准备一个三层次架构时，首先要做"逻辑化设计系统"。然而，对那些方法论者也许会感到痛苦又加深了，但是这却是建立以组件基础系统的基本步骤。根据方法论者所提出理论来制作逻辑化设计，也许会很有帮助，但其并不需要一个严格的过程，而且你并不需要对这些过程作太多的服务或考虑。
在逻辑化系统设计阶段，组件的实体和它们最后的配置是有关系的。此项目是确认系统中实际的实体并了解它们之间如何交互。该实体通常是繁重工作的一部分，因为它有处理最近执行工作的能力，并且可以确认哪些事务是相关的。前述技术超出了本篇文章的讨论范围，下一节将提供一些建议，让你了解如何哪些组件是需要先建构的，以及如何花一点时间就可以将你的系统组件化。
请记住逻辑化系统是可增长的，并且要随着系统发展进行更新与改进。它并不像一个项目团队在第一次就要设计出完美的设计，甚至不像当有些情况改变时，仍然保持其完美性。该逻辑化设计必须延续下去且逐渐增长，正如系统一般，在做系统组件化后将会发现移植的发生率更加趋缓。
从何处着手
一旦已确定有多个用户，就应该决定系统中的"商务服务"和"数据服务"中，哪一项是应该首先建立的。然而对许多系统而言，这是个实际问题，当系统完全地变成组件编写时，整个项目不可能随时待命。然而对VB/OLE 服务器技术而言，你可以增加系统组件化程度，可以在项目允许情况下，从中移出一些组件先着手。
第一个步骤是在系统中建立低层组件。由此可知，所谓的这些"低层组件"指的是被整个系统使用的，并且提供了操作系统扩充性的组件。正如你的数据访问组件、登录服务、传送消息和网络服务，还有电话集成服务和状态管理服务等组件一样，这些可重用组件并不限于只在你的项目使用，因为它们可以被整个系统使用，但是大部分系统均有相同的低层要求。当然，对其他项目而言，这些组件的功能，也是极具吸引力的。例如，一个组件允许你的应用程序写入NT的事件日志，而且可能会被其它的应用程序使用。相对地，当你在现存的系统中开始拆开其它组件时，这些组件将需要低层服务，尤其在形成高层组件前，必须要先有低层的组件的存在。
下一步要建立这些服务，它们将对在客户端应用程序中，欲进入一个分开的地址空间，或是一个在实体上不同的机器有所帮助。这些服务的例子包括：信用卡验证，传真程序长时间运算及报表行生成程序。OLE服务器可以在客户端应用程序中的同一个进程，或是在
