聚會時間公告: 因應COSCUP 2011, Kalug 8月份休會一次

四月 28, 2010
» [雲端計算] NOSQL 背後的共通原則

同樣的這篇文章, 也是老魚從簡體中文譯者那“借來”的, 除了加工再潤詞成正體中文(當然也用紅筆自行畫了重點~呵), 在文中作者提到了 Google 檔案系統論文中最初的設計基礎, 建立在“硬體與網路的失效(Failure)是必定會發生的!”, 這才是一個真正的世界, 大多的 NOSQL 實作可分為二大觀點, 重視使用硬碟, 抑或盡可能的利用 RAM做為一級存儲, 作者也進行了比較說明, 本文中對於想進入 NOSQL 技術領域者, 可以視為一篇入門文選, 所以老魚在此分享本文給各位. Wikipedia - NOSQL, http://en.wikipedia.org/wiki/NoSQLNOSQL Database ORG, http://nosql-database.org/原文: http://natishalom.typepad.com/nati_shaloms_blog/2009/12/the-common-principles-behind-the-nosql-alternatives.html Posted by Nati Shalom at 12:01 PM Dec 15, 2009 譯文: 王旭(http://wangxu.me , @gnawux)2009年12月 16/19日 簡體轉正體中文及校潤詞句:郭朝益(http://wisdomfish.org, @master) 幾個星期之前,我寫了一篇文章描述了經常被稱作 NOSQL 這一類新型資料庫的背後需求動機。幾個星期之前,我在 Qcon 上發表了一個演講,其中,我介紹了一個 可伸縮性(scalable)的 Twitter 應用的構建模式,在我們的議論中,一個顯而易見的難題就是資料庫的 規模可伸縮性(scalability)。要解答這個問題,我試圖尋找隱藏在各種 NOSQL 背後的共通模式,並展示他們是如何解決資料庫規模可伸縮性問題的。在本文中,我將盡力勾勒出這些共通的原則。 實作者們的共通原則 假設失效是必然發生的 Assume that Failure is Inevitable 與我們在此之前認知通過昂貴硬體之類的手段,盡力去避免失效的手段不同,NOSQL 實作都建立在硬碟、機器和網路都會失效(Failure)這些假設之上。我們有需要承認,我們不能徹底阻止這些失效,相反,我們需要讓我們的系統能夠在假使非常極端的條件下也能應付這些失效。Amazon S3 就是這種設計的一個好例子。你可以在我最近的文章 Why Existing Databases (RAC) are So Breakable! 中找到進一步描述。在那裡,我介紹了一些來自 Jason McHugh 所講演的以"失效"為導向的架構設計內容(Jason 是在 Amazon 做 S3 相關工作的高階工程師)。 對資料進行分區 Partition the Data 通過對資料進行分區(分割),我們最小化了失效帶來的服務失效影響,也將讀寫操作的負載分佈到了不同的機器上。如果一個節點(Node)失效了,只有該節點上存儲的資料受到影響,而不是全部的資料。 對同一資料保持多個副本 Keep Multiple Replicas of the Same Data 大部分 NOSQL 實作都基於資料副本的熱備份(hot-backup)來保證連續的高可用性(high availability)。某些實作產品提供了 API,可以控制副本的複製,也就是說,當你存儲一個物件的時候,你可以在物件級別指定你希望保存的副本數量。在 GigaSpaces,我們還可以立即複製一個新的副本到其他節點,甚至在必要時啟動一台新機器。這讓我們不必在每個節點上保存太多的資料副本,從而降低總存儲量以節約成本。 你還可以控制副本複製是同步(synchronous)還是異步(非同步, asynchronous)的,或者兩者兼俱。這決定了你的叢集(Cluster)的一致性、可用性與性能[consistency, reliability and performance]三者。對於同步複製,可以犧牲性能保障一致性和可用性(進行寫入作業之後的任意讀取作業都可以保證得到相同版本的資料,即使是發生失效也會如此)。而最為常見的 GigaSpaces 的配置是同步副本到被分界點,異步存儲到後端存儲。 動態伸縮 Dynamic Scaling 要掌控不斷呈線性增長的資料量,大部分 NOSQL 實作提供了不停機或完全重建分區的擴展叢集的方法。一個已知的處理這個問題的演算法稱為一致性雜湊法(consistent hashing)。有很多種不同演算法可以實作一致性雜湊演算。 演算法會在節點加入或失效時 通知某一分區的鄰近節點。僅有這些節點受到這一變化的影響,而不是整個叢集。有一個協議用於掌控需要在原有叢集和新節點之間重新分佈的資料的變換區間。另一個(簡單很多)的演算法使用邏輯分區。在邏輯分區中,分區的數量是固定的,但分區在機器上的分佈式動態的。於是,例如有兩台機器和 1000 個邏輯分區,那麼每 500 個邏輯分區會放在一台機器上。當我們加入了第三台機器的時候,就成了每 333 個分區放在一台機器上了。因為邏輯分區是輕量級的(基於在記憶體中的雜湊表[hash table]),分散這些邏輯分區非常容易。 第二種方法的優勢在於它是可預測並且一致的,而使用一致性雜湊演算方法,分區之間的重新分佈可能並不平穩,當一個新節點加入網路時可能會消耗更長時間。一個使用 者在這時尋找正在轉移的資料會得到一個異常。邏輯分區方法的缺點是可伸縮性受限於邏輯分區的數量。 更進一步的關於這一問題的討論,建議閱讀 Ricky Ho 的文章 NOSQL Patterns 。 對查詢式的支持 Query Support 在這個方面,不同的實作有著本質上相當的區別。不同實作的一個共通性在於雜湊表中的 key/value 匹配。有些實作提供了更高階的查詢式支持,例如文檔導向(document-oriented)的方 法,其中資料以 blob 的方式存儲,關聯一個鍵值對屬性列表(List)。這種模型是一種無預定義結構的(schema-less)存儲,對一個文檔增加或刪除屬性是非常容易 地,無需考慮文檔結構的演變。而 GigaSpaces 支持很多 SQL 操作。假如 SQL 查詢沒有指出特定的鍵值(key),那麼這個查詢就會被平行地(parallel query) map 到所有的節點去,由客戶端完成結果的聚合(aggregated)。所有這些都是發生在系統後端的,使用者程式碼無需關注這些。 使用 Map/Reduce 處理聚合 Use Map/Reduce to Handle Aggregation Map/Reduce 是一個經常被用來進行複雜分析的模型,經常會和 Hadoop 聯繫在一起。 map/reduce 常常被看作是平行聚合查詢(parallel aggregated queries)的一種模式。大部分 NOSQL 實作並不提供 map/reduce 的內建支持,需要一個外部的框架來處理這些查詢。對於 GigaSpaces 來說,我們在 SQL 查詢中隱含了對 map/reduce 的支持,同時也顯式地提供了一個稱為 executors 的 API 來支持 map/reduce。在這模型中,你可以將程式碼發送到資料所在地地方,並在該節點上直接運行複雜的查詢。這方面的更多細節,建議閱讀 Ricky Ho 的文章 Query Processing for NOSQL DB 。 磁碟基礎 vs. 內部記憶體的實作 Disk-Based vs. In-Memory Implementation NOSQL 實作分為基於檔案的方法和在記憶體(RAM)中的方法。有些實作提供了混合模型,將RAM和磁碟結合使用。兩類方法的最主要區別在於每 GB 成本和讀寫(R/W)性能。最近,Stanford University 斯坦福的一項稱為「The Case for RAMCloud」的調查,對磁碟和 RAM 兩種方法給出了一些性能和成本方面的有趣比較。總體上說,成本也是性能的一個函數。對於較低性能的實作,磁碟方案的成本遠低於基於 RAM 的方法,而對於高性能需求的場合,RAM 方案則更加廉價。 記憶體型態雲端系統 (RAMClouds)最顯而易見的缺點就是單位容量的高成本和高電能耗損。對於這些指標,RAMClouds 會比純粹的磁碟系統差 50到 100倍,比使用快閃記憶體(flash memory)的系統差5-10倍(典型配置情況和指標參見參考文獻[1])。RAMClouds 同時還比基於磁碟和快閃記憶體的系統需要更多的機房面積。這樣,如果一個應用需要存儲大量的廉價資料,不需要高速存取,那麼,快閃記憶體將不是最佳選擇。 然而,對於要求高吞吐量需求的應用,RAMClouds 將更有競爭力。當使用每次操作的 成本和電能耗損作為衡量因素的時候,RAMClouds 的效率是傳統硬碟系統的 100 到 1000 倍,是快閃憶記體系統的 5-10 倍。因此,對於高吞吐量需求的系統來說,RAMClouds不僅提供了高性能,也提供了更高的效率。同時,如果使用 DRAM 動態記憶體晶片組提供的低功耗模式,也可以降低 RAMClouds 的電能功耗,特別是在系統閒置的時候。此外,RAMClouds 還有一些缺點,一些 RAMClouds 無法支持需要將資料在多個資料中心之間進行資料複製。對於這些環境,更新的時間延遲將主要取決於資料中心間資料傳輸的時間消耗

