IBM 内的 SOA 应用，第 1 部分: SOA 案例研究

COATS 与“盒子里的工厂”

文档选项

将此页作为电子邮件发送

拓展 Tomcat 应用

下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1
级别: 中级
Luba Cherbakov (lubacher@us.ibm.com), IBM 杰出工程师, IBM
2006 年 10 月 30 日
和很多其他企业一样，IBM 在对自身进行转换，以应对激烈的全球竞争和伙伴合作关系、实际的安全威胁、过多的日常需求、成本压力以及更高的灵活性和敏捷性要求。面向服务的思考方式和面向服务的体系结构（Service-Oriented Architecture，SOA）在此转换过程中扮演着重要的角色。
本系列将描述七个 IBM SOA 支持的转换活动，按照不同的业务价值主张进行划分——从法律法规遵从到更灵活的业务模型，再到通过消除重复系统和流程减少成本。对于每个案例研究，我们都将描述业务情况和挑战、有效进行转换所需的更改、SOA 支持解决方案和实际业务成果。我们还描述了所使用的最佳 SOA 实践、支持解决方案的技术以及所得到的经验教训。本文是本系列的第一篇文章，将详细说明 Customer Order Analysis and Tracking System (COATS) 和 IBM Microelectronics 的“盒子里的工厂 (Factory in a box)”。
人们对当前业务环境和正在发生的巨大变化进行了大量的讨论：来自传统和非传统对手的激烈竞争、不断变化的法律法规遵从要求、创造新收益来源的压力以及对更多创新和更高灵活性的要求。为了在这种环境中取得成功，各个企业正在进行转换工作，开始重新思考行业结构，准备实现组件化和采用面向服务的方法来实现所需的灵活性。
SOA 受到越来越广泛的接受，正逐渐成为支持此类业务转换的主要技术，可提供业务流程和启用 IT 支持之间更紧密的联系。虽然 Ron Schmelzer 和 Jason Bloomberg（ZapThink，2006 年 4 月，请参见参考资料）等很多分析家称 IBM 是其客户“面向服务的体系结构运动中的主要先锋之一”，但在过去数年中，IBM 本身也在进行 SOA 支持业务转换。
客户经常要求我们分享 IBM 内部的此类经验。在本文中，我们将简单介绍七个 SOA 案例研究中的前两个——真正的内部转换活动。后续文章将讨论剩下的其他案例研究。每个活动都已有了实际的业务成果，并提供了宝贵的经验和教训： 案例研究 1：Customer Order Analysis and Tracking System [COATS] 案例研究 2：Microelectronics“盒子里的工厂”[Microelectronics] 案例研究 3：Export Validation 法律法规遵从 [Export] 案例研究 4：Central Customer Master System [CCMS] 案例研究 5：IBM Intranet Password——内部应用程序标识管理 [IIP] 案例研究 6：IBM Intranet Password——外部业务合作伙伴应用程序标识管理 [IIPX] 案例研究 7：客户 Web 标识管理 [Web Identity]
 
