面向服务及其在互联系统策略中的角
核心提示：面向服务是1种创建散布式系统的方法。在它最抽象的层面，面向服务作为1个服务提供程序，包括了1切——从大型机利用程序到打印机到码头工作职员到隔夜交货公司。
面向服务的业务环境
面向服务是1种创建散布式系统的方法。在它最抽象的层面，面向服务作为1个服务提供程序，包括了1切——从大型机利用程序到打印机到码头工作职员到隔夜交货公司。服务提供程序通过接口公然了功能。面向服务的体系结构与这些功能和接口进行了映照，这样它们便可以够编制到流程里。这类服务模型是“不规则的”：新构成的流程本身就是1个服务，它公然了1种全新的聚合功能。
这类服务模型的基础是接口与实现之间的分离。服务的调用者只需要(只应当)了解接口;实现进程可以随着时间而发展，而不会干扰到此服务的客户。有趣的是，很多实现工具都可以提供相同的接口;面向服务的几个关键利益来源于从如何提供功能的角度对功能进行抽象化。
对，这就是面向服务。那末面向服务都对谁有帮助呢?
看到1个鸡蛋，农民可能会想到1只小鸡;厨师可能会想到1盘煎蛋卷;小孩可能会想到1个5光10色的复活节装璜品。面向服务就是1个鸡蛋。
对开发职员和解决方案架构师而言，面向服务是1种创建动态的协作利用程序的方法。通过支持运行时选择的功能提供程序，面向服务答应利用程序对特定业务流程的内容和环境具有敏感性，并随着时间的推移适度地合并新的功能提供程序。
对IT经理而言，面向服务是1种有效的集成现代企业数据中心的各种典型系统的方法。面向服务提供了1个模型，可将多个系统的信息和业务逻辑聚合到1个单独的接口中，这样便可以够通过通用的、1致的接口集处理各种冗余的系统。
对首席信息官而言，面向服务是1种在不制止部署新功能的情况下保护现有IT投资的方法。通过在基于功能的接口以后封装业务利用程序，该服务模型答应对关键任务利用程序进行控制性访问，同时它还创造了在此接口以后延续改良实现进程的机会。面向服务使投资避免了纷纷的变化。
对业务分析师而言，面向服务是1种使信息技术投资更符合业务策略的方法。通过将员工、外部功能提供程序和自动化系统映照到1个单独的模型中，分析师可以更好地理解与人、系统和来源的投资相干的本钱权衡。
对Microsoft Corporation而言，面向服务是创建互联系统的1个重要条件。互联系统属于利用程序，它们可利用网络来链接推动业务流程的履行者和系统。你可以在1种特殊的利用程序模型上构建互联系统，这类模型超出了任何设备，适度地逾越了边界，并抑制了同步性的限制。通过将1系列服务和设备集中到了1起，互联系统可以比过往的分离的利用程序更有效地应对业务挑战。
企业的IT部份需要取得更深进的业务活动洞察，在此需求的带动下，它们正在寻觅有效、简便的方法来集成它们的利用程序组合。其目标是透明性和1致性：
•对我们的客户和业务关系，我们是否是具有1致的观点(它能够让我们以最好的方式服务于它们的需求和显现我们的产品)?
•我们所有的业务流程是否是都符合组织要求和政府规定?
•我们的系统是否是能够针对我们的业务目标有效地提供价值?
•我们的技术投资能够实现1般任务的自动化，并对我们的员工的工作进行配合，从而克服复杂的挑战，这能否使我们最大限度地进步生产力?
为了实现透明性和1致性，组织必须创建各种连接机制。它们必须连接系统，以创建1致的信息治理程序。它们必须连接人和技术功能，以创建1致的业务流程。它们必须连接工作职员，以创建协作的工作团队。它们必须连接组织，以创建有效的价值链。
通用的功能调用模型是面向服务的重点，而面向服务是有效的互联系统策略的核心。
服务和互联系统
在计算机组件模型的环境下，服务是1种通过交换消息进行通讯的程序。换句话说，服务是1组利用逻辑，它接收和发送的消息完全地定义了它的接口。
通过以可扩大标记语言(XML)为基础开发消息标准，面向服务正迅速成为构建互联系统的主流方法。
在连接各种不同的系统的进程中，其固有的挑战是特定平台的信息和进程模型的转换。在理想的世界里，我们将具有：
•标准语法，在此可以明确地表达来自所有系统的信息。
•标准语义模型，各组织可以通过1种1致的语言表达它们的业务实践方法。
•标准协议，可以逾越操纵环境和组织之间的边界传递信息。
•标准方法，用来绑定行动和业务文档。
在理想的世界里，我们的所有系统都将说这类“世界语”(除它们本身的语言之外)，这样它们便可以够在它们的本地环境之外进行通讯。
XML、XSD、WSDL、UDDI和WS-*规范，比如WS-Security和WS-Policy，是这类不断发展的通用语言的第1批模型。
以广泛支持的标准为基础的虚拟平台提供了互操纵性，假设没有这类互操纵性，面向服务就将是1门需要大量的协议设计专业知识的晦涩难懂的学科，同时它也将是1种不可靠的投资回报。假设没有Web服务逾越各种异类平台连接你的企业功能，面向服务对你和你的组织的价值就将大幅度减少。
客户端是互联系统的1个非常重要但是却常常遭到忽视的元素。服务只有在遭到调用时才会引发留意。不同的交互要求需要支持各种不同的客户端模式。Web服务的客户端包括：
•具有丰富用户体验的智能利用程序—它们是具有以下特性的解决方案：与1个或很多服务进行交互;对它们检索的信息进行智能缓存;既提供了良好的交互性，又对离线信息处理提供了支持。
•智能设备—它们是包括以下范围的解决方案：从自助式电话亭得手持式库存跟踪技术到智能电话联系人治理。
•Web用户界面(UI)—它们属于企业门户解决方案，这些解决方案对业务与员工和组与组之间的交互进行了同1和调和。
•自动化系统—它们属于客户端，这些客户端1般不显现UI，除非需要引发异常。
•流程编制服务——它们是调用其它服务来提供聚合的功能的服务。
不断发展的Web服务标准和实现它们的平台必须支持客户端驱动的概念，例如缓存杂注、资源束缚设备的页响应和长时间运行的交互进程的对话环境治理。
即使面向服务的热情支持者对该模型的范围也没法达成1致。争辩主要集中在以下题目上：“面向服务的基础还有甚么?”(“你想用这些鸡蛋做甚么?”)下面让我们探讨与此争辩相干的几个服务友好的概念：
•企业体系结构—对组织的目标、优先级、资源和流程进行系统建模，以实现有控制的改进所需的自我意识。
•企业信息集成—为业务实体(复杂的“类型”，例如“客户”、“员工”和“采购定单”)创建1套组织标准，它们由你的利用程序组合进行操纵。
•面向流程—使业务流程成为你的企业体系结构和信息技术组合的设计重点。
•业务流程编制—这类模型可支持灵活的业务流程，由于它们能够使流程中的步骤排序尽可能地实现轻便性和适应性。
•事件驱动的体系结构—在这类模型中，业务事件(例如，部件到达码头或对发票付款)可触发消息发送到定阅服务，这样它们便可以够采取适当的措施。
•虚拟企业—将业务流程视为价值链，这类价值链能够逾越组织进行扩大，这样每个组织便可以够集中精力开发其核心功能，并将非核心功能外包给外部服务提供商。
•面向方面—提供了1种1致地处理横切关注点(例如，业务活动监控、服务访问控制和消息传递的可靠性)的方法。
•基于职员的工作流治理—调和信息工作者和他们与业务流程的交互作用，以进步效率并实现对客户需求的响应。
•非居间化—逾越业务边界自动交换非异常信息，以消除信息工作者履行常规任务的需求，例如，通过书面(传真、邮件、电子邮件)或口头的信息交换进行数据输进。
•灵活性—这类系统的设计是为了响应业务要求的特殊环境和内容，和业务要求和业务策略的更广泛的变化。
•模型驱动的开发—通太高级(通常是图形化的)语言驱动解决方案的开发流程，这类语言与正在实现自动化的业务流程进行了更紧密的绑定(例如，与Visual C#相比)。
Microsoft将灵活性和面向方面视为面向服务在业务和技术方面取得成功的关键因素;在本论文中，将不断地围绕这些主题进行讨论。不干预性是面向服务解决方案的1个非常普通的目标，因此它可能被视作该体系结构的1个隐含收益。其它任何概念都是对面向服务的补充，它们可能(或不会)对你的互联系统策略起到关键作用。
你的互联系统策略需要成为1种应对机会和困难的标准方法，它们保证了你的IT投资的最好回报。服务和支持模型的交换使用是无穷制的，但是发展的实例应当证实它具有启发意义。
第1步：爬
Typhoon Taylor是Rum Island Industries(RII)的信息关键。每份定单和发货报告都要经过他的办公桌，他必须确保数据输进到了主机里。但是，在RII被Worldwide Spirits(WWS)收购以后，Typhoon发现他必须将相同的信息输进到RII操纵系统和WWS企业资源计划(ERP)系统中;不同的信息模型不断地造成数据输进毛病，它们导致了两个系统之间的数据不1致。
Typhoon与他的IT搭档Daiquiri Jones讨论了这类情况。Daiquiri不想破坏主机利用程序，但是她又没法取得WWS ERP系统的修改权限，因此她建议在两个系统之前添加1个服务层。
通过与Typhoon合作，Daiquiri定义了1个PurchaseOrder(采购定单)文档，它包括了该操纵系统或ERP系统需要的全部信息，同时它又对2者都需要的公共元素进行了映照。然后，Daiquiri将这份草案交给会计部份的Hurricane Harris和客服部份的Salty Robinson过目。根据他们的反馈意见，她又在PurchaseOrder架构上添加了若干元素，以便支持Hurricane和Salty的需求。
通过再次与Typhoon合作，Daiquiri肯定了两项服务：
•NewOrder(新定单)：接收采购定单文档，并更新两个后端系统。
•ProcessShipment(进行发货)：接收Shipment(发货)文档，将它与定单相干联，然后更新后端系统。
通过利用DB2数据库和WWS ERP系统现有的适配器，并使用ASP.NET为Typhoon迅速编制1个用户接口，Daiquiri在BizTalk Server 2004中实现了这些服务。
Typhoon非常兴奋。尔后，他只需要输进1次数据，而且信息不1致的题目也解决了。
第2步：走
但是，Salty和Hurricane却刚刚开始感觉到麻烦。
由于运输途中海浪很大，常常会打坏几个瓶子，每当出现这类情况时，Salty就不能不处理客户的投诉。面对各种不同的系统，Salty乃至不知道该从哪里提取客户数据;另外，在客户需要紧急更换货物时，他必须与Typhoon协商酒产品脱离包装线的改向题目。
对Daiquiri来讲，为Salty提供Typhoon用来检查定单完成情况的GetPurchaseOrder (取得采购定单)接口非常轻易，但是Typhoon坚持以为，在没有他的批准的情况下，Salty无权擅自更新定单。因此，Daiquiri为PurchaseOrder业务服务定义了1套角色，并将Salty映照为“读取者”的角色。
Daiquiri还拟订了1份新的CustomerCredit(客户信誉)提案，Salty可以用它来处理关于产品破损的投诉，但是当Hurricane看到这份文档时，她变得非常愤怒。这份提案根本没有考虑到Sarbanes-Oxley的合规性题目。“我们作为1家固定而疏松的私人公司的日子已结束了!”她咆哮说。因此，通过使用WWS会计部份已采取的架构，Daiquiri又重新肯定了CustomerCredit文档包括的各项元素，并收进了RegulatoryCompliance(合规性)元素。
在发货进程中重新排列客户的优先次序变得更加复杂，但它也是1次解决题目的机会，在Rum Island(拉姆岛)，长时间以来这个题目1直限制着生产力的发展，客户对这个题目也非常关心。
通过与Typhoon、Salty和发货部份的Mojito Moore进行合作，Daiquiri重新设计了Shipment的架构，以包括对Customers(客户)和PurchaseOrders的绑定。然后，她为Shipment文档实现了1个优先级队列，这样Mojito就会知道下1个离线的集装箱应当发往哪里。(Mojito被映照为队列接口的“写进者”角色，因此他可以根据离港的货船来优化队列。)
Daiquiri定义了1个工作流，当Salty调用ReprioritizeShipmentQueue(重新排列发货队列的优先次序)接口时，此接口会把相干要求发送给Typhoon审核，这样工作流就会得到实例化。
之前的某些工作流程需要手动完成，这会牵涉到Typhoon、Mojito和Salty之间的不正确通讯，而现在，这类工作流程可以非常顺利地进行。固然，每当Typhoon否决了Salty的1个要求时，Salty还是会发脾气。
第3步：跑
当Daiquiri的预算再1次被削减时，她意想到她必须具有找到资金的创造力。她投进大量资金购买了1条通向WWS的长途电缆，但是这条电缆每天只有几百KB的电子数据交换(EDI)流量。假设……
在WWS总部，Martini Wilson已创建了可进步EDI流量的XML架构;他需要它们将传进的EDI消息转换为符合《美国爱国者法案》(USA PATRIOT Act)的数据包。通过使用加密的Web服务调用功能，而不是使用专用的EDI电缆，WSS的大部份子公司都可以下降本钱，他同意这1点，因此他实现了1项可将要求映照到EDI处理管道的网关服务。
通过利用她的新基础结构和专业知识，Daiquiri还向Rum Island的甘蔗供给商推荐了1组服务接口。Beachcomber Perry是这项服务的受益者之1，他感到非常兴奋;他已厌倦了整天与种植园主和船长在电话里打交道。固然，Mojito也参加了这项活动。通过使用这类改良的信息，他可以安排相同的货船来运糖，以便酿酒。Rum Island的库存治理从没像现在这样好过。
某些种植者和船员对这类变化进行了抵制，但是这仅仅意味着他们以后在Rum Island看到的业务将越来越少。
面向服务的技术
Microsoft对面向服务的投进
1999年9月，当时的Microsoft总裁(现在的首席履行官)Steve Ballmer首先公然探讨了“软件即服务”的挑战，并第1次引进了Web服务的概念。随着Internet的成熟，1种新的编程模型很快就会出现，这1点很明显;在这类模型里，软件组件将可以逾越广域网、逾越平台、逾越组织边界进行调用。究竟是甚么使这类编程模型成了1种值得信任的业务利用平台?
2000年6月，这类新兴的策略取得了1个名字：“Microsoft .NET”。
紧接着是1段调剂期，与Microsoft有关的组织纷纭对本身进行调剂，以应对.NET提出的新挑战。出现了1系列与XML Web服务相干的面向服务策略，不论是对你现有的Microsoft产品，还是对你的组织技术组合中的所有其它资产，它们都充当了连接Microsoft产品的1致性策略。
Microsoft熟习到，为了使技术发展到与业务流程相干的下1阶段，使技术继续增进员工生产力方面的收益，必须逾越相干的边界。其中1个边界完全来自于技术职员本身的构成：各履行平台之间的边界。Microsoft致力于与其它平台供给商进行合作，以便与他们联手将这座墙推倒。
通过与BEA Systems Inc.、IBM Corp.、TIBCO Software Inc.、VeriSign Inc.和其它技术供给商进行合作，Microsoft创建了1种流程，它可以扩大SOAP消息的跨平台功能，并实现竞争规范的公道化。这些规范以1种免除版税的方式发布到了标准的体系中。通过不断的努力，这些竞争组织达成了合作，为它们的客户提供了互操纵性，这类互操纵性对实现全局消息起到了关键作用。
由于熟习到了这些规范的不足——早期的标准没法在实现进程中取得互操纵性，Microsoft、IBM和其他援助商合作创建了Web服务互操纵性组织(WS-I)。WS-I为Web服务标准的通用解释提供了1个论坛，这样技术客户便可以够相信WS-Security的两种实现进程实在将会实现互操纵。WS-I成立于2002年2月，现在它已具有了接近150个成员，这些成员包括了各种不同的组织机构：从系统供给商到系统集成商到解决方案提供商到保健服务提供商到政府机构。America Online Inc.、BEA、Fujitsu、HP、NEC Corp.、Oracle Corp.、SAP AG、Siebel Systems Inc.、Sun Microsystems Inc.和TIBCO都是WS-I的成员。
在此基础之上，Microsoft又将基于标准的互操纵性置进了它的企业计算产品系列中。
面向服务的目前状态
Microsoft平台支持创建符合WS-I Basic Profile 1.0的服务和解决方案，同时它也支持对高级的WS-* Web服务规范进行早期的采取。
使用ASP.NET对Web服务的支持是Microsoft平台上创建Web服务的主要方法，ASP.NET Web服务俗称为“.asmx”或“ASMX”，这是由于Visual Studio对这些可履行文件使用了这类文件扩大名。
BizTalk Server 2004答应将编制服务公然为Web服务，对缺少本地Web服务支持的业务利用程序，这大大加快了Web服务网关的开发进程。
在Web Services Enhancements for Microsoft .NET (WSE)中，可使用早期实现的高级Web服务功能，例如，使用了WS-Addressing规范的复杂消息路由，和WS-Security规范的消息级安全性。WSE是1种技术预览程序，可用于特定的客户——这些客户希看以推荐的标准为基础对技术进行实验。
对从我们的操纵系统(Windows XP、Windows Server 2003和Windows CE)和Microsoft Office系统调用Web服务，Microsoft提供了丰富的支持。
Microsoft Office InfoPath 2003是Microsoft Office系统中提供的1个新组件，它支持将图式化的表单用作包括后端服务的交互模型。InfoPath已证实它在结构化的协作方案(从人力资源注册到合同协商)中是非常有用的。
Office的另1个新组件是Microsoft Office Information Bridge Framework (IBF)，有了它，便可以够通过Web服务访问信息。IBF是Visual Studio .NET的1个外接程序，它使开发职员可以创建基于Web服务的解决方案，这类解决方案能够访问企业业务数据，例如销售额、库存数字、客户信息等等。在Word、Excel和Outlook的2003版中，可以直接查看这些信息。IBF能够让信息工作者在不离开他们熟习的Office利用程序的情况下检索和操纵信息，从而增强了他们的生产力。
Visual Studio为企业的行业利用程序提供了最好的开发环境，它1直保存了这类传统。Visual Studio .NET支持Web服务的实例包括：
•服务部署
•XSD创作
•WSDL的自动天生
•UDDI注册
•数据中心部署包
•通过UDDI发现客户端服务
•客户端服务绑定
•服务代理的自动天生
同时，Microsoft正努力提供必要的指导，以便开发职员完善创建进程。传统上，MSDN为开发职员提供了较为完善的指导材料，Microsoft对这些指导材料进行了扩大，它以书籍、***、参考利用程序和模式库的情势提供了体系结构指导。Microsoft的模式与实践门户(http://www.microsoft.com/practices/)是体系结构指导的进口，从信息设计到解决方案体系结构到解决方案建模(目的是将这些解决方案部署到企业的数据中心中)，这些指导材料包括了非常丰富的内容。
使用SQL Server 2005和Visual Studio .NET 2005实现面向服务Microsoft SQL Server 2005 (代号为“Yukon”)和Visual Studio .NET 2005 (代号为“Whidbey”)将是2005年发布的两项关键技术。
对需要应对特殊挑战(使用Web服务设计散布式系统)的架构师，Visual Studio将引进1种新的建模画布。另外，Visual Studio还将附带两个使用了此画布的设计工具：
•逻辑利用程序设计器，可用来对面向服务的解决方案的各个组件和它们之间的交互作用进行建模。
•逻辑数据中心设计器，可用来对部署服务的处理器和这些处理器的防火墙所在的安全区域进行建模。
这些建模工具主要是为了支持解决方案架构师和系统架构师之间的早期通讯，从而保证设计阶段能够完全地考虑到解决方案的操纵要求。Microsoft不断地接到以下的客户反馈：由于部署题目，很多项目都延期进行，并且超过了预算;假设事前进行更好的建模，这些题目本来都是可以免的。
双方的设计师都以系统定义模型(SDM)为目标，SDM是1种XML架构，可描写软件组件、计算机硬件、网络和交互模型。作为1种用来描写和分析互联系统的建模语言，SDM是动态系统计划的技术基础(参见下文)。
SQL Server 2005具有很多改进的地方，其中之1是加强了对XML和Web服务的支持。SQL将提供：
•XML文档的本地存储。
•支持XQuery搜索这些文档。
•在XML中返回结果集。
•将存储进程公然为Web服务。
SQL Server中的若干体系结构元素将支持面向服务的数据中心内的解决方案：
•通知服务可用于发布和定阅信息源。
•报表服务可履行计划的查询，并针对分析结果产生XML格式的通知。
•SQL Service Broker可用来支持在散布式数据模型上设计的服务，包括超标量的信息存储库。
使用“Indigo”和Windows “Longhorn”实现面向服务
“Indigo”将成为Microsoft对互操纵性消息的投资的高峰：
•它将成为Microsoft对高级Web服务(WS-*规范)的实现。
•它将成为Microsoft用于散布式计算(从进程间通讯到跨组织的Web服务调用)的同1消息堆栈。
•它将成为Microsoft用来开发面向服务的业务利用程序的模型和框架。
根据协议、消息、通道和服务的面向服务概念，“Indigo”将提供1个编程模型和1个消息实现程序。“Indigo”将支持更安全、可靠的交易信息交换和功能调用，同时它们应当符合各参与组织声明的交换政策。
“Indigo”技术将包括到“Longhorn”客户端发行版中，同时可供Windows XP和Windows Server 2003使用。
下1代Windows客户端(代号为“Longhorn”)将引进创新技术，它们将扩大桌面参与面向服务的业务协作的能力。
“Longhorn”将引进XAML，这是1种基于XML的标记语言，可用于智能的Windows利用程序。与HTML1样，XAML使用了1种描写UI元素的声明语法，相对进程声明，它可以非常轻易地通过编程方式进行天生和分析。这类创新将答利用户接口更好地反应它们表示的信息，这是由于UI能够基于交互状态以编程方式天生。
WinFX完成了到Windows中的托管代码的过渡，这类过渡是从2002年Visual Studio .NET的引进开始的。WinFX是下1代的系统编程接口。在面向服务方面，WinFX同1了Microsoft的多个消息模型，以检索自Web服务的信息为基础对代码访问的安全性提供了支持，并向利用程序开发职员公然了“Indigo”消息堆栈的功能。
通过动态系统计划(DSI)，Microsoft正在努力进步IT的生产力，并下降与面向服务的系统的设计、部署和散布式操纵相干的本钱。作为此计划的1部份，系统定义模型(SDM)是1项核心技术，通过为利用程序、系统和交互操纵定义通用的语义，它使面向服务的规则可以利用到系统治理中。通过使用这类通用的领域特定语言，利用程序可以表达它们的技术要求，比如CPU周期、内存容量和存储容量，同时系统还可以对其资源进行描写。这类新的建模技术将能够使业务更迅速地推出面向服务的利用程序，这类利用程序更轻易部署，治理用度也更低。DSI是Microsoft和业界共同努力的结果，它将对软件开发工具和利用程序、操纵系统、治理解决方案及硬件平台产生深远的影响。欲了解DSI的具体信息，请参见http://www.microsoft.com/dsi/。
创建面向服务的解决方案
其实不是所有的Web服务都是同等创建的。1个鸡蛋可能变成美味可口的蛋奶酥;但是假设将它放在荷兰辣酱油上，就将变成1次让人反胃的品味;或，假设掉在了地上，它就会变成1团粘糊糊的东西。每个人都可以通过服务构建任何事物：好的，坏的，或丑陋的。
在策划企业服务组合时，需要面对3个基本的挑战：
•面向服务的分析—为了支持组织的业务优先级，应当创建哪些服务?
•服务设计—应当怎样创建每项服务?
•服务治理—为了支持业务服务，应当部署哪些基础结构服务?了解和处理异常需要哪些支持?
本章节将探讨所有这些挑战，并进行整体的指导，告知你现在应当怎样做才能取得面向服务带来的直接收益;同时，它还为你提供了1些提示，这样你便可以够猜想完成互联系统策略所需的未来投资。
面向服务的分析
面向服务的体系结构是组织机构业务流程的建模艺术，同时它也是网络可寻址的业务组件的结构完善的组合。
真实的挑战来自于那个看似平常的修饰语：结构完善的。在肯定对组织功能的建模起关键作用的信息集(请将它作为“结构化业务文档”的1个使人讨厌的同义词来浏览)和行动时，总有1种“翻江倒海”的***——想法为组织的所有行动创建1个完全的自上而下的视图，并在1个1致的企业体系结构中对其进行建模。同时，那些需要解决方案的业务单位目前正通过技术和业务流程重组投资而迅速发展。
“权宜之计”是1个强大的动力。利用它，但是也要对它进行适度的控制。在不断的尝试中学会爬;在不断的交换中学会走;在不断的协作中学会跑。
应当怎样权宜性地定义1个服务组合呢?这里有几个原则。
设计长时间稳定的服务，设计灵活应变的系统
在1个企业服务体系结构中，功能服务是构成业务流程和业务系统的组件。对服务接口进行建模，从而紧密地结合业务功能模型，这是1个重要的最好实践方法。例如，大多数制造商都有接收订购要求的业务需求;定义1个描写订购要求的信息集和1个接收此信息集实例的终点，即可构成1个井然有序的服务范例。
业务流程远比它们处理的信息不稳定。在流程中，操纵者(人)的判定乃至是1时冲动都会对处理操纵造成很大的影响，同时各种服务异常情况也会对业务实例造成干扰。每个业务流程实例都可以构成1条穿过你的服务组合的唯1线路。
因此，系统必须具有灵活性。流程的编制应当易于修改，乃至是完全动态的。对成功的业务系统而言，将硬编码的业务流程排进已编译的可履行文件是1种反模式。
事件驱动的体系结构的概念对有效的流程设计具有指导意义。流程应当能够洞察推动其发展或使其脱离正常线路的业务事件。当异常事件使某个流程脱离正常的轨道时，应当努力使流程恢复正常，并使其返回主要的轨道;假设对全部流程进行人工监控，将导致流程本钱的激增，乃至远远超过流程本身带给组织的价值。
从全局着眼，从局部着手
大多数组织都具有几个(也很多达10个)关键实体，这些实体在它们的核心业务流程里运行。1般的例子包括Customer(客户)、Employee(员工)和BusinessTransaction(业务交易，或通称为PurchaseOrder(采购定单))。应努力对这几个关键实体进行定义，以创建实体类型的组织模式，并开发实体建模的专业知识。同时，还应参阅关于指导和重复使用的正式标准和实际标准(假设你所在的垂直行业中存在着任何满足要求的标准，那末便可以够使用此标准)。
我们已建立了专业知识和1组观点，下面我们要更加深进地探讨如何应对业务机会和困难：
•肯定进行改进的关键机会。
•对目前的业务方案进行建模，并适当参考现有的标准。
•与3到4个相干业务科目的专家1起检查此模型。
•根据他们的反馈扩大和修改此模型。
•开发业务服务。
•重复以上步骤。
结果将不会很完善。稍后就会发现某些业务案例需要附加的信息。必须向业务流程模型中添加步骤。不过，有了下1条原则，你便可以够对变化做好充分的豫备。
对可扩大性的设计
在时间的考验下，任何对要求的理解都是不充分的。为了进1步证实你的服务和解决方案，你必须将可扩大性设计进来。可扩大性有两个关键领域：实体可扩大性和行动可扩大性。
在实体中扩大模式化信息的主要原则是容纳1系列可能包括任何内容的Extension(扩大名)元素。这些元素通常都会使用1个名称来鉴别自己，并援用它们自己的架构。通过在实体定义中包括这类支持功能，你便可以够创建多态实体。1个已扩大的Employee实体依然可以由任何了解基础实体的服务进行操纵，不过它也能够支持那些了解实体的服务(也就是称为TravelProfile(旅游资料)的扩大名)进行扩大处理。
不同的地区需要不同的信息。例如，1个税号在不同的国家可能会有不同的构成方式。请勿将社会保险号作为你的Employee实体中的顶级元素;正确的做法是，包括1个可能将其子类型标记为“US-SSN”的TaxID(税号)元素。
与面向对象不同，面向服务对行动进行了延迟的绑定——只有在实体被传送到1个知道如何处理其内部包括的信息的服务时，实体的“行动”才会得到绑定。
因此，可通过操纵实体增加价值的公然服务基本上实现了行动可扩大性。假设要将新的行动绑定到实体上，可使用很多有效的模式，但是本文不会先容这些模式，由于它们超出了本文讨论的范围。不过，1个具有指导意义的实例是，1个服务充当了另1个服务(该服务能够操纵较大实体的元素)的门面。VerifyEmployeeAddress(验证员工地址)或许可以接收Employee实体，并提取它的Address(地址)元素，然后将它传送到更通用的VerifyAddress(验证地址)服务中，VerifyAddress服务是由合适的国家邮政服务提供的。
另外，1个关键的指导原则是从标准化的元素组成实体，从而最大限度地进步实用服务的可重用性和通用信息元素处理的1致性。
分开的功能和操纵关注点
请将你的业务服务和基础结构服务都视作提供的功能。基础结构服务提供了横向的功能，它也被称作横切关注点或方面(比较深奥)。
在进行面向服务的分析时，你的挑战是如何肯定这些横切关注点并把它们从你的业务实体中分解出来。你最需要的是单独实现每个基础结构服务，它们可以通过管道传送，以满足特殊消息交换的整体操纵要求。
你的基础结构服务组合可能会成为购买和创建行动的综合体，假设在市场上可以取得合适的实现工具，它就将以购买为主。下面的“服务治理”1节将更具体地讨论这个主题。
牢记客户
进行以用户为中心的设计练习是面向服务的分析的1个重要部份。这些服务有哪些用例?它们将由谁调用，为甚么?用户将会在哪些角色里访问这些服务?谁可以调用服务，谁又不可以?需要支持哪些类型的设备和体验?为了简化从所有这些设备到服务的访问，我们是否是需要开发服务代理?
为客户操纵进行信息建模时，需要考虑以下几个方面：
•只能使用XSD类型(和由XSD类型组成的复杂类型);不要通过特定平台的数据编码将你自己绑定到操纵平台上。
•架构应当表现出对数据值的束缚，以答应客户端在提交更新要求之前对其进行验证;客户真个验证可大大减少服务拒尽要求由于数据值超出限制所带来的本钱和阻碍。(固然，即使在发布束缚时，服务依然需要验证数据值。)
•参考信息应当具有时间戳或版本标记，以支持缓存、增量更新和连续的更新要求。
在服务可用时，你的组织里的聪明人会找到办法来使用它。请不要假定你在设计阶段所能够肯定的客户是所有将会调用此服务的客户。请不要寄希看于客户对服务协议会有更深进的理解，也不要相信客户只会向服务发送有效的要求。
服务设计
面向服务是创建散布式系统的最好实践方法的发展和完善。与此相同，它的模式来自于散布式对象技术和面向消息的中间件解决方案的成功的地方，同时它也肯定了这些体系结构的不完善的地方导致的反模式。“Indigo”小组的Don Box肯定了在考虑面向服务时要牢记的4个原则：
•原则1：边界是显式的。通过边界后面的显式消息传递方式，服务可以进行交互。对服务边界以后的空间，我们不做任何假定。逾越服务边界可能需要很高的本钱(例如，你可能需要扩大地域、可靠的边界或履行环境)。通过在服务之间正式地传递已定义的消息，我们明确地决定调用服务。显式的边界使我们可以正式地展现独立于实现进程的交互操纵——我们没必要明确地选择实现其它服务所使用的平台、中间件或编码语言。
•原则2：服务是自治的。作为独立的实体，服务采取了公道的行动。对服务边界之间的空间，我们不做任何假定。在面向服务的环境中，并没有主导的权威。服务的部署、版本控制和治理都是独立的。履行服务的拓扑可能会(也势必会)不断地发展。服务应当预感到对等的服务可能会(也势必会)失效，而且它可能会(也势必会)收到残缺的或恶意的消息。应当使用冗余和故障转移等技术来创建服务，以免服务失效。
•原则3：服务对架构和协议(而不是类)进行共享。服务只在其使用架构的结构表达式和使用协议的行动表达式上进行交互。服务的协议描写了消息的结构和消息的排序束缚。表达式的情势使机器可以验证传进的消息，这样我们便可以够保护服务的完全性。在时间变化时，协议和架构必须保持稳定，因此灵活地创建它们(例如，通过在架构中使用xsd:any)很重要。
•原则4：服务的兼容性是以策略为基础的。服务提供者和服务消费者都具有与跨边界交相互干的策略——操纵要求。提供端策略的1个简单示例是，服务可能需要调用者在服务提供者那里具有有效的帐户。从消费真个角度来讲，组织可能需要对逾越Internet的服务调用进行加密，这样它就只能使用可提供安全性增强的双向数据交换功能的服务。服务使用了机器可读的策略表达式来表现其功能和要求。策略断言是由1个稳定的全局唯1名称来标识的。单独的策略断言对全部系统而言是难以理解的;服务必须能够满足彼此的策略要求。
在你的服务边界上进行的通讯应当支持以上的原则。对面向服务的环境中存在的服务，这些原则需要它们之间的架构、协议和策略的正规表达式。可以开发专门为眼前的题目创建的机制，以表示服务的边界，但是这些机制仅限于创造者的影响范围之内。例如，假设你开发了1种系统，这类系统能够以1种特殊的方式表示架构和协议，而只有你的部份才能辨认这类表示方式，那末你就避免了你的服务在你的部份之外被使用。
为了充分实现面向服务带来的利益，你的服务边界表达式必须得到最广泛的采取，并具有最高的互操纵性。本行业已将SOAP消息中传播的WS-*协议明确选定为服务的互操纵性标准。在实际利用时，面向服务需要取得Web服务和SOAP消息，并使用WS-*协议。
选择1项支持面向服务的消息技术就相当于选择了1项能够支持SOAP和WS-*协议的消息技术。在目前发布的Microsoft技术中，这项技术指的是ASP.NET中的.asmx。假设你需要支持不断发展的WS协议，请结合WSE使用.asmx。假设要以1种互操纵的方式公然架构、协议和策略，并且此进程要独立于实现进程，那末请选择.asmx，由于它在目前的Microsoft消息技术中提供的支持是最好的。
服务边界的重点在于，在边界内可使用任何实现工具。假设你通过ASMX和/或WSE正式指定了你的服务边界，那末你便可以够在这些边界内选用任何技术或消息堆栈履行处理和数据交换。为了实现简单性和1致性，我们推荐保存此服务模型，并结合服务边界使用ASMX。不过，不论是为了支持特定的功能，还是为了支持现有部署工具的使用，MSMQ、Remoting或Enterprise Services都是服务边界内的公道选择。假设要实现服务的边界接口，这些技术就不适用了。
服务治理
SOAP规范的精巧的地方在于，它答应从服务的操纵要求(例如，与传送消息相干的指令和对服务的授权访问)中明确地分离服务的功能要求(服务将要处理的业务信息)。SOAP消息的正文满足了功能要求;SOAP消息标题中的元素满足了操纵要求。
就保持这类方式。假设你支持消息登录到你的Employee实体中，你就需要创建1个可以分析Employee实体的消息登录实现工具。假设你具有这样1个通用的消息登录实现工具——它可以在SOAP标题里定位合适的元素，而不用往管SOAP正文里包括了甚么，你的工作就会方便很多。
可互操纵的基础结构服务的开发和保护是1个本钱很高的项目。基于WS-*规范创建值得信任的服务实现工具，对它们进行测试并将测试结果与所有合作火伴组织使用的实现工具相比较，将会超出大多数IT预算的范围。系统供给商可以逾越更广阔的用户群利用这些开发本钱，并针对其他供给商的补充技术测试互操纵性。在创建这些服务(而不是从系统供给商处取得这些服务)之前，各个组织应当进行认真的思考。
那末，在系统供给商依然把持着WS-*规范的实现工具的情况下，为了满足目前的操纵要求，IT部份应当怎样做呢?
折衷。使用能够最有效地满足你的需求的现有技术，假设本地服务技术具有可用性并得到了你的系统供给商的充分支持，那末就计划向本地服务技术进行移植。假设你需要保证传输的安全性，请使用HTTPS;假设你需要可靠的消息功能，请使用MSMQ。
某些操纵要求将会简化组织的服务组合，但是其实不会得到系统供给商的良好支持。1部份示例可能来自于垂直行业的需求，例如，在汽车行业中需要跟踪零部件的来源;同时，其它示例多是完全组织化的，比如主动的跟踪调查计划，其目的是在雇佣和提拔员工的进程中保证同等的机会。
当你需要设计和创建这些服务时，请参照供给商的WS-*协议实现工具中出现的模式：
•与相干的团体进行合作，以有效地搜集需求;对垂直行业的需求，可与贸易火伴乃至是竞争对手合作。
•为SOAP标题定义架构，这类SOAP标题可以附加到任何消息上，以传送操纵信息。
•考虑1组可有效地重复利用的关注点和因素。例如，1条包括保健信息的消息可能需要转达多个具有类似结构的隐私声明。
•通太重复利用处理了真实的横向关注点(比如对物理地址的描写)的工作成果来构成你的架构。
•重复构建进程;在时间和预算答应的情况下，努力构建你的消息基础结构。
面向服务的解决方案的模式
那末，为了创建互联系统，你现在应当怎样做呢?是否是应当立即着手围绕面向服务的模型重新设计你的全部利用程序组合?还是应当先观看1下?
Microsoft本身的经验通过我们的客户和合作火伴的经验得到了加强，它提出了1个更适当的方法。现在，对很多的业务和技术模式，面向服务都提供了明确的利益。
最普遍的模式是信息集成，它在Rum Island crawl(爬)方案中得到了描写。由于技术体系结构在过往的30年里不断地发展，组织开始治理或取得大量的散布式冗余数据。例如，1个客户的完全描写信息可能会传播到1打业务利用程序和数据库。这类信息很难完全同步，为了实现最好的客户(或合作火伴或员工)交互而进行的信息聚合也没法得到足够的支持。信息集成服务是1种有效的方法，它可使用这些关键实体的同1视图来表示你的利用程序组合，并保证你的所有后端系统之间的信息的1致性。Microsoft的内部项目Alchemy就成功地克服了我们在公司信息存储区题目上的挑战。信息集成项目可以从战术角度(比如Rum Island的例子)到广泛的战略角度(逐渐深进的信息访问再设计和跨企业治理)运行。
传统集成模式描写了对服务的战术性使用，其目的是保存对业务利用程序的现有投资，同时扩大它们实现的功能。例如，为了符合新的规定，服务可能会在现有的ERP包前增加支持功能。利用程序也将得到重新设计，以便与服务交换消息，服务将会提取与合规性有关的数据，然后向ERP包发送要求。
上1个例子提出了1个更广泛的面向服务模式：流程治理。在此模式中，“标题”元素用来传送关键的业务元数据——从客户要求的周转时间到特殊业务决策批准者的身份。基础结构服务将会捕捉到此元数据，以用于实时分析和/或聚合分析。“本地服务”流程将会把此信息包括在SOAP标题中，非本地利用程序则需要进行重新设计，以便将元数据作为消息传送到治理服务器。
另1个略有不同的模式(或可以直接称为派生的模式)是1致的访问——在1组不同的利用程序需要连接关键的后端资源时，使用服务层来保证各种操纵要求得到1致的履行。通过命令所有访问通过1个服务接口进行路由，组织可以履行1致的访问授权、本钱分配和负载治理。
很多服务都提供了某种情势的资源虚拟化。这里有1些例子：
•辨别上下文和辨别内容的要求路由，比如向指定地区的农场房地产专业代理商发送房地产咨询题目。
•到分区信息存储区的要求路由(要求者不必了解分区方案)。
•逾越可用资源的负载平衡要求——从客户服务代表到流视频源。
最后，各组织都非常成功地使用这些服务实现了流程具体化。目前，通过使用Web服务，使用者可以安全地协商工资单处理情况、员工用度报销和后勤支持等事宜。移动电话服务提供商和Internet门户使用Web服务来聚合各种内容。需要面对客户的组织使用Web服务来创建合成的报价材料，比如包括了飞机票价和租车价格的信息包。基于目前的技术堆栈，流程具体化取得成功的关键是对你自己的要求进行治理——根据现有技术的限制，折衷处理你的要求，这样你就不必使用你的利润或储备资金来创建将会在几年之内更换的基础结构服务。
这些只是高级模式的几个例子，你的组织目前可能会用到这些高级模式。你了解你自己的业务;互联系统怎样才能帮助你呢?
http://www.fw8.net/TAG:程序,系统,信息,消息,业务
|
评论加载中...
|
邮 箱：admin@fw8.net 