简介

金色皮书连串目的在于提供有关集成难题的点拨。

在铁锈色皮书中,大家将通过保证业的案例来表达 Microsoft
平台的互操作作用。随着技术升高以及新技巧不断涌现,许多商行在专营商发展的顺序阶段只怕选择了不一致的技艺:从基于大型机的
COBOL 或 FO凯雷德TRAN 类型的思想意识应用程序,到越来越现代的基于 .NET、移动系统或
Java
的化解方案,以及整个的中档技术。因而,随着集团所选用技术的日渐庞杂,各种技能所面临的限制也更是多。

担保互操作连串

浅莲灰皮书意在为面临保证行业集成难题的社团设计师提供指引。本文将向您出示怎么使用
Microsoft
集成技术为铺面合并各类具有本质差距的系列。其它,本文书档案会针对利用开放式标准(如
WS-*)来创设互操作化解方案方面,提供实用的筹划指南。此体系中还将囊括下列文书档案:

用来塑造互操作保证种类的布局概述

担保保障化解方案的安全性

分析和操作管理

安顿集团缓解方案

支付复合应用程序

含有的技巧包蕴:

BizTalk 2006。用于此解决方案的集成技术。解决方案也会用到 BizTalk 业务规则和工作流编排功能。

Windows Communication Foundation (WCF)。用于开发 Web 服务消息以及使用 WS-* 协议来管理协议级通信的编程模型。

Windows Workflow Foundation (WF)。用于采用智能客户端技术来创建恰当的工作流。

SQL Server 2006。所有应用程序和客户数据的存储库。

Windows Server 2003。服务器平台。

该案例将使大家对业务流程有叁个发端询问。与广大别的店铺同样,每家保险公司都有和好尤其的流水生产线处理格局。不过,这么些同盟社在阳台级别具有部分相似之处。那代表大家能够使用那几个共有的平台服务来创设面向服务的系统布局
(SOA),从而为那一个全体一定业务流程的集体带来更大的灵活性。

 

保障业影响因素

脚下保险业中所选择的技术有四种,蕴含大型机、UNIX 以及
Windows。在所利用的阳台技术那样眼花缭乱的情事下,要对不断变化的金融市集保持灵活应对的还要开始展览管理和平运动作正变得越发不方便。多年的话,各类集团直接在创设并购入技术以满足这个需求。互操作性已经济体改为在构建和/或促成了缓解方案后只可以消除的灾荒难题。在此之前,人们采纳的是点到点集成的法子,但那种办法只可以一挥而就采纳程序级或系统级的一点特定难点,而一筹莫展消除事情职能级的难题。

XML 1

图 1. 点到点集成的结果

假如不严厉,多年以来的点到点集成会导致:

由于系统重复、集成形式多样以及应用程序依赖性管理等原因,IT 资产组合变得无法管理。

大量的自定义集成造成 IT 系统成本大幅度上升。

由于代码复杂性增加、重用性有限以及企业内部缺乏标准化,因此显著降低了系统开发的速度,从而导致了灵活性的丧失。

那正是说,对于广大保险集团而言,那意味着如何?那意味互操作性很是关键,不仅是成效难点,对增长公司竞争力也颇为关键。在现代商业竞争中,公司必须经过简化流程及升高灵活性来扩充其
IT 系统的投资回报 (ROI),从而保险竞争力。

咱俩的对象是应用 Microsoft
平台上的一组公司就绪技术来应对行业挑战。示例中带有以下因素:

企业级解决方案

标准通信:

采用 WS-* 标准

ACORD 消息

确保与现有解决方案之间的互操作性

 

本文书档案中使用的行业术语

ACORD—ACO牧马人D (www.acord.org)
是三个非赢利组织,其目标是推进有限协助、再保证以及有关金融服务行业标准的发展和应用。

订单系统—创立对外表数据的呼吁,将其传输给相应的第叁方数据提供者,管理收到的响应并将响应与相应的请求者对应起来。

其三方服务提供者—完结保证必要请求的表面系统(例如,信用评级系统)。

确定保障流程—执行新工作的评估和拍卖流程。

代办系统—可选用的智能客户端前端系统,由保险代理人使用,效能是订单输入以及经过监视。也可采纳其余前端系统,例如为委托人提供的
Web 门户,或然由客户自助输入订单的 Web UI。

 