我们专门精选了这些案例研究来代表利用 SOA 解决的各种业务挑战。其中一些挑战通常会出现在跨行业场景中，如第五、六、七个案例研究。其他案例（如第二个案例）是特定于行业的，其中也包含可由 SOA 成功处理的典型挑战。
那些仍然在问为什么应该考虑 SOA 的读者或需要为其采用创建业务用例的读者会发现，表 1 和每个活动的业务驱动因素的详细描述非常有用。
对于每个案例研究，除了业务上下文，我们还描述了活动必须克服的挑战、所得到的解决方案的体系结构概述及其支持技术和工具。我们还将描述每个活动实现的实际业务成果和我们所获得并在 IBM 及我们的客户中得到应用的最佳实践和“经验教训”。
在过去几年中，作者和 IBM 同事曾与数百客户协作，以实现基于 SOA 的解决方案来解决各种业务问题。虽然所有人都在谈论总体的业务灵活性和敏捷性，但每个活动通常都是由一个具体的业务价值主张（或希望的业务成果）驱动的。企业采用 SOA 来应对不同的业务挑战。希望的业务成果可以由下表中所示的多个类别进行表示。
业务价值主张 业务驱动因素
业务流程灵活性 快速对市场变化做出响应 改进上市时间
减少外部流程成本和周期时间 从手动事务过渡到自动事务 促进与业务合作伙伴的协作
减少风险和对外暴露程度 提高业务操作的可见性
法律法规遵从 符合政府强制要求 符合行业法规
简化系统集成 集成以前的独立系统 便于处理合并和收购的情况
降低成本 消除重复系统、技能和投资 一次性构建功能，方便重用 提高效率
成功的 SOA 实现可以实现多种不同的业务成果，而通常是由一个或两个关键驱动因素促成相关活动的。尽管通过服务重用实现的好处可以减少开发和集成的成本这一事实非常重要，但就长远来看，SOA 的业务转换价值却更为重要。
在以下部分中描述的 IBM 案例研究具有不同的预期结果（公司内部和外部），如表 2 中所示。
COATS Microelectronics Export CCMS IIP IIPX Web Identity
业务流程灵活性 X X - X - X X
减少外部流程成本和周期时间 - X X X - X X
减少风险和对外暴露程度 - X X X X X X
法律法规遵从 - - X - - - -
简化系统集成 X X X X - X X
降低成本 X X X X X X X
Customer Order Analysis and Tracking System 是供全球二十多个工厂使用的共享订单输入应用程序，每个工厂都具有自己的自定义需求和访问模式，如“高容量低价格”与“高价格低容量”。COATS 是 IBM Supply Chain 的一部分，在订单执行中扮演着重要的角色，可处理大量订单，帮助每天处理 10,000 个以上的包裹。COATS 提供全天候服务，可接受 IBM 客户、业务合作伙伴和 IBM 销售专业人士的复杂配置硬件订单：System i、System p、System z、Storage、Printers 和 Retail。
购买者通过提交有关新计算机、升级、定制的订单和对现有订单的其他更改来间接访问 COATS。应用程序会将这些订单与制造规则和客户已安装硬件库加以比较，从而进行排序和确定优先级。COATS 会将订单流“翻译”为制造材料列表（物料清单，Bill of Materials）和其他指令，这些内容通常被转发到全球相应的 IBM 制造工厂。制造工厂将随后开始执行订单，并运送到客户的收货地点。订单的一个例子是指定了详细规格、预装软件和交付日期等的大型机。对应的输出示例将包括特定工厂的制造车间的配置，而对应的相关术语包括物料单、配置计划等。
原始应用程序是已经使用了 25 年的复杂旧式批处理系统。其中包含 140 万行 PL/1、OS/390 汇编语言、Java 和其他编程语言代码，峰值时已非常接近其处理容量极限。批处理瓶颈和冲突数据对订购和配送造成延迟。
COATS 具有硬编码的业务规则、过程、逻辑和数据访问，已发展为难于针对现有和新兴业务需求进行调整的系统。更改业务流程通常要求进行大量的重新编码工作：开发人员必须理解一组复杂的点到点连接和组件独立性，以便预测变更的效果。为了应对不断发生的订单变化（包括调度系统为了满足客户的交货日期而进行的自动调整），必须对多个数据库进行更新和查询，具体取决于地理位置和其他参数（如所保留的五到十年的计算机销售历史记录等）。
为了支持新活动、新产品和业务机会，频繁地对应用程序进行了更新。由于采用了严格的遗留代码，花费了大量资源（时间和资金）进行新功能开发——每个版本的开发时间都要花费六个月时间，占用超过 8,000 小时开发时间。
存在这样的实际需求，需要提高对功能和驻留在现有遗留系统中的宝贵业务数据的访问，并要求能够从其他系统方便地进行访问。
和很多企业关键应用程序一样，大规模进行替换费用太高，且会带来干扰。
COATS 转换项目的重点在业务涉众认为非常重要的几个目标上： 降低应用程序更改或错误导致的生产停滞频率 降低由于 COATS 子系统间订单批处理方式的差异而导致收益损失的可能性 通过加速更新周期和允许以增量方式重写、更改和重新部署功能来更快、更简单地满足业务需求 允许通过建模和监视业务流程模型来进行业务流程管理。
 

