可以在重构项目中处理多个软件设计问题：

　　混合UI、业务和数据相关数据

　　例如，在创建应用程序来显示和编辑主文件的内容时，最简单的单用户设计将从用户接收查询参数，查询数据库并显示找到的头15个项，让数据库游标保持打开状态，直到用户编辑之前显示的一个项或向下滚动以查看接下来的15个项。当查询结果在消息中返回（而不是显示）时，此设计很难更改。如果用户希望接收多于或少于15个项时，也很难进行更改。在查询逻辑和UI逻辑之间创建一个接口可解决大部分此类问题。查询结果在消息中返回；可以在一个传入参数中指定要返回的结果数量。

　　维护用户会话相关状态

　　在前面的示例中，两个用户交互之间将保持数据库游标打开，从而防止其他用户访问被锁定的数据段。对于多用户系统，在进程内存中缓存查询输出并释放数据锁定可提高总体系统性能。不过，具有用户特定的缓存内容的应用程序进程将挂起，直到用户执行某个操作为止。进程拥有线程、内存和其他资源，随着用户负载的增加，这些资源现在开始变得稀缺。通过添加代码来同时在单个进程中管理多个用户的查询缓存，不需要挂起进程，而可以进行切换来为另一个用户执行工作。高级事务管理器中间件（如CICS和IMS）提供了临时存储区域（剪贴板、临时存储队列），可用于跨用户交互缓存应用程序状态。此外，中间件还可以对这些缓存进行管理，从而减少主存的压力，并能在处理器之间复制这些信息，以改善工作负载管理。

　　用户会话与应用程序中的用户会话状态的耦合

　　如果进程用于多个用户，则在每次执行时，都必须能够标识发出当前请求的用户，以定位用户相关的会话状态。在SOA应用程序中，服务用户可以是人、计算机化的工作流脚本和其他组件，因此最好在应用程序进程开始执行时将单一类型的用户密钥（标识用户会话的数据值）传递给该进程。较老的应用程序可能会包含不符合此要求的用户密钥（如TERmid）。引入用户密钥参数在必须执行多个组件来满足用户请求时特别有用；这样的做法可确保在每个组件中使用恰当的用户会话状态。

　　隔离业务逻辑和数据逻辑

　　尽管一些业务流程（如折扣和销售税计算）是纯逻辑，但其中的大部分都采用常见的创建、读取、更新和删除(CRUD)模式对持久性数据（客户地址、持有股票）进行更改。简单的程序体系结构会自然地将业务逻辑和数据访问逻辑（如SQL）混合。对数据模式和特定版本的SQL的这种依赖性可能会抑止重用业务逻辑和数据的灵活性。将数据操作逻辑放入到数据访问服务或过程中可减少业务逻辑对数据源的依赖性。此外，数据访问服务本身的设计和实现也可成为可重用资源。如果需要最高的性能，通常可以将数据访问服务作为数据库存储过程实现。

　　在考虑重构项目时，还可能出现很多其他设计问题，应当加以考虑。如果未对其进行处理，此处列出问题可能会严重妨碍过渡到SOA的进度。

　　这些建议的设计更改可促进组件化（要讨论的下一个SOA支持模式）的实现。

　　组件化

　　组件化可通过为无法访问的内部功能（如在交互产品订购应用程序中的折扣计算）创建接口来使得应用程序模块化。组件化是重构的扩展，因为它在应用程序内引入了SOA接口，而重构仅应用于外部接口。

　　现代组件体系结构假定组件在称为容器 的中间件环境中执行。容器将承担很多资源管理责任，而这些在其他情况下必须编码到应用程序中（如资源连接的设置和销毁、线程管理、事务控制以及数据结构实例的创建和删除）。而这使得组件几乎不依赖任何特定资源类型或操作系统。将组件重新部署到具有类似功能的其他容器中的工作将变得简单得多。因此，组件化还包括对应用程序进行重构，以从应用程序中删除资源管理功能，并将其替换为容器提供的等效功能。

　　在现代组件体系结构中，开发人员将使用资源管理策略语言显式地指定组件的资源管理需求。这样的例子包括J2EE部署描述符和Enterprise JavaBeans Query Language(EJB QL)。在组件部署专家准备要在特定中间件环境中执行的组件并将其与将使用的实际资源关联时，部署工具将读取此信息。在较老的中间件环境中，软件部署是由系统程序员使用特别方法完成的（例如，应用程序开发人员以书面形式指定相关内容，并将其交给系统程序员）。资源管理策略语言实际是一种配置语言，该语言将应用程序级别的策略（如数据库连接）和中间件策略（如使用何种传输协议进行消息交换）混合在了一起。较新的做法可以通过工具实现自动化，出错的可能性更小。例如，部署工具可以在应用程序执行前检测与数据库相关的错误。以前，应用程序只有到执行时才会检测到此错误，并产生错误消息和一个存储转储。

