SQL Server行使 .NET 3.0 技术构建互操作保障系统[转发]

简介

本白皮书体系意在提供关于集成问题的点拨。

在本白皮书中,大家将因此保障业的案例来表明 Microsoft
平台的互操作功用。随着技术发展以及新技巧不断涌现,许多集团在店铺升高的一一阶段或者采纳了分化的技艺:从基于大型机的
COBOL 或 FORTRAN 类型的价值观应用程序,到进一步现代的基于 .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。在所运用的阳台技术那样眼花缭乱的意况下,要对频频转变的金融市场保持灵活应对的同时展开管制和周转正变得愈加困难。多年来说,各种协会直接在构建并选购技术以满足那几个须要。互操作性已经成为在构建和/或完结了化解方案后不得不解决的来之不易问题。以前,人们使用的是点到点集成的主意,但这种艺术只好化解使用程序级或系统级的一些特定问题,而望洋兴叹缓解事情功用级的题材。

SQL Server 1

图 1. 点到点集成的结果

即使不谨慎,多年的话的点到点集成会导致:

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

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

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

那么,对于众多承保公司而言,那代表怎么样?那代表互操作性格外紧要,不仅是作用问题,对进步企业竞争力也颇为关键。在现代商业竞争中,公司必须经过简化流程及进步灵活性来充实其
IT 系统的投资回报 (ROI),从而保持竞争力。

俺们的目的是应用 Microsoft
平台上的一组公司就绪技术来应对行业挑战。示例中蕴涵以下因素:

企业级解决方案

标准通信:

采用 WS-* 标准

ACORD 消息

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

 

正文档中使用的正业术语

ACORD—ACORD (www.acord.org)
是一个非赢利社团,其目的是促进担保、再有限帮忙以及有关金融服务行业标准的迈入和运用。

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

其三方服务提供者—落成有限支撑要求请求的外部系统(例如,信用评级系统)。

保障流程—执行新工作的评估和处理流程。

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

 

人寿保证保单案例

客户 罗伯特(Bert) 要购置 1 百万美金的白金级寿险。代理人 汤姆(Tom)使用其智能客户端应用程序来输入 罗伯特(伯特)(Robert)的保单申请。保单被发送到订单系统,然后系统会对其举行处理并传递到对应系统以开头有限支撑流程。保单处于订单系统中时,便会启动第三方服务。在本案例中,大家使用
Paramed,那是一种核实有限协理申请人健康意况以及治疗记录的第三方服务。

借使满意特定条件,内置业务逻辑也得以变动对第三方的哀求。那里的第三方得以是代表或担保公司的另一个同盟伙伴。

SQL Server 2

图 2. 此案例的业务流程

 

布局概述

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

为了有限支撑适用于实际问题,大家会指出一组高级需求。

要求

以下是对合作社级解决方案的须求:

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

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

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

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

在此解决方案中,大家利用 BizTalk
作为音信焦点,因为它功效强大,而且此保障解决方案越发要求将八个连串绑定在一块儿并保管几个外表工作流。

SQL Server 3

图 3. 采用音信总线技术

图 3 所出示的是当做店铺劳动总线 (ESB) 的 BizTalk
的小卖部视图。请留心,并不是必然要将它看成
ESB。本白皮书仅将此层作为新闻层,由此在其它动静下都可以把它集成到解决方案中。

采取 BizTalk 的根本原因在于它可以提供用于以下职能的集中化平台:

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

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

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

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

 

担保代理人保单系统

当前,保障行业中的技术进步动向概括门户、胖客户端、3270
主机终端仿真屏幕以及智能客户端。在该领域存在各个应用程序和重重供应商的状态下,基于以下理由,大家挑选使用智能客户端用户界面
(UI) 来为代表提供最佳体验:

离线和在线模式

不依赖网络连接

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

断开模型对代表而言尤其适用,因为代表会常常处于活动状态或者在造访网络资源方面存在限制。但是,由于大家在构建此解决方案时将
Web 服务作为新闻传递策略的中央,由此最后代理人提交保单的法子并不重大。

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

