M-A-T Tory's Blog

關于BPEL好像不是你那么理解的，我建議你看看這篇文章
http://www-128.ibm.com/developerworks/cn/webservices/ws-bpel/part1/

這幾天可能有些亂，前幾天定的計劃是學習。主要學關于UML，和一些與業務相關的知識，以及WebService。但考試好像把這一計劃弄亂了，今天Merlin把業務擴展的已經差不多了，就像我說的一樣，在這上面用不了很多時間。接下來的任務就應該是業務建模了吧，。但這方面的知識我們懂得不是很多，我們最后要的文檔是專業的，不能隨便寫一個就算了。總之，我覺得現在還不是寫文檔的時候，時間很緊，這是事實。但我們決不能急，很多事情光著急時沒有用的。靜下心了，還是好好的學習。如果你覺得時間緊，那就抓緊時間。定計劃時一定要想明白你現在能干什么，計劃定得再好，完不成就是扯！

這個時候的考試讓人覺得很不爽，明天該看WebService了

今天去了學校的收發室，地址寫的應該沒什么問題。估計是五一耽誤le ，這幾天的計劃已經定了，努力吧！

盡自己所能吧

架構是一個系統的核心，系統的好壞完全有架構決定。也許現在的架構還不能稱得上真正的架構，隨著學習的深入，它可能被更改。由于搜索引擎的存在，很多東西不方便寫在這里，呵呵。

這兩天的研究WebSphere，400多頁的英文的讓人一看腦袋就大。但仔細多起來發現也沒什么，文章中基本上都是很簡單的句型，不像英語考試中有那么多的復合的長句。雖然開始的時候有不少單詞不認識，但在金山詞霸的幫助下可以很輕松的理解。那些單詞出現的頻率很高，到了后來基本上就記住了。良好的英文閱讀能力在將來的工作中是必需的，現在就應該加強鍛煉。關于這兩天的一些心得貼在我的Blog 上，有些亂，大家可去看看，等我對WebSphere 有了更全面的認識后我會好好總結一下，與大家分享。

我昨天的總結已經發在我的Blog 上了，大家可以過去看看。這里把一個個人認為很有用的一點東西貼在這：

SOA 的一個架構模板

SOA 的一個抽象觀點將它描述為與業務過程結合在一起的合成服務的部分分層架構。 圖 3 呈現了這種類型的架構。

服務和組建之間的關系是，企業級的組件（大粒度的企業或者業務線組件）實現該服務并且負責提供它們的功能和維持它們的服務質量。通過組合這些公開的服務到合成的應用程序，就可以支持業務過程流。綜合的架構通過使用 Enterprise Service Bus（ESB）支持這些服務、組件和流程的路由、中介和轉化。為了服務質量和非功能性的需求，必須監視和管理已經部署的服務。


圖 3：SOA 層

對于每一層，你都必須做設計和架構決定。因此，為了幫助用文件說明你的 SOA，你可能應該創建文檔，由每個層相應的部分所組成。

這里是為你的 SOA 架構文檔設計的模板：

范圍 <此架構適用于企業的哪個領域>
操作系統層
打包的應用程序
自定義應用程序
架構決策
企業組件層
企業組件支持的功能范圍
<這個企業組件支持業務領域、目標和過程>
關于控制的決策
<作為這個客戶端組織內部企業組件來選擇某物的標準>
架構決策
服務層
服務分類表
架構決策
業務過程和合成層
業務過程可以表現為舞蹈編排（choreographies）
架構決策
<哪一個過程需要編排在舞蹈編排里面以及哪一個鑲嵌在應用程序里面？>
訪問或者表現層
<證明這層中 Web 服務和 SOA 的含意；即便要。例如，在用戶接口級別上調用 Web 服務的 portlet 的使用，以及在此層機能上的含意。>
集成層
<包含 ESB 因素>
<我們如何確保使用服務的客戶端系統級的一致性（SLA）和服務質量（QoS）？>
安全問題和決策
性能問題和決策
技術和標準的局限性以及決策
服務的監控和管理
描述和決策
現在，讓我們更加仔細的描述一下每一層以及每一層之間的合成。


層 1：操作系統層。本層包含現有的自定義構建的應用程序，也叫做 遺留系統，包含現有的 CRM 和 ERP 打包應用程序，以及 較舊的基于對象的系統實現，還有業務智能應用程序。SOA 的復合層架構可以利用現有的系統并且用基于服務的集成技術來集成它們。

層 2：企業組件層。本層由那些負責實現功能和保持公開服務 QoS 的企業組件組成。這些特殊的組件是企業和業務單元級支持的企業資產的受管理和控制的集合。 同企業范圍資產一樣，他們通過架構最佳實踐應用程序來負責確保 SLAs 的一致。大多數情況下，本層使用基于容器的技術，比如實現組件、負載均衡、高可用性和工作量管理的應用服務器。

