Safeco是一家保险公司，总部位于西雅图，提供汽车，房主和小型企业保单。 当客户提出索赔时，Safeco为其提供个性化的服务和支持而感到自豪。 Safeco依靠庞大的独立代理商和经纪人全国网络来帮助客户确定其最佳覆盖范围。 代理商调查一直将我们基于Web的销售和服务平台定位为行业的领导者。 该平台是在.Net和后端的旧IMS应用程序上开发的。
在2006年初，Safeco开始开发面向服务的体系结构，以在两个战略领域为业务提供支持：新产品开发和业务流程改进。 从IT角度支持这些团队的任务具有挑战性，因为通常在不考虑部门或系统边界的情况下指定新产品，解决方案和改进。 此外，我们需要显着提高提供解决方案的响应时间，以满足市场和财务目标，同时降低实施成本。
面向服务的体系结构简介
面向服务的体系结构非常适合满足转换和敏捷性方面的这些目标，因为SOA提供了一个新的可重用性模型，该模型可以通过重用和扩展现有资产来构成和构建新解决方案。 如今，分布式技术（尤其是Web服务技术）所实现的性能，可伸缩性，可靠性，安全性和互操作性，使IT资产的运行成本最低的地方都可以重用。 传统上，IT经常将大部分预算用于复制资产（数据或代码），并针对每次发生的更改保持同步。 这种新的范式相当于信息系统的标准化，这是逻辑上的而非物理上的。 这种标准化是通过一种新型的软件代理，服务来实现的，它们提供对特定数据或业务功能的访问。
但是，SOA远远超出了服务的概念，它得到了完整的应用程序模型，复合应用程序模型的支持，其中（图1）：
- 所有传统操作都是形式明确的边界明确的活动，无论是用户交互，服务调用还是整个过程。
- 这些活动变得松散耦合（即，它们不在相同的技术或调用堆栈中，在相同的安全性授权下，通过它们之间的专用连接运行）。
- 新的组合技术使服务组合能够执行协作复杂的业务功能，作为企业业务流程的一部分
图1在SOA中，应用程序的传统方面变得松散耦合
面向服务的体系结构中的根本范式转换涉及将现有应用程序转换为带有服务接口的“记录系统”，该接口实现Act，Record，Inform和Compute类型的活动。 这种转换成功的关键因素是从记录系统中捕获的业务对象的内容外部化业务流程实例的状态。 服务通常是“上下文”独立的，即，它们对消费者为何在特定时间调用它们的了解尽可能少。 服务实现的作用是几乎完全作为纯数据访问层来执行记录完整性的系统。
这些服务用于实现特定目标的使用上下文由业务流程层管理（图2）。 通常，面向服务的体系结构将依靠业务流程引擎来执行此功能。
一旦将应用程序模型的各层松散地耦合在一起，就可以更轻松地部署业务活动监视（BAM）基础结构，该基础结构监视跨消息流的事件（特定状态的发生）。 某些BAM基础结构甚至可以帮助关联复杂消息流中的事件（复杂事件处理）。
图2 SOA应用程序模型
技术选择
在此项目的上下文中，Safeco选择了Microsoft Windows Communication Foundation作为企业服务层，选择了IBM WebSphere Process Server作为过程层，并选择了ASP.Net作为表示层（图2）。
WCF是迄今为止最好的服务容器之一。 微软是第一个进行创新并为服务容器提供与技术无关的编程模型的公司：用.Net编写的相同代码可以部署在各种分布式技术中，而不仅仅是Web服务。 WCF是Service Factory的补充，Service Factory是一种向导，它使开发人员可以轻松地创建完整的服务项目，从合同定义（首先是WSDL）开始，或者从一组将暴露一系列操作的类（类第一）。 Java随后跟随WCF的领导，并在类似的地方开发了新的组件模型（SCA）。 任何Java代码都可以使用在部署时选择的各种分布式技术来调用。
SCA通过“组装机制”增强了这种新的编程模型，该机制使集成开发人员可以按照依赖项注入模式快速组装Web服务和异构组件（用Java，C ++，BPEL等编写）。 SCA的汇编机制提供了一种可行的替代方法，可以在运行时使用注册表将调用路由到逻辑端点而不是物理端点。 任何给定装配的中间件技术都是在装配时选择的，而不是在组件开发时选择的。 IBM WebSphere Process Server是基于BPEL的引擎，它支持SCA规范的早期草案。 Process Server不是“精通业务”的业务流程引擎。 它是一个以流程为中心的集成平台，可以使用在WebSphere Business Modeler中建模的业务级流程定义。 这样，它就可以组装通常由集成开发人员而非业务分析师实施的复杂解决方案。
之所以在表示层级别选择ASP.Net，主要是因为Safeco在这项技术中拥有大量的开发人员。 其他选择可能会在不久的将来影响我们的标准表示技术。 但是，我们希望面向服务的体系结构将始终使我们有机会选择最合适的交付机制来支持任何给定的用户交互。
Safeco的SOA卓越中心
作为企业体系结构小组的一部分，我们创建了一个SOA卓越中心，其中包括来自交付组织的领域和解决方案架构师以及开发人员，QA和业务分析师。 选择该模型是为了将我们训练有素的资源保留在同一小组中，以便能够一起执行一系列项目。 随着时间的流逝，我们期望卓越中心模型将被我们组织中为任何给定项目带来专业知识的小型SOA组所取代。
图3. Safeco的SOA卓越中心
但是，将来会保留一个小型的卓越中心，以支持方法论，标准，治理流程和管理服务注册表。 该核心小组的主要目标是在设计时建立最佳实践，以最大程度地提高服务的可重用性。
案例分析
问题域 ：所有“报价和签发”和“续签”过程均要求我们将客户的事件（机票，事故等）声明与他或她的机动车登记（MVR）记录相匹配。 由于获取这些记录会产生成本，因此实际上我们在处理过程中相当晚才订购MVR记录。 使问题复杂化的是，美国一些州能够“实时”提供记录，而另一些州则提供夜间批处理提要，其中包含几乎在任何给定日期订购的所有记录。 该项目的目标是创建一个企业组件，该组件可以通过将MVR记录与策略记录进行比较来处理所有匹配的请求。 将来，此组件将在所有报价和发行以及续订过程中使用。
我们还负责自动化针对Q＆I销售和服务平台不支持的批次状态进行的手动验证过程。 验证单元执行的MVR处理的当前状态包括手动处理以及在单独系统中的多个屏幕导航，以手动执行对帐。 此外，当前的手动过程可能会基于MVR记录的工作顺序在策略上创建多个背书，例如该策略上需要更新MVR信息的两个驱动程序的情况。
图4.当前批状态的MVR验证过程
在此过程中，客户可以在Safeco代理商的帮助下签署政策。 如果客户具有批处理状态的记录，则在根据客户提供的信息发布策略时订购MVR记录。 在几天之内，记录将通过批处理文件发送给我们，客户服务代表将手动查看记录和保单信息，以确定是否需要对保单重新定价。 在这种情况下，将更新的策略发送给代理和客户。 大约35％的MVR记录与策略信息匹配。 匹配逻辑是复杂的，并且受各个国家监管。 培训企业社会责任以学习所有业务规则的成本很高。
这种逻辑的复杂性经常会引起质量问题。 此外，策略可能具有多个驱动程序。 过去，这对保单产生了多次更新，并可能对保荐人进行了多次重新定价或转介。 匹配服务设计中的关键要求之一是在同一策略上支持多个驱动程序。
解决方案概述 ：该项目非常适合SOA。 这将使我们能够重用其中一个旧版应用程序中已经实现的某些逻辑来开发企业级匹配服务。 基于流程引擎的解决方案将是围绕MVR对帐流程快速开发自动化基础结构的好方法。 我们的解决方案旨在在找到匹配项时直接更新策略记录，并提供匹配报告，其中包括我们CSR的所有策略驱动因素。 CSR最终将使用旧版应用程序对这些策略重新定价。
图5预期的MVR验证过程
深入分析：MVR对帐解决方案
在该项目之前，我们的SOA业务分析师接受了3个月的培训，在此期间，他和其他人开发了IBM流程工具（WebSphere Business Modeler和WebSphere Integration Developer）的工作知识。 他开发了一个原样模型和一个将来模型。 一旦我们对未来模型感到满意。 业务分析师执行了To-Be流程的模拟，假设35％的记录匹配率无需进一步验证，并且基于匹配服务直接提供的匹配报告，验证时间更短（与MVR记录相比，MVR记录通常是秘密的）以及代码因州而异）。
通过此分析，我们发现有必要开展一项人工任务，该任务将工作项目作为验证报告提交给我们的CSR。 从验证报告中，企业社会责任人员将拥有更新我们的政策体系所需的信息。
导入了To-Be业务流程以创建流程的初始BPEL实施。
解决方案中有两个主要服务：MVR记录匹配服务和Policy服务。 该解决方案使用了getPolicy，updatePolicy和matchMVRPolicy操作。
图6. MVR解决方案技术架构
每天都会在我们的旧版系统之一中上传MVR文件（图6）。 每天早晨，WebSphere Message Broker处理此文件，并调用我们的Process Server实例为由MVR记录标识的每个策略创建一个业务流程实例。 对应于同一策略的不同驱动程序的所有记录都合并到相应的策略流程实例中。 处理完文件后，将触发每个流程实例以调用getPolicy操作，然后调用matchMVRPolicy操作。 此时，MVR记录是流程实例上下文的一部分，不需要存储在其他位置。 如果存在匹配项，则BPEL实现将调用updatePolicy操作并终止流程实例。 否则，将实例化工作项，并在流程实例上下文中等待，直到用户声明任务并完成任务为止。
深入研究：流程建模，仿真，执行
过去，业务流程引擎供应商和业务流程标准（例如BPEL或BPML）都吹捧使业务用户能够对流程进行建模的功能，该流程可以直接部署到引擎以执行该流程。
我们的经验是，此操作不像某些人所表达的那样无缝。 但是，在启动SOA计划时，我们没有特别的期望。
图7.模型驱动的优势
我们已经体验到某些过程比其他过程更能支持这种范例。 由于MVR流程的本质（驱动程序合并，用于服务调用的特定业务逻辑...），业务视图和生成的BPEL明显不同。 我们已经处理了其他业务流程，从业务角度来看，生成BPEL的过程要简单得多。 根据经验，无论哪里“ BPEL实现中嵌入了系统调用逻辑”，我们都希望差异很大。
向下钻取：MVR记录合并
在此项目中，关键是将属于同一策略的不同驱动程序的记录一起处理，以避免对策略进行多次更新以及向代理和客户的通知。
这是在支持MVR解决方案的BPEL定义中直接实现的。
图8. MVR记录合并的BPEL实现
当Process Server收到新的MVR记录时，第一个活动将启动业务流程实例。 作为processMotorVehicleReport操作中接收的一部分，我们建立必要的关联集，以将具有相同策略编号的其他MVR记录定向到此新流程实例。
BPEL继续进行while循环，该循环接收与此流程实例相关的其他消息，或者在批处理文件处理完成后超时。 收到所有记录后，将对其进行处理。
深入研究：Microsoft / IBM互操作性
由于我们选择了异构平台，因此我们不得不正面应对互操作性。 我们内置在ASP.Net中的表示层调用Process Server服务来声明人工任务，而Process Server调用WCF服务作为流程实现的一部分（图6）。
只要您知道每个堆栈的哪些设置都可以互操作，我们就认为互操作性相当好。 当前，WebSphere Process Server只能与基于以下内容的WCF的basicHttpBinding进行互操作：
- HTTP 1.1
- MTOM
- WSDL 1.1
- SOAP 1.1
- WSS SOAP消息安全性1.0
- WSS SOAP消息安全性用户名令牌配置文件1.0和X.509令牌配置文件1.0
这意味着无法利用WCF的最高级功能，例如WS-Policy或SOAP 1.2的使用。
我们还遇到了与每种产品处理名称空间有关的问题。 WCF采用服务视图，每个服务工件都位于特定于服务的名称空间中，而Process Server采用服务层之上的业务对象视图。 因此，如果策略服务和Matching Service共有一个策略模式，则该特定策略模式必须在WSDL级别上共享，因为业务流程定义中只有一个策略模式。 我们必须调整WCF生成的命名空间，以使结果WSDL可被Process Server消耗。
这是Web服务技术的一个普遍问题，因为没有特定的“业务对象模型”来表示作为服务调用的一部分交换的资源。 每个供应商都可以自由采用可以更好地代表其产品线或客户群的方案。
深入研究：安全互操作性
描述Safeco的安全基础结构超出了本文的范围。 在互操作性方面，我们探索了多种安全机制组合，以支持身份验证，完整性和机密性功能。
Web服务安全性基于基于消息的安全性的概念：消息的SOAP信封以明文形式发送，但是SOAP主体以加密形式进行传输。
在WCF方面，可以通过多种方式实现基于消息的安全性。 但是，在各种环境下如何支持它有多种变体。 一些较常见的形式是：
| 捆绑 | 凭证类型 |
| basicHttpBinding | 证书 |
| basicHttpBinding | 通过证书加密的用户名 |
| wsHttpBinding | 用户名 |
- 证书身份验证：除了通过加密提供安全性之外，WCF还支持使用客户端证书作为识别客户端的方法。
- Windows身份验证：通过有效地跨服务边界传递“ WindowsPrinciple”来完成。 然后，基于WCF的服务可以模拟客户端，以便它们在客户端身份的特权上下文中运行。
- 用户名令牌身份验证：“用户名令牌”提供了一种机制，用于在客户端身份与服务环境中的有效Windows身份不对应时，将客户端身份传输到服务器。
值得注意的是，在我们的项目中，我们能够实现安全性机制的100％可配置性，即我们所使用的机制没有代码依赖性。 可以在部署时配置安全设置。
Process Server和WCF之间实现了数字签名和加密的互操作性。
我们遇到了一个小问题，这是Oasis发布的非规范勘误的结果，但并非所有人都遵循。 微软没有实施勘误表，IBM实施了勘误表。
结果，请求消息包含以下密钥标识符名称空间：
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3SubjectKeyIdentifier" >
lptrlv+cM5o0L2B954iFCDANFD0=
X509v3SubjectKeyIdentifier中的v3由errata引入，不受Microsoft支持。 解决方法是手动输入名称空间值或升级到最新版本的Websphere，IBM似乎在其中还原了其对非规范勘误的实现。
得到教训
学习曲线陡峭。 并不是给定的方面很难学习，而是执行整个项目必须熟悉的大量技术和工具。
我们请求两位顾问的帮助，以执行第一个项目，一位来自IBM，一位来自Microsoft。 事实证明，这对于解决互操作性，配置和部署问题非常有帮助。
从我们的角度来看，似乎很难期望让业务用户参与建模活动。 经验丰富的业务分析师可以轻松地将业务需求转换为业务流程模型。 此模型通常不能按原样部署在流程引擎中。 需要使集成开发人员参与进来，以使流程可执行。 最初，SOA项目应被视为传统的实施项目。 随着时间的流逝，为业务团队提供部署模型是很有价值的。 当我们能够在此状态模型中添加操作指标时，我们期望该值将变得足够高，以说服业务团队参与建模活动并建立一个闭环模型驱动的交付过程。
该项目展示了SOA可以为组织带来的大部分收益。
首先，我们可以重用遗留代码，而这些遗留代码如果不使用Web服务技术作为服务公开，就无法重用。 在将解决方案部署到生产环境中之后，拥有此代码的Q＆I团队对Matching Service的实现进行了一些更改。 这些修改可立即用于MVR解决方案，如果代码已被复制则不会是这种情况。
其次，Web服务技术实现了互操作性，而互操作性又是构建复合应用程序时成功的关键因素。 我们在此领域并没有遇到重大困难，我们只能期望在SOAP 1.2，WS-Transaction和WS-ReliableExchange ...的支持下，互操作性的程度将会提高。
第三，我们能够在不到8周的时间内，由4位开发人员，2位质量保证人员和2位建筑师组成的团队，提供集成了5个系统的复杂解决方案。 生产基础结构（包括安全性）是作为一个单独的项目构建的，具有较少的资源。
第四，使用少于20行的代码来完成过程实现，而这些代码是为特殊的映射功能而编写的。 过程组件，服务和人工CSR之间的组装是通过SCA实现的。 这些功能证明，模型驱动的方法可以有效地实现实际解决方案，并且该方法可以在流程级别消除90％以上的代码。 如果我们要使用传统的应用程序模型（例如J2EE或.Net）在没有业务流程引擎的情况下对该过程实现进行编码，则该实现将需要数千行代码。 此外，该代码是有状态的，这将使以后的调试或更改变得更加困难。
总体而言，Safeco已成功部署了面向服务，以流程为中心，模型驱动的应用程序模型的第一次迭代。
未来发展方向
我们当前的SOA基础架构不完整。 下一阶段将继续建立我们在业务活动监视，注册和管理与监视方面的能力。
我们已经获得了业务客户的大力支持，他们赞赏较低的交付成本，交付速度以及生产后更改解决方案的能力。 我们已经建立了可以由SOA解决的项目管道。 治理和方法是可重用性和交付速度的关键。 因此，我们将不断加强它们，以达到最高成熟度的持续努力。
面向服务的体系结构的主要好处是它具有创建IT资产的能力，可以在构建新解决方案时重复使用和扩展这些资产。 能够重用这些资产的未来项目将更容易，更快，更便宜地构建，同时限制了集成需求。 因此，SOA是转型，提高业务/ IT一致性和敏捷性的关键推动力。 通过使用SOA，Safeco IT能够在非常短的开发周期内交付解决方案，从而满足市场和财务目标，同时降低了软件开发的实施成本。
277
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