订单管理组件服务项目负责将总体 COATS 系统转换为实时的订单提交系统。
解决方案的面向服务的体系结构（参见图 1）对业务流程和 IT 需求进行了标准化。在此体系结构中，业务规则被外部化，而遗留系统功能则被组件化，以便提高灵活性、可伸缩性和重用性。
Order Process Subsystem 负责接收处理客户订单组的请求，并随后将订单发送到其他服务。此系统能够处理多个通道，包括用于实时处理和批处理的 B2B 消息传递系统。
接收到订单后，Order Process Subsystem 将其标记为需要进行验证，并将订单转发给 Validation and Topology Generation 服务。该服务将进行分析，并为不同类别的订单使用专门的验证服务。
传递验证步骤的制造订单组将随后发送到 Manufacture Plant 服务，以转换为物料单，并转发给制造工厂。这些服务将通过服务适配器与实际向目标工厂交付物料单的现有遗留应用程序或业务合作伙伴应用程序交互。
开发过程将首先从支持 IT 系统中分离业务流程和数据。在 IBM WebSphere® Business Modeler（以下称为 Business Modeler）内对业务流程进行了建模和表示。
COATS 开发团队采用了迭代的方法进行此转换项目。迭代过程从使用 Business Modeler 进行业务分析开始，业务分析的目的是为了构建原始 COATS 应用程序中使用的“原样”业务流程的模型。获得了模型后，分析人员就能够确定进行改进的机会、提出更改建议，并能够预估更改对 COATS 应用程序的影响。此外，对“原样”模型的分析还能帮助标识现有资产，以供进行重用。
为了创建模型的“原样”版本并最终确定业务流程的规范，团队使用了业务涉众认为重要的项目目标来确定服务和组件。这些目标用于定义标识“原样”模型的各个领域的决策标准，以从转换到利用工作流和业务规则的灵活实现获得最大的好处。
为了标识和指定 COATS 业务服务，该团队采用了一种可重复方法，而这个方法后来促成了 IBM 面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）方法的形成。SOMA 是一种旨在通过从 SOA 基础标识、指定和实现与业务一致的服务来支持目标业务流程的方法。SOMA 将业务特征扩展到 IT 分析和体系结构决策中，从而创建了业务意图与 IT 实现间的连续体。SOMA 期间执行的分析和建模工作并不特定于技术和产品，而是要建立一个上下文，以便在生命周期的以后阶段进行技术和产品特定的决策。其目标是提供 SOA 建模（分析和决策）的指南。IBM 流程工程师和架构师将 SOMA 用于进行客户合作项目和内部项目。
在进行业务分析的同时，数据架构师使用了 Rational ® eXtended Development Environment 来定义基于统一建模语言（Unified Modeling Language，UML）的数据模型。这些数据模型表示 COATS 业务流程要使用的业务对象，用于在组件间进行通信。
开发构件——业务流程执行语言（Business Process Execution Language，BPEL）、Web 服务描述语言（Web Service Definition Language，WSDL）、XML 模式定义（XML Schema Definition，XSD）和 Business Modeler 与 Rational eXtended Development Environment 产生的基于 Java 的数据模型实现——都由集成开发人员通过使用 WebSphere Studio Application Developer Integration Edition 工具进行了进一步增强。开发团队使用了 WebSphere Studio Application Developer Integration Edition 来实现以下更改，以完成工作流实现： 通过创建到 MQSeries® 和 CICS® 的适配器来允许访问遗留系统 添加用于人工决策和异常处理的成员活动 将决策点重构到存储在外部 BRBean 存储库中的业务规则内 与 WebSphere Portal 表示层集成。
 
COATS 的生命周期扩展到了开发之外，包含业务流程管理的各个方面。开发迭代产生应用程序的可部署工作版本（应用程序的工作构建）后，业务分析人员可以通过跟踪关键性能指标（Key Performance Indicator，KPI）来监视系统的实时性能。KPI 是在实现工作流前由涉众定义的，可提供每小时通过系统的平均订单数量、系统处理的无效订单数量以及操作员处理无效订单的平均时间等交付信息，从而便于从业务的角度监视系统运行情况。最后，执行人员可以使用通过监视应用程序收集到的信息来进行业务流程更改决策，以满足业务单位性能目标。
应用基于 SOA 的新解决方案的若干增量版本后，提高了业务性能和灵活性。此外，也实现了减少开发成本和缩短开发周期的目标。业务成果简要总结如下： 订单事务处理时间从 4 分钟缩短到 10 秒。在 COATS 中，每天平均有大约 2,500 个请求（高峰时，每小时 300 个）。因此，节约了四分钟时间，总共节约的时间每天可能超过 150 个小时，所以在转换完成后，可以提高每天的订单处理速度。 这个解决方案简化了系统间的集成方式，支持可减少交付计划中的差异的实时事务。 能够通过简单的可选择规则对运行时工作流进行随需应变的更改。 新系统消除了开发流程中的冗余 开发周期中的这些改进意味着，IBM 能够更灵活地应对与其他订单执行流程相关的不断更改的业务需求 开发时间和成本节约超过 25%
包含了更好的错误处理工具，能够更快地进行异常处理，从而提高了收益。 在此工作期间，我们获得了大量可重用的开发资产和最佳实践。此活动帮助我们强化了 SOMA 方法（请参见参考资料）。
 