　　早就提供了具有资源管理功能和配置语言的容器的大型机子系统（如CICS、IMS和DB2中间件），目前正在逐渐向现代资源资源管理语言和容器提供的标准服务集过渡。同时，现有应用程序的组件化仍然可提供大量的重用和灵活性好处。

　　在应用组件化模式时，要处理一系列技术问题。以下列出了其中一些问题，并可能在后续文章中对其进行详细讨论。或许最困难的挑战在于从多个源文件收集相关代码；开发工具可以极大地加快这个任务的进行。另一个挑战是，重新设计以前属于单个模块的两个或更多代码段间共享信息的方法；虽然在参数传递信息可行，但并不总是最佳解决方案。

　　什么是组件？

　　前面的大量讨论内容都集中在称为组件 的软件单元技术要求上。这一部分将开始讨论如何标识现有应用程序中的潜在组件。您将在本文中了解用于发现和创建组件的工具和最佳实践。

　　组件发现是确定结构和逻辑边界的设计活动：即哪些数据和行为要放置在一个组件中，而哪些数据和行为属于其他组件。在创建组件时，通过在重用数据库中注册这些组件及其重要属性，可允许其他开发人员查找并重用这些组件。

　　组件与面向对象的编程中的对象具有很多相似之处。因此，组件发现过程自然和面向对象的设计相似。就最一般的层面而言，组件提供与以下之一相关的服务：

　　·特定类型的数据，如客户和产品。

　　·特定类型的流程（如工资支付、帐单编制或评估）。此类组件通常使用和集成很多类型的数据。例如，帐单编制将聚合来自产品、客户、订单和其他流程（如运输和财务）的信息。在实际中，存在很多不同类型的流程，设计者通常会创建流程相关的组件子类别，以利用流程类型方面的相似性。

　　尽管某些专家会首先标识数据相关的组件（他们认为这有助于以后标识流程相关的组件），但我们建议交叉进行这两个活动，随着设计的细化调整您最初的组件设计。

　　首先要将数据结构和序列映射到业务级别的概念。IBM Rational Software Modeler之类的建模工具相对于电子表格或数据库之类的简单工具有很大的提高，可帮助可视化软件关系和进行验证及其他类型的分析任务。注释或元模型的扩展可将您的模型链接到被分析的代码。这些模型中包含流程相关组件和数据相关组件的初始定义，会在定义组件时编辑这些定义。已完成的模型是将现有代码安排到组件中的蓝图。

　　开发人员可使用此蓝图来编辑组件中的包含代码。在某些情况下，组件外壳从模型直接生成；不过，可以始终根据模型手动创建组件外壳。要重用的代码将随后从应用程序源提取出来，并插入到组件外壳中。需要进行一些最后的编辑工作，以使此代码与组件外壳中已有的代码兼容，并与组件外壳定义的接口兼容。

　　这个过程还包含很多工作，远远超过此处的简单描述中提及的内容。要准备好进行大量的初期尝试。选取那些成功时将带来业务好处的组件化项目，但要避免复杂项目或那些对业务关键或将不允许进行试验（和出现错误）的时间紧迫的项目。听从专家建议并与类似项目协调进行总是有益的。请确保您了解所获得的建议背后的基本原理，并确实与您的目标相关。

　　您将发现流程相关组件会聚合（组装）其他数据和流程相关组件。这些流程相关组件的服务接口将成为面向替换旧应用程序的组件化新服务的接口。采用流程特定的语言（如业务流程执行语言——Business Process &#101xecution Language，BPEL）编写频繁发生变化的流程组件可能效率更高。由于BPEL可以比Java语言或COBOL更精简地描述流程，因此可以减少要更改的量。由于Java语言是一种支持快速更改/测试周期的解释语言，只要流程不是性能关键的，就比COBOL更适合用于此用途。

　　SOA项目通常包括大量新代码，用于添加之前由人工完成的数据集成和流程自动化任务；这些新代码应该符合组件化原则。可以采用BPEL、Java语言或COBOL进行实现，具体取决于项目的需求和可用的技能。

