Posted on 2006-10-03 17:14
Dart 閱讀(1872)
評論(6) 編輯 收藏 所屬分類:
SCA
發個鬧騷
我們習慣把那些給企業單位做項目的公司稱為集成商。
現在來看，很多集成商日子并不好過，集成商由于競爭激烈，拿到項目變得比以前困難了，再加上現在給企業和單位做項目越來越難，
一個項目的實際投入和最后的回報越來越接近相等，于是利潤變得越來越少。
現在的項目開發商的投入越來越大，比如一個金融行業的項目開發商，從程序員到行業專家，各個層面的人才都要有；一個項目開發過程基本就是從無到有，而以前的項目積累，真正能復用的部分很少，最多的就是拿上一個項目的需求分析，作為這個項目開發的參考，將以前的代碼摘出來，能用就用，不能用的也將就用。
為了獲得最大利潤，開發商想盡了一切方法：比如加強對軟件開發過程的管理，盡量優化開發過程；構建自己的重用庫，盡量做到一勞永逸；壓縮開發人員的成本支出（薪水下降），盡可能提供工作效率（加班），但是誰有能想到，即使這么做了，還是難以應付日趨增加的項目的開發成本呢，再加上國內軟件行業的不規范化，錢是越來越難掙了。
而我們這些處于低層的開發人員是直接受害者：項目獎金成為了美麗的傳說，按時發放工資已經成為我們在同行面前驕傲的資本，于是開發人員紛紛以跳槽向公司提出抗議。領導們的日子更不好過，面對人才流動的加劇，項目周期不得不一拖再拖，最后也只能接受客戶壓價的決定，面對這種得不符失的情況，領導們開始吶喊：拿什么奉賢給你，我的員工？能
發工資就不錯了，還奢望項目獎金呢。就這樣，惡性循環開始了。
1.1 離職
這種現象我想并不是某一家公司是這樣的，應該說在很多公司都存在這種問題。那為什么導致這種問題的存在呢？競爭激烈？客戶越來越難擺平？還是公司自身存在的諸多問題呢？其實，這些都不是問題，每個行業都存在上述問題，軟件企業需要做的并不是解決上述問題，而是認真思考如何去降低我們的開發成本。
開發
平臺/框架的誕生
就如同上面所說的，多少年來，我們為許多企業，政府部門，銀行等單位開發了一套又一套的系統，每套系統的開發過程都如出一轍：需求分析，概要設計，詳細設計，編碼，
Debug
，交付，然后緊接著就是不停地根據用戶的需求更改或者增加系統功能，假設在需求分析和設計階段，我們做得很好，能夠很容易地應付用戶的需求變更，但是也不能做到應變自如。
在這種前提下，近年來，有很多公司開發研發“框架平臺”類產品，這一類產品可以分到中間件的范疇，作為業務邏輯層的中間件存在，它的任務就是將一些已經成型的技術和行業業務邏輯成了組件的形式，這些組件之間有著很強的交互性能，然后通過開發工具將這些組件按照業務需要像搭積木一樣組合起來，形成一套業務邏輯框架。這大大縮短了開發時間。這一類的產品目前不少，比如我以前所在公司的
ezONE
平臺，普元的
EOS
平臺，科諾的
KA
平臺，還有東方通的
BOA
等。
而這些“平臺”真的能夠提高我們的開發效率嗎？在一定程度上說是可以的，但是這需要我們已經擁有了大量現成的行業組件。
大量的可用組件，能夠讓開發人員更少地去關注技術細節，而把更多精力投入到對業務本身，讓我們的項目開發不會由于技術細節而耗費更多的時間。由于組件之間的可以動態進行配置，所以用戶的需求變更對于開發人員來說只不過是替換一個新的組件，再改變一下組件之間的連接調用順序而已。
2.1 “就像搭積木一樣簡單”
可惜的是，這些平臺都各自為戰，并沒有一個統一的標準。
SOA
和
SCA
SOA(面向服務)并不是什么技術標準，而是一種思想，它是方法論層面上的東西，就像當年的
OOP
一樣，只是一種指導我們思考問題的方法。
上面所提到的諸多平臺可以說就是基于
SOA
思想的，但是大部分還是基于構件或者組件的。它們把業務功能單元設計成了服務構件，服務之間通過明確的接口定義進行連接起來，這些粗粒度，松偶合的服務能夠很容易地進行整合。
但是
SOA
僅僅是一種思想，并沒有一個特定的技術規范或者標準，各個廠商為了能夠盡快讓
SOA
“落地”，于是就由數家比較大的
IT
公司推出了一個基于
SOA
思想的
SCA
框架標準。
SCA
標準目前還在完善階段，它于
2005
年
11
月發布了
0.9
版本，目前版本已經到了
0.96
。在
0.9
版本中，
SCA
標準就提出了
Java
實現以及
C++
實現標準，而且在以后的版本中，會陸續加入其他的實現標準，也就是說
SCA
并不是只針對某一種語言的，不同語言或者環境之間通過開放的，標準的技術來實現互操作，比如我們常見的WebService等
。
SCA
提出的這套基于
SOA
去構建企業應用的編程模型，它的基礎思想就將業務功能構造成一系列的服務，并且能夠很好地將這些服務組合起來，達到解決業務需求的目的。在構建這些應用時所用到的服務，不僅包含新建服務，而且可以包括已有的業務應用中的業務功能，也就是說，
SCA
提供了一套針對服務組合和服務創建的模型。
目前國內的
普元
已經加入到了OSOA組織，參與到了SCA/SDO的規范制定中，而且
中企動力
和
方欣科技
也作為Supporter加入到OSOA中。
而在實際開發中，很難說真存在這種一勞永逸的開發模式
可是隨著時間的推移，誰能保證這些組件庫的功能還能夠滿足用戶的需要呢？退一步說，這些粗粒度的組件庫能夠承擔多年后的開發任務嗎？而對這些組件庫的維護又怎么辦？
所有的一切我們只能拭目以待。
異想天開
假如真的存在一個完善的，標準化的面向服務的框架平臺，那我們以后的項目開發可能會是另外一種模式。
首先，在完善的面向服務框架平下，很多服務提供商開始誕生，這些提供商都是有多年行業經驗的開發商演變而來，他們將以前的項目積累作為服務發布出來，根據業務不同，創建出不同的服務，每個服務能夠完成一定的業務邏輯，但是需要進行整合或者二次開發。
然后在這種環境下，行業咨詢公司如同雨后春筍一般不斷涌現，這些公司都是由行業內部人士為核心的咨詢公司，他們將多年在行業內部的經驗轉變成需求，提供給集成商。
而集成商還需要一些外包開發商進行支持（不是人才外包），外包開發商具有很強的技術背景，擁有一批技術開發能力很強的開發人員，專門從事技術細節的實現，能夠很好地解決較難的技術細節問題。
一個項目的開發過程變成了由企業提出需求，然后通過行業咨詢公司，作出更專業需求以及解決方案，跟著企業會根據咨詢公司提供的方案和建議，去采購服務提供商的產品，然后將項目發給集成商，集成商再根據需要進行服務的組裝集成，然后在外包公司的協助下完成項目。
以后的項目開發，不再是一家公司從頭做到尾了，開發一個項目需要設計到各個領域專業性比較強的公司，這樣一來，開發任務分攤到了各個公司頭上，項目開發難度大大降低。
?
?
4.1 聯合起來
結束語
面向服務很有可能是以后的一種開發趨勢，各位開發同仁們不妨做做技術前瞻，多關注一下SCA/SDO的發展趨勢，為下一階段的工作做好準備。
有小道消息稱，現在企業的CIO一聽到“基于SOA”眼睛就放光……