??????? 五一長假,感謝莊老師的支持,我可以專心去準備SOA的比賽了。一個人在宿舍看東西也挺悶的,找個人聊聊才好。還好下午有些收獲,且聽一一道來。
??????? 在SOA中,使用舊有的OOAD,EA,BPM這些建模方法已經不足以囊括SOA所涉及的所有部分,而集以上建模方法其中優點從其中改進而來的SOAD(Service-Oriented Analysis and Design)就成了SOA建模的首選了。
如何確認并定義服務呢?
?????? 有頂至下的,商業層次的建模技術(如CBM等)可以作為SOA建模活動的開始。但是SOA的實施并不是從無到有的過程,創建一個SOA的解決方案是通過拆分現有的遺留系統成服務,操作,商業流程和商業規則并整合他們。

直接和間接的商業分析
BPM和通過對股東的談話和CBM的直接商業分析是確定候選服務的合適的方法。
過往的經驗表明需要間接的技術來補足這種方法。當挖掘候選服務時,必須與產品經理和其他商業經理談話。比如,什么是計劃中的支付模型?正在建立中的系統和所有已有的非SOA的案例都會作為建議分析。在建中的商業表示的術語是另一個操作候選分析的主要來源。
領域拆分
領域拆分,子系統分析,目的模型創建和相關技術是最先的商業架構方法或服務概念框架的方案。
服務粒度
選擇合適層次的仇隙那個是服務建模的關鍵。應該將模型拆解到保證其完整性,一致性的越粗粒度越好。由于SOA不等同于Web service和SOAP不同的協議綁定可以用于在不同的抽象層次來訪問服務。另一個選擇是利用Fa?ade 模式來將數個相關的服務綁定成粗粒度的服務定義。
命名約定
企業范圍的命名規范(比如XML命名空間,Java包名,網絡域)需要被確定。比如可以用服務的以一個名詞和他的操作這個動詞來命名。這個建議是來自OOAD的名字空間。
以下是結合了OOAD,BPM和EA的SOAD重要的概念:
Service categorization and aggregation 服務分類與聚合
服務有不同的用處和目的,SOAD中可以通過executable models(如BPEL)來簡化其服務的組合。
Policies and aspects 策略與方面
在建模過程中服務是具有語法,語義和Qos特性的。正式的接口合約將不單單包括WSDL(Web Services Description Language),還將包括Ws-Policy等等。同時還須定義些非技術的領域專家也可以理解的語言來描述系統的結構。
Process: meet-in-the-middle 流程:上下雙管齊下
在處理真實世界的系統(包括遺留系統)用上下雙管齊下的方法將會比單純的自頂向下或者由下向上的方法更有優勢。由下至上的方法會導致不良的商業服務抽象,使其設計更多是聽從于現有系統,而不是去實現現有系統或者未來需要的需求。而有頂向下將會脫離現有的系統而產生不適合的需求。
Semantic brokering 語義代理
調用語法和語義是在接口定義中十分重要的。
Service harvesting and knowledge brokering 收集服務和知識代理
所有服務都是被定義用于重用的。所有服務的是被設計成超過1位用戶所使用的。
這些將會是我們在以后設計所需注意的原則。
?????????????????????????????????????????????????????????????????????????????????????????????????????????????????程啟健
? 2006-05-07