層 3：服務層。業務選擇來支持和公開的服務處在這一層。它們可以被 發現或者直接靜態綁定，接下來被調用，或者可能的話，編排到合成服務中。這個服務公開層同樣提供了獲取企業范圍組件，業務單元特定組件，以及有些情況下，特定項目組建的機制，并且以服務描述的形式具體化了他們的接口子集。因此，企業組件使用它們接口提供的功能在運行時提供服務實現。在這一層的接口公開為一個服務描述，在這層中他們被公開以提供使用。他們可以獨立存在或者作為合成服務。

層 4：業務過程合成或編排層。第三層中公開的服務的合成和編排在這一層中被定義。通過配合、編排，服務被綁定成一個流程，并且從而作為單獨的應用程序而共同作用。這些應用程序支持特殊的用例和業務過程。這里，可視的流程合成工具，比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用來設計應用程序流程。

層 5：訪問或表現層。盡管這一層經常超出了圍繞 SOA 討論的范圍，但是它卻變得越來越有意義。在這里我描述它因為標準越來越集中，比如用于 Remote Portlets Version 2.0 的 Web 服務和其他技術，這些技術追求在應用程序接口或者表現層來利用 Web 服務。你可以把它作為將來的層用來滿足將來的解決方案的需求。注意到以下這兩點是非常重要的：SOA 將用戶接口從組件中分離出來；最終你需要提供從訪問路線到服務或者合成服務的端到端解決方案。

層 6：集成（ESB）。這一層使服務可以集成，通過引入一系列可靠的性能的集合，比如智能路由，協議中介和其他轉化機制，經常被描述為 ESB（參閱 參考資料）。Web Services Description Language（WSDL）制定了綁定，其包含提供服務的地址。另一方面，ESB 為集成提供了位置獨立機制。

層 7：QoS。這一層提供了監視，管理和維持諸如安全，性能和可用性等 QoS 的能力。這是一個通過 sense-and-respond 機制和監測 SOA 應用程序健康的工具來進行的后臺處理過程，包括 WS-Management 和其他相關協議的所有的重要的標準實現以及為 SOA 實現服務質量的標準。

這篇文章主要講了如何將 Web 服務組件組合成跨多重 SOA 的中間件應用程序，以及如何使用下面四種不同的方法來開發它們：

1.自頂向下
2.自底向上
3.旁路
4.嵌入式

在開放的體系結構中開發 SOA 中間件應用程序依賴于（舉例）您想要使用哪種關系型或 WebSphere® 包。

還在讀《在企業級 SOA 中使用 Web 服務》7篇系列文章，各篇的心得都寫在該篇文章下的評論上了。畢竟這不是我的Blog，不能像April 這樣寫隨筆。寫我blog 上有不方便交流，評論是個不錯的選擇。我的Blog 上有我 認為比較有用的文章的摘抄，歡迎大家f閱讀。

SOA整合中心、可復用的體系結構 、模塊化的 SOA 庫、庫用例，使這篇文章提到的幾個重要的概念。感覺SOA 整合中心應該是今后研究的重點，模塊化的SOA 庫應該是一個設計的一個標準。將這兩個概念列下

SOA 整合中心是 Web 服務與非 Web 服務的合并的 SOA 與后端企業系統的集成。它使得 Web 服務及非 Web 服務能夠與運行在不同平臺上的服務器、主機和微機上的企業系統交互。

然而，SOA 整合中心不同于面向服務的整合（service-oriented integration，SOI）。SOI 將 Web 服務與運行在不同平臺上的主機系統相整合。它使得 Web 服務能夠通過網關與主機交互。您需要 ASP.Net 或其它技術獲取網關來執行普通的 Web 服務。


模塊化的 SOA 庫

您可以開發模塊化的和優化的 SOA 庫，這些 SOA 被分成了不同類別的層次。每個類別可以通過層次最低級別的 Web 服務被進一步劃分成 SOA 的子組。

您可以將庫用作到 Web 服務應用程序的動態鏈接。當應用程序需要訪問模塊化的 SOA 時，它將自己鏈接到庫中。當它不再需要檢索到的 SOA 時，將從庫中釋放自己，當提高速度及性能時節省磁盤空間。

調用框架

要構建 SOAP 請求，需要使用 Web 服務描述語言 (Web Services Description Language，WSDL)，這是一種描述如何訪問 Web 服務以及將執行什么操作的語言。您可以指定服務的類型，而不用自定義 Web 服務的代碼，也不用重新編譯以前的應用程序。

為確保 WSDL 文件能在各種軟件架構中工作，您可以利用 IBM Web Services Invocation Framework (WSIF)，它讓您可以將 WSDL 作為不同軟件標準來描述。這表明您可以通過描述語言周圍的 API 以獨立于協議和位置的方式訪問 WSDL。還意味著您可以通過 WSDL 將 Web 服務結合復合成應用程序，在 WSDL 中您可以在各種條件和異常情況下切換協議和位置。

