cloud computing 懶人包 收集

IDC（國際數據資訊公司）的Frank Gens說2010年會是IT產業的轉變年（transformational year for IT），部份轉變來自雲端運算技術。雖然雲端運算是熱門話題，許多IT朋友對主機部份從供應商的選擇到對安全與順應性的控制，仍感迷失與不確定。我們整理出一份很讚的資源列表來助你在這些議題中導航。如果你發現其它值得分享的內容，請讓我們知道。

有數家企業機構和集團在協助瞭解雲端技術，提供了最佳的實行方式並促成標準化：

• 
   Cloud Security Alliance雲端安全聯盟是一個非營利性機構，宣導提供安全防護和一般教育的最佳雲端運算使用實行方式。他們設有Google Group和LinkedIn Group 可供提問或參考其他IT人員所面對的問題。可在Twitter推特@CloudSA.上進行跟隨。
• 
   Jericho ForumJericho討論區致力於全球公開網路環境安全事業的提升。
• 
    Cloud Computing Interoperability Forum雲端運算互通性討論區是一個非營利協會組織，在推動接納雲端服務。可加入他們的Google Group來瞭解更多相關資訊。
• 
    Open Cloud Computing Interface Working Group雲端運算公開介面工作小組正在進行雲端運算基礎架構中遠端管理的應用程式介面（Application Program Interface，簡稱API）。
• 
    Distributed Management Task Force:  Open Cloud Standards Incubator 分散管理工作小組：公開雲端標準化培育，處理雲端系統管理的互通性。
• 
     歐洲網路與資訊安全局（European Network and Information Security Agency，簡稱ENISA）整理出一份雲端運算風險評估（Cloud Computing Risk Assessment）報告，審視雲端運算的安全優勢與風險。
