本系列中的另外两个SOA实现将说明IBM Corporation如何使用SOA来部署关键业务服务。案例研究5讨论用于外部业务合作伙伴应用程序的IBM员工标识管理案例研究6讨论IBM客户与业务合作伙伴标识管理及IBM网站用户的授权。我们专门精选了这些案例研究来代表利用SOA解决的各种业务挑战。每个案例研究都说明了启用SOA的解决方案如何通过对流程和业务规则进行更广、更方便且更便宜（甚至跨组织边界）的更改，来帮助实现所需的业务灵活性。

　　引言

　　各个案例研究说明了IBM如何处理各种业务挑战（在其中利用了SOA来处理这些挑战），通过这些案例研究，可以帮助您了解如何使用SOA来处理您自己的业务挑战。

　　本系列的第1部分重点讨论了两个案例研究。案例研究1重点讨论客户订单分析。案例研究2重点讨论跟踪系统和Microelectronics“盒子里的工厂”。除了业务上下文之外，文章还描述了每个案例研究项目必须克服的挑战，同时还说明了所得到的解决方案的体系结构概述以及支持技术与工具。文章还描述了每个项目实现的实际业务成果和我们所获得并在IBM及IBM客户中得到应用的最佳实践和经验教训。

　　本系列的第2部分重点讨论了另外两个案例研究。案例研究3重点讨论帮助实现法律法规遵从性的Export Validation Service。案例研究4重点讨论Central Customer Master System。

　　本文讨论使用相同方法的其余案例研究。案例研究5讨论用于外部业务合作伙伴应用程序的标识管理。案例研究6重点讨论IBM客户与业务合作伙伴标识管理与IBM网站用户的授权。前两个部分中讨论的部分案例研究是特定于行业的。与这些研究不同，本部分描述的活动代表了经常出现的跨行业场景。

　　案例研究5：IBM Intranet Password External(IIPx)

　　案例研究5 讨论用于外部业务合作伙伴应用程序的标识管理。

　　业务上下文

　　随着IBM内部Web应用程序的增多，IBM员工必须管理多个ID和密码，因为每个早期应用程序都开发了自己独有的身份验证机制。20世纪90年代中期后，我们发现了需要为所有IBM内部Web应用程序采用单一的全球身份验证机制，从而为每个IBM员工提供单一的ID和密码凭据。IBM Intranet Password (IIP)功能是作为公用解决方案开发和部署的，目的是支持内部应用程序的标识管理。不过，IIP为每个IBM员工实现单个ID和密码的目标当时并没有完全实现，因为存在大量IBM员工用于进行其日常IBM相关工作的IBM业务合作伙伴网站和应用程序。这些外部的第三方供应商网站包括外包旅行预定、管理调查、退休福利与规划、辅导计划和IBM书店等。应用程序提供者对于其每个系统采用了独有的ID和密码方案，从而导致IBM员工仍然需要使用多个ID和密码才能访问他们的网站。

　　挑战

　　当IBM员工使用合作伙伴提供的业务应用程序时，他们需要使用每个应用程序实现的不同身份验证方案。每个业务合作伙伴通常为其网站的用户创建用户身份验证凭据（通常只是ID与密码的组合），各自建立了有效密码和密码过期的规则。IBM员工在执行与IBM业务相关的职能时，会浪费大量的时间记录和重置这些外部网站上的多个ID和密码。

　　由于各自采用了独特的身份验证系统，IBM合作伙伴必须提供足够的帮助中心覆盖，以处理IBM员工要求提供凭据协助的呼叫。此外，与身份验证管理解决方案和业务规则相关的开销成本必须通过IBM的合同费用得到补偿。

　　对跨多个合作伙伴应用程序的身份验证的需求变得非常明显了，需要能够借此提高员工的满意度和减少成本。为了管理IBM员工凭据的身份验证，有些业务合作伙伴要求提供IBM员工LDAP目录的副本并定期进行更新。为了维护IBM内部网络的完整性以及保护隐私，IBM无法在IBM外部共享员工数据或允许合作伙伴访问IBM内部网络来直接使用内部LDAP实例。问题的任何解决方案都受到已经存在的安全系统的约束。