為構建 WSIF，無論您打算使用什么提供商，您都需要滿足最低需求，該選項包括如下：

JAXP XML 解析器
Java API 的 WSDL
Apache SOAP
Apache Axis。

WSDL.....

服務是什么，在一個典型的業務環境里，服務意味著業務函數、業務事務和系統服務
從應用程序的角度來看，業務函數實際上是原子的非系統函數。業務事務很像是調用應用程序的簡單函數，但是它們可能是作為自己的事務的上下文所包含的復合函數來實現的

人為的規定服務之間的區別，僅僅是為了引入粒度這個概念。 -----但本文沒有給出粒度的確切概念。但根據下文粒度可能是區別函數級別的概念。

接下來的體系結構的集成部分介紹了幾個應當考慮的問題。
包括1應用程序集成。2終端用戶界面集成。3 應用程序連接 4 流集成 5 信息集成

疑問：
本文還介紹了框架，但不明白

要點總結：

首先必須理解 Web 服務并不等同于 面向服務的體系結構。

SOA 只不過是一種體系結構。它不是任何諸如 Web 服務這樣的特定技術的集合

1。所有功能都定義為服務。這僅僅包括業務功能、由底層功能組成的業務事務和系統服務功能。這將會產生粒度問題，后面我們將對此進行討論。
2。所有的服務都是獨立的。它們就像“黑匣子”一樣運行：外部組件既不知道也不關心它們如何執行它們的功能，而僅僅關心它們是否返回期望的結果。
3。在其最一般的意義上來說，接口是可調用的；也就是說，在體系結構的層面上，它們究竟是本地的（在本系統內）還是遠程的（在直接系統外）、是用什么互連 Scheme 或協議來調用或需要什么樣的基礎架構組件來連接，都是無關緊要的。服務可能是在相同的應用程序中，也可能是在公司內部網內完全不同的系統上的不對稱多處理器的不同地址空間中，還有可能是在用于 B2B 配置的合作伙伴的系統上的應用程序中。

補充一個：
CORBA

=Common Object Request Broker Architecture，是一組用來定義“分布式對象系統”的標準，由OMG(Object Menagement Group)作為發起和標準制定單位。CORBA的目的是定義一套協議，符合這個協議的對象可以互相交互，不論它們是用什么樣的語言寫的，不論它們運行于什么樣的機器和操作系統。

今天馬上就要過去了，總結一些今天的成果。
人才管理系統遇到了一個很讓人不可思議的錯誤，改了一下午也沒弄明白什么原因。心里很是不爽，被這么一個錯誤擋住，浪費了那么多時間。
晚上，似乎浪費了更多時間。公司里的考試，本來就沒有必要了，更不用說講考卷了。不過公司付錢給我們，也就這么算了。哈哈
快要回去了，剩下的時間就是自己的了。該好好看看SOA 了，50篇文章呢。

通過SOA ，您可以擴大或縮小編制的范圍和性質，通過復用代碼來改變復合應用程序的業務流程邏輯。基于個人提出的功能，SOA 中的 Web 服務可被復用并結合到高級服務的復合應用程序中來創建新的業務服務，反之，該業務服務可被復用并結合到另一個 SOA 的業務服務的高級復合應用程序中。
在短時間內一些 Web 服務連同其它的 Web 服務（包括長期運行的基于一套復合業務規則的應用程序）一起完成了業務流程，在整合這樣的 Web 服務的過程中您可能會發現問題。Web 服務非常適合于短時間運行的應用程序，而不適合于處理繁重事務的環境，因為在這樣的環境下需要很長時間才能完成業務流程。
通過SOA，可以將一系列的Web 服務的業務邏輯結合成一個或更多的復合應應用程序，并使Web 服務能夠達到最佳性能，并且不會發生SOAP 超載問題。

以上是我今天看完這篇文章后對SOA 的認識，請大家指正。

這幾天忙壞了，四天內弄一個人才管理系統果然不是一件鬧著玩的事。但值得慶幸的是今天終于看到曙光了，昨天弄明白了那個問題后進度有了明顯加快。今晚能完成全部的編碼了，明天再處理一些細節就可交差了。
世界上只有一種不可能，那就是不可能有不可能。我們這四天差不多驗證了這句話。
哈哈哈哈。
明天就可以鉆心研究SOA了。非常感謝ApriL，它為我們準備這么資料，省得我們自己去找了。Great Job! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! !

我叫譚修光，也就是Tory 。
在此之前，從來沒聽過SOA，對于我們來說這是一個全新的概念。 但是我們不會因此感到畏懼，探索新的知識是我的最愛，也是我們團隊的特點。探索的道路并不是那么平坦，但我們堅信： 只要有付出，就會有回報。