IBM? 面向服務體系結構(Service-Oriented Architecture,SOA)編程模型使非程序員可以創建和重用 IT 資產,而不需要掌握 IT 技能。該模型包括組件類型,布線,模板,應用程序適配器,統一數據表示和企業服務總線(Enterprise Service Bus,ESB)。本文是系列文章的第一部分,該系列文章介紹了 IBM SOA 編程模型,選擇、開發、部署工作所需的內容,以及建議的編程模型元素。本文陳述的內容考慮了使用該模型的開發人員可能具備不同的技術水平和工作角色。
SOA 編程模型系列
對于任何獨立程序員來說,有效的掌握和應用飛速增長的軟件技術、實踐、工具和平臺,變得越來越困難,當然更不用說非程序員了。然而,如果業務流程轉換能夠成功進行,很多的非程序員就可以使用現有的 IT 資產來進行他們的工作,而不用去學習繁瑣的底層技術細節。本系列文章描述了一個新的面向服務體系結構(SOA)編程模型,該模型實現了業務關系的分離,因此企業中具備不同技術水平和工作角色的人,即使不是專業的 IT 人員,也可以在軟件開發生命周期每個階段創建和使用 IT 資產。這可以顯著提高隨需應變企業的業務靈活性。
引言
IBM 產品逐漸應用了 SOA 和編程模型。程序員構建服務、使用服務,并且開發聚集服務的解決方案。我們在這里使用"程序員(programmer)"這個泛稱,因為 SOA 編程模型的一個關鍵方面是將"編程"的概念擴展到非傳統開發人員的工作角色和技能,比如業務分析員和腳本語言用戶。
大多數關于 Web 服務的文章主要集中在服務接口和這些接口的使用方面。為了補充接口標準和最佳實踐,IBM 引入了一個編程模型,來實現服務并將它們組合為解決方案。擴展 IBM 軟件平臺的范圍,使之能夠被更多的用戶團體使用 -- 包括非傳統的開發人員 -- 這個模型提供了新的組件類型與用戶的角色、目標、技能和概念框架相匹配。這些組件類型使更直觀的開發工具可以使用。另一個主要的主題是通過編程模型特性和功能的逐步透明化來增強可使用性。
這是關于 SOA 編程模型系列文章中的第一篇,特別針對軟件開發專業人員。在本系列中,我們介紹了實現這些目標的一些新的編程模型元素。我們介紹了如何利用它們來使您選擇、開發、建議或管理的軟件能夠更加容易的開發、重用和消費。將軟件構造為服務對于按需的企業來說更加有價值,因為不具備太多技能的開發人員可以將其"接入"到解決方案中,或者編入一個業務流程編排流中來滿足快速變更的業務需求。不管你是大型企業或者小型業務的開發人員、獨立軟件供應商(ISV),還是應用程序提供者或者中間件供應商,你都可以通過這種方式構造你的軟件,從而從中受益。那么,讓我們立即開始應用 SOA 原理。
SOA 編程模型的亮點
讓我們首先重點介紹 SOA 編程模型的幾個主要特性。
服務數據對象(SDO)是 IBM SOA 中的一個基礎概念。SDO 大大提高了開發人員的生產力,并且將你從如何訪問特定后端數據源、應用程序和服務的技術細節中解脫出來。它們提供了簡化的抽象,使程序員可以更多的集中在業務邏輯上。SDO 還提供了統一的消息表示來與服務交互,淘汰了用于數據表示的復雜技術迷宮,僅僅訪問單個統一模型。
SOA 編程模型同樣需要統一的范型來創建和訪問業務邏輯。為了易于使用,服務應該隱藏實現技術之間的差別,并應該建立在比現有編程結構(比如 Enterprise Java?Bean(EJB))更高級別的抽象上。服務可以通過組裝到模塊(這些模塊可以組成解決方案)中的組件來實現。通過組件公開的服務可以使用可定位的接口來調用。您可以使用 Web 服務描述語言(WSDL)、Java 或其他語言來描述接口。這個實現類型可以有對所需服務的待定引用,在將組件結合在一起執行之前,這些服務是滿足需求的。
這個編程模型還引入了良好定義的組件類型,對程序員開發和部署到解決方案中的常用構件建模。例子包括"無格式舊 Java 對象"、業務流程執行語言(BPEL)流程、結構化查詢語言(SQL)服務、Adaptive Business Objects、通過 Java 連接器體系結構(J2C)資源適配器訪問的 CICS?程序、使用 SAP 業務應用程序編程接口的應用程序、Java 2 Enterprise Edition(J2EE)無狀態會話 bean 和 MQSeries? 應用程序。
企業服務總線是多協議結構的一個關鍵角色,將服務組件編成無縫的交互,通過在消息路徑中加入被稱為中介的特別組件,來代理服務間的交互,而不用更改現有的端點,從而允許在核心級別上處理企業關注的內容 -- 比如審核、日志、路由、不匹配接口的適配、等價組件的增量替換、安全等。
新的流程語言縮小了 IT 概念和業務構件之間的間隙。很重要的一個是 BPEL。雖然流程可以通過業務分析員引入圖形化工具來定義,但它也是一個可執行程序。流程在按需業務轉換中占有重要的地位,例如為擴展價值鏈描述長時間運行的可執行流程。通過擴展價值鏈,我們可以跨越多個供應商和 IT 域來進行業務安排,比如一個零售商和他的多個獨立的供應商,保險公司及其眾多的第三方理賠員,IT 外購狀況等。
業務狀態機(business state machine)是業務分析師可以通過圖形工具創建流程的另一個編程框架,并且在流程設計引擎中執行。狀態機可以表示業務構件 -- 比如采購單、保險索賠等 -- 這些轉換通過一些良好定義的狀態來響應特定的生命周期"事件"。
需要重用的組件可以封裝為具有可變店(points of variability)的模板,可以在放入解決方案中時進行設計。這種適配成為我們的編程模型的第一部分,同時結合規則語言和相關的工具,為新型用戶提供定制的能力。
另一個創新領域是新的解決方案模型,它讓部署者、管理者和其它業務用戶可以將組件組裝成解決方案。在開發的時候,你可以將服務實現與托管服務的拓撲(系統架構師建模的部署拓撲)關聯在一起。模型捕捉的系統需求和環境假設在早期的實現中進行校驗,降低了應用程序生命周期的費用,并且極大的提高了可靠性和可計賬性(accountability)。該模型的特性還包括現有應用程序的后期綁定、數據轉換中介和適配器,可以通過企業服務總線來實現面向服務的交互。
總的來說,SOA 編程模型將開發和部署活動分割為不同的階段,這些階段可以發生在不同的時間,并且可以通過不同的個人使用不同的技能來實現。這就產生了關系的分離,使軟件組件可以被重用。它也將軟件體驗劃分為單獨用戶的業務角色、技能和任務。最終,它使軟件生命周期可以適應按需企業的需要,因為它們通過針對業務靈活性重新設計 IT 流程來尋求更高的有效性。
編程模型的概念
編程模型通常是 IBM SOA 和 IBM 產品的核心。它定義了程序員可以構建和使用的概念和抽象。運行時產品,例如 WebSphere? Application Server,DB2?和 CICS,可以運行或托管編程模型構件。開發工具支持編程模型構件的建模和實現、組裝到應用程序(解決方案),以及部署到運行時環境中。最后,系統管理產品、代理和設備支持對運行時和它們托管的編程模型構件的管理。
編程模型是什么?雖然目前沒有公認的一般定義,但我們喜歡將它定義為:
- 程序員構建的一套部件類型。部件類型包括多種編程模型構件:超文本標記語言(HTML)文件、數據庫存儲過程、Java 類、可擴展標記語言(XML)Schema 定義、定義 MQSeries 消息的 C 結構,等等。
- 一系列角色,將具備相似技能和知識的開發和管理人員分組。用這種方式對開發人員分類有助于生產適應于角色的工具,使非程序員可以實現服務并將服務組裝為解決方案。業務分析人員定義業務流程,銷售專家定義顧客分類的策略并計算產品折扣。每一種角色包含:
- 角色所具備的技能。例如,用戶界面開發人員開發界面,用來呈現應用程序或者解決方案的功能構件。假設這個角色了解正在開發的應用程序和它的業務目標,充分了解應用程序的用戶及他們的任務,精通一些用戶界面設計方法,能夠通過為每個任務選擇恰當的類型來創建易于使用的用戶接口。
- 角色交互(消費或者生產)所用的部件類型和應用程序接口。例如,動態頁面設計人員 -- 角色 -- 生產 JavaServer Page(JSP)并消費 EJB -- 部件類型 -- 包裝現有的信息資源和應用程序。
- 角色使用的工具。例如,Web 開發人員所用的適合于角色的工具是所見即所得的頁面設計工具,用來構建動態頁面,使用與 HTML 和 JSP 標簽庫相關的控件,并將控件連接到 EJB。
使 Web 服務易于實現和使用的關鍵是對現有技術和知識進行增量擴展,從而使 SOA 可以被消費。以 CICS COBOL 事務程序形式存在的服務與用 BPEL 編寫的服務差別很大。從數據庫存儲過程中調用服務與從 JSP 中調用也是不同的;技能和期望值是不同的。通過提供工具的分類來使部件類型適應于各種技能,并適應于開發流程的階段,你可以實現可消費性(consumability)。
本系列的后續文章更加詳細的介紹了 SOA 編程模型的部件類型。
產品架構
圖 1. 產品架構
支持 IBM SOA 方案的產品分成兩個主要類別:服務端點和連接它們的消息傳送結構。這個通用的架構 -- 包含了許多產品,這些產品都不是 IBM SOA 的專用傳輸工具 -- 如圖 1 所示。
核心是服務間的 ESB 提供的連通性。ESB 是多協議的,支持點到點和發布-訂閱兩種通信類型,并支持快速處理消息的中介服務。IBM WebSphere MQ,IBM WebSphere MQ Integrator Broker 以及支持 Web 服務和 Java 消息服務(JMS)的 WebSphere 都屬于第一個類別。
服務存在于抽象的托管環境(容器)中,并且提供了特定的編程框架。容器加載服務的實現代碼,提供到 ESB 的連接性,并管理服務實例。不同類型的服務存在于不同的容器中。(在典型的遞規設計的例子中,ESB 本身被認為是用于中介服務的容器。)表 1 列出了一些主要的 IBM SOA 托管環境和托管的組件類型。
表 1. 托管各種組件和服務類型的容器
服務/組件類型
|
容器
|
用 COBOL、PL/1 和其他語言編寫的事務處理程序 |
CICS 或者 IMS(信息管理系統 -- 一種企業事務處理系統)。程序員可以使用 SOAP/HTTP、WebSphere MQ 和 J2EE J2C 連接來訪問服務。 |
業務流程編排 |
WebSphere Business Integration Server Foundation。該容器支持長期存在的工作流,這些工作流實現了 Web 服務接口并調用其他 Web 服務上的操作。它同樣支持長期運行的業務活動事務。 |
應用程序適配器 -- 為現有的應用程序和系統提供 SOA/Web 服務的會話虛包(facade)。 |
WebSphere Business Integration Server Foundation 提供的應用程序適配器容器。適配器在 SOA 協議和格式,以及現有應用程序和系統的協議和格式之間進行轉換。例如,SAP 適配器將 SOA 編碼并通過 HTTP 傳輸的 XML 轉換到 SAP 的現有業務應用程序編程接口格式和 Remote Function Call(RFC)。 |
預定義的 SQL 查詢、XML 查詢或數據庫存儲過程實現的服務 |
DB2 結合 WebSphere Application Server。查詢的參數來自 SOA 操作的輸入消息以及提供輸出消息的結果。 |
使用 Java 類和 EJB 實現的服務。 |
WebSphere Application Server。 |
結束語
IBM SOA 編程模型系列文章的第一篇概述了 IBM 工具和產品如何適用于模型,以及開發人員如何有效的在應用程序開發中使用它。
- 使用 SDO 簡化數據訪問
- 服務定義以及組件模型發展狀況的介紹
- 用組件類型來簡化開發
- 基本組件類型
- 服務組合和定制
- 流程組件:BPEL 和業務狀態機
- 定制服務:設計模式,模板和可變點
- 面向服務的用戶接口
- 用于管理的 SOA 方法
- SOA 軟件生命周期開發工具
- SOA 的安全性