由于那是智能客户端,再次回到数据可以存放在缓存中以供离线查看和换代。那对代表极其有用。除了数据,在客户端应用程序上还会有一个小的事情逻辑层。大多数应用程序逻辑会驻留在保障公司那端。其根本原因是大家将使用轻量规则来驱动
UI 成效。

SQL Server 4

图 4. 客户端逻辑结构

要在客户端发起对音信传递层的调用,大家将拔取 Windows Communication
Foundation (WCF)。WCF 会选择 ACORD 信息传递架构来发送 SOAP 1.2 Web
服务音讯。WCF
为开发人士提供了用来编码通信的合并支付模型。站在协商的角度,大家会选用一种类WS-* 标准。不过,那还不足以确保互操作性。选择 ACORD
行业标准也很要紧。大家应能在“本地转移”的应用程序、COTS
应用程序以及第三方服务时期展开无缝互操作。

音信传递结构

经过 Web 服务,各种通道便能运用通用的 Web 服务。该服务以 ACORD 103
信息(具有指定的保单号,在一切示例司令员使用该号码来展开跟踪/关联)的款型收取新的事务申请并将申请出席保证流程中。该
ACORD 103 New Business Submission 信息基于 SOAP 音信传输优化机制
(MTOM/XOP) 附件,其中涵盖 罗伯特(Bert)(Robert) 签名的二进制表示,以依照 HIPAA
的渴求授权公布医疗新闻。鲜明,将 ACORD
标准集成到消息传递中足够重大。这可确保布局的可移植性。

通讯的安全性和可相信性也十分重大。为达此目标,大家将 WS-Secure
Conversation (WS-SC) 用于可能要通过未知数目中间方的个人音讯。我们还将
WS-SC
用于量大且反复的伸手(例如信用审核),所有新的保单申请都会进展此类请求。大家将
WS-Security 用于频率较低的呼吁,例如主治大夫报告
(APS),其中树立会话的费用大小并不由请求的量来控制。在极少数景况下,服务会一直处理请求而不通过其余中间传送进程,此时大家也选取TLS/SSL(也称作 HTTPS)。

对此急需跟踪接收意况的音信传递(例如确保接收到新的保单以获得代理权),大家会使用
WS- Reliable Messaging (WS-RM)。我们也会将 WS RM
用于拍卖起来代价高昂的多寡请求(那种状态普通涉及人力工作流,如 APS
查询)。这确保请求只传递两回,防止了代价高昂的重新请求。

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

SQL Server 5

图 5. 客户端音信交流形式

事务

业务流程

WS-* 协议

布局决定

交付新保单(103 请求)

代办客户端

管教流程

WS-Security (WS-S)

WS-Reliable Messaging (WS-RM)

WS-S 用于可能会透过未知数目中间方的个人音信。

WS-RM 用于跟踪新闻接收。

鉴于作业不频仍,由此不须要面向会话的平安机制,如 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 RM 用于拍卖代价高昂的数据请求。

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

在开展提交后,您可能会问自己:为何状态在独立的事体中回到?原因有两地点。首先,该进程异步进行很重点,并且
ACORD
标准差距旨在平昔不将气象从提交分离出来的动静下进展实践。其次,通过查询状态服务,代理人可以定期从报名经过得到再次来到状态。

 

确保公司系统

千古在构建解决方案的服务器端时,必要考虑下列问题:

该结构用于碎片系统。

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

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

结果就是,存在大批量与特定应用程序的点到点集成,由此必要特其余贯彻进程。在本解决方案中,会围绕这一个现有的应用程序创立外层。

SQL Server 6

图 6. 担保音讯总线

在本图中,您可以看到我们什么样将店铺劳动总线 (ESB)
用作信息总线。该层会作为管理之中和表面音信的集中化信息传递层来发挥功能。管理和编制功效是该社团首要的长处。

此类基础结构可以将智能的长日子运作业务流程和事情策略置于一层而不是多层,从而使分化的点到点集成变得绘身绘色。在五或三个以上的系列中兼有几个精光分裂的按照COTS
的应用程序以成功端到端的事务处理会很宽泛。大家正透过集合冗余功用(例如工作流和音讯传递)来减小系统,将基础结构级的效果留在其所属地方并在适用的应用程序中保存业务逻辑。

