活到老，學到老

     摘要:     概念：觀察者模式定義了一對多依賴，這樣一來，當一個對象改變狀態時，它的所有依賴者都會收到通知并自動更新。     舉個網上商城的例子，比如很多顧客對某個商品感興趣，把商品收藏，當該商品降價、促銷、有貨了等事件發生時，就會發Email通知顧客。     UML圖...  閱讀全文

    從今天開始，把常用的設計模式都簡單的整理一遍，希望每個星期能至少整理2個模式吧，先從簡單的策略模式開始。
    
    概念：它定義了一系列的算法，并將每一個算法封裝起來，而且使它們還可以相互替換。策略模式讓算法的變化不會影響到使用算法的客戶。
    
    策略模式很簡單，實際上就是OO中的多態，舉個例子，某商場要進行促銷，對于普通顧客打88折，對于銀卡客戶在88折基礎上再滿400減160，對于金卡客戶在88折基礎上再滿400減200。
    
    UML圖如下所示：
    

    接口DiscountStrategy代碼如下：
    

public interface DiscountStrategy {
    public double discount(double sum);
}

    類GeneralDiscountStrategy類代碼如下：
    
    類SilverDiscountStrategy類代碼如下：
    
    類GoldenDiscountStrategy代碼如下：
    
    類Cashier代碼如下：
    

     摘要:     這篇寫一個簡單的HelloWorld例子。     首先準備環境，我使用的JDK1.6,1.5應該也可以。還需要去oracle下載JMX RI包，地址為：http://www.oracle.com/technetwork/java/javase/tech/download-jsp-141676.html，下載...  閱讀全文

    這是我讀了JMX In Action以后的總結，這篇文章是這個系列的第一篇，主要介紹一下什么是JMX，為什么要使用JMX？以及簡單闡述一下JMX的架構。
    什么是JMX？
    首先看一下維基百科的定義：JMX（Java Management Extensions，即Java管理擴展）是Java平臺上為應用程序、設備、系統等植入管理功能的框架。
JMX可以跨越一系列異構操作系統平臺、系統體系結構和網絡傳輸協議，靈活的開發無縫集成的系統、網絡和服務管理應用。
    隨著企業 IT 規模的不斷增長，IT 資源（IT resource）數量不斷增加，IT 資源的分布也越來越分散。IT資源主要包括網絡和應用等。管理網絡（硬件）的主要工具是