　　需要能确保满足以下约束的解决方案：

　　·对现有应用程序的影响最小。要求每个业务合作伙伴执行实现新解决方案的主要工作并不现实。

　　·仍然可以使用这些应用程序的现有ID和密码。另一个目标是尽可能让IBM员工方便地进行过渡。

　　·对业务合作伙伴而言，该解决方案的实现需要相对简单。解决方案必须安全，但业务合作伙伴对需要自己进行大量工作和需要持续进行密码维护的解决方案不感兴趣。

　　基于SOA的解决方案

　　所得到的采用SOA的解决方案名为IIPx，如图1中所示。IIPx是一个身份验证实用工具，可使用IBM内部网ID和密码获得对外部Web应用程序的访问。IIPx基于早期部署的用于提供内部应用程序的员工标识管理的IIP解决方案的基础。

　　图1. IIPx体系结构概述
 
　　外部应用程序使用IBM提供的Web服务来验证 IBM员工的身份。此服务对令牌（经过数字签名的XML文档）进行验证。IIPx会在IBM内部IIP对员工进行了身份验证后创建该令牌。IIPx将使用内部目录执行本地LDAP身份验证。对用户的凭据进行了内部身份验证后，其浏览器将使用令牌重定向到外部站点。

　　以下是图1中所示的典型IIPx登录会话的详细描述。描述中使用的数字与图中的数字对应：

　　·IBM员工连接到业务合作伙伴网站。IBM员工通过包含供应商标识代码的链接导航到IIPx登录页。这在IBM内部网络（用w3指代）进行。此链接 通常为到IBM内IIPx登录页的按钮或URL。

　　·身份验证通过w3进行。

　　员工输入IIP登录凭据。此为IBM员工正常的内部ID和密码。
　　IIPx服务器将会像处理任何内部IBM员工的凭据一样验证IIP登录。
　　IIPx服务器创建包含基本员工信息的XML文档，该信息从内部IBM员工目录（在IBM内部称为蓝页）检索。此文档传递给供应商，以提供关于访问网站的员工的信息。
　　IIPx服务器为XML文档创建数字签名。此数字签名基于公用IBM主控密钥，此密钥仅在IBM内可用。
　　IIPx服务器生成HTTP重定向URL，其中包含已编码的XML文档和签名，服务器会将此URL返回给员工桌面上的客户机浏览器。

　　·传递身份验证令牌。

　　客户机浏览器根据重定向URL导航到第三方网站。
　　第三方从URL的变量中检索XML文档和签名。
　　第三方站点将签名和文档传递给IBM的IIPx Web服务（SOAP接口）。这个IBM承载的服务在外部网上向业务合作伙伴提供。
　　IBM IIPx外部Web服务验证文档和签名的匹配情况。这可确保密钥匹配，即来自IBM的登录和数据是正确的。服务返回确定信息。
　　第三方站点建立用户会话，信息量通过供应商的站点继续。

　　为了管理IIPx的实际部署，使用了增量式加载的概念。其理念是，在部署新功能的同时应用程序可以继续操作其现有身份验证功能。在较短的过渡期间，可以同时使用新旧两种IIPx身份验证。只有经过完全测试，才能关闭之前的身份验证。

　　增量式加载还保证所有应用程序不存在统一的退役日期。这样就使得业务合作伙伴能够确定对其应用程序和自己的工作负载可行的退役计划。增量式加载还能给IBM员工带来好处，让他们有更多的时间注意到对所有用户推出的更改。

　　业务成果

　　IIPx解决方案很快被大家接受，并从合作伙伴和员工收到了大量积极的反馈。这个新身份验证功能的引入几乎对员工是透明的。通过实现此服务，IBM实现了业务灵活性，可方便地添加新员工用户和从已建立的IBM机制内方便地管理ID和密码。IBM员工现在获得了更好的外部网体验，只需要记住一个ID和密码，而不需要执行特殊的步骤来调用这些由供应商进行管理的外部应用程序网站。IBM业务合作伙伴通过使用此服务节省了大量成本。业务合作伙伴并不需要为用户设置ID和密码，合作伙伴也不需要维护这些密码系统。