數個線上討論區：  Google谷歌的Cloud Computing雲端運算和LinkedIn的Cloud Computing雲端運算。 CloudCamp（Google谷歌）和CloudCamp（LinkedIn）。 A6 (Automated Audit, Assertion, Assessment, and Assurance API) Working GroupA6（自動化審計，維護，評估，確認及應用程式介面）旨在提供一個共同的介面，讓供應者對他們環境中的審計，維護，評估和確認進行自動化。 LinkedIn的VM People Virtualization & Cloud Group虛擬機器技術人的虛擬化和雲端團隊針對虛擬化和雲端運算專業人員網絡互通和討論產業相關話題。 業界則相當幸運有許多專家利用部落格，推特Tweet和podcast在討論雲端技術：   Craig Balding：Cloud Computing Security雲端運算安全，@craigbalding，及和Christofer Hoff共同執筆的Cloud Security Podcast雲端安全podcast。 Christopher Hoff：Rational Survivability理性生存力，@Beaker，及和Craig Balding共同執筆的Cloud Security Podcast雲端安全podcast。 David Linthicum：Cloud Computing (InfoWorld)雲端運算（InfoWorld資訊世界）， Cloud Computing Podcast雲端安全podcast，@DavidLinthicum。 James Urquhart：The Wisdom of Clouds雲端的智慧，@jamesurquhart，及在podcast上與Geva Perry共同執筆的Overcast 。 Geva Perry：Thinking Out Cloud思考雲端，@gevaperry，及在podcast上與James Urquhart共同執筆的Overcast。 Randy Bias：Cloudscaling登入雲端，@randybias。 Kevin Jackson：Cloud Musings雲端沉思，@Kevin_Jackson。 Sam Charrington：Cloud Pulse雲端脈動，@samcharrington。 Reuven Cohen：ElasticVapor靈活的雲霧，@ruv。 James Watters：SiliconANGLE矽角度，@wattersjames。 Jay Fry：Data Center Dialog數據中心對話，@jayfry3。 Jeff Barr：Amazon Web Services Blog亞馬遜網路服務部落格，@jeffbarr。 Chris Wolf：Chris Wolf’s Virtualization Tips and RamblingsChris Wolf虛擬化竅門與漫遊，@cswolf。 Chenxi Wang：Chenxi Wang’s BlogChenxi Wang部落格。 John Willis：IT Management and Cloud BlogIT管理與雲端部落格。 Chirag Mehta：Cloud Computing雲端運算。 George Reese：@GeorgeReese Stuart Miniman：@stu Lori MacVittie：@lmacvittie Simon Wardley：@swardley CloudAve雲端大道，@krishnan。 Plug Into the Cloud伸入雲端（Information Week資訊週報）。 Inside Enterprise IT 企業IT內幕（Dell戴爾）。 @原始來源：Got Cloud Confusion? Check out these resources…  @雲端運算相關文章： * 雲端運算安全趨勢＊Google 攻擊並非雲端攻擊 ＊雲端運算安全趨勢＊參加Gartner Data Center Conference 的6 個心得 * 雲端運算安全趨勢*網路犯罪份子走入雲端？ 雲端運算將帶來新的資訊安全挑戰 *雲端運算安全趨勢* PaaS 和它的陰暗面 [何謂雲端運算？」雲端的定義(Defining the Cloud) SaaS、PaaS、IaaS等雲端運算模式，是把雞蛋放在同一個籃子裏嗎？(附文茜財經周報專訪張明正談趨勢科技投入雲端運算影片) [ 年度回顧與展望」2010年＝雲端殭屍年？ *雲端趨勢*Google Chrome 作業系統能否解決我們的安全問題？ *雲端趨勢* 當資料在雲裏被攻破，誰來收拾殘局？ *雲端趨勢* 雲端運算標準，夢想vs. 現實 * 雲端趨勢* 你相信他們說的“相信我們”嗎？談私人資料在公共雲端的安全 * 雲端趨勢* DDoS 和雲端運算：沮喪，但卻是真的 『雲端運算研討會』:趨勢科技張明正談雲端運算(影音）-1

紅帽提交雲端API作為業界開放標準

Linux大廠紅帽（Red Hat）周三（8/25）揭露了該公司的雲端計畫，並宣布已提交該公司的Deltacloud雲端API規格予分散式管理工作小組（Distributed Management Task Force，DMTF），以期成為開放的雲端業界標準。

Deltacloud是紅帽在2009年所建立的開放源碼專案，由該公司的架構即服務（Infrastructure as a Service，IaaS）雲端管理API所構成，並在今年初轉至Apache軟體基金會旗下的Apache Incubator，並開放外界存取。至於創立於1992年的DMTF則是專門號召IT產業共同開發、驗證、推廣及採用各種系統管理標準的組織。

紅帽雲端事業部總經理Scott Crenshaw表示，雲端運算逐漸在現代的企業中擴大，互動及可攜性日益重要，很高興可提交Deltacloud API予DMTF以協助所有雲端間的互動。DMTF總裁Winston Bumpus，隨著該組織持續建立雲端運算的開放管理標準，紅帽的貢獻將可推動雲端的一致性。

紅帽於今年開始推廣其雲端解決方案，在今年6月的紅帽高峰會中發表了該公司的雲端基礎（Cloud Foundations）產品線，主要的兩大部份為可支援私有雲端及公共雲端的架構即服務（IaaS）與平台即服務（PaaS），並著眼於互動及可攜性。

除了提交IaaS管理API給DMTF之外，紅帽周三也揭露了其PaaS雲端策略，PaaS建基於JBoss Enterprise Middleware上，其解決方案可允許企業、雲端服務供應商及軟體即服務（SaaS）供應商可利用既有的資產及開發新的應用程式，並將它們部署在公共及私有雲端上。

Gartner副總裁Yefim Natis認為，像是中介軟體的應用程式架構在企業運算及雲端運算中皆屬於重要的技術層，要達到雲端運算在生產力、規模或成本上的效益，必須透過支援應用程式架構的雲端來部署應用程式，主流業者在計畫未來的應用程式架構投資時，應考量及評估包含雲端在內的各種部署選項。

 以下為外國學者提出PaaS 未來發展API是一個非常重要的問題


By Krishnan Subramanian on June 10, 2010

PaaS Is The Future Of Cloud Services: APIs Are The Key

By Krishnan Subramanian on June 10, 2010

This is my fifth post in the series titled “PaaS Is The Future Of Cloud Services” and I am going to briefly discuss one of the key elements of this PaaS-y future, the APIs. Even though having an API doesn’t make something a platform, APIs are key to the very success of the Platform Services. The successful Platform Services players of the future will be the ones who got their API strategy right. This is the reason I called APIs the oxygen for the PaaS-y future in a recent post about Apigee-Heroku announcement. In this post, I will briefly discuss the role played by APIs in the Platform Services and highlight some of the issues to be considered while developing APIs for platform. Please note that this is by no means exhaustive and feel free to add your thoughts in the comments section below. The Role played by APIs
In any platform, APIs

• greatly simplify the life of developers by making it easy to access the functionality of the platform. Instead of developing everything from the scratch, they could tap the APIs and access the functionality easily
• speeds up the platform access
• makes the platform highly extensible leading to a rich feature set
• helps co-opt with other service providers
• helps in integration and interoperability
• helps in better management of platform security
• offers an easy option to handle analytics
• even helps in ensuring compliance

etc.. If a platform provider ignore the importance of APIs, they will go down very fast. Even the tech giant Google learnt it in a hard way. They launched Google Buzz and Google Latitude with much fanfare but they didn’t release the API for these services. This resulted in lack of interest among the developers and, hence, failed to gain traction among the users. Clearly, even if you are the hottest web company in the world, if you don’t release the APIs for your platform, you will fail. It is going to become even more pronounced as we march towards the PaaS-y future. For example, more than 50% of the workload carried by salesforce.com systems arrives through their API, rather than coming in through the UI of one of the applications hosted on their platform. This was the case before they released Chatter and it is only going to increase in the future. As we enter a future dominated by platform services, concerns about vendor lock-in are only going to get louder and louder. In order to remove the concerns about possible vendor lock-in, platform services providers will be expected to be interoperable with competing platforms and support data portability. APIs are going to be critical in ensuring interoperability and data portability. In other words, APIs are going to be the oxygen for the much anticipated PaaS-y future.
APIs: Some Considerations
Business Considerations:
Opening up the platform through API is key to the success but it is also important to realize that giving access through API costs money for the platform providers. The platform providers should consider the costs related to API access and plan their business model accordingly. For example, Twitter allowed all sorts of services in their ecosystem to use the Twitter API. Suddenly, one day they realized that they have to make money and banned all services that pushes ads to the timeline using the Twitter API. Even though this move by Twitter is perfectly legitimate, it sent some businesses whose business model were based on injecting ads to the twitter timeline to bust. In the mostly consumer centric Twitter ecosystem, the impact was minimal. Imagine the impact of such drastic moves on a business centric platform ecosystem. It is cruciasl for the Platform Service providers to take the business side of the API access seriously and plan accordingly.
Technological Considerations:
One of the essential characteristics of cloud based services is the ability to scale out based on the demand. Not only the system should be horizontally scalable, the APIs should also be designed for such scalability. Similarly, there are many other technological issues that needs to be considered while designing the API. Therefore, a good API design is crucial to the very existence of the platform service provider. Not only it helps the developers, it also plays an important role on the business success of the provider. Another consideration is to keep the APIs simple. Many platforms start with a simple API but the complexity increases as they grow in their feature set and usage. A complex API makes the life difficult for the developers and it could potentially drive the developers away. There are services like Apigee and Gnip which takes the complexity out of the APIs but it is crucial for the platform providers to not burden their developers.
Legal Considerations:
Apart from the business and technological issues, it is important to take care of the legal considerations too. When you open up access to your platform through API, you are opening yourself up to legal troubles. There are issues like abuse of your resources through API including possible security nightmares. You will need a strong legal handle to take care of such issues. There are issues like misuse of the API and data stored in the platform by third party providers and the associated legal ramifications. Then, there is the contract between the service providers and developers and potential legal wars associated with it. Suppose the platform service provider abruptly changes the terms like what Twitter did recently and if it completely disrupts the business of a third party developer/service provider, their affected clients may create legal troubles for the platform service provider too. These are some of the legal problems that could spring up while opening up the API for a platform. Like in any business, platform providers should ensure due diligence on the legal side of the API.
Conclusion
In this post, I have tried to scratch the surface on the importance of APIs in a world dominated by Platform Services. In fact, there are way too many issues to be considered and I can do a complete research report on the topic. I have just touched upon handful of issues that came to my mind while writing this post. APIs are the backbone of Platform Services and it is important for us to understand the business, technolog
ical and legal issues surrounding it. I hope this post will serve as a starting point for a deep dive on this topic by other members of the Clouderati. I strongly encourage the readers of this blog to jump in and offer their thoughts on this important topic.
優點

• 大大簡化了開發商的生活，從而易於訪問功能的平台。 除了開發一切，從白手起家，他們可以挖掘API和功能輕鬆訪問
• 加快平台訪問
• 高度可擴展的平台使導致了豐富的功能集
• 幫助協調與其他服務供應商選擇
• 有助於集成和互操作性
• 有助於更好地管理平台的安全性
• 提供了一個簡單的選項來處理分析
• 甚至有助於確保遵守

eGroupWare 減少傳統資訊流 即時協同式合作

群組軟體簡單的說就是為了讓一群人共同作業而設計的軟體，目前商業軟體中比較有名的是 IBM Lotus Notes、Microsoft Exchange、Oracle Collaboration 與NOVELL Groupwise（台灣地區）；但是許多人常誤以為它只是電子郵件系統的延伸，因為大部份購買類似軟體的公司，往往只規劃了軟體購置的預算，而忽略了教育訓練的問題，造成許多人只懂得使用它的基本功能。


軟體的功能日益強大，對於一個愛嘗鮮的資訊人員而言，不難去適應大量的軟體操作程序；不過大部份人對於這樣子的變化相當難以調適，因而無法讓軟體功能發揮應有的效益。面對這樣的現況，開放原始碼的解決方案就提供了更多彈性，許多這個類型的產品可以免費取得與使用，讓導入的公司可以有更多資源放在人員訓練之上。
eGroupWare [1]就是一個開放原始碼的群組軟體，雖然國內還沒有公司能夠提供完整支援，但是中文介面已經大致翻譯完成，加上能夠免費取得，讓有心採用的機構能夠先行測試是否符合需求。
最新版本的 eGroupWare 有數十個成熟的模組能夠使用，支援許多新技術，像是LDAP、AD、XML-RPC、SYNCML、AJAX等介面，也能夠進行像是知識管理、企業入口網站與工作流程等應用，甚至有香港的朋友為它加入了財會系統CK-ERP[2]，讓它能夠滿足越來越多元的需求。
要完整使用它的功能，所需要了解的技術層面相當廣泛，但是許多基本的應用只需要一個下午就能夠完成環境建置，可以根據實際的需求與技術能力彈性調整。

eGroupWare主要模組介紹
[felamimail 電子郵件]

一個只支援 IMAP 協定（大部分是 POP3）的郵件閱讀程式，它支援 Sieve 郵件過濾規則語言（RFC 3028），也能夠在 eGroupWare 建立新帳號時，同步在Cyrus IMAP或是Postfix等郵件伺服器上建立對應的郵件帳號；只是目前對於歐美語系以外郵件的支援還不算完整。

[calendar 行事曆]

eGroupWare的行事曆提供許多彈性，能夠在安排行程時檢視同樣群組的使用者行程，也能夠由系統協助查詢時間的空檔，避免在安排行程時產生衝突。除了一般常見到的重複行程、行程提醒與相關欄位外，它還能夠與eGroupWare的其他模組產生連結，並且安排行程的與會人員、需要的資源（例如會議室、投影機等），考慮的相當週到。

行事曆、通訊錄與記事本等模組能夠透過 SyncML 協定與電腦、手機和PDA等設備進行資料同步，行程的資料也可以透過 iCAL 或是 CSV 格式匯入，以及匯出 iCAL 格式資料。
[timesheet 時間表]

時間表也可以稱之為工時記錄表，主要是配合專案管理模組使用，用來讓使用者根據專案中的工作內容提報工時，方便會計部門進行專案成本的估算。
[manual 線上說明]
線上說明是基於 wiki 模組延伸出來的功能，主要是希望在官方網站匯集來自世界各地使用者提供的操作說明，透過這個模組就可以下載官方網站最新版本的資料，只是目前資料是以英語、德語為主。
[resources 資源管理]
許多公司內部經常發生搶資源的情形，像是約了一個客戶來公司卻發現所有的會議室都在使用中，或是等半天就是借不到那個神奇的投影機。資源管理模組就是為了避免類似情況而設計，可以讓使用者預約包括會議室、投影機、公務車或是各種公用資源，避免因為行程上的衝突造成損失。…當然，前提是沒有人有”插隊”的特權。
[projectmanager,projects 專案管理]
projectmanager是新版的專案管理模組，前一個版本為 projects ，前者與其他模組有較佳的整合，而後者則是兼顧了許多細節；雖然兩個模組各有擁護者，但是都來自同一個開發者，而這個開發者未來應該只會維護新版的專案管理模組。
[mydms,filemanager 檔案管理]
舊版的檔案管理模組 filemanager 只是單純提供檔案上傳與下載的管理功能，而 mydms 提供了許多進階功能，像是版本控制、關聯檔案、異動通知與權限控管等；filemanager也能夠控制權限，不過僅限於模組本身的增、刪、改、查， mydms 進一步做到控制類別與個別檔案的權限，適合對於資料安全訴求較高的組織。
[mydms,filemanager 檔案管理]


舊版的檔案管理模組 filemanager 只是單純提供檔案上傳與下載的管理功能，而 mydms 提供了許多進階功能，像是版本控制、關聯檔案、異動通知與權限控管等；filemanager也能夠控制權限，不過僅限於模組本身的增、刪、改、查， mydms 進一步做到控制類別與個別檔案的權限，適合對於資料安全訴求較高的組織。
[fudforum 討論區]


FUDforum[5]本身就是國外的一個熱門討論區系統，除了大部分討論區系統可以看到的功能外，甚至能夠透過與新聞群組、通訊論壇等系統整合，讓部份從BBS起家的網站能夠移轉或是保留現有系統運作。eGroupWare所內建的 FUDforum 版本已經沒有再更新，不過功能已經能夠滿足大部分需求。

[tts 問題傳票系統]

傳票給人的感覺很像會計在使用的，其實這個模組有點類似內部聯繫單，像是電腦壞了需要人處理、客戶留言需要轉給業務、或是初一十五拜拜要請人去採買牲禮等都可以透過這個模組”交辦”或是”求救”；因為這樣的需求可能像是A部門接到B部門的客戶電話，然後將資料轉給B部門的主管，再由B部門的主管轉給適當的業務處理，資訊需要傳來傳去，所以稱之為傳票。
[messenger 線上傳訊]
這個模組提供個人與個人之間的留言功能，不受限於時間與地理位置限制，像是A部門的某甲男心儀B部門的某乙女，就可以透過這個功能留言給某乙女，請她去吃個飯；公司是否允許這樣的行為不清楚、某乙女會不會把某甲男的簡訊傳給其他人看也不知道，線上傳訊就是這麼樣的一個工具。
[workflow 工作流程]
工作流程是eGroupWare中較複雜的模組之一，主要用來進行商業流程的自動化，像是文件、資訊或任務在一個流程中的參與者中如何傳遞、處理與通知，可以定義相當多的自動處理規則；這個模組的前身是 tikiwiki 的 GalaxiaWorkflow[6]，一個以活動為基礎的工作流程系統，需要花些時間理解其中的概念才能夠應用。
[wiki 協同編輯]

資訊圈子中的朋友對於 wiki 這個新名詞應該不陌生，也有人將它翻譯作”快記”，大部分的人都將它拿來當作知識管理的工具之一；eGroupWare內建的 wiki 模組與需要記憶大量特殊語法的wiki系統不同，使用了所見即所得編輯器處理大部分的內容，只要在內容中包含了wiki words（一種大小寫混用且首字大寫的英文字，像是 GroupWare ）或是類似 ((twpug)) 這樣的標籤就可以與新文件或是其他相關內容產生連結。
[jinn 網站管理]
JiNN 代表了 JiNN is Not Nuke 的遞迴縮寫，作者藉此傳達對於 Nuke 系統的熱門相當不以為意；這個模組有點像是進階的資料庫管理工具，能夠同時讓多個人參與多個網站資料庫的管理工作，只是操作方式需要花些時間理解。
舉例來說，在JiNN中定義了一個網站後，JiNN會去擷取指定網站的資料庫資訊，接著可以根據資料庫中的資料表定義物件；物件中除了資料表的欄位名稱與屬性外，還能夠進一步定義資料欄位間的關聯以及資料欄位輸入的方式、限制等。相關操作完成後就可以透過JiNN對該網站進行資料的增、刪、改、查，甚至是製作報表等進階功能，等於是只要將一個網站的前端處理完成就能夠用它來進行管理，功能還不會比自己設計的管理介面遜色。
[phpbrain 知識管理]

最簡單的知識管理方式就是蒐集常見問答，接著將許多相關的文章串連在一起，必要時在以這些問答內容為基礎撰寫完整的教學，甚至延伸出其它格式的教學內容；eGroupWare中的知識管理就是基於這樣的概念設計，除了發問、回答、自問自答外，還能夠連結內部文章或是外部網站，並且附加檔案、評論等，所有的操作也會有詳實的紀錄保留。
[chatty 聊天室]

Chatty是一個即時的聊天室，也是修改自一個獨立的程式[7]，不過是原作者帶著它加入eGroupWare中；透過它可以檢視目前有哪些人上線，並且與上線的人即時傳遞訊息。比較特別的地方是這個模組是以 AJAX 技術設計，因此並不會像部份網路聊天室一樣頻繁的更新畫面（這樣子對眼睛很不好…），對於伺服器也不會造成太大的負擔。

eGroupWare是Web-based的應用程式，所以你必須有把它安裝到Web Server上，目前支援的有Apache、IIS和Roxen。資料庫則可以使用Mysql、PostgreSQL、MSSQL。PHP的版本需要在4.1以上。
目前egroupware包括了下面功能：

* 通訊錄 [ addressbook ]

* 系統管理 [ admin ]

* 備份 [ backup ]

* 書籤 [ bookmarks ]

* 行事曆 [ calendar ]

* 漫畫 [ comic ]

* 翻譯工具 [ developer_tools ]

* 電子郵件 [ email ]

* 樣板管理系統 [ etemplate ]

* 郵件管理 [ felamimail ]

* 檔案管理 [ filemanager ]

* 簡易討論區 [ forum ]

* FTP網頁介面用戶端 [ ftp ]

* 多功能討論區 [ fudforum ]

* 他站新聞 [ headlines ]

* 記事本 [ infolog ]

* 內容管理系統 [ jinn ]

* 私人訊息 [ messenger ]

* 提醒視窗 [ notifywindow ]

* 新聞發布與管理 [ news_admin ]

* 知識庫 [ phpbrain ]

* LDAP線上管理系統 [ phpldapadmin ]

* 系統資訊 [ phpsysinfo ]

* 投票 [ polls ]

* 偏好設定 [ preferences ]

* 專案管理 [ projects ]

* 線上註冊 [ registration ]

* 安裝設定 [ setup ]

* 網站管理員 [ sitemgr ]

* 網站介面 [ sitemgr-link ]

* 股票 [ stocks ]

* 傳票管理 [ tts ]

* 多人線上文件編輯系統 [ wiki ]

要想了解這個系統可能要花不少時間，但是了解後許多工作的進行會更方便
目前有那一些的知名的商業群組軟體呢？
1.Dsk Nts

2.Nvell Nterprise

3.Oracle Collaboration Suite

4.Microsoft Exchange Server

5.IBM Loutus Note

這些群組軟體由於開發時間較久，也能提供客製化功能，但是要建置一套商業群組軟體的系統，所費不貲。

egroupware的好處是，都是由php所寫成的，以web介面執行，有跨平台的介面

而在sever端，可以

apacha+php+mysql

IIS+PHP+mssql

在經過上千個鐘頭的開發工作後，eGroupWare研發團隊正式推出了 1.0 版，除了感謝許多人外，也提出下個版本的目標：

1. 工作流程(workflow)引擎

2. 聯絡中心(取代目前的通訊錄)

3. 新的檔案管理員模組

4. 支援MaxDB

5. 許多行事曆的延伸功能

6. 一個能夠與微軟Outlook同步的軟體已經正在開發中

=======================================相關資訊=======

下載中文安裝說明PDF檔



中文研發團隊

http://free.tnc.edu.tw/modules/news/...p?storyid=1304

艾桃科技Advanced Technology Ongoing - 線上教學

http://download.ossacc.org/Ani/xoop/h/tutor.htm

企業EIP速建指南(書)

http://www.netz.com.tw/product.asp?good_id=132


台灣站長俱樂部(運用想法)

http://webmaster.club.tw/index.php?s...1c144465455758

Open Virtualization Format

今天，虛擬化技術得到廣泛應用，而不同的虛擬化平台（VMware、Xen、KVM等等）也是百花齊放百家爭鳴。這樣就產生了一個問題，不同的虛擬化平台支持不同的虛擬化格式，他們之間往往是不兼容的，我們迫切需要一種將虛擬機在不同的虛擬化平台之間封裝和分發的標準方法。因此VMware和虛擬化領域的其它先驅創建了Open Virtualization Format，一種平台獨立的、高效、可擴展的虛擬機封裝和分發格式。

通過OVF，可以高效、靈活、安全地分發企業軟件，可以實現虛擬機在不同的虛擬化平台之間轉移，從而為客戶提供相對的平台獨立性和供應商獨立性，客戶完全可以將一個OVF格式的虛擬機部署到另一個虛擬化平台上。

OVF將大大增強虛擬化使用體驗，通過OVF提供的便攜性，平台獨立性，核實，簽字，版本控制和授權功能，您可以：

精簡安裝方式，提高用戶體驗；

提供虛擬化平台獨立性和靈活性；

更容易地創建複雜的多層服務；

通過便攜式虛擬機高效地分發企業軟件；

提供特定平台的增強能力，通過可擴展性，更容易採用虛擬化的先進技術；

OVF 的Key Features：

對發佈的優化：OVF能夠提供虛擬應用（virtual appliances）的可移植性發佈。OVF支持格式壓縮以提高傳輸效率，同時提供工業標準的內容檢查和完整性檢查，並提供基本的軟件許可證管理。
提供簡單的自動化的用戶體驗：OVF提供了一個強大的、用戶友好的安裝方式以簡化整個安裝過程。在安裝過程中，OVF文件中的元數據可以通過用戶管理工具進行校驗以確定將要安裝的虛擬機數據的有效性。同時還能驗證和本地虛擬化環境是否兼容。
支持多虛擬機配置：一個虛擬應用方案中可能包括多個虛擬應用，通過OVF可以配置由多個相互關聯的虛擬應用構成的複雜多層服務。
虛擬機的可移植性：OVF是虛擬化平台獨立的。但同時又支持具體平台的可擴展性。它支持現有的所有虛擬機硬盤文件格式和將來的硬盤格式
供應商和平台獨立性：OVF不依賴某個特定的主機平台、虛擬化平台、或客戶操作系統。
支持本地化；OVF支持多語言環境，支持多語言交互式的虛擬應用安裝過程。
可擴展性：OVF是可擴展的，它被設計成可隨虛擬應用發展的。
From
OpenSource China

參考文獻：
http://www.dmtf.org/initiatives/vman_initiative/

服務導向架構(Service-Oriented Architecture，SOA)

服務導向架構(Service-Oriented Architecture，SOA) 簡介

作者： 曾保彰 / 臺灣大學計算機及資訊網路中心資訊網路組

「以客為尊」的核心概念，提供網路服務單位建構一個具彈性、可重複使用的整合性介面，加速達到網路服務提升的目標。


前言
SOA是一種架構模型，由網站服務技術等標準化元件組成，目的是為企業、學校或提供網路服務單位建構一個具彈性、可重複使用的整合性介面，促進內外部如內部應用程式、用戶、與部門(系所)等相關單位完美的溝通，盡速達到網路服務提升的目標。

何謂SOA?

我們常聴到 Information Technology (IT)產業的架構演進，由1980年代的主機(mainframe)架構，到1990年代的主從式(client server)架構，到1999年時是network centric架構，而到2004年時已複雜到所謂的 Service-Oriented Architecture架構(SOA，服務導向架構) 。此外也常聴到：如果企業不導入這個架構，企業在未來就會沒有競爭力。因此，本文將針對SOA作淺顯的簡介，也希望透過本文的介紹，對於本校網站服務技術(web services) 未來的架構有所幫助。

首先讓我們釐清一些SOA的迷思。正確來說 [1]：

1.
SOA不是新玩意：多年前即有資訊部門或公司成功地用SOA方式來建構、運行應用程式，且當時XML、web service都尚未提出
2.
SOA不是種技術：它是種建構、組織的方法，用來建立應用程式的運行環境，以及讓學校的業務程式能以「功能化」方式發展、累積。
3.
就算購買最新的XML、web services產品（如開發工具、執行平台、軟體元件等），也不表示就可以建構出SOA式的應用程式。

簡單來說，SOA是一種遵循典範，是針對學校或企業內應用程式的設計、開發、佈建、管理所提出的遵循典範。從資訊技術層面而言，一個執行學校或企業業務的應用程式稱為一個獨立的「邏輯單位」，而對學校或企業營運層面而言則可稱為一項「服務」，在企業的整體運算環境中就存在著多個「獨立邏輯／業務服務」，且需要對其進行妥善設計、開發、佈建、管理等，也因此需要採行服務導向架構（SOA）。
要實現SOA，需要學校或企業的程式設計師改採「持續累積服務」的觀念與角度來開發應用程式，即便這麼做在短時間內看不到顯著好處，程式師還是必須跳脫、超越過往對應用程式的想法，改以「既有服務可否再運用？」或者是「能否沿用其他同仁開發過的服務再建構？」的觀點來面對程式開發。
SOA主張「程式開發技術」與「程式建構方法」的交替並用，以類似傳訊溝通的作法，將數個所需的「業務服務」進行連結，以此來實現一個新的應用程式，而非「從頭開發」。透過適當的程式組構及傳訊式的程式連結，可讓學校或企業快速因應學生或用戶的需求與改變，新的應用程式只要透過「傳訊微調」即可實現，而非「重新撰寫」。
SOA不單只是程式開發的方法論，也提供行政管理層面的依循。例如它並非是以應用程式個體為角度來進行管理，而是直接將過往程式師開發出的程式視為「服務」來管理。而對「服務」間的「互動傳訊」進行分析，SOA便可讓程式設計部門的主管瞭解何時該執行哪個業務邏輯，以及為何要執行，如此資訊管理者與分析師便可對服務程序進行最佳化調適。
SOA如何運作?
SOA服務導向架構是一種新興的系統架構模型，主要概念是針對學校或企業需求組合而成的一組軟體元件。組合的元素通常包括：軟體元件、服務及流程三個部份。當學校或企業面對外部要求時，流程負責定義外部要求的處理步驟；服務包括特定步驟的所有程式元件，而軟體元件則負責執行工作的程式。SOA 已成為現今軟體發展的重要技術，透過 SOA 讓異質系統整合變得容易，程式再使用度也提高。不必自行開發或擁有所有程式元件，發展者可以視其需要組合網路上最好的服務。不受限於特定廠商的產品功能或是平台，達到真正的開放性(Openness)。從分散式元件架構到 SOA概念上，SOA 如同物件導向、軟體元件等軟體技術一般，運用小的零組件組合成應用系統。但 SOA 強調的是如何將彼此關係鬆散的應用系統功能元件在網路上發行、組合及使用。SOA 具有下列技術特性[2]：
1.
分散式架構 (distributed)－SOA 的組成元件是由許多分散在網路上的系統組合而來，可能是區域網路，也可能是來自廣域網路。例如網站服務技術 (web services) 就是運作 HTTP來相互連結的 SOA。如此的作法，也使得網站服務技術很快的就成為所有支援網際網路的系統平台均能使用的技術。
2.
關係鬆散的界面 (loosely coupled)－傳統的系統主要是將應用系統功能需求切割成相互關聯的小零組件：模組、物件或元件，發展者要花費極大的心力了解零組件是如何設計及使用，以確保不會違反零組件連接關係限制。如此一來，若要以不同零組件替換原始設計，就成為一件困難的事。SOA 的作法是以界面標準來組合系統，只要符合界面要求，零組件可以任意替換，大幅提高系統變更的彈性度。
3.
依據開放的標準 (Open standard)－使用開放標準是 SOA 的核心特色，過去的軟體元件平台如 CORBA、DCOM、RMI、J2EE 採用專屬協定作為元件連結的規範，使得不同平台的元件無法相通。SOA 則著重於標準與互動性，將可避免不同平台 (.NET web services 與 Java web services) 開發程式間相互整合的困擾。
4.
以流程角度出發 (process centric)－在建構系統時，首先了解特定工作的流程要求，並將其切割成服務界面(包括輸入與輸出資料格式)，如此其他的發展者就可以依據服務界面開發 (或選擇) 合適的元件來完成工作。

最後舉一個學校常用的例子來說明SOA在實際應用上帶來的可能性。假設我們要建立一個線上投稿的網站，網站提供的服務包括了線上投稿作業、論文分派作業、論文審查作業、線上註冊及報名作業等。傳統的方式我們會儘快找一個類似的網站，再儘快將其他類似網站的原始碼(source code)拿來修改，但其他類似網站的原始碼所執行的平台有可能不是架站者所熟悉的作業系統。若要讓架站者作一個客製化，並符合自己投稿主題的線上投稿的網站，可能要熟悉這個平台並修改網頁及測試，再加上別人的網站可能有一些bug，如果要做到毫無問題，除錯時間可能要花上三個月的時間。但是，如果我們導入SOA的架構的話，可能將來只要花費心力將作業服務模組化、物件化或元件化，然後將它們整合到網站中即可，不需要再花費時間和資源自己去維護一個線上投稿的網站，也不需要再自行建立和資料庫連結、報名付款機制等。這個網站就像是建立在SOA上，整合了這些web services元件的一個應用程式系統。更重要的是，透過如http、XML、SOAP 等產業標準開放式協定，不必擔心這些服務使用甚麼平台、甚麼技術來建立，而將來如果有更好的服務或服務提供者時，也可以輕易的將服務更換或更新。對系統開發者來講，可以快速輕鬆的將系統建構完成，將心思專注在規劃更好、更完善的系統上；對服務提供者而言，只要能設計出一個好的服務，它的潛在使用者市場將不再受到使用者平台的限制而有無限的可能。單就這類應用所呈現的美好遠景，應該可以解釋為什麼會到處聽到有人在談論SOA了。
因此 SOA 的實作，就是將所有程式邏輯及服務內容全部包裹在服務內部，並實作一個標準的介面與外部作溝通，這種做法跟傳統的元件導向做法非常類似，唯一的差別是介面定義的方式、資料格式、與溝通管道必須是產業標準 (http、XML、SOAP 等)。 也就是說只要能實作出這樣的介面，不論介面後面是什麼，都可使成為 SOA。


綜合以上的介紹，SOA能帶來的幫助，有以下好處：

1.增加企業盈收，或提升學校的服務品質。

2.提供可變動的網路服務型態。

3.降低學校或企業的成本。

4.降低開發服務的時間。

5.整合學校或企業的網路服務技術資源。

6.降低整體風險及意外。

參考文獻

[1] http://dev2dev.bea.com.tw/techdoc/07soa/07soa_040812_01.htm

[2] http://www.microsoft.com/taiwan/msdn/columns/soa/SOA_overview_2004112901.htm