Web服務作為炙手可熱的技術
如何應用到企業的IT系統和商業流程之中
並給企業帶來直接的經濟效益
一直備受國內外企業管理者的高度關注和推崇
而在近兩年
出現了一種技術架構被譽為下一代Web服務的基礎架構
它就是SOA（Service
oriented architecture
面向服務架構）
年
Gartner最早提出SOA
年
月
Gartner提出SOA是
現代應用開發領域最重要的課題
還預計到
年
SOA將成為占有絕對優勢的軟件工程實踐方法
主流企業現在就應該在理解和應用SOA開發技能方面進行投資
更好支持商業流程 SOA並不是一個新事物
IT組織已經成功建立並實施SOA應用軟件很多年了
BEA
IBM
等廠商看到了它的價值
紛紛跟進
SOA的目標在於讓IT變得更有彈性
以更快地響應業務單位的需求
實現實時企業（Real
Time Enterprise
這是Gartner為SOA描述的願景目標）
而BEA的CIO Rhonda早在
年
月就提出要將BEA的IT基礎架構轉變為SOA
並且從對整個企業架構的控制能力
提升開發效率
加快開發速度
降低在客戶化和人員技能的投入等方面取得了不錯的成績
SOA是在計算環境下設計
開發
應用
管理分散的邏輯（服務）單元的一種規范
這個定義決定了SOA的廣泛性
SOA要求開發者從服務集成的角度來設計應用軟件
即使這麼做的利益不會馬上顯現
SOA要求開發者超越應用軟件來思考
並考慮復用現有的服務
或者檢查如何讓服務被重復利用
SOA鼓勵使用可替代的技術和方法（例如消息機制）
通過把服務聯系在一起而非編寫新代碼來構架應用
經過適當構架後
這種消息機制的應用允許公司僅通過調整原有服務模式而非被迫進行大規模新的應用代碼的開發
使得在商業環境許可的時間內對變化的市場條件做出快速的響應
SOA也不僅僅是一種開發的方法論
它還包含管理
例如
應用SOA後
管理者可以方便的管理這些搭建在服務平台上的企業應用
而不是管理單一的應用模塊
其原理是
通過分析服務之間的相互調用
SOA使得公司管理人員方便的拿到什麼時候
什麼原因
哪些商業邏輯被執行的數據信息
這樣就幫助了企業管理人員或應用架構師迭代地優化他們的企業業務流程
應用系統
SOA的一個中心思想就是使得企業應用擺脫面向技術的解決方案的束縛
輕松應對企業商業服務變化
發展的需要
企業環境中單個應用程序是無法包容業務用戶的（各種）需求的
即使是一個大型的ERP解決方案
仍然不能滿足這個需求在不斷膨脹
變化的缺口
對市場快速做出反應
商業用戶只能通過不斷開發新應用
擴展現有應用程序來艱難的支撐其現有的業務需求
通過將注意力放在服務上
應用程序能夠集中起來提供更加豐富
目的性更強的商業流程
其結果就是
基於SOA的企業應用系統通常會更加真實地反映出與業務模型的結合
服務是從業務流程的角度來看待技術的
這是從上向下看的
這種角度同一般的從可用技術所驅動的商業視角是相反的
服務的優勢很清楚
它們會同業務流程結合在一起
因此能夠更加精確地表示業務模型
更好地支持業務流程
相反我們可以看到以應用程序為中心的企業應用模型迫使業務用戶將其能力局限為應用程序的能力
企業流程（enterprise process）是流經企業框架的空氣
它賦予業務模型裡的組件以生命
並更加清晰地定義了它們之間的關系
流程定義了同業務模型進行交互操作的專門方法
例如
會計可能是企業服務系統的一個組件
但是將發票寄給客戶卻是一個業務流程
服務被定義用來支持業務流程
因而貫穿整個流程始終的是
各種服務組件在流程和邏輯實現過程中的裝配操作
理解業務流程是定制服務的關鍵所在
有利於企業業務的集成 傳統的應用集成方法（點對點集成
企業消息總線或中間件的集成（EAI）
基於業務流程的集成）都很復雜
昂貴
並且不靈活
這些集成方法難於快速適應基於企業現代業務變化不斷產生的需求
基於面向服務架構 (SOA) 的應用開發和集成可以很好的解決其中的許多問題
SOA 描述了一套完善的開發模式來幫助客戶端應用連接到服務上
這些模式定制了系列機制用於描述服務
通知及發現服務
與服務進行通信
不同於傳統的應用集成方法
在 SOA 中
圍繞服務的所有模式都是以基於標准的技術實現的
大部分的通信中間件系統
如 RPC
CORBA
DCOM
EJB 和 RMI
也同樣如此
可是它們的實現都不是很完美的
在權衡交互性以及標准定制的可接受性方面總是存在問題
SOA 試圖排除這些缺陷
因為幾乎所有的通信中間件系統都有固定的處理模式
如RPC 的功能
CORBA 的對象等等
然而
服務既可以定義為功能
又可同時對外定義為對象
應用等等
這使得 SOA 可適應於任何現有系統
並使得系統在集成時不必刻意遵循任何特殊定制
SOA 幫助企業信息系統遷移到
leave
and
layer
架構之上
這意味著在不用對現有的企業系統做修改的前提下
系統可對外提供 Web 服務接口
這是因為它們已經被可以提供 Web 服務接口的應用層做了一層封裝
所以在不用修改現有系統架構的情況下
SOA 可以將系統和應用迅速轉換為服務
SOA 不僅覆蓋來自於打包應用
定制應用和遺留系統中的信息
而且還覆蓋來自於如安全
內容管理
搜索等 IT 架構中的功能和數據
因為基於 SOA 的應用能很容易地從這些基礎服務架構中添加功能
所以基於SOA的應用能更快地應對市場變化
為使企業業務部門設計開發出新的功能應用
下圖提供了使用基於服務集成的企業應用的高級視圖
與傳統的企業應用集成架構的主要區別在於該系統使用基於標准的服務
並包括過程/數據服務
編排和組合
基於標准的服務成了應用間的集成點
服務的編排和組合增加了服務的靈活性
重用性和集成性
圖示使用基於服務集成的企業應用 SOA服務粒度 可以按基於服務的功能及發送和接收的數據數量來定義服務
如細粒度服務
粗粒度服務或組合服務
在 SOA 中服務粒度有兩種相關的意思
服務是如何實現的
服務使用和返回了多少數據或多少消息
細粒度服務執行了最小的功能
發送和接收少量的數據
粗粒度服務執行了較大的業務功能
並交換了更多的數據
細粒度服務是供粗粒度服務或組合服務使用的
而不是由終端應用直接使用的
如果應用是使用細粒度服務建立的
則應用將不得不調用網絡上多個服務
並且發生在每個服務上的數據量較少
因而會對對系統整體性帶來影響
所以粗粒度服務的用戶不能直接調用他所使用的細粒度服務
然而
由於粗粒度服務可能使用多個細粒度服務
因此它們不能提供粒度級的安全和訪問控制
組合服務可以使用粗粒度服務和細粒度服務進行組裝
數據數量數量不是粗粒度服務和組合服務之間的區別
粗粒度服務例子
如創建新客戶
在這一過程的操作是
需要通過一些外部服務驗證對客戶進行驗證
並在 CRM 應用系統中創建客戶記錄
組合服務例子可以是提供一個新的DSL線
這需要一個服務調用來驗證定單
創建或驗證客戶
確認產品庫存及為數據線分配資源
下圖描述了服務粒度的不同級別及它們之間的關系
圖示服務粒度 通過一組有效設計和組合的粗粒度服務
業務專家就能夠有效地組合出新的業務流程和應用程序了
SOA與Web服務 SOA不是一定需要 Web 服務來實現
並且一個基於Web 服務開發出來的應用也不代表就是一個基於 SOA 構架應用
Web 服務只是服務實現的一個典型
是實現企業 SOA的一個組件（非必需組件）
SOA 為基於服務的分布式系統提供了概念上的設計模式
Web 服務則是基於標准的
可經濟實惠地實現 SOA的一項技術
SOA將IT資源透過服務這樣一個在業務上有重要涵義的概念來提供
共享
把IT與業務的距離更加拉近了一步
服務在涉及的層次上要比組件
函數
流程等更高
而且往往在業務上可以找到與之直接對應的概念或實體
例如報價
訂單
服務打破了IT系統間的藩籬
就像一家公司的各個部門
平常各自扮演特定對內或對外服務的角色
但彼此間如果能有效地通過共通的語言及文字
進行良好的溝通
便能協力達成更大
更高的目標
隨著SOA和Web服務的潮流
帶來了組合式應用（composite application）的開發方式和觀念
開始逐漸被大量應用在Portal（門戶）和Integration（集成）上
組合式Portal的做法
就是通過Portal界面所提供的應用
往往不是真的在Portal服務器上執行
而是將Web服務即時抓過來
再加以呈現
同時匯總給Portal的使用者
在整合方面也是采用組合式的方式
通過高級工具來設定
使系統得以靈活地配合任務的調整
對各項以Web服務方式提供的服務進行不同形式的串聯和協作
同時快速地加以部署
年
月
BEA發布了一個企業門戶合理化（enterprise portal rationalization
EPR）戰略
這個戰略用來平衡BEA WebLogic Platform的SOA能力
憑借最好的行業實踐和行業專家
幫助客戶解決多年來形成的散亂的portal和Web應用程序開發
如果說Web服務等技術是SOA的血肉
那麼正確的服務設計理念及系統運行平台則是SOA的靈魂
SOA試圖讓IT能更快和業務同步
在規劃上以提供彈性的業務服務為目標
從CIO到負責規劃的系統分析人員
需要和業務單位
策略伙伴間有充分的溝通
CIO必須認識到
SOA的建立將是一個為期數年的承諾
基礎建設需要按部就班地進行
資助的模式也必須在IT和各個業務部門間建立
來陸續支援基礎建設及各項業務服務的開發
在中間件領域
SOA架構日益成為中間件軟件供應商爭
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26963.html