　　最佳实践及获得的经验教训

　　IIPx的实现对IIP实现了重用，而后者是一个经过了验证的IIP服务。此重用清楚地表明了SOA的灵活性。IIP在内部为IBM员工实现，用以访问内部应用程序。此身份验证模型和Web服务允许从IBM外部使用此功能，从而在不影响IBM员工目录的安全性和完整性前提下获得此功能的好处。

　　尽管IBM业务合作伙伴很快接受了此解决方案，但仍然需要花一定的时间对其各个解决方案进行转换。由于其计划、资源可用性和其他业务约束会导致一些延迟。不过，增量实现的概念让IBM业务合作伙伴能够在计划中定义可满足其需求的单独的无干扰转换过程。最终我们按应用程序逐个引入新功能，项目并没有具体的时间限制。

　　使用Web服务的SOA接口提供了用于员工凭据的身份验证的安全而准确的解决方案，不仅在整个企业内，而且还跨多个外部合作伙伴。此接口很难被欺骗，因为安全凭据传递给业务合作伙伴的方式非常安全。凭据是作为参数在URL上传递的。因此，业务合作伙伴将使用IBM外部网Web服务，实际上是让IBM验证这些凭据。此匹配让员工和业务合作伙伴都相信能正确标识员工并应向其提供被授权的功能和数据。

　　IIPx团队还对遗留应用程序使用了增量式加载，以实现无缝过渡。有些应用程序在采用IIPx前已经具有ID和密码系统。这些合作伙伴可以在开发完成时过渡到此方法，甚至允许在退役期结束之前同时使用新旧两种形式的身份验证。

　　最后，IIPx非常成功，因为它并不要求所有IBM员工仅为了访问供应商管理的IBM功能而获取新ID和密码。大部分IBM员工可能并不会认识到这些应用程序在IBM外的环境中运行，因为到业务合作伙伴的转换几乎是无缝的。这种几乎透明的新功能实现或迁移是大部分项目的目标，但通常却没有实现。

　　案例研究6：Customer IBM Web Identify——IBM网站和相关功能的用户的标识管理与授权

　　业务上下文

　　www.ibm.com域是IBM用于提供信息和与客户及业务合作伙伴进行交互的一组网站和相关应用程序。除了直接电子商务与招聘网站外，此域还包括业务合作伙伴可以在其中找到的关于制造、采购或配送的信息门户。

　　各种支持客户和业务合作伙伴的外部IBM网站要求其用户对每个网站采用独有的用户凭据（用户ID和密码）。要注册，客户和业务合作伙伴必须向每个外部站点提交实际上是多余的基本注册信息，如姓名、地址、电子邮件地址。尽管为独立的站点域（如 Software Developer Support）部署了一些公用身份验证和注册解决方案，用户仍然需要维护多个凭据才能访问各种IBM网站。此外，各个Web应用程序间还存在资源浪费，每个应用程序开发、部署和维护自己的用户ID和密码身份验证功能。这是造成客户不满意的原因，需要使用针对整个IBM企业的公共IT解决方案加以处理，与(IBM Intranet Password)解决方案类似。

　　挑战

　　为了确保安全地保护ibm.com domain中的信息，并仅交付给授权的人员，关键功能中始终包括身份验证系统。不过，随着Internet的发展，各个IBM Web应用程序开发团队在创建应用程序供业务合作伙伴和客户使用的过程中也创建了很多不同的密码模式。

　　当时并不存在针对外部用户的中央目录；因此，IBM Web应用程序无法共享关于其用户的标识和注册信息。IBM为IBM客户和合作伙伴部署的每个网页或应用程序都必须收集自己的身份验证信息。此外，每个应用程序要建立不同的用户ID和密码要求（如密码允许的字符数和类型）。这对用户来说非常费时，安装新应用程序的时间会过长。

　　需要公用的企业级解决方案来为每个客户和业务合作伙伴提供单一用户ID和密码，以登录到ibm.com域的任何Web应用程序。此解决方案还必须支持每个应用程序所有者分开管理应用程序访问权限。