此活动帮助我们创建、实现和获得了将遗留业务功能以增量方式转换为实时而灵活且支持 SOA 的解决方案的方法。所用的最佳实践及获得的经验教训简要总结如下： 使用服务的增量实现获得早期的支持，通过对预期情况进行管理来实现无干扰迁移。与遗留代码服务共存，支持将系统功能逐步过渡到新体系结构。 通过服务建模保持业务/IT 体系结构一致。 要开发灵活的业务流程，需要在方法和工具的支持下考虑整个服务生命周期——从建模到监视。 遵循迭代设计和增量开发方法，采用建模、设计和集成模式（请参见参考资料）。 创建早期 BPEL 流程模型 不要包含活动细节——细节应该在用例中进行记录 创建业务流程模型的同时创建数据模型
 
我们通过恰当使用服务建模、增量开发方法、工具和中间件组件说明了如何进行增量转换。在此活动中确定的流程自定义、增量转换和遗留集成方法正在 IBM 和我们的客户中广泛应用。
通过阅读 developerWorks 系列文章“On demand business process life cycle”（请参见参考资料），可以了解有关如何构建可重用资产来转换订单处理系统的更多信息。
对公司的结构进行分解（划分）并允许将重点放在核心业务竞争力上的做法自然会导致协作生态系统的出现。制造行业首先发现了规范化和协作的强大力量，并使其达到了新的高度，随后这也在电子行业得到了广泛的认可（请参见参考资料）。
在这种协作生态系统中，半导体行业正逐渐从完全自包含的制造系统的垂直集成转向合作伙伴的集成参与网络，其中的每个合作伙伴均能以高效低成本的方式提供专业的制造服务。考虑到当今希望尽可能利用全球资源的经济环境，运营环境也迅速从关注本地力量发展到了关注来自多个国家的力量的全球协作。微电子行业产品解决方案的复杂性不断增加，以满足新客户需求，而这促使自定义解决方案出现了超过传统标准产品服务的势头。这就要求制造系统具有更高的适应能力，且要具有更广泛的执行能力，而这已不再能完全通过“内部”解决方案得以解决了。
2003 年，IBM Microelectronics 认识到需要更大的灵活性，以满足与跨多个场所和供应商的晶片和模块制造关联的不断变化的制造需求。对更高灵活性和响应能力（以获得“随需应变”的制造能力）的需求是虚拟制造企业概念的起源，此概念的重点在于跨多个微电子生产场所（内部的和已外包的）进行制造控制和执行的集成方法。
2000 年中期，IBM Microelectronics 遇到了与其他同行类似的挑战： 财务模型：尽管激烈的竞争正导致单个产品单元的成本和价格下浮，但与新产品相关的复杂性和成本却在持续升高。更复杂的解决方案还提高了计划、开发和制造流程的复杂性。当今半导体行业的高级需求易失性带来了高费用投资易失性。经常很难预测产品需求的快速波动和为之准备制造系统。必须对制造基础设施的投资进行策略规划，以与预期或非预期市场情况吻合。 领域集成：尽管现在主要的重点在核心竞争力，但半导体产品存在一定程度的的多样性，需要集成以前独立的制造系统。这个集成需求也适用于各个业务领域，如工程、企业资源规划、测试、机会管理、财务、产品发布、产品设计和开发以及信息数据仓库等。 外包：新全球化趋势提出了集成多个可互换的合作伙伴的需求。内部制造功能必须通过一次性构建功能并在以后加以利用，从而在操作停机时间尽可能少的前提下快速复制到外包供应商。这些供应商功能必须针对晶片制造、晶片测试、模块构建和模块测试等功能进行集成。所有参与者之间的通路必须可靠和安全，而且 IBM 必须能看到出现的所有事件，还必须能够收集产生的所有数据。供应商参与者必须接受 IBM 的一定控制，以获得一致的产品流程结果，而且必须能访问所有必要的功能——即使不是本地/本机环境也应如此。全球化的虚拟制造体系结构要求使用开放的行业标准来提高互操作性和尽可能减少合作伙伴采用 IBM 的接口所需花费的时间。
 