请务必牢记,此音讯总线是“逻辑”表示。“完成”视图与此有一定大的差距。例如,音信总线可能是几个BizTalk 服务器,或者是由位于不一样 DMZ
环境中的服务器来保管其中和表面通讯。

SQL Server 7

图 7. 工作流设计器

上面一层(在内部进行一定业务职能)包蕴以一个接口封装的四个分歧的观念系统:订单系统和履行系统。大家将它们当做单身的连串而不是把它们统一在共同的缘故是,多数时候,这是五个独立的、基于
COTS 的连串。

加上状态系统的来头是:

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

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

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

订单系统和实施系统已转移为经过消除服务。那样可以免除独立已毕之间的看重。这么些系统的装有通信现在都会因而音信大旨。然后,通过音讯总线来管理的公然
Web 服务端点可以利用内置在 BizTalk 中的编排技术来保管。

SQL Server 8

图 8. 端到端新闻互换格局

出于这一个应用程序作为 Web 服务公开,任何接受 Web 服务 XML
的技能都足以和这么些应用程序集成。那消除了其他技术协议间可能会限制互操作性的严苛耦合。例如,假若您事先用的是依据Java 的系统,您现在仍可对那几个连串举行轻松使用。

SQL Server
在那里用于将应用程序数据存储在数码库层中。由于本白皮书的主干是合二为一和复合应用程序,在此我们就不对这点展开重点介绍了。

引用的第三方服务是外部服务,由履行劳动来调用。那么些劳动有不相同的商谈需要。但是,本白皮书会向您出示
WS-*
标准是如何提供更多用来服务的功效。请务必注意,许多其实的保证第三方服务只接济基于
XML 的通讯,而不帮衬越发高档的依照 SOAP 的 Web
服务。前边的音讯传递结构部分会介绍更多关于第三方服务的内容。

保障集团信息传递结构

本节会介绍由保证公司处理的中坚寿险保单。在 Robert所提供音讯的功底上,保障流程中定义的事情规则/启发逻辑确定还索要主治大夫告诉
APS(即身体检查)。

因为另一个提供者必须执行该请求,订单系统会创制 ACORD XML TransType 121
General Requirements Order Request 事务 (TXLifeRequest),并将它传输给
Robert 的大夫所用的二级外部订单系统(APS 系统)。该信息还带有 罗伯特(伯特(Bert))签名的 MTOM/XOP 附件,签名初步由 ACORD 103 New Business Submission
引导,用于授权他的医生向有限支撑集团颁发其诊治新闻。

在某个时刻,罗伯特(伯特(Bert))(Robert) 的医务卫生人员会验证 罗伯特(Robert)的署名是或不是与她所具有的文本上的签署匹配,然后检查 罗伯特(Bert) 的疾病史,填写
APS 报告上需求的信息,从而落成 APS 订单的处理。

在先生成功 APS 报告后,会生成 1122 General Requirements Status/Results
Transmittal 音信并将其传输回 WS-Addressing ReplyTo(在以前的 ACORD 121
中指定)中指定的端点引用。也会接纳 WS-Reliable Messaging
来可看重传递该音信。

业务流程的其余部分伊始执行,其中包含富有活动保障计算师决策。不过,在本例中,由于有
APS
以及一些也许不可能活动处理的叠加新闻,因而该案例会被标记以供保证商检查和批准。

SQL Server 9

图 9. 确保流程音讯互换方式

实施劳动

在有限辅助业中,履行系统或服务与执行的流水线大不一样:

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

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

您可能会问,为何要保存履行劳动。就本例而言,我们只要此类系统是被看成黑盒解决方案购买的。那并不是说不可以去除那一个层并转而将其联合到音信总线中。

采用新闻传递形式并不像挑选一组正式那么不难。在规划缓解方案的这一部分时,必须停下来翻看一下各类业务的业务和观念地方。

一点事情,例如接收信用报告,比较便于确定。可是,诸如请求 APS
报告的工作,则必要拥有附件作用。

以下是部分在规划音信传递时要考虑的情节:

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

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

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

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

SQL Server 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

相关文章