SOA有毒----SOA業務開發平台(三)

SOA有毒
那天在QQ群，和眾多網友討論關於SOA的話題，發現業界對於SOA的宣傳，不是太飛機，說的都是高層面的理念，就是太土鱉，講的都是如何開發SOA。但是缺少中間一個層面的落實，那就是理念層次往專案經理和程式員這邊降一層，而非一直高飛在架構師、總規劃師這一層面。
因為現在大量的程式員，都是新生代的程式員，他們寫的代碼量少，做的軟體項目少，還無法體會代碼量多了會如何解決，還無法體會項目定製多了會如何解決。沒有問題的痛楚，當然也就不太明白為什麼要彙總成函數。討論過程中，發現不少程式員，連函數層面都未理解到，他們代碼中的函數是怎麼來的呢，是他們在編程過程中組件的事件產生的，如onclick之類的函數。他們自己並未主動或者很少主動封裝函數。而且不少人也把函數僅僅停留在為了公用調用，或者一個代碼都1500多行了，實在整理不了清晰思路了，才切割代碼成另一個函數，和我初期對函數的理解是一模一樣。對於真正理解函數的封裝，並沒有多深刻。就更不用說痛則思痛，更進一步應用物件導向和面向組件方法。因為寫的代碼量並不多，還沒有遇到問題，所以也就不需要更進階的方法。許多人寫物件導向和面向組件的代碼，是由於現在的3GL開發語言和IDE所決定，自然而為之，而不是程式員自己主動要物件導向或面向組件。不過有些覺醒者開始模仿使用物件導向了，但真正對物件導向的好處理解還不是很深刻，還處於照貓畫虎的階段。很多人寫過COM+，寫過EJB，但都是人家IDE工具和人家的組件規範確定的，自己內部寫的代碼思路並沒有與之相匹配，還是代碼的堆積。
所以，在這個層面階段，讓大家再用面向服務，很多人肯定不理解，覺得沒有必要。也有一些趕技術時髦的公司開始使用面向服務開發，但思路仍然停留在寫COM+的樣子，也就是代碼外殼是面向組件的，但內在的代碼思路和面向組件沒關係。
技術是為瞭解決問題的，而不是顯擺時髦的。客戶並不理解技術，如果你的技術並沒有為客戶帶來明顯價值好處，客戶也不會為你的技術成本付出而買單。過去是有一批客戶的CIO人員，挺關注最新技術的產品，如果你是PB做的，他是.net做的，就會買.NET做的。但是現在中國資訊化比較全國風行，實施的項目案例比過去多了N倍，也就有N倍的項目死亡或者宣告失敗。已經有不少慘痛教訓，讓不少盲目沒有目的的追求技術的軟體公司和CIO們吃虧。
SOA在程式員寫代碼看代碼這一層次看起來是面向組件的另一個高度，但SOA非常複雜。如果你沒有面臨複雜業務和業務投資，少碰SOA為佳。
上次寫的部落格，我是從程式員寫代碼的層次上給大家講面向組件的來曆。但從另一個方面，從架構上來看，面向組件並非我講的只是代碼多了需要更上一層封裝這麼簡單。
在業界，有OMG組織，也就是對象管理集團。這個組織的支撐大佬是IBM、HP、BEA之類的公司，幾乎全世界頂級IT公司都加入了進來。所有業界統一的認識就是，軟體的世界，應該是各個功能封裝成一個個的組件，程式員只要把組件內部實現好，封裝好，實現的內部規格和外部介面規格符合統一標準就OK。那麼，這一個個的組件就需要插入到一個組件平台上。這就好比什麼顯卡、音效卡、網卡，都有標準的介面，都能接受主板的訊號調度，所以都插入到主板上，接受主板資料匯流排的統一管理。所以，業界認為軟體也應該是這樣的，才能實現軟體的靈活性。這是從架構的高度來講面向組件的好處的。我上次並沒有從這個角度講，因為大部分人還是程式員，他們比較關注自己代碼如何更靈活的修改，對於架構，覺得有些空和遠。所以，有了上一篇的鋪墊，本篇就好講多了。
大家都知道，COM+有組件規範，EJB有組件規範，.NET有組件規範，CORBA也有組件規範。而這個軟體主板是什麼，在COM+中有COM容器，過去叫MTS，現在叫元件服務。.NET的組件容器就是.NET平台，裡面有Framework，有虛擬機器，有組件容器。微軟實現成一個封裝裡，就是為了屏蔽技術細節，這樣大家才覺得微軟的產品簡單。而JAVA一方呢，就怕所有模組都綁在一起，所以每個模組都分開，EJB組件容器獨立成了中介軟體，JAVA還有虛擬機器和Framework。
我知道很多人在混淆WebService和SOA。SOA也有組件規範，那就是SCA，全稱就是服務元件架構。講的就是面向服務的組件應該是什麼規格。過去制定的CORBA組件規範，是面向組件的，而非面向服務的組件。面向服務的組件，比面向組件更多了一層服務的高層搭建。
有組件規範了，還得有組件之間的通訊規範。CORBA有ORB，EJB有中介軟體規範，COM+有實際的落地，但由於微軟對此技術的封閉，我沒有看到太多的這方面的規範。到了SOA，有沒有組件之間的通訊規範呢。
有。但是SOA並沒有自己制定獨立的一套通訊規範。這就是SOA的一個很好的開放的心態。既然現在有了這麼多規範了，我們幹嗎還要重新發明輪子呢，我們何不利用這些規範呢，這樣也保護投資。於是，SOA利用了WebService的通訊規範，也可以應用JMS通訊規範。這就是很多人容易混淆WebService和SOA的根源所在。
但WebService僅僅定義了介面是怎麼回事，你必須統一，但你內部代碼怎麼寫，webService不管你。本來WebService的發明是為了異構調用，這是WebService的目標，也是重點。所以WebService並沒有組件規範。因為世界上，三大主流.net、EJB、CORBA，都有自己的組件規範，何必再重造組件規範呢。
很多人認為，你管我內部怎麼寫代碼的，我告訴你webService介面，你調用能返回你想要的結果不就OK了麼。對，對於調用服務的一方來說，並沒有什麼，能調用能實現需求就OK。
但是，管你內部怎麼寫代碼，是容器的需要。如果你把webservice都放在了一堆，然後這些webService互相調用，這隻能算是一個整合平台。整合平台關注的是如何管理這些webservice。
而SOA想做到的不僅僅如此。它是一整套思想體系。它不僅僅想管理你的介面，你的組件之間的通訊，還想管理你的組件。
更進一步來說，SOA還想管理你的資料交換。
過去用WebService，交換的是XML，但是XML內部也得有個格式，而這個格式過去是沒有規範的，只要雙方約定好怎麼解析就OK了。但是SOA不這樣看。它還制定了SDO。規定了你的交換的資料的內部格式。很多人看到這裡，應該想明白SOA為什麼要定義SCA規範了吧。大家都知道，交換資料，如果內部格式統一，這樣就非常利用交換資料，而不是自己自訂一套，還不知道定義的靈活不靈活，嚴謹不嚴謹。SCA的制定也是出於同樣的目的，如果大家內部寫代碼，都是任憑自己的想法隨便代碼堆砌，那麼即使應用了SOA，也無法達到面向組件的靈活性。
我們都想搭建一個業務平台，希望我們的功能能夠靈活修改，而不是動一發牽全身。但是，如果沒有一個規範，我們怎麼可能搭建一個可靈活可擴充的平台呢。我們現在大家都是在憑自己的經驗來搭建業務平台，來感覺自己搭建才靈活。但人家業界已經給出了標準，這樣搭建平台，用這樣的思想，用這樣的規範，搭建出來的平台就能達到靈活性。但偏偏許多人還在自己冥思苦想什麼樣的架構可以達到靈活。
SOA是個很開放的面向服務的組件的架構。不管你是COM組件，是EJB組件，是.NET組件，是CORABA組件，是用的.NET虛擬機器，還是JVM，只要符合這個SCA/SDO規範，就可以搭建靈活的平台了。而且已經有了靈活的平台，那就是ESB。ESB也不是一個很新的東西，它也是混合了WebService技術、訊息中介軟體技術、組件容器技術、BPEL流程引擎技術、組件容器技術。其實質就是把組件容器中介軟體+訊息中介軟體+流程編排中介軟體+WebService整合在一起，如果符合SCA/SDO標準，那麼這個ESB就可以說是一個SOA ESB。
SOA是盡量保護現有投資，不另造獨立王國，現有的虛擬機器、中介軟體、WebService、整合技術，都不用荒廢。而可以實現更高層次的統一。你當然可以把現有的.NET組件或EJB組件封裝成SCA組件，也可以直接開發SCA組件。
我們過去面對了如此多樣的技術，我們眼界迷離，無從選擇。現在我們有了SOA，只需要選擇這一種更高層面更抽象層面的規範，我們就可以實現組件和組件平台，就可以像硬體主板和顯卡的關係一樣靈活。
當然，這樣的平台只是給了我們一個基礎平台，我們想開發我們的業務，還需要在此基礎上搭建我們業務功能需要的準系統，我們的具體業務功能，需要基於我們自己的業務基礎層來開發，而非在ESB上直接開發SCA組件。這個很好理解，我們也不是在.NET平台上直接開發我們的業務功能，而往往會搭建一個業務基礎類庫，大家在這個業務基礎類庫之上再開發業務功能就輕鬆許多。當然，這個業務基礎類庫搭建的不怎麼樣，沒有架構，沒有順應組件架構，那麼這個基礎類庫也會讓業務開發人員感到很變扭，還不如不做這一層基礎代碼。
所以說，理解了，順應了，才感覺到順暢與自由。不理解，無法順應思想，強制要基於之上開發，只能感到變扭，覺得幹嗎要這一層這麼礙事。
SOA，面向服務的、組件的、架構。這三個關鍵詞。架構，就肯定是分層分塊的。所以有組件容器，有組件，有組件通訊協議，有元件服務串聯編排工具和執行引擎。
不過，我總覺得現在服務編排還不大好。因為我過去面向組件開發的時候，有業務組件，也有流程組件。而BPEL，就是致力於流程組件這一目標。現在看著BPEL的XML，總覺得變扭。我自己隱約感覺這還不是最好的編排方式，XML適合配合，但不適合描述流程。描述流程，現在最適合，也最通用，最靈活的，應該是javascript。
我個人的觀點相信，未來的焦點決戰，肯定是javascript。而javascritp的決戰，不僅僅現在已經燒到了chrome瀏覽器，燒到flex action script，燒到open API，燒到比Restful WebService更有前途的atom APP上，未來，還會燒到企業市場的SOA中。
JAVASCRIPT，你看到了嗎。
我非常佩服我的朋友周愛民，他在JAVASCRIPT鑽研多年，非常精進，我相信，他看到了未來。