tiger_hsiaoID:tiger_hsiao
[修改头像]
29866次访问,排名3336(1)好友0人,关注者3
tiger_hsiao的文章
原创 12 篇
翻译 0 篇
转载 0 篇
评论 37 篇
劳虎的公告
萧百龄 (笔名:劳虎)--曾担任独立技术咨询顾问,并曾服务于专注于XML数据库及XML相关领域的德商Software AG公司,担任解决方案研发经理。目前就职于SOA软件的领导厂家- BEA Systems大中国区,担任首席SOA顾问(之前为 BEA 台湾分公司技术总监)。 过去任务涉及Unix/Linux系统及网站管理、HTML、Perl、面向对象分析及设计、Java、中间件(包括应用服务器、Portal、应用与数据集成)、XML、Web services等不同的科技领域。在W3C推广XML技术的初期,1999年著作《无废话XML》。
最近评论
tangdch2008:很好
debugself:正持续关注中
dgdlxh:???
广泛大使馆:dfasdfasdf
gunsand:SOA网上查了一些。也不知道是太深还是咋回事。感觉虚头八脑的。。。。
软件项目交易
订阅我的博客
XML聚合  FeedSky
订阅到鲜果
订阅到Google
订阅到抓虾
订阅到BlogLines
订阅到Yahoo
订阅到GouGou
订阅到飞鸽
订阅到Rojo
订阅到newsgator
订阅到netvibes
文章分类
    收藏
      相册
      我的相册
      特别推荐
      欢迎加入 SOA 专家群
      存档

      原创 请 WOA 到一旁“休息”去

      新一篇: 2007 SOA 市场探温

      2005 年底,著名 IT 分析机构 Gartner 的一个分析师 Nick Gall 发明了一个新词 -- WOA (Web-Oriented Architecture) 。大家知道,发明新缩写字 (acronym) 一向是 Gartner 的绝活。几个月后,SOA 界著名的 blogger 和专栏作家 Dion Hinchcliffe 对它表示支持,他甚至画了一幅图,说明基于 SOAP 和 WS-* 的 Web services,和基于 REST、POXJSON 的 WOA,以及其他 SOA 相关科技,在复杂度和丰富程度上的比较。

      本以为 "WOA" 的命运,差不多已经和先前广遭声讨的 "SOA 2.0" 一样,开始消声匿迹,但最近在一片大谈 REST 声中(前两篇帖子的主题),发现 WOA 已死灰复燃

      到底什么是 WOA?来看看始作俑者是怎么定义的。Nick Gall 在评论一篇同事的 blog 时为 WOA 下了以下的定义

      Shorthand version: WOA = SOA + WWW + REST
      精简版:WOA = SOA + WWW + REST

      他接着说:

      BTW, Since WOA is a substyle of SOA (ie it imposes additional constraints above and beyond those imposed by SOA), you may be interested in our definition of SOA:
      附带一提,因为 WOA 是 SOA 的一种子样式(也就是说,它在原本基于 SOA 的制约之上,还多了些额外的限制),你可能也会有兴趣看看我们对 SOA 的定义:

      Service-Oriented Architecture:
      面向服务架构:

      Long version: An architectural style in which certain discrete functions are packaged into modular, shareable, distributable elements ("services"), which can be invoked by consumers in a loosely coupled manner.
      冗长版:一种架构样式,将某些特定的功能包装成模块化、可共享、可发布的元素(即“服务”),这些服务可以被消费者以松耦合的方式调用。

      我想信他所谓的“SOA + WWW + REST”并非如算数的加法(联集),而指的是必须兼具 SOA、WWW,和 REST,是交集。但以上这些定义,真把 WOA 说清楚、讲明白了吗?

      正因为Web是个偌大的空间,加上所有在上面不断发生的事,使得 “Web”成了一个非常大而模糊的概念,许多对技术不娴熟的用户,更是常把 “Internet”和 “Web”混为一谈。一个很经典的例子是“Web 2.0”这个已存在两年的词汇–恐怕到现在,许多人对到底什么是“Web 2.0”,仍存在着不尽相同的理解和看法。炒作 “WOA”,一个“面向Web的架构”,有着同样的问题,因为 Web 概念太宽了,到底什么是它的核心精神?扯不完!Web 2.0 相关科技 (AJAX, mashups) 能不能算是 WOA?那PHP, Ruby on Rails, Perl, Python 开发的 Web 应用呢?JSP、ASP 的应用呢?SaaS (Software as a Service) 应用又算不算 WOA?如果按照 Nick Gall 的定义,所有的 WOA 都必须符合 SOA,但不见得所有SOA 都是 WOA;还有一个关键是 REST。有人可能会抗议地说:凭什么只有 RESTful 和面向服务的算是 WOA?!凭什么说走 HTTP 的 SOAP Web services就不是 Web?争议的根源,正是在于 “Web”所涵盖的面太广了,大过 SOA 所在的企业计算领域。所以如果反过来硬要把 WOA 局限定义成 SOA 的子集,绝对是招引争议和混淆的好方法。如果目标是提倡 REST,那么先前帖子中提过的面向资源的架构 ROA (Resource-Oriented Architecture) ,是一个比 WOA 更适合的名称。“资源”和“服务”是两个更适合相提并论的抽象概念,并且“资源”充分地凸显出 REST 的设计哲学。

      嗯... WOA... 反覆思索后,还是感觉它的概念很虚。乍看之下,看似是一个和 SOA 互别苗头的新架构,但主张者又强调,它是一个 SOA 的子集,是实现 SOA 的一种特殊的 style。无疑地,如前两篇帖子所谈,REST 的确是个好东西,可以利用在某些 SOA、SaaS,和 Web 2.0 领域的应用,但如果硬要搞出一个 WOA 并把它和 SOA 的关系扯复杂的话,可预见未来在许多企业的 SOA 发展史上,将应验两千多年前孔老夫子已预测到的情节:“名不正(某大大炒作出一个 "WOA" 的词),则言不顺(但仔细检验后,其实概念很虚);言不顺,则事不成(用 REST 做了一堆点应用 [point solutions],便洋洋得意以为已经是 SOA 化,其实差得远了);事不成,则礼乐不兴(没有规规矩矩从 SOA 方法论入手,分析企业战略目标、业务架构、信息架构等,做完善规划);礼乐不兴,则刑罚不中(SOA 治理 [governance] 不到位,未能清楚定义执行战略和可量化的评价指标,因而无从得知 SOA 执行的效果和投资回报);刑罚不中,则民无所措手足(end users 感觉不出来 所谓 "SOA" 的项目和做法比过去传统作法有何高明之处)。

      聪明的 SOA 治理团队和架构小组,无疑会开始探索 REST 之美,并把它善用在架构当中,但不会迷失在 WOA,或无谓的 SOAP vs REST 之争当中。选择 REST 绝不是基于“为了 REST 而 REST”。

      不久前听到 "JBOWS" (也有人用 "JBOS")一词,它和 RedHat 的 JBoss 没有直接关系,尽管发音相近。这是个讽刺搞笑的说法,代表 "Just a Bunch Of Web Services"。意思是说,目前许多已经采用了一堆 Web services 的企业,不等于已经做到 SOA,就像采用了 AJAX 不见得就具备 Web 2.0 精神一样。著名的 SOA 分析师 Jason Bloomberg 前不久才大声疾呼,用了不少篇幅强调这个重点(另一篇相关文章:SOA != Web Services)。基于 SOAP 的实现,是一种 Web services 的 style,而 RESTful 则是另一种 Web services 的 style。也就是说,Web services != SOA 的公式,放到 REST 的上下文中,依然成立。

      正本要清源,擒贼要擒王。实施 SOA 的动机,应出自于加强 IT 和业务部门间的磨合,提高业务敏捷和未来应变的弹性和灵活性,而不是因为新冒出一个超酷、超简单,名为 WOA 或 REST 的技术实现手段。中文的老话叫“本末倒置”,新话叫“屁股领导脑袋”;而老外则有:“拖车放在马前面”"putting the cart in front of the horse" 一词。别告诉我:“你说的那种 SOA,是企业级的 SOA;而我们现在谈的,是比较广义的,很多用 REST 架构的 Web 应用,都可算是广义的 SOA,包括一些 Web 2.0 和 Enterprise 2.0 的应用”。如果是这样的话,那干脆把所有 IT 的东西统统叫 SOA 算了!大家对 SOA 本来就已经够模糊了,这么做,只会徒增混淆,火上浇油,而太便宜了那些炒概念的分析师。某个科技概念的价值,是会随着它的定义被灌水、扩大解释而锐减的。分析师大大和厂商们,请珍惜 SOA,别残害它。

      发表于 @ 2007年09月03日 14:47:00|评论(loading...)|编辑

      旧一篇: 担心未来的 REST 怪物正在形成

      评论

      #bjblues 发表于2007-09-04 09:34:58  IP: 124.42.38.*
      老兄高见,哈哈
      #mcs51a 发表于2007-09-05 09:17:10  IP: 58.32.189.*
      这些人老是炒作,干吗
      #mdot 发表于2007-09-09 10:19:57  IP: 121.32.164.*
      有个关于ESB的问题想请教:在一个SOA
      的系统中,如果要开发一个比较购物的程序的话,假如合作伙伴A和合作伙伴B,他们提供的接口不同,那么服务的请求方,就必须用ESB,将服务的请求通过ESB进行转换,分别发送到两个合作伙伴的WEB服务?
      #劳虎 发表于2007-09-10 17:17:05  IP: 203.222.183.*
      mdot: 您描述的这种场景,的确很适合 ESB 上场
      #mdot 发表于2007-09-13 12:46:29  IP: 211.154.127.*
      那比如我的这两个服务商提供的服务,都规定了一样的接口的话,但需要按一个流程来调用的话,那是不是应该用BPEL来实现了?
      比如我想做个比较购物的,将请求分别发到A,B两间不同的合作伙伴商店的话,然后用BPEL异步获得请求回复的内容,这样可以吧?这样的话,应该不用ESB了,我感觉在SOA里,不一定要用ESB吧?
      #劳虎 发表于2007-09-17 15:04:27  IP: 203.222.183.*
      mdot:本来 SOA 在架构上就没有绝对放诸四海皆准的做法,ESB 本来就不见得是所有场景都必要(但您之前描述的场景听起来的确适合),一切看情况和粒度大小而定,至少我从不认为 ESB 在任何情况下都是绝对必要的。当然,如果有比较长时性、异步、甚至人机交互的流程,则 BPM 自然是合理的选择(不过 BPEL 标准无法涵盖人机交互的操作),但我想强调, BPM 和 ESB 二者关系并非互斥,而有许多情况下是协作。ESB 之所以在 SOA 探讨中被提的很多,一部份是因为它在跨企业系统交互的场景中,的确能跨防火墙扮演类似 gateway/proxy 的角色,对于安全、管理、监控上都提供了更大的弹性
      发表评论  


      登录
      Csdn Blog version 3.1a
      Copyright © 劳虎