Oslo:微软启动它太仓促了!

  • Jean-Jacques Dubray
  • 胡键

2007 年 11 月 13 日

话题:SOA.NET架构语言 & 开发

InfoQ 采访了Compassion International的企业应用架构师Brandon Satrom。Brandon 最近在他的博客上分享了关于组合应用基础设施的分析

在我的组织,当为组合应用开发长期策略时,有一点非常明显。那就是,尽管微软技术将在我们未来架构中的很多领域扮演重要角色,但是有几个非常重要的部分在微软套件中找不到,我们可能需要在其它地方去寻找。我总觉得这并非是我个人观点,而且 Oslo 公告暗示着微软同样关心他们当前产品中的空白。

Charles Young 评论说

微软确实只是一种替补方案(behind the curve)……[而且] 让他的竞争对手们通过 ESB 架构和不断丰富的 BPM 工具赢得大众的目光。

Brandon 认为 Oslo 公告表明微软转变了处理 SOA 的方式:

尽管没有在产品本身中出现,但是我看到微软架构师和其他博客(如Mike Walker),以及其他看起来对组合应用的长期潜力有很好理解的人们在鼓吹组合应用的愿景。关于 Oslo 公告的好消息是那些人不再是少数异端了。

Brian Loesgen在这次公告中看到了更多的连贯性:

对于使用微软技术组合(使用.NET、BizTalk 、IIS 等)的开发者来说,我们拥有创建复杂分布式应用的一切。但是,有很多移动部分(moving part)……Oslo 的愿景声称:显著简化组织内和跨组织分布式应用的设计、建构、部署和管理所需的努力。

这也符合 Jean-Marc Prieur(DSL 专家,他以法国为基地领导了 CodePlex 上的DSLfactory.utilities项目)在一次私人会话中所表达的观点:

Oslo 是迈向软件工厂的一步。Oslo 将包含一个仓库并支持模型关系。

然而,Arnon Rotem-Gal-Oz注意到微软的 DSL 策略可能正在转变:

新闻发布谈论了“模型驱动”方法,而不是软件工厂

如果人们对这个方向表现积极,公告产生的问题可能比答案更多。Brandon 解释说:

我对 Oslo 公告有一点怀疑,有两个原因:首先,我认为微软所表达的组合应用愿景太狭隘了。尽管软件 + 服务和 SOA 愿景是必须的,但是我认为任何组合应用策略的最终目标应该逐渐能使组合上升到面向终端用户层面。

第二个令我对赞扬微软 Oslo 愿景感到犹豫的是,与他们公告相关联的技术是距离新闻发布时间的 1 到 3 年间或更远的技术。大多数工具更新是两次发布之后的事情……组织需要今天的解决方案,而不是宣布明天来临的解决方案。例如,当我们管理所有的模型、元数据和服务(我们所知的关于我们策略的缺陷之一)这 3 个东西的能力已经超过我们控制的时候,我的组织不能等待一个仓库来管理它们。

这个观点得到了Gavin Clarke的回应,他没有给人留下深刻印象:

尽可能的将一些时髦的词语包装进单个新闻公告,可能证明你是在“传递信息”,但是这不能掩盖你的战略滞后于城中主要玩家的事实。

一份报告(PDF)在 2009 年的某个时候提到了 Oslo。那意味着在中间件方面,微软的服务器和工具将远远的落到重要对手 IBM、Oracle、和 SAP,甚至渺小的 BEA Systems 后面……

为了让你了解所有这些是如何得出的,此处有一些值得考虑的事实。

当前 Visual Studio 的发布周期大约是 3 年,微软已经又要发布 Visual Studio 2008 了——定于明年。这让 Visual Studio 10 到了 2011 年的某个时间。关于.NET 框架,它的装货日期大致与 Visual Studio 相同,微软正准备与 Visual Studio 2008 一起发布 3.5 版,这意味着你有望与 Visual Studio 10 同年得到.NET 框架 4。

[微软] 近年来落到了登陆冲刺的后面,远远看到 IBM、Oracle、SAP 和 BEA 购买或建构他们自己的系统——取得了不同程度的成功。

极少数人就微软宣布的计划中功能发表了评论。这是一次真正的革新,因为其他主要厂商,包括 Google,尚未进行这方面的努力。Tim Rayburn写道:

软件 + 服务:现在一段时间以来,微软一直承诺这是他们的方向,BizTalk Services 似乎可能成为首先达到商业发布的实际服务集合之一。

Andy Dorman 就“互联网服务总线(Internet Service Bus)”提出了他的想法,Oslo 会令该服务更易用:

当一个服务与不同组织连接在一起时(Web 服务的最初承诺),SOA 的真正杀手级应用。现在有些困难,由于安全性和互操作性问题,但是当两个参与者都将他们的应用托管给同一个提供者时,问题就变得简单了。最大的问题是谁将成为提供者。如果微软不小心的话,就有可能是 Salesforce.com、Google 或甚至是 Web 2.0 的起步公司之一。

Brandon 总结道:

好消息是当 SOA 和组合应用正确的完成后,被锁定到特定厂商的问题(vendor lock-in)减轻了,组织可以关注交付今天的业务,而不是等待残余的难题块落在某个明天地方。

Brian Loesgen看到了一线希望:

这是令人激动的时刻。我们有了一系列的技术(WS-* 规范、BizTalk Server R2、WCF/WF/WPF),它们全部都在朝好的方向不断成熟。Oslo 波浪将建构在这个成熟性之上,并有潜力极大提高我们的生产力和灵活性。

Tim Rayburn分享了他的观点(takeaways):

  • 如果你是 BizTalk 开发者,并且对 WCF 和 WF 还没有很好的理解,那就马上去学习它们,并且以那个顺序。
  • 花一些时间从市场上的竞争对手(如 IBM)那儿学习元数据仓库,那么你就明白这儿有哪些麻烦了

查看英文原文:Oslo: Microsoft Gets it but Hurry !

SOA.NET架构语言 & 开发