　　由于很多应用程序具有自己的身份验证解决方案，因此业务合作伙伴已经具有了自己的注册用户。一个目标是将其中用户尽可能多地迁移到新系统中，并接纳已经存在的不同用户ID和密码的格式。理想情况下，外部用户不应必须注册，甚至不应注意到是新系统在后台管理身份验证。需要使用所得到Web Identify服务来在一个解决方案中支持所有这些需求。

　　基于SOA的解决方案

　　Web Identify(WI)系统向ibm.com应用程序提供关于用户的信息。该系统将用户概要信息收集在中央数据存储区中，并通过Web服务接口向外提供。概要信息包括标准元素，如用户名、地址、内容首选项、所感兴趣的领域以及营销权限等。此外，它还提供应用程序特定的数据。通过在集中的位置收集概要信息，可减少ibm.com的零碎视图，从而使得将来的Web个性化成为可能。

　　WI还提供了对身份验证服务的访问，允许应用程序对用户进行身份验证，并管理组与角色。

　　最后，应用程序可以通过WI系统共享会话信息，从而消除通过URL参数或Cookie传递信息的需求。

　　Web Identify具有加载流程，可供应用程序用于描述与Web Identify工具中的应用程序关联的角色和权限。Web Identity提供了基于LDAP的目录服务来支持应用程序管理员将用户分配到角色，以供应用程序用于管理用户授权。

　　使用Web Identify功能的步骤通过面向服务(SOAP)的接口执行：

　　·加载应用程序。
　　·设置用户ID和概要。
　　·用户登录到应用程序。

　　加载应用程序

　　此部分描述如何在WI中加载应用程序，以及批准用户访问请求的持续工作。每个应用程序分配一个或多个管理员来控制用户对其功能的访问。对于某些应用程序，管理员是负责管理其各自站点的IBM员工，在其他情况下，管理员是合作伙伴，负责管理公司员工的授权，以开发与合作伙伴进行交互的IBM网站中的应用程序。管理员与WI团队合作定义应用程序，包括应该对特定的应用程序设置哪些角色和访问级别。管理员将检查新用户的访问请求，并将其分配到与应用程序关联的特定角色。这样可允许用户获得对其需要使用的各种IBM应用程序的访问权限。

　　设置用户ID和概要

　　从外部用户的角度而言，WI网站允许他们为自己创建用户ID和密码。这之后，用户独立于其访问的应用程序维护其用户ID和密码。此外，网站还允许用户注册和创建基本信息概要（如姓名、地址和电子邮件地址），并声明其可能感兴趣的站点部分或IBM服务/产品。最初的时候，用户ID并不与任何特定应用程序领域相关，且没有任何权限。为了获得访问权限，用户将基于自己的需要请求对特定应用程序的访问，包括特定角色或访问级别。经过批准后，用户可以登录到特定的应用程序，并使用这些功能。

　　图2. Web Identity体系结构概述
 
　　用户登录到应用程序

　　以下是图2中所示的典型会话的描述。描述中的内容与图中从左到右的功能对应。

　　·用户可以访问ibm.com系统的功能，并使用Tivoli Access Manager(TAM)进行身份验证。TAM对用户执行身份验证功能，将接受或拒绝登录。
　　·用户的凭据通过身份验证后，会将会话传递给WI Adopting Applications，以执行相应的功能。
　　·WI Adopting Applications能够通过一系列调用和Web服务访问用户安全设置、概要和会话信息，从而使应用程序能够获取关于用户的特定信息。

　　身份验证与授权功能

　　WI提供用于在用户启动会话后检索用户的凭据和概要信息的服务。这些服务允许应用程序检索用户的基本注册概要信息以及向用户分配的应用程序和角色。这就允许应用程序收集关于每个用户的更为详细的信息来在任何ibm.com网站上自定义用户会话。

　　表1 显示了其中一些可用服务。

　　表1. Web Identity功能

　　业务成果

　　WI最初在1999年部署，已成功用于ibm.com应用程序。现有应用程序逐渐将其身份验证与注册功能过渡到使用WI。2003年将WI正式定义为了IBM公司的外部身份验证标准，此后我们加速了此迁移工作。

