傳統的軟件開發咱們看到能力複用層面是比較差的,對於系統管理,工做流引擎,公共技術組件庫,UI庫,技術架構和平臺每每都須要本身搞一套,這自己和 SOA複用的思想也是違背的。按SOA業務和流程驅動IT,CBM組件化業務模型的思路,後續最理性的就是逐步淡化掉業務系統的概念。整個企業就一個業務大系統,在這個業務大系統裏面剩餘的僅僅是業務功能組件。
原有的系統構建和結構能夠描述爲以下:
基於組件化架構的思路,須要解決的是淡化業務系統的概念,強化業務組件的概念。同時對業務系統內部已有的業務功能模塊進行解耦,業務組件經過註冊到ESB 上的業務服務進行交付。而基於平臺化的思路,則是原有業務系統構建過程當中全部和業務無關的內容都進行平臺化建設,全部平臺化層面的內容都進行統一規劃和建設,爲全部的業務組件提供公共服務能力。以下圖:
在這種模式下能夠看到業務系統徹底進行了拆解,真正一個業務系統的構成須要多個技術能力支撐單元和業務單元共同組裝來完成。對於用戶來說可能看不到太大的變化,可是在內部實現細節上則進行了平臺化和標準化。理想的業務系統構建模式將變化爲基於一個完整的提供技術,平臺,前臺展示各類支撐能力的空應用容器中開發知足各個業務需求的業務組件。
系統再也不是後續的交付單位,業務組件纔是交付單位。業務組件建設徹底只關注業務,不關注技術底層和各類平臺層能力的實現。業務組件經過服務接口和各類底層支撐能力,外層掛接能力進行集成。業務組件高度自治,能夠獨立進行分析,設計,打包部署和運行。
公共技術組件和平臺層組件徹底獨立部署和運行。其能力的提供一方面能夠是以註冊在ESB總線上的服務的方式,也能夠是業務組件直接內嵌平臺層組件提供的代理模塊和輕量API接口。底層組件提供全局的數據建模和數據存儲,這些數據跨全部的業務組件共享。
外層應用框架是一個徹底能夠運行起來的相似門戶的框架,其自身已經包含了登陸認證,權限,菜單管理等各類基礎功能。外層應用框架實現各個業務組件的動態裝載和使用。企業內應用構建徹底實現AppStore化。而對於ESB企業服務總線,則既實現業務組件和底層平臺層的服務集成,也實現業務組件間的服務集成。技術集成以消息和輕量的rest方式實現,而業務集成則以傳統的soap webservice方式實現。html