人寿保障保险单案例

客户 罗Bert 要购买 1 百万美元的白金级寿险。代理人 Tom使用其智能客户端应用程序来输入 罗Bert的保险单申请。保险单被发送到订单系统,然后系统会对其实行拍卖并传递到对应系统以开端保障流程。保险单处于订单系统中时,便会运维第1方服务。在此案例中,大家利用
Paramed,那是一种核实保险申请人健康景况以及医疗记录的第3方服务。

假定满意特定条件,内置业务逻辑也足以生成对第二方的呼吁。那里的第②方能够是代表或担保公司的另三个合营伙伴。

XML 2

图 2. 此案例的业务流程

 

结构概述

本节将介绍此案例中使用的尖端逻辑结构。有关特定地点(如安全性、新闻、开发和布局)的详细音信会在本体系的其他小说中介绍。

为了保证适用于实际难题,大家会建议一组高级要求。

要求

以下是对商店级化解方案的渴求:

必须能够与已有的现成商业应用程序进行互操作。如前文所述,许多组织会购买并自定义软件。因此,满足此要求便显得极为关键。

集成技术必须为 Web 服务。许多形式的通信(例如二进制通信)都是专用的。直到出现 Web 服务,才有了消息通信的标准化方法。Web 服务提供了在完全不同的平台间进行通信的方法。

必须采用 WS-* 标准。多年以来,采用 SOAP 和 WSDL 的 Web 服务一直是行业的集成标准。但是,这些传统的 Web 服务缺乏消息传递所需要的健壮性。WS-* 标准提供了这些必要功能,而且不需要使用二进制通信。

长时间运行工作流。长时间业务管理非常困难,尤其是当该工作流还会衍生出许多更小的外部工作流时,在这种情况下协调和事务管理会变得极为复杂。

在此化解方案中,大家运用 BizTalk
作为音讯核心,因为它功用强大,而且此保证消除方案尤其供给将多少个系统绑定在协同并保管八个外表工作流。

XML 3

图 3. 应用消息总线技术

图 3 所展现的是作为公司劳动总线 (ESB) 的 BizTalk
的店堂视图。请小心,并不是迟早要将它看做
ESB。松石绿皮书仅将此层作为音信层,因而在此外情状下都足以把它集成到消除方案中。

行使 BizTalk 的根本原因在于它亦可提供用于以下成效的集中国化学工业进出口总集团平台:

业务流程管理—将可重复使用的业务流程集中化不仅可给出服务导向,而且向组织提供了在无需修改现有或购买的现成(基于 COTS)商业应用程序的情况下对其进行扩展的机制。

工作流编排—通过该平台可以简化对多个工作流的管理。从而按应有的方式管理解决方案,而不需要对每个工作流进行编码或协调。我们通过创建一个工作流,来从头至尾管理能够编排多个内部系统工作流的业务流程。

丰富的适配器支持—快速开发对于组织而言有着重要的意义。BizTalk 具有多种适配器,可满足集成需要。在保险领域,有一种 ACORD 适配器,可以使集成突飞猛进。Web 服务适配器和基于文件的适配器可与 ACORD 一起供 BizTalk 使用。

消息传送和转换—必须对消息进行转换其他系统才能理解时,消息的传送会非常复杂。BizTalk 可以提供平台,在降低复杂性的同时仍符合开放标准。

 

担保代理人保险单系统

眼前,保险行业中的技术进步动向总结门户、胖客户端、3270
主机终端仿真显示屏以及智能客户端。在该领域存在各个应用程序和无数供应商的情况下,基于以下理由,大家选拔采用智能客户端用户界面
(UI) 来为代表提供最佳体验:

离线和在线模式

不依赖网络连接

增强的功能带来更为丰富的用户体验

断开模型对代表而言相当适用,因为代表会时不时处于移动意况大概在拜访网络财富方面存在限制。不过,由于我们在创设此消除方案时将
Web 服务作为音信传递策略的基本,由此最后代理人提交保险单的法门并不首要。

对于客户端结构,使用 Windows
窗体作为用户界面,来为委托人提供所需的用户界面。界面上有一些控件,如数据网格、文本框及命令按钮。Windows
窗体上的数量网格将由代表使用,用作到保险单管道的窗口。大家利用 Web
服务来更新该数据网格以有限援救实时更新。