簡單網絡管理協議（SNMP），硬件廠商一般都會在設備中提供SNMP hooks，但SNMP開發不是件容易的事情，而且需要掌握特定的語言，對JAVA開發者絕非易事。
    有些企業開發的應用的時候，是不會考慮運行時配置和管理問題。有些企業直接在產品中開發管理工具和界面。也有一些企業直接使用應用服務器或web服務器的管理工具。
    現實世界的IT資源管理需求主要有以下一些：
    1、監控平臺和硬件的健康。硬件可以通過SNMP，WEB服務器和應用服務器可以通過他們自己的管理工具。數據庫也是一樣等。
   2、配置應用層面的資源。比如配置應用在查詢結果中每頁顯示的數量，配置數據庫連接池，或者外部請求數等。
   3、收集應用程序的統計信息。如多少成功訂單，多少失敗訂單等。
   4、日志級別，改變日志級別。出問題的時候，可以通過改變日志級別來打印調試信息，快速定位問題。
   5、監視服務器的性能、負載，通過email、sms等通知關鍵性事件，比如服務器負載超過預設的界限。
    要滿足這些需求往往是非常昂貴和困難的，管理員通常需要通過不同的工具來管理不同的服務和硬件。 如果使用JMX，創建一個滿足上面需求的管理系統將是廉價、更加靈活、所需時間更短。     
    
    使用JMX的好處
     1、非常容易使用。特別是對一個JAVA程序員，要理解SNMP是困難的。而JMX對他來說非常容易。
      2、利用現有的技術：現有的管理工具可以插入JMX，JMX提供了很多協議（SNMP、HTTP）和傳輸方式（如RMI），如果原有的應用和設備沒有提供管理能力，則可以創建JMX代理提供管理能力。
      3、模塊化。以模塊化的方式創建你的管理環境。
      4、警告、事件和統計信息。
        JMX提供了一套通知系統，充分利用了面向對象優勢，通知提供了不僅僅是數據，而是一個有分布式JAVA對象，封裝了數據和行為。例如，你發送了一個服務器負載的通知，里面還包含了一個顯示負載重要性的級別的機制，說白了就是對象里面有個方法，可以判定負載的嚴重程度。
      5、快速的監控解決方案。不同的開發人員只需要自己開發MBean，而不需要花很多的時間在相互的協作上面，這些MBean分布在不同的主機上，但可以通過一個管理工具就可以管理所有的這些應用。

    JMX的一些術語
    1、可管理資源（Manageable resource）
    可以是任何的應用、設備、或者其他存在的實體，能夠被java訪問和包裝。是被JMX MBean管理的資源。
    2、MBean（Managed Bean）
    是滿足某些命名規則和繼承JMX 規范的java類，為可管理資源的管理和訪問暴露接口。通過屬性和行為來暴露接口。有這3類：Standard, Dynamic, and Model MBeans。
    3、MBean Server
    管理一組MBean的JAVA類。是JMX 管理環境核心。是MBean的注冊器。
    4、JMX Agent
    JMX代理是為管理一組MBean提供一系列服務的java進程。是一個MBean Server的容器，它還提供了一些有用的服務：創建MBean之間的關系，動態加載類，簡單的監控服務，定時器服務。Agent有一個協議適配器和連接器集合能使外部程序連接到他們。
    5、Protocol adapters and connectors
    協議適配器和連接器是位于JMX Agent內部的對象。把Agent暴露給管理程序和協議。一個Agent可以有很多適配器和連接器。
    6、Management application
    連接到JMX Agent的用戶應用程序。
    7、Notification
    通知是Mbean或者Mbean server發送的java對象，他們封裝了事件、警告、或者其他的一般信息。其他的Mbean或者java對象可以注冊成為監聽器來接受通知。
    8、Instrumentation（設備化）
    用MBean暴露一個可管理資源的過程。
    
    JMX架構
    JMX架構主要分為三層：Distributed layer，Agent layer，Instrumentation layer，如下圖所示：
      

    1、Distributed layer（分布式層）
      屬于JMX架構的最外層，這層主要負責使JMX Agent能對外部程序可用。    又分為兩種：一種通過不同的協議（如SNMP，HTTP）來為MBean提供可見性。 另一種是把Agent API暴露給其他的分布式技術如RMI。
    2、The agent layer（代理層）
    它包含的最主要的組件是MBean Server，它還包括4個代理服務使管理MBean更加容易，它們分別是：    定時器（timer）、監控服務、動態MBean加載、和MBean關系服務。Agent可以和被管理的資源在同一個主機上，也可以是遠程的。
    3、The instrumentation layer
    這是最靠近資源的一層，它包含了注冊在Agent里面的MBean。
    4、Notifications
    除了架構中的三層以外，JMX提供了一個通知機制，類似于JAVA事件模型。通知機制是管理系統的最后必須的組件。Agent和MBean可以使用通知機制來發送警告或信息給管理應用。
    以上就是JMX架構的主要內容，下一篇構建一個HelloWorld的JMX程序。

    這本書的前面三章主要講了一下基本概念，客戶端程序，和Amazon的S3，這篇博客總結一下第四章，個人感覺有很多重要的概念。
    面向資源的架構（The Resource-Oriented Architecture），這里的資源必須要有一個URI，資源和URI的關系：一個資源可能有一個或多個URI，而一個URI只能指定一個資源。

    Restful WS的特性：
    1、可尋址性（Addressability）
        資源通過URI來暴露給用戶，可尋址性是最基本的特性。由于可尋址性，你可以把URI保存在你的書簽里，你可以把鏈接發給別人，而不用把Html文件下載下來發給別人，也可以通過URI對資源進行緩存。

    2、無狀態性（Statelessness）
        無狀態性意味著每個HTTP請求是完全隔離的。每次客戶端發送請求都必須帶上所有服務器端需要的信息。    
        無狀態的應用更容易分布到有負責均衡的多臺服務器上；無狀態性也更容易緩存：緩存工具只需要看這一個請求，和任何其他請求無關。
        應用狀態和資源狀態（Application State Versus Resource State）
        應用狀態位于客戶端，而資源狀態位于服務器端，對于客戶端，每個客戶端都有各自的應用狀態，例如：在google搜索，你可能搜索某個單詞且當前頁是第3頁，我可能搜索另一個單詞且在第一頁，所以每個客戶端都有一個應用狀態。當客戶端發起請求的時候，必須告訴服務器你的應用狀態，比如你當前要看某個單詞搜索結果的第幾頁，服務器端返回結果上有其他鏈接，這些鏈接客戶端可能作為未來的請求。
        而對于資源狀態，對于每個客戶端都是相同的，就是服務器上的資源。  
  
    3、表述性（Representations）
        表述性，就是資源的表現形式，相同的資源可以有不同的表述性，比如同一個bug列表可以用XML文檔表示，也可以用文本方式表示等等。對于同一資源的不同的Representation，如何知道客戶端請求哪一種呢？作者建議不同的Representation使用不同的URI。

    4、連通性（Links and Connectedness）
        簡單點說，就是返回的結果中有對其他資源的鏈接（URI），比如google搜索，搜索結果可能有其他頁的鏈接。

    5、統一的接口（The Uniform Interface）
        也就是說Restful WS使用HTTP的基本方法作為他的方法的表示，主要使用HTTP的四個方法：GET,PUT,DELETE,POST。HEAD和OPTIONS用的比較少。
        取得某個資源的表述的時候使用GET。
        創建一個新的資源的時候，PUT到一個新的URI，或者POST到一個已經存在的URI。
        修改資源，使用PUT到存在的URI。
        刪除資源使用DELETE。
        PUT和POST都可以創建新的資源，那有什么區別呢？POST可以創建從屬資源，如一個webblog程序通過資源（/weblogs/myweblog）暴露每個blog，而某個blog下面的條目作為從屬資源為/weblogs/myweblog/entries/1，當你需要增加一個條目的時候，你可以POST到父資源/weblogs/myweblog，同樣PUT也可以完成這個工作，在這里POST和PUT的區別是：當客戶端可以控制新資源的URI的時候，則使用PUT，比如blog的下面的某篇文章使用名字來訪問，如/weblogs/myweblog/entries/restful_ws_1（這樣某個博客下面的文章不能重復），則當你發表一篇新文章的時候，可以PUT到新的URI如/weblogs/myweblog/entries/restful_ws_2來創建資源。而如果客戶端不能控制URI的時候，比如blog是通過服務器端某個序列號來訪問，客戶端是無法知道下一個序號是什么，這時只能使用POST，這種POST如果創建成功，則返回201，響應頭中的Location可以保護新創建資源的URI。
        還有一個區別，POST對某個存在的資源更新時，一般是追加（append），比如說對某個日志文件做POST，則把日志追加到原日志的后面。如果是PUT則進行的是替換，所以PUT是等冪的，而POST不是（后面會講）。

        安全（Safety）
        GET和HEAD方法只是獲取資源的表述，所以是安全的。當然也可能有一些副作用，比如有些服務端會記錄GET的次數等。

        等冪性（Idempotence）
        等冪性簡單點說就是一次請求和多次請求，資源的狀態是一樣。比如GET和HEAD，不論你請求多少次，資源還是在那里。請注意，DELETE和PUT也是等冪的，以為對同一個資源刪除一次或者多次，結果是一樣的，就是資源被刪除了，不存在了。為什么說PUT也是等冪的？當你PUT一個新資源的時候，資源被創建，再次PUT這個URI的時候，資源還是沒變。當你PUT一個存在的資源時，更新了資源，再次PUT的時候，還是更新成這個樣子。在PUT更新的時候，不能做相對的更新（依賴資源現在的狀態），比如每次對一個數加1，這樣資源狀態就會變化。應該每次更新成某個數，比如把某個數變成4，則無論多少次PUT，值都是4，這樣就是等冪了。
        我們設計Restful WS的時候，GET，HEAD, PUT, DELETE一定要設計成等冪的。由于網絡是不可靠的，安全性和等冪性就顯得特別重要。如果一次請求，服務器收到處理以后，客戶端沒有收到相應，客戶端會再次請求，如果沒有等冪性保障，就會發生意想不到的問題。
        POST是不安全也不等冪的，還是拿weblog的例子，如果兩次POST相同的博文，則會產生兩個資源，URI可能是這樣/weblogs/myweblog/entries/1和/weblogs/myweblog/entries/2，盡管他們的內容是一摸一樣的。
        
    

    雙親委派模型
    Java從1.2開始引入雙親委派模型。除了啟動類裝載器，每個類裝載器都有一個雙親。當類裝載器裝載某個類的時候，首先會委派它的雙親去裝載這個類，它的雙再委派自己的雙親，直到啟動類裝載器。
    Java類裝載器的結構如下：
     

    1、啟動類裝載器
    主要負責裝載jdk_home/lib目錄下的核心api  或 -Xbootclasspath 選項指定的jar包。處于雙親委派的最頂層，該類其實是由C語言編寫。
    2、擴展類裝載器
    主要負責裝載jdk_home/lib/ext目錄下的jar包或 -Djava.ext.dirs 指定目錄下的jar包
    3、系統類裝載器
    主要負責裝載ClassPath下的類。
    4、自定義類裝載器
    自定義類繼承ClassLoader或其子類。可以運行時動態裝載某些類。