为了处理上述挑战，IBM 的 System Technology Group (STG) 半导体制造部门基于集成的模块化体系结构创建了一套解决方案。他们的目标是创建一个虚拟化框架来管理与高效外包计划并存的内部制造资源，从而形成了他们称为“盒子里的工厂”的新概念。这是一个全球的模块化制造功能“盒子”，包括网络传输、安全性、数据管理、监视、制造控制以及独特的自定义等功能。“盒子里的工厂”是通过将这些功能打包为一组 IBM 软件产品和自定义代码实现的，而这些产品和代码也称为多源数据集成器（Multi-source Data Integrator，MDI）。MDI 安装在 IBM 和供应商合作伙伴的厂区内（如图 2 中所示），以创建 STG 的各种制造业务领域与物理制造安装之间的无缝交互，而不受其位置限制——从而创建了一个虚拟化的制造环境。这允许将供应商视为 IBM 制造环境的扩展。

有人可能会问，“不错，这是一个很好的随需应变业务的例子，但 SOA 在哪里呢？”关键的 MDI 集成元素包括其企业服务总线（通过 Business Modeler Message Broker）和一组基于 SOAP 的自包含 Web 服务。Message Broker 除了完成路由任务外，还可在建立了 ESB 体系结构模式后通过协议和消息转换实现高度分离。有些服务是完全自包含的，仅支持内部 MDI 功能，对盒子外部的任何对象都是透明的。不过，其他服务则可以由 IBM 应用程序用户、供应商应用程序用户访问（有时候两者都可以访问）。正是这样将 SOA 功能打包为可移植的形式，从而使有些人将 MDI 的原始名称改成了“盒子里的服务 (Services in a Box)”。
服务示例： Wafer Die Disposition：各种与晶片制造及测试相关的功能。这些功能最初的目的是为了用于外包制造，但正越来越多地用于内部用途。 Manufacturing Execution System Transaction：为大量制造执行系统提供无依赖性的接口，允许查询制造批次状态和属性。 Module Disposition：支持涉及到模块制造和测试的各种功能 ULL Generator：支持基于规则生成特定于位置的唯一通用批次标签（Universal Lot Label，ULL）。ULL 服务通常针对每个独特的 MDI 位置进行了自定义，以使用位置特定的规则生成 ULL。
 
MDI 是在经过验证的 IBM 中间件和操作管理产品基础上构建的。这些产品包括 DB2®、WebSphere Application Server、MQSeries®、WebSphere Business Integration Message Broker、WebSphere Business Integration Connect 和 Tivoli Management Environment® for Monitoring。由 IBM Global Technology Services 将其安装在 IBM 和供应商的工作区内。供应商安装在 IBM 托管服务器上的非专用区域，可通过 IBM 远程通信访问，也可以通过供应商的防火墙由供应商访问。
体系结构解决方案的突出特点： 快速外包：一个由标准驱动的公共机制，用于和 IBM 内部及供应商制造工具进行交互，可以促进将 IBM 的制造工作有效外包。 “盒子里的服务”：一个全新的概念，允许在远程位置方便地传输和管理一组预定义的可配置服务。 外部化的业务规则：MDI 中的规则引擎已与操作代码分离，可提供灵活性，能在无需重新编码的情况下针对新业务情况进行调整。 “虚拟工厂”：受业务域（每个域都具有自己的一组流程和数据）间的技术隔离层框架支持的 MD 的黑盒实现。 服务：将新功能和遗留功能分解为可重用服务。
 