鉴于这是智能客户端,重返数据足以存放在缓存中以供离线查看和更新。这对代表极其有用。除了数据,在客户端应用程序上还会有三个小的政工逻辑层。领先50%应用程序逻辑会驻留在保障集团那端。其根本原因是大家将使用轻量规则来驱动
UI 功用。

XML 4

图 4. 客户端逻辑结构

要在客户端发起对音讯传递层的调用,大家将采纳 Windows Communication
Foundation (WCF)。WCF 会采用 ACO科雷傲D 音讯传递架构来发送 SOAP 1.2 Web
服务新闻。WCF
为开发职员提供了用来编码通讯的联合开发模型。站在商讨的角度,大家会动用一文山会海
WS-* 标准。但是,那还不足以确定保证互操作性。接纳 ACOKoleosD
行业标准也很首要。大家应能在“本地转移”的应用程序、COTS
应用程序以及第壹方服务时期展开无缝互操作。

信息传递结构

因此 Web 服务,各样通道便能运用通用的 Web 服务。该服务以 ACOXC60D 103
音讯(具有钦命的保险单号,在全部示例中将使用该号码来拓展跟踪/关联)的样式吸收新的作业申请并将申请加保流程中。该
ACO昂CoraD 103 New Business Submission 音讯基于 SOAP 音信传输优化机制
(MTOM/XOP) 附属类小部件,其中富含 罗伯特 签名的二进制表示,以依照 HIPAA
的须求授权发布医疗音讯。显明,将 ACOLX570D
标准集成到新闻传递中相当重庆大学。那可保证组织的可移植性。

通信的安全性和可信赖性也格外重庆大学。为达此指标,大家将 WS-Secure
Conversation (WS-SC) 用于只怕要由此未知数目中间方的个人消息。我们还将
WS-SC
用于量大且频仍的伏乞(例如信用审核),全数新的保险单申请都会开始展览此类请求。大家将
WS-Security 用于频率较低的请求,例如主要医治大夫报告
(APS),当中树立会话的花费大小并不由请求的量来支配。在极少数状态下,服务会平素处理请求而不经过别的中间传送进程,此时大家也采纳TLS/SSL(也称作 HTTPS)。

对此急需跟踪接收情形的音讯传递(例如确认保障接收到新的保险单以博取代理权),大家会使用
WS- Reliable Messaging (WS-君越M)。大家也会将 WS HavalM
用于拍卖起来代价高昂的数码请求(那种景况不足为奇涉及人力工作流,如 APS
查询)。那确定保障请求只传递3次,幸免了代价高昂的再次请求。

对此长日子运作的新闻,大家使用 WS-Secure Conversation
(WS-SC)(请参阅资源)。

XML 5

图 5. 客户端新闻交换格局

事务

业务流程

WS-* 协议

布局决定

交付新保险单(103 请求)

代理客户端

确认保证流程

WS-Security (WS-S)

WS-Reliable Messaging (WS-RM)

WS-S 用于也许会透过未知数目中间方的个人消息。

WS-本田UR-VM 用于跟踪新闻接收。

是因为工作不频仍,因而不必要面向会话的安全部制,如 WS-Secure
Conversation。

场地查询(122 请求/响应)

代理客户端

保险流程

实施流程

WS-Secure Conversation (WS-SC)

可以轻松地重试非关键的各自请求或响应音讯,但照样会包括个人新闻。

管教要求订单请求 (121)

保证流程

WS-Secure Conversation (WS-SC) 或 WS-Security (WSS) 或传输级别安全性
(TLS/SSL)

那个消息包蕴个人消息。

担保需要订单响应 (1122)

推行流程

WS-Reliable Messaging (WS-RM)

WS-SC 用于量大、频仍的伸手(如信用审核)。

将 WS-Security
用于频率较低的央浼,个中树立会话的付出大小不由请求的量来支配。

在劳动一贯处理请求而不须要任何中间传送的景况下,使用 TLS/SSL。

将 WS CRUISERM 用于拍卖代价高昂的多寡请求。

表 1:业务流程音讯传递设计决策矩阵

在进展付出后,您大概会问本人:为何状态在独立的工作中回到?原因有两地方。首先,该进度异步进行很主要,并且
ACO凯雷德D
标准不容许在未曾将气象从提交分离出来的情状下进展实践。其次,通过查询状态服务,代理人能够定期从报名进度得到再次回到状态。

 