四月 24, 2010
» [雲端計算]HBase vs Cassandra: 我們遷移系統的原因

首先要跟各位聲明的, 這篇文章內容主要是老魚去申請轉載而來, 而我僅是用長年閱讀簡體中文詞彙的經驗加以正體中文和稍加校詞潤飾, 特別選這篇文, 有幾個目的: 老魚為一個新的SNS開發專案, 進行研究評估幾個雲端(分散式)儲存系統, 過程中也是棄了 HBase, MongoDB 選 Cassandra, 而當我這二天看到這篇文中的不少技術選型的出發點, 讓我閱讀後有不少處有所同感(在文章中標紅色的段落).籍由這篇文選, 希望同是身為電腦科學工程與甚至任職企業資訊採購決策管理者一份子的您, 能從這篇文中, 去思考當我們在企業中扮演一個對資訊科技採購時, 不應只是表面名牌價格與廠商行銷手法, 龐大複雜且難以駕馭系統規劃被廠商合理化之, 反造成企業長期的營運維護成本上升, 企業逐漸受外在資訊廠商所“挾持”, 從而失去企業自我資訊自主的競爭本能.這篇文中如果扣除作者在評論其二家產品, 各位看官也可以獲得不少目前電腦科學領域中當前最競爭的幾點新知, 尤其作者是以該領域的專家評論, 在出發點上就不會有太多被一般新聞過度炒作“雲端計算Cloud Computing”名詞上的疑慮.文中作者也對 CAP, CA, AP 等理論給予突破性的實證觀點.原文: http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/ 原作者:Dominic Williams 原文發佈日期:February 24, 2010 at 7:27 pm 譯者:王旭(http://wangxu.me/blog/ , @gnawux) 翻譯時間:2010年3月21-25日 簡體轉正體中文及校潤詞句:郭朝益(http://wisdomfish.org, @master) 我的團隊近來正在忙於一個全新的產品——即將發佈的網絡遊戲 www.FightMyMonster.com。 這讓我們得以奢侈地去構建一個全新的 NoSQL 資料存儲庫系統,也就是說,我們可以把恐怖的 MySQL sharding 和昂貴的可伸縮性拋在腦後了。最近有很多人一直在問,為什麼我們要把注意力再從 HBase 上轉移到 Cassandra 上去。我確認,確實有這樣的變化,實際上我們在基礎上已經把程式碼移植到了 Cassandra 上了,這裡我將作出解釋。 為了那些不熟悉 NOSQL 的讀者,在往後的其他文章中,我會介紹為什麼我們將會在未來幾年中看到如地震般的從 SQL 到 NoSQL 的遷移,這正和向雲計算的遷移一樣重要。往後的文章還會嘗試解釋為什麼我認為 NoSQL 可能會是貴公司的正確選擇。不過本文我只是解釋我們選擇 Cassandra 作為我們的 NoSQL 解決方案的選擇。 免責聲明——如果你正在尋找一個捷徑來決定你的系統選擇,你必須要明白,這可不是一個詳盡而嚴格的比較,它只是概述了另一個初創團 隊在有限時間和資 源的情況下的邏輯。Cassandra 的血統是否預言了它的未來 我最喜歡的一個電腦工程師們用來找 bug 的謁語是「廣度優先於深度」。 這也許可能對那些解決技術細節的人來說很惱人,因為它暗示著如果他們只是看看的話,解決方法就會簡單很多(忠告:只對那些能夠原諒你的同事說這個)。我之所以給出這個謁語的原因在於,我發現,軟體工程問題中,如果我們強迫自己在進入某行程式碼的細節層面之前,先去看看那些較高層次的考慮的話,可以節省大量時間。 所以,在談論技術之前,我在做 HBase 和 Cassandra 之間的選擇問題上先應用一下我的箴言。我們選擇切換的技術結論可能已經可以預測了:Hbase 和 Cassandra 有著迥異的血統和基因,而我認為這會影響到他們對我們的商業適用性。 嚴格來說,Hbase 和它的支持系統源於著名的 Google BigTable 和 Google 檔案系統設計(GFS 的論文期刊被發佈於 2003 年,BigTable 的論文發於 2006 年)。而 Cassandra 則是最近 Facebook 資料存儲庫系統的開放源始碼分支專案,它在實作了 BigTable 的資料模型的同時,使用了基於 Amazon 的 Dynamo 系統架構來存儲資料(實際上,Cassandra 的最初開發工作就是由兩位從 Amazon 跳槽到 Facebook 的 Dynamo 電腦工程師完成的)。 在我看來,這些不同的歷史也導致 Hbase 更加適合於資料倉儲、大型資料的處理和分析(如進行 Web 頁面的索引等等),而 Cassandra 則更適合於實時(Real-Time, RT)事務交易處理和提供交互型資料。要進行系統研究來證明這個觀點超出了本文的範疇,但我相信你在考慮資料庫的時候總能發現這個差異的存在。 注意:如果你正在尋找一個簡單的證明,你可以通過主要 Committer(對參與專案程式撰寫並提交貢獻者之稱) 的關注點來進行驗證:大部分 HBase 的 committer 都為 Bing 工作(M$[Microsoft] 在去年09收購了他們的搜尋公司,並允許他們在數月之後繼續提交開放專案的程式碼)。與之對應,Cassandra 的主要 committer 來自 Rackspace,用來可以自由授權獲取, 支持先進且通用的 NoSQL 的解決方案,用以與 Google, Yahoo, Amazon EC2 等所提供的鎖定在專有授權的 NoSQL 系統解決方案的相互抗衡。Malcolm Gladwell 會說只是根據這些背景的不同就可以簡單地選擇了 Cassandra。不過這是小馬過河的問題。但當然,閉著眼睛就進行一個商業選擇是相當困難的…… 哪個 NoSQL資料儲存庫風頭更勁? 另一個說服我們轉向 Cassandra 的原因是我們社群中的大風潮。如你所知,在電腦科學平台行業裡,始終有著大者恆大的慣性——那些被普遍前景看好的系統平台,會有更多人群聚在這個平台周圍,於是,從長遠來看,你可以得到更好的生態系統的支援(也就是說,大部分支援的軟體工程可以從該社群中獲取,並且也會有更多的開發者可以因此被僱傭)。 如果從 HBase 開始時,我的印象就是它後面有巨大的社群力量,但我現在相信,Cassandra 更加強大。最初的印象部分來源於 StumpleUpon 和 Streamy 的兩位 CTO 兩位非常有說服力的出色的演講者,他們是 Web 行業中兩個在 Cassandra 成為一個可選系統之前的 HBase 的兩個重要的貢獻者,同時也部分來源於閱讀一篇名為「HBase vs Cassandra: NoSQL 戰役!」的文章(大部分內容都己被廣泛證實了)。 勢力是很難被確證的,你不得不自己進行研究,不過我可以找到的一個重要的標誌是 IRC 上的開發者動向。如果你在 freenode.org 上比較 #hbase 和 #cassandra 的開發這頻道,你會發現 Cassandra 差不多在任何時候都有達兩倍的開發者在線上。 如果你用考慮 HBase 一般的時間來考察 Cassandra,你就能發現 Cassandra 的背後確實有非常明顯的加速勢力。你可能還會發現那些逐漸出現的鼎鼎大名,如 Twitter,他們也計劃廣泛使用 Cassandra(這裡)。 註:Cassandra 的網站看起來比 HBase 的好看多了,但認真的說,這可能不僅是市場的趨勢。繼續吧。 深入到技術部分: CAP 和 CA 與 AP 的神話 對於分散式系統,有個非常重要的理論(這裡我們在討論分散式資料庫,我相信你 注意到了)。這個理論被稱為 CAP 理論,由 Inktomi 的 聯合創始人兼首席科學家 Eric Brewer 博士提出。 這個理論說明,分散式(或共享資料)系統的設計中, 至多只能夠提供三個重要特性中的兩個——一致性(C)、可用性(A)和容忍網路分區(P)[Consistency, Availability and tolerance to network Partitions.]。簡單的說,一致性指如果一個人向資料庫寫了一個值,那麼其他使用者能夠立刻讀取這個值,可用性意味著如果一些節點(Node)失效了,叢集(Cluster)中的分散式系統仍然能繼續工作,而容忍分區意味著, 如果節點被分割成兩組無法互相通信的節點,系統仍然能夠繼續工作。 Brewer 教授是一個傑出的人物,許多開發者,包括 HBase 社區的很多人,都把此理論牢記在心,並用於他們的軟體系統設計當中。事實上,如果你搜尋網路上攸關於 HBase 和 Cassandra 比較的文章,你通常會發現,HBase 社群解釋他們選擇了 CP,而 Cassandra 選擇了 AP ——毫無疑問,大多數開發者需要某種程度的一致性 (C)。 不過,我需要請你注意,事實上這些生命基於一個不完全的推論。 CAP 理論僅僅適用於一個分散式演算法(我希望 Brewer 教授可以統一)。但沒有說明你不能設計一個超出理論的系統,並在其中各種操作的底層演算法選擇上進行特性切換。所以,在一個系統中,確實一個操作職能提供這些特性中的兩個,但被忽視的問題是在系統設計(SD)中,實際是可以允許調用者來選擇他們的某個操作時需要哪些特性的。不僅如此, 現實世界也非簡單的劃分為黑白兩色,所有這些特性都可以以某種程度來提供。這就是 Cassandra。 這點非常重要,我重申:Cassandra 的優點在於你可以根據具體情況來選擇一個最佳的折衷,來滿足特定操作的需求。Cassandra 證明,你可以超越通常的 CAP 理論的解讀

十二月 1, 2009
» [分享製表] Lift Web Framework 基礎架構圖

當您處於任何開發框架(Framework)之中時, 尤甚以 Web 形態的學習或者產品階段, 您都必須隨時提醒自己, 您的"創造力"正不自覺被“框“限並受侵蝕, 進而可能讓您僅成為特定"框"架的高階使用者甚至它的代言人, 這點要非常之小心, 不要忘了您愛上程序開發能力的初衷!~ 老魚 老魚最近有幾個小型專案, 將以 Scala / Lift 作為開發技術的選定, 一方面希望能更了解 Scala 的特點, 另一方面也將了解 Lift 對 Comet 的能力為重心, 先製作了一張初步的整體架構參考圖分享給更多想了解的朋友. Lift Web Framework Architecture 基礎架構圖 Lift 是一個非常優雅的 web 框架,基於 Scala 程序語言, 使用 Apache 2.0 license 許可發佈。Lift 提供開發者最好的方式建構交互的, 高性能的 web 應用。基於Lift 的應用能夠部署為 WAR 文件進入 JEE 容器, 類似 Jetty, Tomcat, 和 WebLogic。 基於 Lift 的應用擁有高性能和能夠使用你現存的 Java 程序庫。 Lift 的 Comet 和 Ajax 支持能夠讓開發者建構實時(Real Time)交互應用 Lift 的簡潔的代碼允許開發者能夠極大的提高開發生產力,類似 Rails 和 TurboGears Lift 提供高性能和擴展能力 Lift 內建支持 REST 和其他 web services Lift 使用 Scala 的類型安全 type-safety ,所以你的測試只需要集中於業務邏輯 老魚相關更多參考 WisdomFish - Scala, Lift Web Framework

五月 23, 2009
» SOA 標準規範與組織

服務導向架構(Service-Oriented Architecture, SOA) 的發展不同以往的IT企業架構的變遷, 多數IT人在未深入了解SOA的同時, 大多以舊經驗的推論, SOA不過是一時潮流的"新名詞", 但仍僅是舊瓶新裝的IT技術; 相反的從2004年至今, SOA持續的發展著, 甚至在許多的業界間產生了技術抽象的共識, SOA相關的規範標準與發展制定的組織也逐漸邁入完善, SOA的理論研究發展也逐漸由學術研究教育體係做為深根, 在國外甚至除了不少專業著作不斷發表, 專以SOA為主題的期刊雜誌也已有一段時日, 業界大廠們也朝向符合相關標準規範來實作自家產品, 對於身為開發者的我們, IDE(整合開發環境)對於SOA技術面的支持不斷強化且便利性也持續的增加.

我們合理的預期, SOA不同以往的IT技術發展, 不再只是一時的潮流, 不再僅是特定或是一群業界封閉性的合作結果; 相對的在眾多的規範與開放組織發展下, 企業架構及系統分析與設計模式將趨向SOA來調整發展, 本篇僅就SOA標準規範與組織做一簡要介紹:


網際網路聯盟聯盟(W3C)


網際網路聯盟(World Wide Web Consortium,簡稱W3C),又稱W3C理事會。
為 解決web應用中不同平台、技術和開發者帶來的不兼容問題,保障Web信息的順利和完整流通,全球資訊網聯盟制定了一系列標準並督促 Web 應用開發者和內容提供者遵循這些標準。標準的內容包括使用語言的規範,開發中使用的導則和解釋引擎的行為等等。W3C也制定了包括 XML 和 CSS 等的眾多影響深遠的標準規範。

W3C對SOA相關Web服務(Web Service)的發展規範如下:
W3C官方網站:W3C - The World Wide Web Consortium



結構化資訊標準促進組織(OASIS)


結構化資訊標準促進組織(Organization for the Advancement of Structured Information Standards,OASIS)
OASIS包括微軟(Mircrosft)、IBM、BEA system、Oracle、Sun、SAP AG、諾基亞 ... 等公司,是一個非營利的國際協會,是目前制定Web服務標準最多的一個組織。 OASIS為SOA專門成立眾多的技術委員會,分別負責制定SOA相關方面的標準。


OASIS 官方網站:


開放SOA合作組織(OSOA)


開放SOA合作組織(Open SOA Collaboration,OSOA)
OSOA 是一個非正式的廠商資訊業界聯盟,其成員包括 IBM、 BEA、SAP、 Oracle ...。目的是開發一個平臺獨立性且語言中立的程序模型,協助企業軟體開發人員能夠在最大限度內發揮SOA架構的特性和其優勢。OSOA 不是一個標準化組織,但制定的規範卻大多會成為實際實作上的標準。OSOA 內有二大專案組別,分別負責制定 SCA 和 SDO 規範。
  • Open SOA (OSOA)
OSOA官方網站: http://www.osoa.org/display/Main/Home



Web服務相互操作性組織 (WS-I)


Web服務相互操作性組織(Web Services Interoperability Organization,WS-I)
WS-I 是一個開放的廠商業界聯盟,目的在鼓勵任何對 Web服務有建立共同溝通標準的廠商加盟並貢獻自己的力量。主要致力於提升Web服務基於平台、作業系統和程式語言中立的相互操作性能力,其成員包括了 IBM, Microsoft, BEA Systems, SAP, Oracle, Fujitsu, Hewlett-Packard(HP), Intel 及 Sun 公司。



References



The OSOA Collaboration




本文來自
中山資訊管理所-SOA論文研究協作平台, 更多參考請見:
[分享製圖] SOA(服務導向架構)簡要歷史演進與特點
更多的老魚 SOA 筆記請轉見:
http://sites.google.com/site/javacodelibrary/process-management-in-service

» [分享製圖] Eclipse STP (服務導向架構工具平臺)

不自見故明。不自是故彰。不自伐故有功。不自矜故長。
- 道德經二十二章

道德經言:
處事不自是己見的人,才是真正明白道理的人。
處事不自為己是的人,才能發揚自己的光大起來。
所行的事成功了,而無妄心貪功才是真正有功。
處事雖然很有能力,但是不自誇能的人,才是真正能幹的人。
~ 老魚與閱者互勉.

最近老魚研究著如何在 SOA 的體制下, 完整的呈現 Java EE / SE 的實作,
(感謝陪同我研究的同好們與學生們的協助分享)
但 SOA 對特定的平臺技術並不列為重點,
但站在只會一種平臺技術(Java)的老魚來說, 我只想專注扮演好自已的角色!!!
以利與其它技術平臺例如 .Net / C++ / PHP 等專家們合作共軌未來的架構.

Eclipse STP, Service-Oriented Architecture Tools Platform
提供了 SOA 相關的有用工具集, 老魚把整理後的關聯圖分享給需要的您參考.

更多 SOA 有關的分享, 老魚隨著學習持續分享於下列的網址中:
http://sites.google.com/site/javacodelibrary/process-management-in-service

SOA - Eclipse SOA Tools Platform, STP (點圖放大後再存檔)



STP 的安裝, 直接於 Eclipse 3.4 的 Plug-in 清單中就可直接勾選安裝


STP 安裝後可用的工具集清單

五月 22, 2009
» [分享製圖] SOA(服務導向架構)簡要歷史演進與特點

柔勝剛,弱勝強。魚不可脫於淵。國之利器,不可以示人。
- 道德經 第三十六

柔弱者性情平和,行事寬恕,剛強者反之,故柔能勝剛,弱能勝強也。
魚必須深藏水底下,魚離水則死,所以不可脫於淵。
國家有價值之厲害武器 的實力,不可以顯露給人知道,顯露則被敵人知其底細,
必敢來侵犯,不可隨便誇張貢高。

SOA, 服務導向架構(Service Oriented Architecture),
是老魚近來準備開工的實體讀書會之一並伴隨著參與者們的研究論文主題發展,
這嚴格來說已不是新的IT發展, 正反二極的看法, 這幾年來有正有負,
但站在研究者的立場, 任何一個新IT的提出, 必有可取之點~

下圖是張很草率但易懂的圖, 但也可能存在點小偏見, 歡迎大家一同討論.

SOA.History.Featurs (點圖放大後再下載)


更多的老魚 SOA 筆記請轉見:
http://sites.google.com/site/javacodelibrary/process-management-in-service

九月 5, 2008
» (教學簡報) JavaEE - Web Services - JAX-WS 2.1

Web Services - JAX-WS 2.1 - Java SE/EE 6

老魚邊研習邊編寫的教學簡報, 分享給同好們~
老魚努力找尋咱們"慢活"的高雄市捷運線上的好地方,
來組個每週定期晚間的 Linux/Java 讀書會.
(歡迎您跟老魚一同學習與成長!)

有任何的好建議及參與者或善心人士,
歡迎跟老魚聯絡 ... 感恩~

JavaEE.Web.Services.1001.JAX-WS
全螢幕觀看:
http://docs.google.com/Present?docid=ddgj2m37_1022fcs2ccd2&skipauth=true


相關的教學範例 Code, 都置在 Blog 右上的 小沙瀰養成用範例庫(SVN)
http://trac.assembla.com/kuoteam/browser/trunk/WebServices

三月 31, 2008
» (分享製作) Java EE 5 標準服務圖 (Mind Map)

在最近的上課教學中, 把心智圖(Mind Map)的概念與 FreeMind 當成工具教授給了小沙瀰們.
目的是希望他們能善用這方式的智能學習技術來強化與加速學習能力,
也在這分享給大家 ...

老僧會陸續把自行製作的有關教學內容的 Mind Map 放上來供大家一同成長,
也方便老僧自己上課教學時, 當上課的教學講義用~呵
往後若該主題更新的圖表, 會直接更新於歷史文章內, 不再新增文章, 減少網路垃圾@@"

(點圖放大~再收藏哦)
Java EE 5 Standard Services (Java EE 5 標準服務圖)

三月 21, 2008
» (分享簡報) SOA 概述 - 為了你要出書, 我跟你拼了

老僧最近總是被目前正在撰寫研究 SOA 論文的老朋友,
不管在平常喝咖啡, 即時通裡, 不斷的要潛移默化我的大腦, 加諸 SOA ...
(你不要以為你有得到 IBM SOA 競賽得獎, 就可以強迫我呀! @@")

前天又幫我上了一課, 果然有專家教還是比看書來的有效,
更希望我在新的開發專案裡, 例如 ERP, CRM 進行時, 適當的融入概念性的架構與實作,
還要老僧協助他書裡有關 Java EE 平台上的相關 SOA 技術實作與研究,
因為老僧的老朋友本身和當前的工作環境是在 .NET 的世界裡 ...
就這樣老僧要為這老朋友協助完成出書的願望, 友情歷久一樣濃~呵
開始寫研究報告與實作給我的研究範圍"Java EE & SOA" ...
(加油吧~)

SOA.S101.SOA概述

support:

biggo.com.tw

A Django site.