![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
很多年来，软件开发方面的发展主要是通过改进编程语言实现的。最近，这个重点开始转向了编程过程；例如，Java™ 语言消除了将经过编译的模块链接到一起的需要。SOA 是这个趋势所带来的最新创新。本文的目标读者是大型机软件开发人员和架构师，但也同样适用于其他环境（如 Linux® 操作系统）的前 SOA 软件。
组件化和组件组装是 SOA 软件设计中的关键部分。SOA 依赖于各种普遍存在的常见技术，如 Internet、XML 和 HTTP。它是由标准定义的，个人和大小企业均可采用此技术。该技术是目前用于应用程序构造的最佳方案。
SOA 在 IBM® SOA Foundation 技术白皮书（有关更多信息，请参阅参考资料）中的定义如下：
现在应该清楚的是，SOA 不仅仅涉及到技术领域。IBM 将 SOA 视为业务和 IT 部门间的全方位关系。SOA 包含用于捕获业务设计和使用设计信息帮助改进业务的各种工具和方法。它还包含用于在信息系统中实现业务设计的工具、编程模型和技术。它包含用于承载该实现的中间件基础设施。SOA 包含该实现的管理，从而确保其对业务的可用性，并确保在执行该实现的过程中高效地使用各种资源。它包含指定谁具有权威的机制和用于控制业务设计中的更改以及其在信息系统中的实现的过程。最后，SOA 可加快体现这些优势的价值。
其中的一些体系结构过程——特别是业务建模和业务流程设计——既可应用于大型机应用程序，也可应用于 Java 2 Platform, Enterprise Edition (J2EE) 环境和其他类型的应用程序。这可帮助将精力集中在专门为适应 IBM 大型机环境而设计的 SOA 实现工具、编程模型和技术。应该将本文作为其他有关各种环境（如批处理环境、IBM CICS®、IMS™ 和 DB2® 环境）的 IBM 大型机应用程序 SOA 支持的文章以及其他 SOA 开发主题文章的补充。
在不改变应用程序原有功能的情况下提供软件 SOA 功能的技术更改称为 SOA 支持。通常，SOA 支持这一术语并不适用于新软件的设计和构造。开发人员可能会择将 SOA 支持工作和应用程序的功能更改一起进行，但 SOA 支持并不要求进行功能更改。
SOA 应用程序设计可为 IT 提供很多优势。此处我们将特别重点讨论三个优势：
- 几乎通用的连接，可消除由于专用技术和中介（仅用于解决技术不匹配问题）所带来的开销和复杂性。
- 可通过在模型驱动的体系结构中良好工作的聚合进行构建，从而实现重用。
- 适用于大部分编程语言和运行时环境。
现代企业都在积极尝试抓住新市场所提供的各种机会，希望能够将效率提高到前所未有的程度。必须具有相当的灵活性才能抓住各种机会，而 IT 灵活性来自能够根据需要重新配置、修改和创建新软件的能力。效率的提高主要通过再工程和自动化业务流程实现。软件具有一定程度的延展性，可以方便地进行更改，以满足不断变化的业务需求。
从发明了存储程序计算机开始，设计和实现延展性软件就是一大挑战。虚拟化 ——将程序元素间的静态绑定替换为可以在操作期间更改的绑定，这是延展性的一个关键方面。不过，应该在高性能计算环境中小心使用，以避免其影响性能和资源使用。
我们已经了解到，要对软件进行恰当设计，以将流程序列逻辑、策略、基本计算、人机接口和数据管理分离开来。之所以进行分离，是因为序列逻辑和策略经常受到业务操作方面的更改的影响。将其他方面（用户界面和数据）进行分离可将应用程序软件从数据存储和用户界面（User Interface，UI）首选设置中的技术更改（包括从门户设备进行访问）隔离开来。绑定这些独立元素实际上就灵活地允许这些元素快速地分离并以不同的方式重新进行联接。例如，可以在不停止策略所属的整个软件进程的情况下删除并替换该策略。
软件组件的构造（无论是处理序列逻辑、策略、基本计算、人机界面或数据管理）都可以通过重用提高效率。它还避免更改多个软件模块的需求，从而提供跨多个业务流程的一致性和简化维护工作。
重用是一个发现过程，只要在新场景中采用共享组件，就会继续此过程。组件将通过积累各种功能自然地得到发展，并同时保留所有旧功能，以面对客户机进行再工程的麻烦。不过，应该定期对组件进行再工程和重构。尽管这通常可以在不影响用户的情况下完成，但在再工程和重构将影响组件用户的情况下，必须能够标识这些组件用户。
在 SOA 中，组件具有使用 Web 服务描述语言（Web Services Description Language，WSDL）描述的服务接口。组件的 WSDL 描述该组件提供的服务和该组件所需要的服务。WSDL 是一个 Web 服务互操作性标准。如果 WSDL 描述匹配，服务提供者就可以连接到服务请求者。这就允许两个组件进行信息交换。
现代大型机出现在 1964 年。它迅速成为了企业计算的主流，并不断发展，始终保持着这个地位。令人惊讶的是，40 年前编写的应用程序代码今天很可能还在大多数大型机环境中运行。目前可能有数百亿或数千亿行的 COBOL 代码在使用，其中很多最初都是在 20 世纪 70 年代和 80 年代编写的。这些应用程序中包含实现有价值的业务过程、计算和策略的逻辑。大型机环境的 SOA 支持包括用于发现这些逻辑并使其具有可重用性的各种实践、体系结构模式、工具和中间件。
IBM 大型机具有高度的可伸缩性，可以每天执行数千万个事务。它们还经过了高度优化，处理器和 I/O 利用率可超过 90%。其可靠性非常高，即使万一出现故障，也能快速恢复，且几乎没有信息丢失。系统配置支持故障转移和灾难恢复，而主系统和备份系统可以放置在距离很远的两个位置。IBM 大型机及其主要应用程序承载环境具有独一无二的可伸缩性和可靠性。这些是大型企业中的关键 IT 的持续操作所必需的特质。IBM 大型机通过各个领域不断的技术创新实现了这些特质，这些领域包括硬件虚拟化、故障转移、自我诊断、大范围共享内存多路处理和远程资源共享等。其中很多技术创新都在中型服务器中得到了应用。企业环境的 SOA 的设计也具有这些属性，可以在不降低效率和服务质量的情况下实现重用。
为企业实现 SOA 要求考虑三个重要的注意事项：
- 应用程序中的更改，包括现有应用程序的再工程和要创建的应用程序中的设计更改
- IT 技能的更改
- IT 基础设施中的更改（硬件、系统、中间件和通信）
尽管本文的重点是应用程序更改，但要记住，SOA 支持项目的成功依赖于所有三种类型的更改。最新版本的硬件、系统、中间件和通信——特别是虚拟化、软件管理和通信——均经过精心设计，能满足 SOA 最佳工作所需的条件。最好在开始 SOA 项目前对 IT 基础设施进行编目，并更新对项目的成功非常关键的设施设备。另外，对可用技能进行编目，并安排培训。有时候，可以要求服务供应商（如 IBM Business Consulting Services）进行一个概念验证项目，并让 IT 人员参与其中，以从中学习所必需的技能。
SOA 技能对于 SOA 系统的初期实现和维护非常必要。企业中的所有组件开发人员——包括 COBOL 语言开发人员——都必须进行 SOA 设计，因为组件的可重用性受限于设计者和实现者对组件服务的可能重用方式的预见。应用程序架构师（包括负责现有应用程序的架构师）也必须了解并使用一项新的 SOA 技能，即集成设计，其中包括组件组装、流程自动化和数据集成。
对于大多数企业，实现 SOA 的过程是漫长的，要通过能提供短期价值和长期价值的增量更改来完成。很多 IT 组织（特别是在金融服务和保险行业中的 IT 组织）都已经开始增量型开发项目，以在其部分现有软件投资组合中实现 SOA 支持。他们的经验表明，即使最低程度的 SOA 支持，也能使应用程序集成、流程自动化和快速软件重新配置变得更易于实现。
我们建议将 SOA 支持作为增量更改过程的一部分进行规划，而不要将其作为所属交付内容要替换现有系统的独立过程。较大的替换项目风险很大，开销也很大，只有现有系统不再能满足业务需求时才能进行。这其中的原因包括所带来的成本、项目进行过程中会变化的要求以及当前实现的干系人的反对。相反，增量式 IT 基础设施更改则是通常采用的方法，几乎不会造成中断，而技能和应用程序结构方面的更改通常也可以方便地通过增量方式完成。
我们的讨论集中在 SOA 如何提供两种类型的价值：访问和重用/灵活性。新的 SOA 应用程序将同时体现这两种价值。为其添加 SOA 支持的现有应用程序通常采用以下模式之一：
- 包装——现有应用程序及其现有接口不加更改地附加到提供一个或多个 SOA 接口的网关。此模式可提供访问，但并不能提高重用或灵活性。
- 重构——修改或扩展现有应用程序，以提供更适合将其作为服务使用的新接口。此模式可提供服务和一定的重用/灵活性。
- 组件化——现有应用程序被分解为组件，然后对这些组件进行重新组合，以促进重用，并将以前不可访问的功能作为服务操作公开。此模式可以提供最大价值的访问和重用/灵活性。
这其中的每种模式都具有优缺点。通常，IT 组织会首先尝试采用包装模式来获得低成本访问。如果包装模式的操作成本较高，IT 将对使用频繁的应用程序进行重构或组件化来提高性能。重构或组件化的一个相关动机是，为了公开以前只能通过需要与公开的服务不直接相关的信息的复杂对话框进行访问的应用程序服务。
接下来让我们对每种模式进行详细分析。
大型机应用程序的包装在客户机/服务器时代就开始了，已是一项具有成熟技术支持的成熟做法。WebSphere® Host Access Transformation Services（以下称为 HATS）等 IBM 网关产品支持包装 3270 和 5250 应用程序。HATS 最近经过了增强，可提供 Web 服务访问。最新版本的 CICS 提供通过 Web 服务的直接访问。此功能与可链接的 3270 网桥和访问流运行时功能一起使用，可以将 CICS 基本映射支持（Basic Mapping Support，BMS）应用程序作为 Web 服务发布。IMS 使用支持通过 IMS Connect 软件连接的 Web 服务的 J2EE 应用服务器来提供类似的功能。
大型机应用程序可能设计为具有一个终端接口或消息接口。有时候同时具有这两种接口，并将 UI、代码和业务逻辑分离开了。CICS 和 IMS 应用程序的一个最佳实践是将 3270 UI 支持从业务逻辑拆分出来，然后使用消息接口实现这两个层间的耦合。这个设计原则与模型/视图/控制器体系结构有些类似，但却是独立出现的。它将 UI 中的更改与业务逻辑中的更改隔离开了，让 UI 在经过优化、可获得最佳 UI 处理效率的独立容器中执行。
设计 SOA 访问时，3270 接口的两个限制尤为突出。
首先，在每个事务中，请求和应答均不能包含超过 1,920 字节的信息。更大的传输需要使用多个事务，添加路径长度和资源使用。例如，搜索 John Smith 的查询事务中可能会返回数百个客户。如果第一个 3270 屏幕（仅一次显示 15 个客户）并未显示正确客户，操作员则要请求后续屏幕，每个请求都是一个新事务，会带来 CPU、I/O 和内存开销。一个更好的接口（尤其是程序间的通信）将一次性返回所有 John Smith 记录。
其次，3270 终端是对话型终端。这意味着对于每个已登录的用户都有一堆大型机资源与其关联，甚至空闲终端也是如此。此外，某些较老的应用程序编写为缓存特定中断请求的信息（如名为 John Smith 客户的完整列表）。虽然此类应用程序代码可提供 show the next 15 customers named John Smith 类事务的性能，但却对其他系统特征造成了负面影响。此类应用程序的用户无法更改终端，或者临时从应用程序断开，中间件无法进行负载平衡，系统无法管理信息缓存，不能在用户思考时或不在时将缓存交换出去来检查内存使用量。
更大的消息允许每个事务中包含更多的信息，能减少开销和提高响应时间。大型机中间件（如 CICS 和 IMS）支持在消息接口中每个事务包含多达 32KB 的消息。当应用程序的 UI 逻辑和业务逻辑拆分开时，SOA 支持通常可以在业务逻辑的消息接口上应用，而完全忽略 UI 代码。此中间件最近的版本已经开始支持更大的消息；不过大于 32KB 的消息要求对应用程序进行更改。
这就引出了下一个模式：重构。
重构模式的目的在于向现有应用程序添加消息接口——通常为 SOA 接口，适合作为服务使用，使用 WSDL 进行描述。该接口必须采用不同的方式实现，具体取决于用户类型和性能需求。重构模式要求进行少量的应用程序更改，可以作为实现完全组件化过程中重要的一步。
重构通常是在不对应用程序进行重新设计的前提下完成的。
可以在 UI 和业务逻辑间引入一个消息接口。此方法可能比较复杂，但能在性能、可重用性和灵活性方面得到很大的提高。
或者，可以复制和编辑现有的应用程序代码，同时保留最初的 UI 和业务混合的情况。这就要添加所需的功能，但并不对原始代码进行大幅度修改，成本和风险可能更低。
可以在重构项目中处理多个软件设计问题：
混合 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 Execution 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 原则提供了现有再工程最佳实践的一个实用扩展，可同样应用于现有软件和新创建的软件。
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- 获得有关本文中讨论的 IBM 产品的更多信息：
- CICS Transaction Server for z/OS V3.1
- DB2 Universal Database for z/OS
- IMS
- WebSphere Message Broker
- WebSphere Developer for zSeries
- WebSphere Studio Asset Analyzer
- WebSphere Integration Developer
- 了解关于 IBM SOA Foundation 的更多信息。
- 了解 IBM 服务组件体系结构(Service Component Architecture)。
- 访问 developerWorks SOA and Web services 专区，了解这个快速发展的领域的更多信息。
- 访问 Safari bookstore，浏览有关这些技术主题以及其他方面的书籍。
获得产品和技术
- 下载以下 IBM 产品的免费试用版：
- WebSphere Application Server for z/OS
- WebSphere MQ
- WebSphere Host Access Transformation Services
- WebSphere Business Modeler
讨论
- 参与论坛讨论。
- 通过参与 developerWorks 博客 加入 developerWorks 社区。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。