管教集团系统

千古在营造消除方案的服务器端时,供给考虑下列难题:

该结构用于碎片系统。

功能区域是自我包含的,需要进行管理。

操作系统和开发环境存在差异。

结果正是,存在大量与特定应用程序的点到点集成,由此必要越发的兑现进度。在本解决方案中,会围绕那么些现有的应用程序创立外层。

XML 6

图 6. 管教消息总线

在本图中,您能够看出大家什么样将公司服务总线 (ESB)
用作音信总线。该层会作为管理内部和外部音讯的集中国化学工业进出口总企业音讯传递层来发挥成效。管理和编排作用是该组织首要的亮点。

此类基础结构得以将智能的长日子运作业务流程和事情策略置于一层而不是多层,从而使分裂的点到点集成变得井井有条。在五或三个以上的种类中持有几个精光不一样的依据COTS
的应用程序以成就端到端的事务处理会很常见。大家正经过联合冗余功能(例如工作流和新闻传递)来减小系统,将基础结构级的功效留在其所属地点并在适用的应用程序中保存业务逻辑。

请务必牢记,此消息总线是“逻辑”表示。“完结”视图与此有一点都相当的大的差别。例如,新闻总线大概是多少个BizTalk 服务器,可能是由位于分歧 DMZ
环境中的服务器来治本之中和表面通讯。

XML 7

图 7. 工作流设计器

上面一层(在其间实行一定业务职能)包蕴以1个接口封装的七个差异的古板系统:订单系统和实施系统。大家将它们当做独立的系统而不是把它们统一在一块儿的缘故是,多数时候,那是七个独立的、基于
COTS 的种类。

增加意况系统的来由是:

提供集中化的方法以向代理人报告状态。

减少查询多个系统所需的接口和控制逻辑的数量。

它能与用于长时间运行工作流的 ESB 的编排功能绝佳配合。

订单系统和执行系统已转移为经过解决服务。这样可以防去独立实现之间的信赖。这一个种类的装有通讯今后都会透过音信宗旨。然后,通过消息总线来治本的当众
Web 服务端点能够使用内置在 BizTalk 中的编排技术来管理。

XML 8

图 8. 端到端新闻交流情势

出于那几个应用程序作为 Web 服务公开,任何接受 Web 服务 XML
的技艺都可以和这一个应用程序集成。那消除了别的技术协议间可能会限制互操作性的严苛耦合。例如,如若你事先用的是依照Java 的系列,您未来仍可对这几个系统举办轻松利用。

SQL Server
在那边用于将应用程序数据存款和储蓄在多少库层中。由于深紫皮书的核心是融合为一和复合应用程序,在此大家就不对那点开始展览重点介绍了。

引用的第②方服务是外表服务,由实施劳动来调用。这几个劳务有例外的商谈要求。不过,浅绛红皮书会向你出示
WS-*
标准是怎么提供更加多用于服务的成效。请务必注意,许多实在的承接保险第1方服务只支持基于
XML 的通讯,而不援助尤其高档的遵照 SOAP 的 Web
服务。前边的音信传递结构部分会介绍更多关于第一方服务的剧情。

保障公司音信传递结构

本节会介绍由有限协助公司拍卖的主导人寿保险保险单。在 罗Bert所提供音讯的基础上,保证流程中定义的工作规则/启发逻辑明显还需求主要医治大夫告诉
APS(即肉体格检查查)。

因为另1个提供者必须实施该请求,订单系统会创建 ACOHighlanderD XML TransType 121
General Requirements Order Request 事务 (TXLifeRequest),并将它传输给
罗Bert 的先生所用的二级外部订单系统(APS 系统)。该新闻还隐含 罗Bert签名的 MTOM/XOP 附属类小部件,签名起始由 ACO奥迪Q7D 103 New Business Submission
辅导,用于授权他的医生向保障集团颁发其临床新闻。

在有些时刻,罗Bert 的医务人士会验证 Robert的签署是或不是与她所负有的文件上的签字匹配,然后检查 Robert 的疾病史,填写
APS 报告上必要的音信,从而做到 APS 订单的处理。