　　最佳实践

　　软件投资组合管理

　　SOA再工程项目中的第一步通常是对现有投资组合包含的软件和软件构件进行编目，标识彼此间的依赖关系。由于SOA项目的目标是让IT更灵活地实现业务流程，因此将构件与其支持的业务流程关联非常有价值。将构件链接到其开发历史（更改统计数据、开发投资、缺陷等等）可以指示SOA驱动的再工程的可能模式。尽管小型SOA试验项目可能不需要这个目录，但此最佳实践可为持续维护以及将来的SOA项目带来好处。

　　这个投资组合目录可以用于标识只能为业务提供很少好处或没有任何好处的软件。可以使用商业软件替换此类软件，或直接停止使用。此目录还可以标识必须进行再工程来实现项目目标的关键软件元素。例如，如果目标是减少呈现服务后提供帐单所花费的时间，则应对帐单编制工作流进行分析，以标识带来延迟的活动，并对其进行重新设计。例如，如果发现在关键批处理应用程序执行并产生所需的数据前，总体业务流程都处于挂起状态，则可以重新设计该批处理应用程序，以更频繁地运行。

　　投资组合管理目录可帮助IT管理人员和架构师确定在何处以何种方式分配开发资源，以获得最大的业务效益。IBM提供了非常适合此用途的Rational Portfolio Manager工具。

　　软件开发

　　研究表明，以下方面是软件开发和维护中开销最大的方面：变更分析、设计和测试。仅仅测试就可能花费掉应用程序维护周期预算的一半。对于现有应用程序，IBM WebSphere Studio Asset Analyzer(WSAA)和其他供应商的类似更改分析工具可加速分析阶段并减少错误。这些工具对源代码、作业控制语言（Job Control Language，JCL）、中间件配置元数据和其他构件的分析将被捕获在数据库中。如果现有数据元素发生了变化或添加了新数据元素，可通过查询此数据库来确定必须更改哪些源模块和数据文件。影响计数和数据项使用可帮助对开发工作投入进行估算。

　　更改分析工具可标识测试数据的更改以及不会检查任何已更改代码的无用测试，从而改进测试计划。还可以使用其他工具来根据测试集跟踪应用程序的测试覆盖率。

　　这方面的最佳实践是在普通应用程序维护周期中包含重构或组件化活动，与其他更改一起逐步引入更改。这个方法有时被称为就位再工程，可减少由于相应范围无控制地扩大或未预见到复杂情况而导致的风险。

　　现代的基于工作站的开发工具提供了最佳的效率，并支持各种编程最佳实践。集成工具可消除易于出错的步骤，如将信息从一个工具打印和复制到另一个工具。集成工具可帮助您将分析项目的结果（例如，受影响的源代码位置和数据文件的列表）传输到集成开发环境（Integrated Development Environment，IDE），而开发人员可以在IDE中访问和编辑源代码文件。使用过基于3270的开发工具的开发人员有时候不愿意使用IDE，但IDE工具具有更高的效率，只要掌握了，开发人员就会对此类工具非常满意。IBM WebSphere Developer for zSeries是一个面向大型机开发人员的IBM IDE产品，其中包括用于为现有大型机应用程序提供SOA支持的各种工具。WebSphere Developer for zSeries是IBM Rational系列IDE（特别是IBM Rational Application Developer）的扩展，包含IBM Rational Application Developer的J2EE组件开发功能。

　　经过重构和组件化的服务通常聚合到（隶属于）业务流程中。在IBM WebSphere Integration Developer等IBM IDE中提供了特殊工具，用于创建BPEL流程和企业服务总线的集成中介。WebSphere Integration Developer和WebSphere Developer for zSeries 一起构成了用于进行大型机SOA开发的完整IDE程序包。此外，WebSphere Developer for zSeries还包含用于简单集成（如CICS内的CICS事务序列化）的工具。

　　建模和分析可成为软件设计和再工程过程的不可或缺的部分。通过使用来自WSAA的信息，可以在Rational Software Modeler中构建软件体系结构模式。然后，可以将此模型用于分析潜在的软件更改。模型的后续分析可以说明为了进行这些更改所需的工作量和标识潜在技术问题。

　　IBM提供了一种新的编程语言，即企业生成语言（Enterprise Generation Language，EGL），并针对此语言提供了一个非常便于应用程序开发人员使用且支持SOA编程的IDE。此语言和IDE可简化程序员的任务，并指导其恰当应用SOA设计原则，从而提高工作效率。