　　通过使用WI提高了客户满意度和效率，对应用程序使用者和应用程序开发人员及管理员也是如此。使用Web Identity系统的客户、业务合作伙伴和开发人员对这个改进予以了认可。

　　目前，可通过ibm.com域内1000多个网站访问的200多个应用程序都在使用WI。Web Identity内建立了超过350万IBM客户、合作伙伴和提供商ID。

　　从1999年开始，使用Web Identity所带来的累计应用程序成本节省估计已达4700万美元。在此期间，IBM已经在Web Identity的开发与部署方面投入了约1180万美元。

　　最佳实践及获得的经验教训

　　在Web Identity的开发与部署期间获得的一些主要经验教训有：

　　·概念验证（Proof of Concept，PoC）对应用程序的性能评估至关重要。WI团队注意到了这一点，成功地使用了PoC来了解和解决WI的原始性能问题。早期进行PoC对Web Identity的初始开发和部署有莫大的好处。
　　·WI团队认识到，应用程序范围的扩大可能具有潜在困难，因此将大量的精力放在了有效扩大流程的定义和文档编制工作上，其中包括处理现有应用程序的资金投入问题。
　　·WI首次发布时，已经存在很多用户ID和密码系统。为了尽可能减少对应用程序和用户的影响，我们将已有的凭据加载到了Web Identity中，从而允许用户保留其原始凭据，而无需进行修改。尽管并非总是能够这样做，但这样的确为很多用户提供了无缝过渡。

　　在ibm.com Web域中首次使用之后，WI被确定为正式的IBM内部开发标准。这对确保在IBM内全面采用WI工具是非常关键的一步。所有外部网站的开发项目都采用一致的方法，以确保正确标识其对外的网站应用程序的用户。

　　结束语

　　本系列文章说明了如何在六个IBM内部活动中采用启用SOA的解决方案来支持所需的业务与IT更改。所有六个活动都通过更快地引入新业务功能和优化业务流程实现了更好的业务灵活性。

　　这六个案例研究说明的重点是通过这些经验得到的常见业务挑战的确定方法和实现模式，这些东西目前正在IBM与客户项目中得到广泛重用。每个案例研究都说明了启用SOA的解决方案如何通过对流程和业务规则进行更广、更方便且更便宜（甚至跨组织边界）的更改，来帮助实现所需的业务灵活性。

　　作者简介

　　Geoffrey Meissner是IBM CIO office的一位执行IT架构师。过去两年中，Geoff致力于开展SOA+活动，大力倡导在IBM的很多内部应用程序中应用SOA解决方案。在担任此工作前，Geoff曾在很多内部组织担任IT架构师，包括公司安全部门、IBM Travel和技术研究院。Geoff还担任过Employee Services的开发与销售首席架构师，负责向外部客户销售呼叫中心解决方案。Geoff为SOA Community of Practice和Asset Architecture Board做出了贡献。他还是多个可重用资产的创建者。他是IBM高级认证架构师。
 
　　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的成员，拥有乔治华盛顿大学的计算机科学硕士学位，主修软件与系统，辅修人工智能与仿真。
 
　　Lance Walker是IBM CIO office的一名高级技术人员。他负责IBM的总体应用程序体系结构的应用程序体系结构设计。撰写本文时，他担任公司SOA+活动（负责加速SOA在IBM内部的推广）的PDTL和首席架构师，同时还担任IBM内部SOA指导委员会主席。此前，他曾负责其他CIO应用程序体系结构活动，如隔离层框架 (Isolation Layer Framework)。他在企业公共服务方面具有丰富的经验，曾担任首任 Web Identity（负责为IBM客户和业务合作伙伴创建公共用户ID和密码）的首席架构师，得益于这些经验，他能够很好地理解IBM内客户独特的业务需求和SOA实现约束。他擅长的主要领域有SOA、企业体系结构设计、加速Web服务的采用以及集成体系结构设计。他拥有丹佛大学的计算机信息系统与电信硕士学位和科罗拉多州立大学的机械工程硕士学位。他还是IBM认证架构师。