主流厂商对SOA的贡献

 
   | |

导读:没有人或组织拥有或控制SOA。从专有平台发展而来的架构促进并支持开放的标准与厂商中立的协议,只要主流软件厂商选择支持,SOA将可能为此保留一个重要的架构。

关键词: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迁移计划。

 
来源:计世网    
 
 
 
 
 

W3C

 
HTML 5是超文本标记语言(HTML)的下一个修订版 ,超文本标记语言是用来描述网页内容和外观的标准编程语言。在2007年,万维网联盟(W3C)……
 
作为服务方法的软件拥有连续机构,可以确保服务之间的互操作性。监管XML和WSDL以及OASIS标准的万维网联盟(W3C)为WS-*标准设置了课程……
 
在前面文章中,我对Web服务相关标准已经做了许多报道,现在是时侯看看那些标准发行机构最近有哪些重大举措了。首先,我们看看W3C……
 
在您最近的博客中提到,在XML.com中有你喜欢的XML内容。关于XML的信息还可通过什么途径可以得到?请与我们分享更多的来源……
 
WSO2治理(governance)与注册中心(registry)开发的下一步就是采用W3C语义网(Semantic Web)概念的SOA策略定制……

热门技术手册排行

 

随着开源技术越来越成熟,一个稍有开发经验的人通过学习就可以用开源的产品和技术构建一套可用的系统。对于从事软件开发的人员,尤其是对Java或动态语言相关领域的人来说,“开源”也许是他们最喜爱的单词。但是,很多时候我们需要的不仅仅是一个可用的系统,而是希望这个系统开发更简易、性能更高和扩展性更好等。这确实是一个令人头痛的问题。本指南很多地方都是点到为止,要深入了解相关信息的读者请借助参考资料、网站等自行挖掘。

 

本专题分六部分探讨SOA设计模式,当初设计面向服务架构的一大初衷就是降低服务间耦合度,由此提高服务的灵活性和自由度。

 

业务流程管理(business process management,bpm)不是一个新概念,甚至不是一个新名词。它是从相关的业务流程变革领域,如业务流程改进(bpi)、业务流程重组(bpr)、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、eai、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。

 

TOAGF是一个架构框架,简而言之,TOGAF是一种协助发展,验收,运行,使用,和维护架构的工具。它是基于一个迭代(Iterative)的过程模型,支持最佳实践和一套可重用的现有架构资产。

 

云计算的概念越来越流行,Amazon、Google和IBM是第一批将云计算引入公众视线的公司。云计算就是新的Web2.0,一种既有技术上的市场绽放。

 

Mashup是一个非常cool的新的应用程序种类。如果你想真正的了解它们,我们需要回过头来看看你现在的计算机,其实它就是一个非常好的帮助你理解mashup的模型。现在开源的操作系统无疑是非常好的apis的集合或应用程序编程接口,帮助开发者去构建其应用程序。计算机本身也是一个很好的为用户提供接口的例子,键盘和鼠标可以被理解为你通过计算机的接口而使用的不同的应用程序。本技术手册为读者提供了一些相关信息,如果需要深入了解mashup,读者可以借助其他参考资源。

查看更多
 
 

登录TechTarget中国

关闭
本服务仅向TechTarget中国的会员开放,请登录或立即免费注册
电子邮件地址:
请输入您的电子邮件地址
密码:
下次自动登录