微軟WCF給SOA帶來的影響

來自微軟的DeVadoss對WCF給SOA帶來的影響進行相關說明

很多我們對Windows Communication Foundation的預計已經展現出來，那么它又帶給哪些我們沒有預計到的東西呢?

John DeVadoss: WCF是構建安全可靠的事務性服務的統一框架。它是一種構建分布式面向服務系統的非常豐富的技術基礎，它統一了消息風格和RPC[Remote Procedure Call]風格，并且通過二進制和基于開放標準的通信達到了平臺最優化。對于我來說，最關鍵的事情是讓更多人了解它，但我認為讓開發人員激動的是編成模型的優雅和簡單。在很多文章中，面向服務已經獲得了這種極高的評價。我想，WCF能做的就是對絕大多數開發人員甚至架構師來說讓這種想法成為現實。

請進一步解釋一下這種想法。在過去很多公司為很多大型項目投入了不少資金，難道集成不是顯而易見的目標嗎?

DeVadoss: 如果你聽聽開發人員和架構師談論SOA甚至更加深奧的東西，你就知道對我們來說，它還只是一種很好的想法而以。它不過是關于松耦合、合約以及消息的遠景想法。而WCF會以相當簡單的方式讓它對我們大多數的受眾成為現實。

如果你停下來想想松耦合的基礎，我想使你困惑的一定是人們使用的不同方法。有的廠商希望SOA成為一種產品或者平臺。而有的廠商希望在更大的服務領域讓SOA成為一次到位的無所不能的企業SOA,要花費24到36個月才能完成。而如果你再想到SOA的基本原則就是幫助你實現互操作性、集成性和靈活性，那么它確實與很多人有關。這個想法更像是不同廠商、服務提供商都在預期的事情。甚至一些架構師組織都把它添加到已讓有些人感到復雜的性質中。

面向服務的基礎形式是與人有關的某種東西，因為它能很好的映射成我們想要得業務。于是，IT就作為服務提供者，在那之上是客戶的行為，這樣使服務獲得優勢。

我是一個Java用戶，WCF的出現應該令我注意些什么呢?

DeVadoss: 有兩件事情值得注意。第一，編成模型所帶來的優雅和簡單。第二，是我們對服務的配置方面所作的工作。從IT管理者或者開發人員以及構架師的角度來看，在決定用什么協議、什么標準、什么機制來通信正是問題的所在。我們的目標非常不明確。我們正在重新定義通信的消息風格以及RPC風格。

為什么說WCF是Vista的組成部分?它與操作系統到底有什么聯系?

DeVadoss: 我們對WCF確實有底層的支持，那么讓我們來把它弄明白。說到它與某個版本耦合在一起，我們選擇了.NET框架。我們希望.NET框架的基礎能夠用到WCF。這是一個關鍵想法。但是，WCF并沒有與Vista硬耦合到一起。如果你是一個使用Windows 2003的開發人員，你依然可以使用WCF的靈活性等強大功能。

那么如果我使用Linux或者Solaris，會有一些限制嗎?

DeVadoss: 不會有。我想，在這個充滿分布式的互聯系統的世界里，更重要的事情就是互操作性，只有集成才能共享通用的基礎設施或者通用的協議，例如WS-*。而每臺機器是否相同就不是那么重要了。更重要的是我們能夠在基礎設計級別互聯和通信，能夠都理解顧客或者帳單的含義。

在過去的幾年中Redmond關于面向服務架構的想法發生過改變嗎?你認為在2006年它又是什么樣子?

DeVadoss: 我認為在2006年會發生兩件事情。首先，面向服務將變成架構系統的普遍風格。另外，還在成長的服務提交這種傳統服務提供方式只是SOA的一個方面，服務消費才是真正正確的途徑。我跟很多架構師和企業客戶談到IT界構建并將實現它的遠景。它們的服務提交、供應、管理和構建都需要非常復雜的基礎設施，但當你與客戶交談時，他們并不知道這樣做的好處。我認為服務客戶將變得更加可行，而且會通過我們對Vista的投資和office工具的投資反映出來。只有客戶得到好處，你才可能用于服務提交的最強大的基礎設施，但沒有業務價值的話一切都是白搭。

微軟在構建SOA方面還沒擁有的最重要的部分是什么?

DeVadoss: 在過去幾年中，在微軟我們做過最多的東西是模型驅動的設計和模型驅動的開發。我希望我們可以加速使用模型來驅動設計，驅動通信。但我們只是最近才使用我們特定領域的語言工具，而且還有更多特定領域語言方面的工作等著我們去做。然而，由于我們要處理的基礎設施，工具以及平臺合適，現在的工作比較現實。我們越早讓架構師和開發人員使用模型，我們就能根據構建系統的類型更好的實施。

模型驅動的架構能幫上什么忙嗎?

DeVadoss: MDA是一種招牌。MDA也是平臺獨立性方面的普遍認識，而且它幾乎專注于讓你在構建出模型后就能由它產生代碼。這兩件事情都是我們要面臨的難點。平臺提供了某些優勢，而對于我們來說，真正利用平臺優勢而不是停留在學術上的平臺獨立性上很有必要。另外，我們也不相信只有一種語言能夠描述模型，例如UML 2.0。以BPEL和XAML為例，差異明顯的領域有著不同的需求，不同的約束，因此我們相信特定領域的語言比起用一種語言來約束自己更加有道理，UML也只是需要的一種語言而已。這就是為什么我相信我們在[ACPI Source Language]方面的投資肯定能夠回報我們付出的時間。