SOA and SOA Governance

軟體設計經驗

在這個過程中，我們給出了SOA和概述SOA Go vernance 。您將深入了解在開發過程中使用服務合同的附加價值。

關鍵概念和主題

• 什麼是SOA？
• 選擇什麼樣的建築風格？
• 「管道和篩檢程式」風格
• 數據類型約束
• 開發生命週期
• 提供適當的抽象級別
• RUP for SOA 中涉及的關鍵主題

服務標識和規範

• 構建服務模型
• WSDL 定義的服務
• 制定服務規範
• 定義服務提供者
• 確定服務的粒度
• 行為規範
• 策略規範
• 定義候選服務
• 重構服務

管理服務組合

• 應用程式作為動態實體
• 可用功能組合
• 處理時間綁定
• 運行時綁定
• WSDL、XSD 和 WS-Policy
• 服務組合管理流程
• 配置 Web 服務的 SLA

對面向服務的解決方案進行分區

• 管理模型
• 對元素進行分類
• 審查模型的不同利益干系人
• 使用套件
• 在模型中表示檢視
• 復合結構 UML 2.0
• 使用“零件”和“連接器”
• 對託管服務進行分區

新的和更新的準則

• 管理郵件附件
• 設計消息
• 確保消息架構的一致性
• 業務數據封裝
• 關係數據架構 - 服務邊界
• 服務仲介
• 狀態管理
• 有狀態和無狀態服務的優點
• 管理資源狀態
• Go從服務到服務元件
• 傳統的設計/實現模型

以消息為中心的設計

• 專注於服務領域
• 領域工程
• 應用面向物件的分析和設計
• 生成高度可重用的模型
• 傳統的企業對企業領域
• EDI標準化
• 以消息和以服務為中心的混合方法
• 用例分析
• 記錄需求
• 使用業務流程模型
• 非功能性需求
• 需求資料庫

以服務為中心的設計

• 公開業務預期的功能
• 暴露服務提供者的操作
• 製作直觀的服務介面
• 以服務為中心的建模
• 用例驅動的方法
• 了解參與者的需求
• 項目目標 - 從業務角度來看
• 軟體架構師的參與
• 服務消費者所需的策略資訊
• 業務主管角色
• 與後端系統的交互
• 將服務連接到實現模型
• 優化服務模型
• 解決性能問題

以 Collaboration 為中心的設計

• 協作服務
• 服務的流程檢視
• 傳統商業模式
• 在協作中履行角色
• 合作夥伴交換流程 （PIP）
• OAGIS 標準
• 以流程為中心的思維方式
• “業務與IT差距”
• “黑匣子”活動
• 定義關鍵績效指標 （KPI）
• 對模型進行版本控制和發佈
• 生成用於監控的指標
• 編舞語言
• 商務流程執行語言 （BPEL）
• 監控服務

什麼是SOA Governance？

• 遵守標準或法律
• 變更管理
• 確保服務品質
• 管理服務組合
• 管理服務生命週期
• 使用策略來限制行為
• 監控服務性能

SOA Governance 問題

• Go以 SOA 計劃的形式出現
• 服務交互的動態環境
• 鼓勵服務的重用
• 控制服務之間的交互方式

SOA Governance 實習生

• 第一：認識到治理是必要的
• 第二：治理提升業務執行力
• 第三：混合技術與行為的改變
• 第四：技術選擇與實施

服務 Management

• 設計時透視
• 運行時透檢視
• 用於重用的服務存儲庫
• 異構平臺中包含的服務
• 用於服務運行時管理的服務虛擬化

關鍵治理元件

• Service Registry Service 和資產存儲庫
• 創建一個“SOA Excellence 中心”
• 專注於建立SOA組織準則
• 組織成熟度
• 商定的治理政策

SOA Governance 工具

• 實時監控事件
• BSM 框架中的故障
• 服務級別檢測
• 與運營管理系統挂鉤
• 虛擬化是分離治理/服務邏輯的推動者
• 由運營人員管理的服務虛擬化

開發核心SOA治理

• 為什麼 SOA 技術棧變得複雜
• COTS和內部混合
• 證明外部顧問提供説明的合理性
• 弄清楚我們真正從事的業務

SOA Governance 中涉及的角色和職責

• 建立 Excel lence 的 SOA 中心
• 企業範圍的規劃和執行協助
• SOA 架構師/治理架構師的角色
• 解決潛在的利益衝突
• 確保遵循治理準則

SOA 治理的障礙

• 沒有意識到治理的必要性
• 缺乏 Governance 技術
• 缺乏服務虛擬化

善政狀況

• 與外部各方的互動
• 管理業務規則和 BRE 管理
• 善治條例
• 協定存儲庫
• 主動將治理嵌入業務中
• Go通過行動而不是通過聲明來表達
• SLA監控，確定溢價

關鍵成功因素

• 儘早開始考慮治理
• 將治理視為一個移動的目標
• 將策略作為具有自己生命週期的實體進行管理
• 選擇技術平臺
• 該平臺應滿足眼前的治理需求
• 隨著SOA基礎設施的擴展，未來的支援
• 強制執行服務級別協定