此解决方案为 IBM Microelectronics 创建了一个“虚拟”制造系统，涉及多个可互换的集成合作伙伴（供应商）——通过 SOA 实现的“盒子里的工厂”。
例如，Technology Group 将半导体测试工具外包给 Amkor Technologies，从而使得 IBM 系统在从 IBM 进行迁移的过程中仅停机四个小时，而在以前通常需要三天才能实现其新的支持 SOA 的体系结构。规则已更新到新工具的路由事务，而这个转变在很大程度上对普通操作是透明的。而这正得益于 MDI 的“盒子里的工厂”构造所实现的模块化技术。此外，这个“预先打包”的 SOA 体系结构现在可方便地完成外包计划，比针对每个新机会进行自定义更为高效。这就可以在数周前进行计划，而无需像以前一样需要三个月前就开始计划工作。
在此活动期间，我们获得了一些重要的经验教训： 业务域的虚拟化及与相关流程和数据的隔离形成了一个“隔离框架”，可实现域之间最佳的分离，从而实现了“虚拟工厂” 规则引擎中包含的外部化业务逻辑与主要操作代码和服务分离，允许更快地进行业务流程更新 可以使用工具 Beta 版，从而有助于为将来的项目定义工具需求 在启动项目前完成 SOA 试验项目可帮助更有效地发挥技术的作用，减少对项目计划的影响。
 
我们要感谢以下同事提供的观点以及通过提供案例研究经验报告而为撰写本文做出的贡献：Jim Doran、German Goldszmidt 和 Dick Panko。
IBM Technology Group 的一个核心团队定义了案例研究 2（Microelectronics“盒子里的工厂”）的策略、体系结构和实现。负责 IBM 内这个优秀的 SOA 示例的主要人员有 Steven Pike（体系结构经理）、Mike Maslack（策略专家）和 Dave Lutton（开发团队负责人）。
我们还要感谢很多 IBM 同事、顾问、架构师、开发和项目经理，他们开发和描述了本文中的创新解决方案，并花时间记录和共享他们得到的经验和教训——最佳实践和反模式。由于涉及人员太多，恕不一一提及。
学习
您可以参阅本文在 developerWorks 全球站点上的英文原文 。
在“Impact of service orientation at the business level”（IBM Systems Journal，第 44 卷，2005 年第 4 期）中，L. Cherbakov、G. Galambos、R. Harishankar、S. Kalyana 和 G. Rackham 说明了组件化和面向服务概念所扮演的重要角色。
ZapThink 提供了有关 XML、Web 服务和面向服务运动所带来的体系结构和组织更改的建议。
IBM Press Room 的IBM to Help Customers Focus on Growth Through Business Transformation 说明了用于帮助公司构建支持业务目标的功能并同时将拮据的 IT 预算解放出来全力应对增长机会的 IBM 服务。
IBM 红皮书Patterns: Service-Oriented Architecture and Web Service 说明了“自我服务和扩展企业”业务模式和“应用程序集成”模式可以如何用于着手开发实现使用面向服务的体系结构方法的解决方案。
“按需业务流程生命周期，第 1 部分: 为您的按需业务流程构建基础”（developerWorks，2004 年 10 月）提供了用于开发灵活的随需应变业务流程的方法。
“SOA 反模式”（developerWorks，2005 年 11 月）讨论了不同的 SOA 反模式；反模式用于描述会产生明确的负面结果的常见情况或解决方案。
请访问SOA and Web services 专区，以获得数百篇关于如何开发 Web 服务应用程序的文章以及入门级、中级和高级教程，您将大开眼界。
获得产品和技术
从 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 获得应用程序开发工具和中间件产品。您可以免费下载产品评估版，或者选择 Linux® 或 Windows® 版本的免费软件评估工具包。
讨论
developerWorks 博客——加入 developerWorks 社区。

 

Luba Cherbakov 是 IBM 杰出工程师和 IBM Academy of Technology 的成员，是 IBM Global Services 一位重要的技术领军人物。在使用面向服务和基于组件的方法进行企业体系结构设计和复杂分布式应用程序开发方面，她是一位得到广泛认可的专家。Luba 是一位重要的体系结构设计者，为很多客户行业提供了很多复杂的一流 IBM Global Services 解决方案。Luba 负责了 IBM 面向服务的建模和体系结构方法的开发。她编写并倡导使用参考体系结构资产、体系结构描述标准和网格计算产品。Luba 获得了 IBM 杰出技术成就奖。Luba 是 IEEE 计算机学会、Society of Women Engineers 和 ACM 的成员，拥有乔治华盛顿大学的计算机科学硕士学位，主修软件与系统，辅修人工智能与仿真。