|
以文本方式查看主题 - 计算机科学论坛 (http://bbs.xml.org.cn/index.asp) -- 『 Web Services & Semantic Web Services 』 (http://bbs.xml.org.cn/list.asp?boardid=10) ---- [转帖]SOA的进化 (http://bbs.xml.org.cn/dispbbs.asp?boardid=10&rootid=&id=29959) |
|
-- 作者：coca -- 发布时间：4/4/2006 10:07:00 AM -- [转帖]SOA的进化 SOA的进化(一)——SOA时间轴 【2006-02-08 09:58】【Cowboy】【GoGo时空】 本文审视XML、Web服务及SOA间的关系，并解释厂商和标准组织如何从那些持续浮现的Web服务规范中形成奇妙的竞争与协同竞技场。然后我们从应用架构简短历史的叙述着手来对过去的二十年作一个总结。 1 SOA时间轴(从XML到Web服务再到SOA) 我们从讲述形成当前SOA平台的关键工业开发入手来建立时间轴。然后我们看一看SOA在它的权限范围内，如何作为当代架构的平台而改变了XML与Web服务技术的角色。 1.1. XML简史 如同HTML，扩展标记语言(XML)系W3C所创建，源自流行的标准通用标记语言(SGML)，它在60年代后期就已存在。这是广泛使用的元语言，允许组织增加原始文档数据。 XML在90年代后期的电子商务运动中声名鹊起，服务器端脚本语言可以经由互联网而处理业务。通过XML的使用，开发者能够给任何片段附加上意义和上下文，再跨越互联网协议传输。 XML不仅被用于以标准化的方式来表达数据，其语言自身还被用作一系列的附加规范的基础。XML Schema定义语言(XSD)与XSL转换语言(XSLT)都以XML表达。这些规范，事实上已成为关键核心XML技术集的关键部分。 XML表达架构代表了SOA的基础层。在其内部，XML建立了在服务各处流动的消息格式与结构。XSD schemas保持消息数据的完整与有效性，而且XSLT使得不同的数据表达间通过schema映射而能够互相通信。换句话说，没有XML你在SOA内寸步难行。 1.2. Web服务简史 在2000年，W3C接受了一项关于简单对象访问协议(SOAP)规范的提案。这个规范本来设计用于(并在一些案例替代)专有RPC通信。想法是对于在构件间传输参数数据可以序列化成XML传送，然后支序列化成其原生格式。 很快，公司及软件厂商开始看到，对于推进通过构建于专有-免费的互联网通信框架之上的电子商务技术，存在日益巨大的潜力。这最后导致了创建一个纯粹的、基于Web的分布式技术能充分利用概念标准化的通信框架，来桥接组织之间和组织内部所存在的巨大差异。这个概念被称为Web服务。 Web服务最重要的部分是其公共接口。它是分配服务识别并使其激活的核心信息块。因此，首先支持Web服务的是Web服务描述(WSDL)。W3C第一份WSDL评议提案是在2001年，此后还在不断地修订这一规范。 为了进一步的开放协同性的愿景，Web服务需要一个互联网友好的、XML兼容的通信格式，以便能够建立一个标准化的通讯框架。尽管有别的选择，譬如可以考虑XML-RPC，但SOAP因为工业界的偏好而胜出，并且保留了最初的通讯标准用于Web服务。 为支持SOAP的新角色，W3C随之发布了更新版本的规范，同时考虑了RPC风格的与文档风格的消息类型。而后者在SOA里面更为常用。最终，“SOAP”一词不再代表“简单对象访问协议”的首字母缩写。到了规范的1.2版，它变成了一个独立的术语。 完成第一代Web服务标准家族的是UDDI规范，它原本由UDDI.org所开发，被递交到OASIS之后，它继续与UDDI.org一起合作开发。这个规范考虑在组织内部及组织边界之外来创建标准化的服务描述的注册。UDDI提供了潜在的对Web服务在一个集中的位置注册，在此处能够被服务请求者所发现。WSDL与SOAP不同，UDDI尚未被工业界所普遍接受，并且保留了一个可选的SOA扩展。 开发定制的Web服务可适应变化的业务需求，并且第三方市场出现了促进各种实用服务的销售或租赁。现存的通讯平台，譬如面向消息的中间件(MOM)产品，结合Web服务可支持SOAP之外的其他消息协议。一些组织可迅速合并Web服务，以促进B2B数据交换经常要转变为EDI(电子数据交换)替代品的需求。 1.3. SOA简史 不久前组织才开始意识到只需要缓和地替代现存的分布式应用，Web服务可成为独立的架构平台---可使用Web服务技术集的效益来实现企业中服务概念的平台。这样，面向服务架构开始进入IT的主流。 在这一点SOA频繁地以不同的方式被分类，经常依赖于构建服务所用的实现技术。早期的模型，主要从Web服务标准初始系列中得到灵感，将SOA定义为一个围绕三个基本的构件的架构模型:服务请求者，服务服务提供者与服务注册(图1)。 图1. SOA的早期形 第一代Web服务标准实现此模型的以下方面: · WSDL描述服务。 · SOAP提供了用于服务及其请求者的通讯格式。 · UDDI提供了标准化的服务注册格式。 从物理架构的角度，基于Web服务的SOA第一次变异实际上超越了原始SOA模型。你或许能回忆起原始SOA不需要使用服务注册。作为替代，发现被归类为当代SOA的一个特征，通过面向服务原则在服务层面被提倡。 我们的原始SOA模型在今天可轻易获得，因为它已被所有主要厂商的开发及运行平台所支持。这些相同厂商都有关于SOA的远大计划，其中许多现在已经能够自我证明。当代SOA的诸多特征，大都是过分主动的开发与协作的结果，已经产生了一系列第一代Web服务平台的扩展。知名的“第二代”或“WS-*”规范，这些扩展处理特殊的功能区域，Web服务技术平台全面提升至企业水平。 补充WS-*领域对于将面向服务概念引入业务分析的世界也很重要。通过面向服务，业务逻辑能够清晰地被封装，并从根本的自动化技术中抽象。这个愿景藉由业务流程定义语言的提升而得到进一步支持，最知名的是WS-BPEL。这不仅考虑到将传统的业务流程管理(BPM)模型解决成一系列的服务，更进一步提供具体的和可执行的格式充分表达业务逻辑的语言能力，填补了分析与实现间的空隙。 这些及其他工业影响已经扩大了SOA的潜在范围。如同更多的当代特征被增加，也很可能今天我们所归类的当代SOA，会形成未来原始SOA的基础。 SOA是一个真正的进化。今天的结果明显是被不同的相关标准组织和软件厂商主动驱动的结果。通过受协作与竞争的混合刺激的不稳定环境，扩展被作为战略定位，每个都定义了我们称为当代SOA技术平台一个特定部分。在第2节，我们近距离看看标准的开发过程。 1.4. SOA如何改造XML与Web服务 如同任何架构，SOA引入了边界和规则。尽管当代SOA可能由XML及Web服务技术平台所构成，但这些平台需要经历大量的变化，以便其各自的技术被适当定位并在面向服务架构范围内加以利用。 使用XML或Web服务的传统分布式应用环境因此肯定有一些重新实现，面向服务的设计原则需要在技术与心态方面都进行改变。以下是当你必须对现存实现翻工时，你可能面对的一些潜在问题示例。 · SOA现在需要数据表达与服务建模标准表达保持一致。这个相当含糊的需求有许多含意，并主要促进内在协同性。 · SOA依赖于负责所有服务间通信的SOAP通讯。结果，所有需要XML的地方，一般也会有SOAP消息，以照顾传输、临时处理与路由及最终交付。XML文档与关联的XSD schema现在经常需要有意地与SOAP通讯一起建模。 · SOA使用标准化的文档风格的通讯。从RPC风格迁移到文档风格的消息给服务描述的设计强加了变化。特别地，接口特征需要以更普通的术语表示，并全面增加操作粒度。 · 由于强调文档风格的SOAP消息，SOA促进内容及高智能模型。这个支持服务的无状态及自治，并使消息传输的频度最小化。然而先前的RPC风格的方法支持带有目标数据的小颗粒XML文档传输，在SOA内的XML文档经常需要代表不止一个数据语境的绑定数据。 · 直到WS-*扩展的高阶信息能力普遍流行，许多应用都将需要配备SOAP报头来实现临时解决方案以管理复杂的消息交换。一些更急迫需求包括管理与关联。这些临时的设计有效地建立了转变模型，需要时可轻易地迁移到工业标准的实现。 要点总结 核心XML技术集已成为分布式互联网架构的通用部分。现在也提供基础数据表达及SOA数据管理层。 第一代Web服务架构来自关键标准开发:WSDL、SOAP与UDDI。然而UDDI对于多数据环境而言仍旧是一个可选的发现机制，WSDL与SOAP已经成为构建在XML层之上定义SOA基本通信框架的核心技术。 SOA充分利用XML与Web服务率先铺设的道路。它将久经考验的概念与先进技术的结合，已经被IT社团所充分接受。 尽管当代SOA已经形成并有了对XML与Web服务的工业级接受度，SOA的到来对于已有XML及Web服务的传统应用还是带来了改变。 SOA的进化（二）——标准组织与贡献厂商 【2006-02-08 10:05】【Cowboy】【GoGo时空】 本文审视XML、Web服务及SOA间的关系，并解释厂商和标准组织如何从那些持续浮现的Web服务规范中形成奇妙的竞争与协同竞技场。然后我们从应用架构简短历史的叙述着手来对过去的二十年作一个总结。 2. SOA的持续进化(标准组织与贡献厂商) XML作为一种语言，被定义为一个规范，但实际上也被用作表达所有的XML及Web服务规范。这个普遍思路褒扬了这样的事实:不管规范的规模会有多大的增长，都分享了一个公共的根基。 无论你是否需要在这些扩展上直接工作，它们的存在与进化将对你所构建的面向服务解决方案有持续影响。有关规范与标准形成的过程及原因的知识，也因此关系到你对于SOA世界的理解。 2.1. 比较“标准”、“规范”与“扩展” 这些术语常可交替使用，但是许多---特别是与标准组织相关---还是有明显的区别。规范是标准的建议文档。直到规范被提交到一个公认的标准组织，并被接受、公布，它都不是正式的工业标准。 尽管如此，规范还可被厂商发布(特别是合作厂商)，并随之被这些厂商平台实现，通常会进一步成为非正式的工业标准，只是由于它们变得非常普遍。 为避免混淆，本书将这些术语作如下定义: · 标准 公认的工业标准。所有的第一代Web服务规范可认作标准，许多XML规范同样如此。 · 规范 被提议的或公认的标准，以规范来描述。XML标准，第一代Web服务标准，以及WS-*扩展都以规范的方式存在。 · 扩展 扩展典型地代表WS-*规范以及WS-*规范所提供的特性。 2.2. 标准组织对SOA的贡献 众所周知，SOA由标准驱动。早先的平台在厂商特定的边界内实现;环境内的标准实际上是专有的。允诺厂商中立的通信框架常伴有不可谈判的需求，就是要定义此框架的标准是同样也厂商中立的。 可是，如何确切地制定这些标准，并非总是很清晰。互联网标准组织现在已经存在很长时间，但是它们各自的议程总不大清楚，有时甚至有所重叠。更复杂的问题是这些主要的厂商中立标准的贡献者是厂商自身。微软、IBM、Sun微系统以及众多其他公司已经扮演了日益重要的角色，不仅是制定Web服务规范，还促进了实现这些规范作为工业标准的实现。 厂商如何贡献并影响了标准的开发过程将在后续章节解释。让我们首先来熟悉三个最主要的标准组织。它们共同负责完成XML与Web服务架构的进化。 万维网联盟(W3C) 最初由提姆•伯尼尔斯•李于1994创立，W3C对于万维网作为全球信息分享的语义媒介负有极大责任。它开始于HTML的发布，这是IT行业所产生的最流行的一种语言。当互联网用于包括由电子商务开端的更广范围时，W3C开始制定关键基于XML的基础标准，象XML Schema及XSLT。 四个独立工作组对W3C的Web服务活动工程作出了重要贡献，导致了重要的Web服务基本标准开发。首要的是SOAP与WSDL标准，现在已成为Web服务相关的标志性规范。更近一些，W3C已提出了Web服务编舞描述语言(WS-CDL)，一个控制标准化的服务间交换模式的规范。值得关注的还有Web服务架构文档本身。尽管这个文档不断经历变化，它还是保留了一个参考点，且是少数可用的平台中立的Web服务架构文档之一。 W3C以正式和严格的标准开发方法而闻名。其过程需要规范受制于诸多的评审与修订阶段，每一个新的版本都会发布在其公开网站上。这样完全的过程要以时间为代价，完成一个标准要用两到三年。 结构化信息标准进步组织(OASIS) 原本于1993年作为SGML开放组织而成立，OASIS五年之后改变了其名称，代表其关注点从SGML转为XML相关的标准。OASIS拥有来自超过600家组织的数千个成员，是一个公认的互联网标准制定组织。 OASIS假定拥有著名的WS-BPEL规范的所有权，并且还以其ebXML的开发(一个旨在建立标准化的B2B数据交换方法的规范)和对于UDDI规范的贡献而闻名，后者是第一代Web服务平台的核心标准。 OASIS组已经有力地推进了XML与Web服务安全扩展的开发。安全声明标记语言(SAML)用扩展访问控制标记语言(XACML)提供了单点登录与授权领域的重要特性。然而，最重要的安全相关项目由Web服务安全(WSS) 技术委员会完成。这个小组被委托进一步开发并实现重要的WS-安全框架。 不同于W3C集中于建立核心的、工业未知标准，OASIS组的主要兴趣在于利用这些标准去制定附加规范以支持不同的垂直行业。而且，OASIS所用的标准开发过程要明显短一些。 Web服务协同组织(WS-I) WS-I的主要目标不是创建新标准，而是确保最终实现开放的协同性目标。这个联盟建立于2002年，已经迅速成长并获得了近200家组织的支持，包括所有的SOA主流厂商。 WS-I最为人所知的是发布基本配置文件，用于建立可用标准的基础推荐文档，这些文档共同用于形成最想要的协同性架构。藉由正式地定位WSDL、SOAP、UDDI、XML与XML Schema规范的版本，基本配置文件已成为IT社团内的重要文档。这些组织想要确保它们开发的SOA与其他系统充分协同，并能够保证对于遵从基本配置文件的高层次赞同。 最近，WS-I开发了基本安全配置文件。本质是与基本配置文件属于同一概念，这个文档建立了最重要的Web服务与XML安全技术集合。WS-I已宣布了持续发布针对每一Web服务主要方面的相关协同性配置文件计划，包括可靠通讯、Web服务管理与编曲。 除了建立基本的协同性架构之外，配置文件还补充了示例实现及最佳实践，以便指导如何与标准一起使用从而达到协同性品质。而且，WS-I还提供了一系列测试工具可用来确保符合配置文件。许多厂商还提供了这些工具的变种，例如:将基本配置文件作为一致的有效性标准的一部分进行有效性检查。 WS-I努力提供一个场所，能在同一水准上接受其成员的贡献。当其成员包括重要的SOA厂商之时，没有哪个公司可以比另一个更有权力，不管其规模和市场分额有多大。 尽管W3C近期拒绝了加入WS-I联合成员的邀请，但来自WS-I的工作组成员不断主动地直接参与W3C及OASIS的各个工作组工作。这些WS-I代表的角色持续对协同性相关问题进行反馈。 它们如何比较 表2.1在概要地提供了我们本节所讨论的三个组织间的相互比较。 W3C OASIS WS-I 创建 1994 1993作为SGML开放组织，1998作为OASIS 2002 大约成员 400 600 200 全面目标（与 SOA相关） 为了促进Web的进化，提供基础标准以改进在线交易及信息共享。 经由特定的Web服务标准提升在线贸易及商务。 利用Web服务标准鼓励标准化的协同能力。 显著交付物（与SOA相关） XML、XML Schema、Xquery、XML加密、XML签名、Xpath、XSLT、WSDL、SOAP、WS-CDL、WS-寻址、Web服务架构 UDDI、ebXML、SAML、XACML、 WS-BPEL、WS-安全 基本配置文件、基本安全配置文 表2.1. 标准组织的比较 2.3. 主流厂商对SOA的贡献 尽管标准组织关于标准应当如何开发有其自已的文化与哲学，它们都要受到来自商业市场的深深影响，因此也应当受到支持。即使这些组织作为独立实体存在，它们的成员也包括了相当多的所有主要的软件厂商。而且，这些厂商同样也是这些标准的主要贡献者和最终开发者。 一些已经参与标准开发过程的公司包括:微软、IBM、BEA系统、Sun微系统、Oracle、Tibco、惠普、佳能、Commerce One、富士通，Software AG、北电、Verisign与WebMethods。这种由厂商间的交互、联盟，及与标准组织动态合作而产生现象相当有趣，值得进一步讨论。 为何要开发标准支持SOA 没有人或组织拥有或控制SOA。从专有平台发展而来的架构促进并支持开放的标准与厂商中立的协议，只要主流软件厂商选择支持，SOA将可能为此保留一个重要的架构。 那是因为，只要SOA能够在全球范围内象现在这样被继续接受，它的效益就能实现。如果只有一部分的解决方案技术跨应用通信所支持，那么构建协同应用的关键是什么呢? 不管如何，SOA今天在所有主流软件组织优先级列表上是首要的。与SOA的不兼容甚至不予考虑，因为这意味着你自己切断了通向正蓬勃成长的市场之路。对于现在和可预测的将来，SOA确实如此。 厂商影响 即使没人单独控制SOA，人人都有关于应当如何形成底层技术平台的观点。为了这一目的，厂商在标准开发过程中的影响已经将SOA的进化转变成一场战争议程。 每个厂商在关于计划如何提升自己产品线方面都有自己的愿景。IBM已经展示了一个技术路径支持在其WebSphere平台内逐渐增加对于SOA的支持。微软不仅在.NET技术框架内逐渐增加SOA特性，而且还构建直接将Web服务技术植入Windows操作系统。 尽管Web服务标准必须保持非专有化，能够帮助形成标准的厂商却有动机考虑使用专有技术。这不是必经的歧途或甚至有意的操纵。任何人可以主张这些标准由通用产品的有意支持来实现，他们应当通过代表更大市场份额的产品线厂商需求所影响。然而，挑战在于要争取所有厂商来决定应该如何设计一个标准。 厂商联盟 过去厂商间的争斗已经导致厂商间的很多不信任。现在，当想要与规范合作有意去鼓励厂商平台间的协同性时，这些猜疑会表面化并变成障碍。这个问题，与如何紧密联合厂商需求一起是一个特别的规范内容，这已经导致了一些公司形成松散联盟。 形成联盟使得厂商为了共同目标而通力合作。通常，联盟的寿命开发止于开发一个特定规范的过程。然而，多数著名的长期合作者(IBM、微软与BEA)已经保持其工作关系而推动了一系列的WS-*扩展。 一个更常谈论的示例是在创建了WS-可靠通讯规范的标准开发中，联盟所扮演的重要角色。本来，需要的可靠通讯机制由一个OASIS技术委员会所处理。其贡献者包括Sun微系统与Oracle，且规范被命名为WS-可靠性。然而，它发布之后只有数周的时间，微软、IBM及其他厂商宣布它们拥有自己的规范，称为WS-可靠通讯。 规范与处理相同的全部需求非常类似。然而，即使它被发布之后与还不能通过(或甚至提案)一个标准组织所开发，WS-可靠通讯扩展成为直接的竞争者。这只是由于这样的事实:厂商通过共同开发它而占据了一块巨大的Web服务技术平台市场份额。类似这样的事件，不仅反映了Web服务行业的不稳定状态，也揭示了缺乏权威标准组织的把控。 选择一个标准组织 可是，通常来说，通过标准组织而获得正式规范对厂商有益。正式建立规范的目标在于支持一个开放的标准，并受制于开放给公众的一般过程。 然而，在时标准组织的选择是有含意的。另一个在标准开发竞技场中的动力是与市场需求直接的。厂商具有市场驱动的目标，发布的产品必须满足客户的要求并匹配或胜过竞争对手所提供的(或计划提供的)。假定W3C仰赖一个冗长的标准开发过程，就会诱惑厂商将它们的标准提交到OASIS。 尽管组织已经开发了相似的规范似乎有所多余，就象是人往高处走。而且尽管事实上对立的动机似乎可能以反作用力来鼓励平台中立的技术标准，迄今为止已发布标准的品质已经足以促进SOA的进一步发展。 为什么你应当关心 在第3章采用SOA的常见缺陷一节中，我们讨论了伴随在产品与标准发布左右的开发的价值。让我们通过重申这一点来总结这一节，并列举一些你应当密切关注标准开发领域特殊理由。 · 当计划迁移到SOA时，考虑一个成熟的关键扩展处理是有益的。这些规范将结束你对这个架构最后支持的功能性需求。 · 观察标准开发的过程，会让你自己对于某个规范进步与否形成自己的观点。对你来说这很重要，可以让你把握现存面向服务解决方案的进化方向。 · 与标准的开发保持接触，并且谁在主导它们能使你更好地理解开发平台的差异，你需要保持厂商中立的视角。这将增强你更好地比较可用产品平台的特性以及对SOA的支持。 要点总结 W3C对于万维网进步的贡献不容忽视。在SOA的舞台，它的职责主要在于标准，负责提供核心和通用的功能规范。 OASIS从一个SGML标准组织进化为专注于电子商务规范的组织。其全部目标在于创建特定行业的标准，并鼓励有电子商务能力的企业间的交易和商务。 作为一个组专注于不同平台的协同性关系，WS-I不产生技术标准。这个组织提供配置文件建立一个经过验证和测试的标准集。组织遵从这些配置文件，可保证它们的环境支持一个工业标准水平的协同性。 尽管标准组织作为独立实体存在，它们都接受来自代表厂商的支持和贡献。厂商的贡献由利己和公共利益的共同驱动。 保持标准开发的高度很重要，因为这让你做一个更专业的SOA迁移计划。 SOA的进化（三）——SOA的根源 【2006-02-08 10:32】【Cowboy】【GoGo时空】 本文审视XML、Web服务及SOA间的关系，并解释厂商和标准组织如何从那些持续浮现的Web服务规范中形成奇妙的竞争与协同竞技场。然后我们从应用架构简短历史的叙述着手来对过去的二十年作一个总结。 3. SOA的根源 (SOA与过去架构的比较) 我们现在实际地跳回时间轴看一看过去架构与SOA的差别。这是一项有趣的研究， 我们能够看出SOA许多当代特征的起源。 3.1. 什么是架构? 自打有计算机处理的自动化解决方案方案起，技术架构就已存在。然而，在较老的环境中，解决方案直接建构于抽象的任务上，并规定其架构很少被执行。 随着多层应用的崛起，应用交付的变异开始剧增。IT部门开始认识到需要定义标准化的基线应用，作为其他应用的模板。这个定义自然是抽象的，但明确地解释了所有解决方案以这个模板为基础，包括其技术、边界、规则、限制及设计特征。这就产生了应用架构。 应用架构 应用架构对于应用开发团队的意义，相当于蓝图对于建筑工团队的意义。不同的组织印证不同水平的应用架构。一些保持了高水平，提供技术蓝图的抽象的物理及逻辑表达。另一些则包括更多的细节，类似通用数据模型，通信流程图，应用范围的安全需求，以及基础设施方面。 对于一个组织而言有几个不同的应用架构的情况是不希奇的。一个架构文档典型地代表了不同的解决方案环境。例如，一个同时拥有.NET与J2EE解决方案的组织很有可能针对每一种有分别的应用架构规范。 任何应用级架构的关键部分在于它既要直接反映解决方案的需求，同样又要考虑长期的、策略性的IT目标。正由于这个缘故，组织内的应用架构会伴以企业架构，并与其中居统治地位的一个保持一致。 企业架构 在较大的IT环境，关键在于需要控制并指导IT基础设施。当有很多不同的应用架构共同存在的时候，且有时甚至要整合，底层的主机平台变会复杂而繁重。因此，通常会创建一个控制规范，为企业内存在的所有异质形态的提供高层概述，同时给出支持基础设施的定义。 继续我们前一个类推，对于组织而言，企业架构规范相当于一个城市的城市规划。因此，城市规划与建筑蓝图间的关系，可与企业与应用架构规范间的关系相类比。 典型地，企业架构的变化直接影响应用架构，这是为什么架构规范通常由同一组人来维护。而且，企业架构经常包含组织长期技术和环境发展规划。例如，阶段性的目标有可能是要立足于这个规范来逐步淘汰过时的技术平台。 最后，也可能会定义技术与策略背后的企业级安全度量。然而，这经常会被作为单独的安全架构规范。 面向服务架构 简单而言，面向服务架构跨越了企业与应用架构两个领域。当被用于跨多解决方案的环境时，SOA所提供的潜在效益才能真正释放。这个是对可复用和可协同服务的投资，并且充分利用基于厂商中立的通信平台。这并不意味着企业必须变成面向服务。SOA所引入的特性及特征大部分都属于这一范畴。 注意术语“SOA”并不意味着一个特殊的架构范围。SOA可以是指一个应用架构，或是用于跨企业的技术架构的标准化方法。因为SOA天生的可组合性(意味着单个的应用层架构可由不同的扩展及技术组成)，完全适用于超越SOA的组织。 请注意，如同前一章所解释的，Web服务平台提供了众多实现SOA形式中的一个。它是本书专门研究的一种方法，但是还存在其他方法，比如由传统的分布式平台所提供的这些。术语方面有一点很重要，就是在后面章节中及整本书中所用的术语“SOA”是指在第3章所建立的当代SOA模型(基于Web服务与面向服务原则)。 3.2. 比较SOA与客户-服务器架构 几乎在任何环境中，只要有一段软件从另一个请求或接收信息，都能够被称为“客户-服务器。”几乎每一个不同的应用架构都曾存在(包括 SOA)一种客户-服务器的交互元素。然而，行业术语“客户-服务器架构”通常是指特殊的前一代环境，期间客户端与服务器扮演了特定的角色，并有清晰的实现特征。 客户-服务器架构简史 初期庞大的主机授予组织严格的计算方式，通常被视作是客户-服务器架构稚形。这些环境，其中庞大的主机后端伺服瘦客户端，被看作单层客户-服务器架构(图2)。 图2. 一个典型的单层客户端服务器架构 共5页。 1 2 3 4 5 8 : 主机系统天然支持同步及异步通信。后一种方法主要用于让服务器连续不断地接收来自终端的字符，以响应个别的击键事件。只在某种条件下服务器才会响应。 虽然它仍有残留痕迹，但是当两层客户-服务器的变化设计在80年代后期出现时，主机作为最初的统治计算平台开始衰退。 这个新方法引入了委派逻辑、以及处理职责下发到单个工作站的概念，导致了胖客户的诞生。受图形用户界面(GUI)创新的进一步支持，两层客户-服务器被认为是前进了一大步，并在90年早期持续统治了IT界数年之久。 这个架构的通常配置包含多个胖客户端，每一个都有自己到中心数据库服务器连接。客户端软件执行大量处理，包括所有的展现相关及多数的数据访问逻辑(图3)。一个或多个服务器通过累积可扩展的关系型数据库管理系统，促进了这些客户端。 图3. 典型的两层客户-服务器架构 让我们通过单独地和将它们与SOA的相应部分作比较两种方式，来看一看两层客户-服务器架构的主要特征。 应用逻辑 客户-服务器环境将大多数应用逻辑放到客户端软件中。这导致庞大的程序连同后端资源来一起来控制用户体验。分布式业务规则是一个例外。一个流行趋势是将嵌入的和维护的业务规则与数据关联，放入数据库的存储过程与触发器之内。这略微抽象了一组来自客户端的业务逻辑，并简化了数据访问编程。尽管如此，客户端还是承担着所有的展示任务。 当代面向服务解决方案中的展现层会有所不同。任何软件片段若有能力依照所需的服务契约进行SOAP消息交换，都可归为服务请求者。同时通常也期望请求者能提供服务，展现层的设计完全开放并对应特定的解决方案需求。 在服务器环境内，存在关于应用逻辑如何驻留与分布的选择权。这些选择权不排除数据库触发器和存储过程。同时，面向服务设计的原则开始起作用，通常指导划分自治处理逻辑的单元。这促进了特定设计品质，比如服务无状态化及协同性，还有可组合性及复用性。 另外，常有这些处理逻辑单元在SOA内不属于任何解决方案的情形。这也支持了促进复用以及跨越应用边界的松散耦合这一终极目标。 应用处理 因为大部分客户-服务器应用逻辑驻留于客户端，客户端工作站负责了大量的处理。80/20比率常被作为一个经验法则，按此法则数据库服务器承担了20%的工作量。尽管如此，数据还是常常成为这些环境中的性能瓶颈。 有大用户量的两层客户-服务器解决方案，通常需要每一客户建立其自身的数据库连接。通信可预期是异步的，而且这些连接是永久的(意味着它们需要通过用户登录并保持活动直至其退出应用)。专有数据库连接是昂贵的，并且资源需求经常压垮数据库服务器，给所有用户以可观的反应时间。 另外，假定客户被分配以主要的处理职责，他们常要求重要的资源。客户端执行完全是有状态的，并要消耗大量的固定PC内存。用户工作站因此经常需要专门运行客户端程序，以便所有可用资源能够提供给应用。 SOA中的处理是高度分布式的，每一服务都有一个清晰的功能边界和相关的资源需求。在面向服务架构建模技术中，对于如何能够定位及部署服务你有很多的选择。 企业解决方案包含多个服务器时，每一个都装有Web服务并支持中间件。因此，对于SOA而言没有固定的比率。服务可根据需要分布，而且在决定物理部署配置时，性能需求是要考虑的因素之一。 服务与请求者间的通信可以是同步的或是异步的。这一灵活性允许进一步改进处理，特别是使用异步的消息模式时。另外，通过在消息中放入更多的智能，可获得消息层面的语境管理选择。这促进了无状态的及自治的服务本性，并进一步经历减少对状态信息缓存的需要。 技术 客户-服务器应用的出现促进了第四代4GL编程语言的使用，比如Visual Basic与PowerBuilder。这些开发环境充分利用了Windows操作系统所提供的能力，来创建更美观丰富、更具交互性的用户界面。尽管如此，传统的第三代语言，比如C++，仍在使用，特别是对于有更严格的性能需求的解决方案。在后端，主流的数据库厂商，象Oracle、Informix、IBM、Sybase与微软，提供了强健的关系型数据库管理系统，能够管理多连接，同时提供了灵活的数据存储及数据管理特性。 SOA所用的技术集实际上并不象它所延展的那么多。旧版本的程序语言的更新版本，象Visual Basic，依旧能够用于创建Web服务，且依旧可以使用传统数据库。尽管如此，SOA的技术版图已经变得日渐不同。除了Web技术的标准集(HTML、CSS、HTTP等等)，当代SOA一并带来了建立XML数据表达架构的绝对需求，还有SOAP通讯框架，以及服务架构所包含的永远扩展的Web服务平台。 安全 除了数据的存储与管理以及嵌入存储过程和触发器中的业务规则，安全是经常在客户-服务器架构的服务器层面集中处理的另一个部分。数据库十分复杂，足以管理用户帐户及用户组长，并将其分配到物理数据模型的个别部分。 安全也能够客户程序中控制，特别是当它与特定应用逻辑执行的业务规则相关联时(譬如挑选用户对部分用户界面进行限制访问)。另外，与操作系统级的安全协作可实现单点登录，此时应用直接继承操作系统的登录账户信息。 尽管有人夸耀SOA的优势，许多架构师却羡慕客户-服务器的安全性。企业数据经由单点鉴权而受到保护，建立了客户端与服务器间的单一连接。在SOA的分布世界中，这是不可能的。安全变成一个重要而复杂的问题，与必需的安全措施程度直接相关。牵扯到许多典型技术，大多数包含在WS-安全框架中。 管理 客户-服务器时代终结的一个重要原因在于相关分发的大量维护成本的增加，以及跨工作站应用逻辑的维护。因为每一个客户装载有应用代码，每一次应用更新都要对所有的工作站重新分发软件。在较大型的环境中，这造成了高度繁重的管理流程。 维护问题跨越了用户端和服务器端。客户工作站受特定环境问题的支配，因为不同的工作站会安装不同的软件程序，或者可能购买不同的硬件厂商。更有甚者，还增加了对服务器端数据库的要求，特别是当客户-服务器应用拓展到更大的用户基础时。 因为面向服务的解决方案会有不同的请求者，它们还要受到来自客户端维护的挑战。同时其分布式后端要适应应用及数据库服务器的扩展性，会引入新的管理需求。例如，一旦SOA发展为服务复用并成为多服务组合的一部分，服务器资源与服务接口的管理会需要强大的管理工具，包括私用注册的使用。 3.3. 比较SOA与分布式互联网架构 这似乎有点自相矛盾，如果SOA可被视作分布式互联网架构的一种形式，同时我们初期建立早先类型的分布式架构也可被设计为SOA。尽管如此，且尽管现在的分布式环境可能已经深深地受到了面向服务原则的影响，SOA这样的变化仍旧是罕见的。故而在此所提供的比较是将传统的分布式互联网架构作为其最常被设计的风格出现。 分布式互联网架构简史 为了对付两层客户服务器架构相关的成本与限制问题，构建基于构件应用的概念成为主流。多层客户-服务器架构浮出水面，将单独的客户程序分解成构件设计，成为符合面向对象的不同扩展。 在构件中不同的分布式应用逻辑(一些仍驻留在客户端，其他在服务器上)，减少了大量逻辑都集中部署在服务器端的令人头痛的问题。服务器端构件，现在集中于应用服务器，从而可共享数据库连接管理池，减轻数据库并发访问的负担(图4)。一个单连接就可轻易满足多用户要求。 图4. 典型的多层客户-服务器架构。 获取这些效益的代价是复杂性的增加，并且最终转换为从部署问题到开发和管理过程的费用和努力。构建多样化处理能力的构件，并发请求比直接为单个用户开发一个可执行程序更困难，而且问题多多。 另外，替代客户-服务器数据库连接的是客户-服务器远程程序调用(RPC)连接。象CORBA与DCOM这样的RPC技术，准许客户工作站与服务器构件间进行远程通信。出现了类似客户-服务器架构的问题，包括资源及永久连接。增加这个新的维护是由于引入了中间件层。比如，在大型环境中对于应用服务器及事务监控需要特别关注。 随着万维网在90年代中后期成为一个计算技术的可用媒介，多层客户-服务器环境开始组成互联网技术。最重要的成就是软件构件被浏览器所替代。这个变化不仅从根本上改变(且限制)了用户界面设计，实际上还把100%的应用逻辑移到了服务器端 (图5)。 图5. 典型的分布式互联网架构 分布式互联网架构也引入了一个新的物理层，Web服务器。这导致HTTP替代了专有的RPC协议而用于工作站与服务器间的通信。RPC的角色被限制到促成远程Web与应用服务器间的通信。 从90年代后期2000年中期，分布式互联网架构对于定制开发的企业解决方案而言，代表了事实上的计算平台。基于构件的日常编程技术及日益复杂的中间件，最终减少了一些整体复杂性。 那么，这个熟悉而又相似的架构该如何与SOA相比较呢?且看分布式互联网架构与SOA特征部分。 注意 尽管多层客户-服务器在其所有权内是一个独特的架构，我们不提供它与SOA之间的比较。大多数在客户-服务器及分布式互联网架构的比较中升级的问题，掩盖了将在多层客户-服务器与SOA的比较中讨论的问题。 应用逻辑 除了一些罕见的应用以专有扩展的方式嵌入到浏览器中以外，分布式互联网应用将其所有应用逻辑放在了服务器端。甚至客户端脚本想要执行在网页上的一个事件响应，都要从Web服务器基于初始的HTTP请求来下载。没有客户工作站上保存的逻辑，整个解决方案都是集中式的。 从而强调了: · 应用逻辑应当如何被分割 · 被分割的处理逻辑应当驻留在何处 · 处理逻辑应当如何交互 从一个物理的角度来看，面向服务架构与分布式互联网架构非常相似。提供者逻辑驻留于服务器端而被分割成单独的单元。其中差异由刚刚所列三个主要设计原则所决定。 传统的分布式应用包含了驻留于一个或多个应用服务器上的一系列的构件。构件设计为不同粒度的功能，依赖于所执行的任务，以及它们被其他任务或应用的复用范围。驻留于相同服务器的构件通过专有API通信，按照它们暴露的公共接口来调用。RPC协议被用于实现跨越服务器边界的通信。这有可能通过使用代表远程构件的本地代理存根来实现(图6)。 图6 构件通信依赖于代理存根 在设计时，预期的交互构件将与其他一起考虑---如此强烈以致实际对其他物理构件的引用可嵌入到程序代码内。这个设计时水平的依赖是紧耦合的形式。这样的稍许处理相对于试图在运行时定位所需构件的浪费而言是有效的。然而，嵌入式耦合导致绑定构件网络，一旦实现，不易更改。 当代SOA依然使用并依赖于构件。然而，整个建模方法现在会考虑创建封装一些或所有构件的服务。这些服务根据面向服务原则而设计，并且策略性地定位及暴露特定的功能集。同时这个功能可由构件提供，也可源自遗留系统及其他资源，象来自其它套装软件产品的适配器接口，或者甚至是数据库。 在服务内包装功能的目标是经由一个开放的、标准化的接口暴露功能---而不用关心用于实现底层逻辑的技术。标准化的接口支持置于SOA核心的开放通信框架。而且，使用Web服务建立了松散耦合的环境，其中也运行着相对设计的分布式应用。如果设计得当，松散耦合的服务支持组合模型，允许单个的服务参与集合的设计。这引入了持续的复用与扩展机会。 有关分布式应用逻辑的设计与行为的另一个重要转变在于服务如何交换信息。当传统构件提供方法时，一旦被激活，就发送与接受参数数据，而Web服务通过SOAP消息通信。即使SOAP支持RPC风格的消息结构，大多数面向服务的Web服务设计却依赖于文档风格的消息。(这一重要差别在后面探究。) 消息也是结构化的并尽可能是自足的。通过使用SOAP报头，消息内容可以伴随阒宽泛的元信息、处理指导以及策略规则。与纯粹构件世界内的数据交换相比较，SOA所用的通讯框架更加复杂、更加庞大，并且更易导致少数的个别传输。 最后，尽管也普遍强调复用传统的分布式设计方法，SOA可通过促进解决方案未知服务的创建鼓励复用以及深层次的跨应用协同。 应用处理 不管什么平台、构件都代表了最大部分的应用逻辑并因此负责大多数的处理。然而，因为用于构件间通信的技术不同于完成服务间通信的技术，处理需求也是如此。 分布式互联网架构促进专有通信协议的使用，象用于远程数据交换的DCOM和厂商实现的CORBA。当这些技术遭遇历史性挑战时，它们相对是有效可靠的，特别是一旦有主动连接时。它们能够支持有状态和无状态构件的创建，主要影响同步数据交换(一些平台支持异步通信，但并未普遍使用)。 另一方面，SOA依赖基于消息的通信。包括负载有XML文档的SOAP消息序列化、传输及去序列化。处理步骤会包括将关系数据转换成XML兼容结构、XML文档预校验以及随后的传输、以及对所接收文档进行解析和抽取。尽管已有所进步，譬如企业解析器及硬件的持续加速，大部分还是抱怨SOAP比RPC通信明显要慢一些。 在面向服务应用环境中，因为SOAP服务器的网络能够有效代替RPC风格的通信通道，导致系统开销成为一个重要的设计问题。文档与消息建模规约及校验逻辑的布置策略是重要因素，形成了面向服务架构的传输层。 这个通讯框架促进了自治服务的创建，支持宽泛的消息交换模式。尽管完全支持同步通信，但还是鼓励异步模式，因为它们提供了由通信最小化而带来的进一步优化的机会。深入支持无状态服务是不同语境的管理可采取的措施，包括使用WS-*规范，如WS-协调与WS-BPEL，还有定制解决方案。 共5页。 9 7 1 2 3 4 5 8 : 技术 分布式互联网架构背后的技术在过去几年内经历了几个阶段。初始架构包含有构件、服务器端脚本以及原生的Web技术，比如HTML与HTTP。中间件方面的进步，允许增加处理能力及事务控制。XML的出现引入了复杂的数据表达，实际上提供了经由互联网协议传输的东西。后来Web服务的可用性允许分布式互联网应用跨越专有平台的边界。 因为许多当前的分布式应用使用了XML与Web服务，有可能这些解决方案背后的技术与那些基于SOA的没有太大不同。虽然一个明显的区别在于当代SOA将有可能构建在XML数据表达与Web服务技术平台技术之上。除了互联网核心技术集和构件的使用，没有被传统的互联网应用所统治的技术。因此，XML与Web服务对于分布式互联网架构而言是可选的，但对于当代SOA不是。 安全 当应用逻辑散布于多个物理边界时，实现象鉴权与授权这样的基本安全措施变得更加困难。 在两层客户-服务器环境中，一个独有的服务器端连接可轻易实现用户论证及企业数据的传输安全。然而，当独立的连接被移除时，而且要跨越不同的物理层传播时，就需要新的安全方法。要确保信息的安全运输及用户凭证的识别、同时保留原始的安全语境，可用象委托和假冒这样传统的安全架构合成方法。加密也被加到其他广泛而开放的HTTP协议方面，可在Web服务器之外传送时受到保护。 SOA通过引入对安全如何组合以及对应用的大规模改变，从而远离了这个模型。由于严重依赖WS-安全框架所建立的扩展和概念，在SOA中所用的安全模型在通讯层面上强调安全逻辑的安置。SOAP消息提供的报送区块中可存入安全逻辑。那样，无论消息在何方，安全也就随之而至。这个方法需要个体自治和服务间的松散耦合，同时一个服务可完全维持在无状态的范围。 管理 维护基于构件的应用包括跟踪单个构件实例、本地及远程通信问题，监控服务器资源需求，当然，还有标准化的数据库管理任务。分布式互联网架构进一步引入了Web服务器，同时解决方案执行时还需要关注额外的物理环境。因为客户---不管本地的还是外部的组织---使用HTTP连接到这些解决方案，Web服务器就成为正式的第一接触点。因此它必须设计成可扩展的---这一需求已导致Web服务器机器资源池的创建。 企业级SOA典型地需要一个额外的运行时管理。通讯框架带来的问题(特别是工作在异步交换模式时)会比基于RPC的数据交换的问题更不易发现。这是因为关于消息如何交换，存在太多的变化。RPC通信一般需要一个来自初始构件的响应，表明成功还是失败。遇到一个失败条件，就会抛出一个异常。通讯框架的异常处理可能更复杂而更不健壮。尽管WS-*扩展被定位于更好地处理这些情形，仍需努力保持高度管理。 其他维护任务，象资源管理(类似于构件管理)，同样需要。然而，为了更好地促进复用性及可组合性，对于企业构建大量的Web服务而言，管理基础设施的一个很有用部分是私有注册。UDDI是一个标准化的技术，用于标准化地注册接口，能够手工或程序化地访问发现服务描述。 3.4. 比较SOA与混合Web服务架构 在前一节中，我们提到最近的分布式互联网架构变化已如何成为混合Web服务。这一主题值得详细说明，因为它已经是(并预期继续是)SOA周围的混乱之源。 首先，传统架构内使用Web服务是完全合理的。由于许多编程语言都支持对Web服务的开发，他们可轻易地将其嵌入老的应用设计。并且，对于那些不支持Web服务定制开发的遗留环境，通常也可用适配器的方法来解决。 注意 尽管我们集中于分布式互联网架构，但并没有限制两层客户-服务器的应用使用Web服务。 Web服务作为构件包装器 Web服务在这个语境中的主要角色已引进了一个包含包装器服务的整合层，促成经由SOAP兼容的集成通道的同步通信(图4.7)。实际上，SOAP规范初始发布和第一代SOAP服务器都被特别设计用来复制使用消息的RPC风格的通信。 这些集成通道主要在集成结构中，被用以促进与其他应用或外部合作伙伴的通信。也被用于促成与其他(更多的面向服务)解决方案通信，还可利用第三方工具提供的Web服务。不管他们在传统架构中的使用或目的，关键是要澄清靠这种方式在分布式互联网架构中纳入Web服务不具备真正的SOA资格。这只是使用Web服务的分布式互联网架构。 并非是反映构件接口和用Web服务建立点对点连接，SOA提供了对于不同通讯模型的强健支持(基于同步和异步的交换)。另外，在SOA内的Web服务受制于特定的设计需求，象由面向服务原则提供的那些。这些和其他的特征都支持对和谐的松散耦合的追求。一旦实现，单个服务不再限于点对点通信;它能够适应任何的现在和未来的请求者。 SOA内部的Web服务 然而SOA在大小和品质方面会有所不同，SOA与其他架构在Web服务的使用方面有切实不同的特征。本书主要专注于探索这些特征。目前已经充分阐明:基本上，SOA构建于一组Web服务，它们被设计用于一个或多个电子商务流程的集体自动化(或者参与自动化的)，SOA促进将这些服务组织成抽象企业自动化逻辑特定部分的特定层。 同样通过跨企业的标准SOA，出现了天然的协同性，超越了专有的应用平台。这考虑到先前不同的环境组成，以支持新的和进化的业务自动化过程。 未完待续
|
|
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
78.125ms |