從一個角度展望未來開發語言的發展方向

任何一個商品的產生，其實都是有兩股力量在發生作用。尤其是在軟體領域，一個是技術本身發展的推動力，另外一個就是需求的拉動力。

目前來看，無論是國際還是國內，幾乎所有的企業與組織機構都面臨一個資訊系統整合的問題，即大家經過一個逐步發展、逐步建設的過程，建立了一系列的軟體產品，來為自己的某個或者某些需求服務。在這些資訊系統建設的初期，幾乎每個系統都展現出其在資訊化方面的優勢，為企業或組織機構帶來一些諸如工作效率提高等的直接可見的優點。

但是，由於資訊系統在建設的過程中，只是著眼於某個或者某幾個部門的業務需求，沒有一個可以給整個企業或者組織機構帶來整體的效益。比如說，前期已經建設好的HR、財務等業務系統，都分別為不同的業務部門服務。但是，在人員資訊發生變化之後，無論是HR還是財務，兩個系統各自都需要進行變更，相當於同樣的資訊，需要在兩個孤立的資訊化系統中，分別維護。這樣極易導致不同業務系統的資料不一致，以及由此帶來的重複操作。而且這樣的問題，隨著已經建設的資訊系統的數量的增多而呈現出指數級的增長。

另外，企業的高層人員，往往通過已經建設的這些業務系統，無法看到目前企業的運營情況。因為，每個業務系統的資料都只為自己的業務部門服務，從而產生的資料也只是針對某個（或者最多某幾個）業務部門，對於整個公司層面的綜合資料，或者無法提供，或者只能通過人工的方式來操作。

於是，在IT領域就產生了能夠讓不同的業務系統進行互聯互連的各種技術。初期，為了能夠將不同的業務系統融合起來，大家採用相對原始的點對點的被動串連方式。即某個時期，需要某幾個業務系統之間進行互動，則針對目前的需要，直接建立點對點的互動（或者最多大家都放到第三方庫中）。這樣的點對點的被動式系統整合的建設，最終的一個結果就是，整個企業建成的資訊系統之間形成一個類似神經系統的網路，牽一髮而動全身，即緊密的耦合。最終，整個企業的資訊系統變得異常僵化，任何一個小的改動，都可能會導致整個系統的故障，甚至崩潰！

所以，現在大家都在推SOA。其實SOA的產生，就是一個需求拉動與技術推動兩個作用力共同作用的結果。既想要進行資訊系統的整合，又想要一個明晰的IT架構。SOA的核心訴求，總結起來就是一個詞——“敏捷”，保障業務業務系統及其之間的整合與互聯互連，並且能夠非常迅速的適應業務變化的需要。

目前看來，大家都比較推薦使用WebService的方式，來保證相互之間的靈活整合。但是，WebService仍然是在開發期或者後期二次開發時，根據具體的需求構建出來的服務，相對來說其可維護性及靈活性並不怎麼高。於是，這就對將來的開發語言提出了一個潛在的需求，可以動態封裝WebService（當然未來隨著技術的發展，也許不是WebService這種形式，但是一定是一種大家都認可的規範的形式）。

未來在開發軟體時，軟體內部的結構，仍然會跟目前的方式差不多，不可能把一個軟體內部所有的模組或者組件都是以WebService的形式開發。因為，畢竟WebService在資源的消耗以及效能方面會比直接的內部調用差很多。但是，未來的開發語言，會允許軟體的終端使用者，根據自己實際的業務需要，將軟體中某個功能模組甚至是更細的部分，比如頁面中的某個按鈕的單擊事件，定義成一個WebService。即WebService的發布，最終用於不再依賴於開發軟，而是可以非常方便的根據自己的需要，動態設定。當然，設定之後的結果的持久化，是必須提供的功能。

使用這樣的開發語言開發的應用系統，不僅可以滿足現有的業務系統的需要，還可以非常方便地與其他的業務系統進行整合。

最終，建成的業務系統，就像之前曾經多處看到的多個不同的顯示器，一接觸就可以自動組裝成一個更大的顯示器的情形一樣。多個業務系統之間，可以非常智能的相互識別，並實現最終的融合。這樣的功能也許業務系統本身就可以實現，也許需要藉助於第三方的平台。