在先生实现 APS 报告后,会生成 1122 General Requirements Status/Results
Transmittal 音讯并将其传输回 WS-Addressing ReplyTo(在前头的 ACO卡宴D 1第21中学内定)中钦点的端点引用。也会采用 WS-Reliable Messaging
来可信赖传递该音讯。

业务流程的别的部分开头实践,在那之中包蕴富有机动保障总计师决策。可是,在本例中,由于有
APS
以及部分大概不能自行处理的附加新闻,因而该案例会被标记以供保证商品检验查和许可。

XML 9

图 9. 保障流程音讯调换形式

执行劳动

在保证业中,履行系统或服务与实践的流水生产线大不一样:

履行系统:接收请求并执行的系统或服务。可将履行服务视为用于收集数据的集成组件。在本例中,履行系统负责从第三方提供者收集各种报告。

履行流程:保险公司核发保单的流程。

你或者会问,为啥要封存履行劳动。就本例而言,我们只要此类系统是被作为黑盒解决方案购买的。那并不是说不能够去除这么些层并转而将其统一到新闻总线中。

分选新闻传递情势并不像挑选一组正式那么不难。在设计缓解方案的这一部分时,必须停下来翻看一下各种工作的业务和观念位置。

或多或少事情,例如接收信用报告,相比较易于明显。可是,诸如请求 APS
报告的业务,则须求有所附属类小部件功用。

以下是一些在统一筹划新闻传递时要考虑的内容:

理解业务流程。理解业务使用这些消息的方式(例如,确保数据安全)非常重要。如果正发送的数据不敏感,则无需对消息采取大量安全预防措施。

理解服务提供者如何使用事务。这包含内部和外部两方面。很多时候,在利用服务提供者时会存在技术上的限制,包括标准支持及操作时间等。

适当关注安全性。这一点经常被忽视。大多数情况下,SSL/TLS 之类的协议级安全便已足够,但并非总是如此。务必要对数据的敏感性进行评估,并检查消息路径以确定在最终使用者前有多少个端点。

注重实际。设计这些服务时,不要试图采用每一个标准。如果标准不属于某个消息,不要强行将它置于其中。这只会带来不必要的复杂性。

XML 10

图 10. 执行系统音信交流形式

 

具备何等价值?

通过本示例,大家介绍了过多有关 Microsoft
平台和开发技术的学问。也根本介绍了结构决定。可是大家尚无就这几个 Microsoft
技术的效应进行尤其介绍。

以下是在保证业中使用 Microsoft 技术的首要性优点:

业务流程自动化—业务流程非常复杂,并且每个运营商都有其独特的运作方式。有了 BizTalk 提供的编排工具,便可由业务分析人员来开发业务流程,不但使开发人员从这项工作中脱离出来,还对业务提供了更好的支持。

减少集成代码—利用 BizTalk 中的自定义适配器以及 WCF 的统一编程模型,集成系统所需要的代码大大减少。

符合标准—WCF 和 BizTalk 本质上基于开放式 XML 标准。因此集成 Web 服务标准无需再进行自定义编码。

效率—通过集成的 Visual Studio IDE 和 .NET 3.0 技术,工具和开发语言两者相结合带来了其他语言无法比拟的高效率。

 

总结

宛如浅青皮书所展现的一模一样,仅使用协议级标准远远不够,捕捉新闻传递事务的业务方面才是让互操作性为业务服务的显要。那适用于种种行当,而不光是保险业。

咱们富有 Web
服务规范,但那不是成套。您还是须要实施须求的操作以便为您的商户做出最佳技术决策。利用此特定的引用实现,我们介绍了三个其实的案例并基于该案例的事务影响因平昔分明最佳音信传递。在选拔适用于贵组织的音讯交流情势时,可将此视作参考。建立了有着的协会后,选择特定标准时就有了度量。首要的是知情那几个权衡的含义并运用正确的正统。

Microsoft
致力于使其客户能够越发自在地营造并开发面向服务的缓解方案。通过本文,您能够发现
Microsoft
已拔除了让客户望而生畏的正业壁垒和复杂性。从提供行业标准中的当先观念到自动执行并创设现成的
Web 服务援救,Microsoft 均能为你一一呈献。

原文:
http://www.microsoft.com/china/MSDN/library/netFramework/netframework/bb220799.mspx

相关文章

网站地图xml地图