　　问题确定

　　SOA应用程序是由多个组件组合而成的程序集。仍然可以使用调试器和转储分析工具等传统工具，但必须与专门为SOA应用程序设计的应用程序监视与管理工具结合起来，后者包括IBM Tivoli Composite Application Manager和IBM Tivoli OMEGAMON XE工具。程序集在组件接口上提供了额外的监视点。这些监视点可以提供更多的细节，从而加速问题确定和恢复工作。

　　防御性编码

　　组件开发人员很自然地认为，由于无法知道将如何使用他们的组件，因此应广泛地对输入数据、引用及产生的输出和引用进行检查。编写这样的组件将导致组件间重复的数据验证工作，从而使其性能弱于单独的应用程序结构。而且，由于开发人员认为组件可能会被最广泛的重用，其为组件的输入和输出签名选择的数据类型可能不能产生最佳的性能。在编写了此类组件后，可能在组件间传递数据时带来不必要的转换开销。例如，当客户机和服务均采用COBOL编写，且传输协议能传输二进制信息，则在COBOL数据和XML之间进行转换的开销就非常大——而且完全没有必要。

　　组件开发始终是在应用程序的服务要求的性能和质量与其组成组件的可重用性和通用性之间进行折衷的一个过程。通过考虑组件在应用程序结构内的主要使用情况，可以更为恰当地确定数据有效性检查的位置——例如，仅在受管理的信任边界进行检查。如果希望组件提供新的主要用途，请考虑这是否会创建新的信任边界和带来在组件外进行额外有效性检查的需求。为组件定义输入和输出数据签名时，也适用相同的原则；将其设计为在主要应用程序中能良好工作，仅在其使用发生大幅度变化时才对其进行更改。

　　SOA还包含更改组件的输入和输出数据签名的适配器；适配器能以很小的性能开销为代价将服务的客户机与其接口的更改隔离。

　　应用程序的组件体系结构

　　IBM与其业务合作伙伴一起已开始发布有关用于实现组件的设计原则、最佳实践以及开发工具的信息。这一组指导原则和工具称为服务组件体系结构（Service Component Architecture，SCA）（请参阅参考资料，以获得有关此主题的文章的链接）。尽管设计原则和最佳实践主要描述的是有关使用Java和J2EE的内容，但几乎所有这些原则和最佳实践都可以在大型机开发人员感兴趣的其他语言（如C、COBOL和PL/I）和中间件（如DB2、CICS和IMS）内部署的生成代码中实现。IBM正与行业协作者、软件开发组织和标准组织紧密合作，以便为其他语言和中间件定义SCA和服务数据对象（Service Data Object，SDO），并将在下一年中发布这些设计原则和最佳实践。应该将SCA和SDO用于所有新应用程序开发工作。SCA同时也是现有应用程序上的组件化活动的主要目标体系结构。

　　SCA将作为创建组件和应用程序聚合（可包含采用很多不同语言编写的可互操作组件）的设计基础。帮助进行此工作所需的技术组件现在已经就位。例如，IBM Enterprise COBOL for z/OS和IBM Enterprise PL/I for z/OS均支持XML处理，而Enterprise COBOL for z/OS提供了与Java进行互操作的新机制。Rational Application Developer和WebSphere Developer for zSeries提供了用于创建数据适配器的工具，以允许在Java和其他语言间传递复杂数据类型。为了进行技术演示，IBM发布了允许开发人员创建在IBM WebSphere Application Server for z/OS容器中执行的COBOL组件的信息。

　　结束语

　　SOA提供了各种工具、技术和最佳实践，用于利用在企业的现有软件投资中包含的业务逻辑。SOA允许采用新方式来对这些宝贵的现有软件资产进行重新组合，从而为您的业务设计产生更为灵活的IT实现，以适应不断变化的业务需求。SOA原则提供了现有再工程最佳实践的一个实用扩展，可同样应用于现有软件和新创建的软件。

　　关于作者
　　
　　Jim Rhyne是一名IBM杰出工程师，担任IBM zSeries中间件和工具的首席架构师，包括CICS、WebSphere Developer for zSeries、Enterprise COBOL for z/OS、Enterprise PL/I for z/OS和WebSphere Studio Asset Analyzer。他之前曾担任过WebSphere和IBM Component Broker软件的高级架构师。Jim是大型机软件现代化的倡导者，经常为IBM大型机用户、行业分析师和软件服务组织提供咨询服务。