popcorny的部落格

POSA2: Reactor

Introduction
Reactor是一個Architectural pattern。目的是讓一個event-driven的應用程式，能夠把產生的事件解多工(demultiplex)並且分派(dispatch)到對應的service做處理。

As Known as
Dispatcher, Notifier

Context
此pattern是應用在event-driven的應用程式。在其中，應用程式可能同時間接收到不同client的service requests，但是卻要同步地(synchronously)且循序地(serially)處理他們。
(註: 這裡的synchorously及serially是相對於asynchronously，也就是同步的呼叫。在同步的呼叫中，caller一定要等callee完成處理後，才能繼續下一個動作，因此才又會是serially。反觀asynchronously process，caller不必要等待callee完成處理就可以做下一個動作)

Problem
Event-driven的應用程式(尤其是server程式)必須要能夠同時處理很多client所產生的service request。而所有的event可以用indication event(如CONNECT及READ)來做區別。但是在處理這些event之前，event-driven的應用程式必須要先把這些indication
event做解多工(demultiplex)跟分派(dispatch)到對應的service。要解決這個問題，我們必須要有以下四個必須考量到的問題
1. 應用程式不應該block在某一個indication event而導致無法處理其他的event，這會導致效能大大的下降。
2. 為了能夠有較好的throughput，任何不必要的context switching, synchronization, data movement都應該要避免。
3. 若未來要整合新的service或是改善暨有的service，所需要花的功夫應該越少越好。
4. 撰寫Service的程式碼中，應該完全不會理會到底層複雜的multi-threading或是synchronization部分的機制。

Solution
用Synchronous的方式去等待來自不同的event source(如connected socket handles)的indication event，並且整合了demultiplex跟dispatch的機制在其中。除此之外，我們把有關demultiplex跟dispatch的機制以及application-specific處理event的邏輯分離。

更詳細的說，我們把處理某個indication event的邏輯看成是一個service，而此service必須實作成一個"event handler"，並且註冊在一個稱為"reactor"的元件當中。"reactor"透過"synchronous event demultiplexer"來等待某個indication event的發生。當indication event產生時，則回傳給reactor，並且找到對應的"event handler"用同步的方式dispatch給它做對應的處理。

Static

Participants and Responsibilities
Handle and Handle Set
-Handle代表的是一個event source。
-Handle Set代表的是一組handles。

Synchronous Event Demultiplexer-提供block waiting，直到在handle set中有任何event的發生
-指示說某個operation可以被呼叫而且不會有任何的blocking

Event Handler
-定義一個處理indication event的共有介面

Concrete Event Handler
-Event Handler的實作，根據程式的邏輯來處理event。

Reactor
-可以register或remove一個event handler
-管理handle set
-執行application的event loop。

Dynamics

1. 首先Main Program先向Reactor註冊Event Handler
2. 而Reactor會呼叫Synchronous Event Demultiplexer的select此blocking method。
3. 當一個或多個event source有任何indication event產生時，select會回傳。
4. 針對產生的event分派給對應的的event handler。

Consequences
此pattern在很多的場合都會看到蹤跡，最常見的就是non-blocking io的select此method，有寫過berkeley socket的人應該很有感覺。但是更不一樣的是此pattern把處理某個event的邏輯抽離出來，委託給應用程式去實作，這是一種"inversion of control"的一種實現。

在java中，J2SE 1.4開始也有了select此method的支援，
分別是用到
java.nio.channles.Selector
java.nio.channels.SelectableSocket
java.nio.channels.SelectionKey
有關實作此pattern的細節可以參考Doug Lea的投影片
http://www.jsptw.com/jute/post/view?bid=12&id=12075&sty=1&tpg=1&age=0

至於此pattern最大的兩個優點我認為是
Coarse-grained concurrency control:
此pattern用一個thread(或process)去處理很多個concurrency，這會大大的減少thread的產生，以及避免複雜的synchronization。

Separartion of concerns:
此pattern把底層demultiplex跟dispatch的機制，跟application-specific service implemenation完全的抽離。如此可以減少application本身的複雜度，同時也增加了整個架構的重複使用性。

但是也有一些缺點
Non-pre-emptive:
若某個handler把thread佔去去做一個很花時間的動作，那整個系統的效能將會被拖垮。此問題可以把task委託給其他thread處理而獲得解決。

Complexity of debugging and testing:
這個問題主要來自reactor pattern是使用"inversion of control"，所以的event handler都是透過callback的方式被喚起，所以無法從頭到尾追蹤錯誤的來源。除此之外，若兩個event之間有State的關係，此種程式會更難撰寫。

比賽結束囉

今天早上去台大present完了
節奏抓的不錯
感覺比預演的時候還要流暢
雖然我個人覺得這個比賽得名的機會不大
(主要這個比賽的對象是公司...)
但是感覺盡了自己所能
把所能表達的發揮到極致
就心滿意足了
也感謝蘇科旭跟小武全程支持..:D
大家都辛苦了

人真的是欠逼

真正逼起來的時候
產量真的是驚人
但是也很累
不過今天成果還不錯
希望禮拜天可以present順利

考到駕照啦!!!

辛苦了一個月...
總算考到駕照囉...
筆試95
路考92
還算滿意啦...
真是爽呀...
總算了了一件事

明天考駕照

現在竟然給我下大雨..~><~
而且最慘的是教練場跟監理站都超遠的
車程都要半個小時...
希望明天一切順利

這禮拜有得忙了

我們實驗室裡報名的比賽竟然入圍了
而且還要再禮拜天demo
所以這禮拜要大趕工
而且負責的博士班學長要出國
所以到時候present也是由我處理..~><~
真是天將降大任於我
看來這禮拜有得忙了
POSA2下一篇遙遙無期

[狂賀]張泰山HR27破本土

太帥了啦.... 昨天HR第27發...
創本土紀錄啦...
而且昨天盜壘兩次.. 離雙20只剩一個盜壘...^^y
張泰山真是太強了...
可惜今年三冠王越來越難...
全壘打沒問題...
打點昨天追平陳致遠
安打跟打擊率大概沒什麼希望了吧....

對jsptw真是又愛又恨

一天花在jsptw的時間不知道多少
事情都做不成
真想拔網路線...~~><~~~

今天又去道路駕駛

但是我不想去阿...
因為下禮拜二就要考試了
原本想說今天好好的練的
結果教練竟然說要去道路駕駛...@@"

今天去新埔監理所
那是我們筆試的地方
還真的有夠遠
看來考試那天要好早起了...
一想到就累...@@"

POSA2: Extension Interface

Introduction
Extension Interface這個design pattern允許元件提供數個介面。會這樣的設計主要是因為當元件不斷的開發的時候，我們不改變舊有的介面；相對的，我們提供新的介面，以免舊有的介面不斷膨脹，甚至影響原有client的正確性。

Context
元件的介面可能不斷開發演進的應用程式環境。

Problem
在應付時常改變的程式需求時，元件所提供的介面可能時常需要修改或是擴充以滿足新功能的要求。若是元件在release之前，我們可以預料需求的改變的話，我們可以用"里斯可夫取代法則(Liskov Substitution Principle)"來選擇適當的base interface允許他的method由子類別去擴充其功能性。

但是有時候我們的元件已經釋出了，之後的改變是我們無法預期的。若元件已經整合在數個應用程式之中，我們還需要增加或修改元件的需求時，修改元件的功夫將需要更加的謹慎。首先我們必須要求不會破壞到使用舊元件的應用程式；再者，新功能可能是在少數應用才會使用到，若一味的增加新功能而讓元件使用者使用該元件過於複雜，也不是很好的結果。

Solution
我們提供元件使用者用不同的介面來存取同一個元件。而每個介面代表的是元件所扮演的一種角色，而非所有角色都透過同一個介面來使用。換言之，我們若想要提供一個元件一個新的功能(或說扮演一個新的角色)，我們不改變暨有的元件介面，相對的，我們為此元件增加一個新的介面來使用這個新的功能。

Structure

Participants and Responsibilities
Copomnent
1. 扮演不同的角色
2. 實作extension interfaces
3. 回傳root interface給component factory

Root Interface
1. 定義所有extension interface所需要的最基本的功能

Extension Interface
1. 定義元件所提供"角色特有"的介面

Client
1. 透過Component Factory產生元件
2. 使用extension interface來存取元件所提供的功能

Component Factory
1. 定義產生元件所需的功能
2. (選用) 定義找尋已存在的component所需的功能

Dynamics
在此，我們有兩種scenario來使用extension interface pattern。
Scenario I
1. client向component factory要求傳回元件的特定介面。
2. 此時component factory產生一個新的component，並且取得roote interface的reference。
3. component factory再透過initial interface來取得extension interface，並且回傳給client

Scenario II
1. client使用extension interface A的某一個method，在此不管他是root或是extension的 interface。
2. component回傳此method的結果。
3. client呼叫getExtension()，並且取得另一個他所感興趣的interface。由於所有的extension interface都是繼承root interface，所以必定有getExtension()此method。
4. client取得extension inteface B後，呼叫extension interface B的某個method。

Known Uses
事實上很明顯的，這個pattern讓人直接想到微軟的COM。root interface就是IUnknown，而getExtension就是IUnknown中QueryInterface這個method。在COM中透過128bit的GUID來代表某一個InterfaceID(或稱IID)。所以若有學過COM的人看此pattern會非常的直覺。

Consequences
優點:
Extensibility
Separation of concerns
Decoupling of components and their client
Support for interface aggregation and delegation
缺點:
Increased component design and implementation effort
Increased client programming complexity
Additional indirection and run-time overhead

POSA2讀書心得...@@"

好像已經好幾天沒有發文了
今天努力生出一篇吧..^^~

怎麼辦 還好想睡

可是等一下要去上一門很理論的課
Distributed Algorithm
希望等一下不要給他睡死...
這們課是我這學期唯一修的一門課
應該是不會太操吧
祇是怕上課會睡著而已
上課企

好用的UML Modeling Tool - Jude

http://objectclub.esm.co.jp/Jude/該有的功能都有
而且剛剛玩玩看也覺得真的不錯用
而且可以全選之後copy到word之上 或是photoshop之上
省下存成檔案的麻煩
大家試了之後發表一下感想吧

POSA2: Interceptor Pattern

Introduction
Interceptor是一個Architectural Pattern。此pattern允許某個service在不影響原有架構下加入framework中，並且當事件發生觸發對應的service處理事件。

Context
可以在不影響架構之下擴充功能的framework。

Problem
1. 一個framework應該允許在不改變核心程式的前提下，整合進額外的服務。
2. 當我們要整合程式特有(application-specific)的service時，理應不用動到既有的 framework元件，也應該改變到使用此framework的應用程式。
3. 使用framework的應用程式也許會需要監測及控制他自己的行為。

Solution
由於要允許應用程式額外註冊一個service，因此我們必須先定義好一個service應有的介面，稱此介面為interceptor。應用程式則根據interceptor介面實作一個concrete interceptor，並且跟concrete framework註冊。當事件發生時，concrete framework透過dispatcher找到適當的concreate interceptor做事件回呼(event callback)，並且傳入context object以提供conrete framework的run-time資訊。

structure

participants and responsibilities
Concrete framework:
-提供應用程式服務
-整合dispatchers以分派event到interceptor
-委派event到對應的dispatcher
Interceptor
-定義service所應有的介面
Concrete Interceptor
-實作interceptor的service
-使用context object去控制concrete framework
Dispatcher
-允許應用程式去註冊或是移除concrete interceptor
-當event發生時，負責分派對對應的concrete interceptor
Context Objects
-允許service存取concrete framework中的資訊
-允許service去控制concreate framework中的行為

dynamcis

conclusions
事實上在Servlet, EJB, Applet都是使用這種pattern
例如HttpServlet就是一個interceptor
我門實作的Servlet就是一個Concrete interceptor
ServletContext就是Context Object
Dispatcher是存在Servlet Container中，負責把某個URL對應到某個Servlet
當然，一個Servlet Container就是一個concrete framework
由此就可以清楚了解interceptor的精隨了

張泰山

喔耶...單場雙響砲
好爽阿~~ ^^
不過今天興隆安打真少..@@"

月亮有夠亮

好刺眼唷....
旁邊的火星也很猛....
在那麼亮的月亮旁邊還是那麼明顯
還沒看到的趕快去看
颱風來了什麼都看不到了

POSA2: Component Configurator

Introduction
Component Configurator這個pattern主要的目的是允許程式在run-time的時候可以安裝或是移除某個component。程式可以不用修改、重新編譯、靜態鏈結(statically relink)。甚至在更理想的狀況下，可以重新安裝一個元件在已經執行的process之上，而不用停止及重新啟動這已經執行的程式。

Context
當我們需要開發的componont，能夠在被initiated, suspended, resumed, terminated這些動作時，越具有彈性(flexibility)越好，並且具有通透性(transparency)。

Problem
1.程式的實作常常會需要改變。
2.程式在開發的過程中我們不會知道最好的實作方式，若一開始就定死某種實作則會大大失去彈性。
3.分散各處的component我們需要一個centralized的管理機制。管理者絕對不希望每個host上的component都要有一個管理程式。

Solution
為了達到可以隨時抽換的功能，所以我們必須降低介面跟實作的耦合性。因此我們必須定義component的介面，以在安裝component到application時，application所使用的API跟任何的實作獨立。之後我們必須時作concrete componets為真正的實作，他必須實作component介面所定義的init(), fini(), suspend(), resume(), terminate()，並且包裝成可以動態鏈結的形式，如windows下的dll(在java中可以包成jar檔，並且用ClassLoader來讀取最新的Component)。而這些dll(或是jar)透過component configurator動態鏈結(在java是動態載入dynamic loading)的方式讀入component的資料，並且存放在component repository。

Structure

Participant
Component: 定義Component應有的介面，如init(), fini(), resume(), suspend(), terminate()...
ConcreteComponent: 實作一個可以動態安裝的application component
ComponentConfigurator: 負責掌管安裝、移除component。
ComponentRepository: 維護應用程式中的component。

dynamic

Implementation
1. 定義component的介面。
2. 實作component repository，需要有一些insert(), remove(), find()等功能。
3. 定義component configurator介面。這邊書上有建議我們可以定義一套directive的方式來操作configurator的功能，因此必須定義有這些directive的format，以及實作parser等。另外還要實作有關動態鏈結的邏輯。因此這一部分會花上很大的功夫。
4. 實作concrete component，撰寫各元件的邏輯。書上提到實作component上需要考慮的問題，其中包跨concurrent model，是只允許single thread，還是允許multithread呢。還有是否支援inter-component communication呢?還有可不可以允許component之間有relationship呢?這些都可以考慮進去。

Known Uses
1. Windows NT Service Control Manager.
2. Modern operating system device driver.
3. JMX。這個我必須多說明一下，事實上使用JMX就是解決這個問題的一個很好的solution。這裡的component就是JMX的MBean，component repository就是在MBeanServer裡，component configurator可以使用MLet的方式做dynamic loading。而centralized的management可以透過http方式去管理，或是透過JSR#160的JMX Remote來完成。

Consequences
其實在java中要實作這個pattern有得天獨厚的優勢就是dynamic loading，所有的class都是透過ClassLoader方式讀入，所以光這點就很好實作此pattern。另外此pattern可以跟GoF strategy pattern跟bridge pattern做個比較，找出這兩個pattern跟此pattern的差異。

ppy也blog囉

網址在這
http://140.113.68.1/mt/
太好了 越來越多人blog了...^^

道路駕駛 PART2

上禮拜五才去去道路駕駛
想不到這禮拜二又去一次
而且今天是跟一個也是交大的女生去
太棒了...^^y

這次換我先開
目標是西濱
太輕鬆了啦
我覺得開車對我來說已經不是太困難的事情了
教練還稱讚我說熟練許多
一路上就這樣有說有笑的開到西濱

西濱真是路寬又直
忍不住就想加油門
不過道路上看到禁止機車的警告標語
還猶豫了幾次... 都忘了自己已經在開四輪車了..XD

一個紅綠燈左轉
哇 開到紅毛港了
好久沒有看到海唷 真是Happy
我門就停在路邊欣賞一下海景..:)

換另一位交大女生開
他好像是第一次開道路駕駛
有點小緊張
方向盤有時候都會沒握穩
車子常常會偏一旁
不過車速不快 倒也不是挺緊張的
路上聊一聊
忽然想起他較婉君
那不是跟佳君室友同名嘛...
一問之下 那還真的是他耶...
想不到他鄉遇故知
也不是故知啦 就是小勾到邊就是了...^^

在外面繞了一個小時
回來教練開始教我S型
有比其他項目難一點
不過倒也還好
離考試只剩兩個禮拜了
希望一切順利..:)

POSA2: Wrapper Facade Pattern

Instroduction
Wrapper Facade pattern主要是用來包裝已經存在的non-object-oriented的API，通常是OS題供的system call，以成為一個object-oriented的api。此方法可以讓API使用起來較為簡單、穩固、增加可攜性、並且更具有凝聚力的object-oriented的程式介面。

Context
開發中的程式必須使用到系統中提供的一些common mechanism或是service。但是這些服務是以non-object-oriented的方式呈現。

Problem

• 不好撰寫，non-OO的程式通常很瑣碎。

• 跟平台綁死，不portable。

• 就算可以portable，還必須用很多directives，程式更難維護。

• non-OO的程式通常都不high cohesive。我們永遠不知道哪些function之間是相關的。

Solution
一言以蔽之，"包起來"。這就是Wrapper Facade的精隨。我們以OO的方式把底層所有的system call或是non-oo library全部給包起來，此層稱為Wrapper Facade，此好處是把原有醜陋的non-OO API，變成簡單易用的OO API。除此之外我們也可以把跟OS-denpendent的部分抽象出來變成一致的OS-Independent的介面，如此以達到跨平台的目的。

Known Uses

• MFC: 把醜陋的Win32 Platform SDK包裝起來。

• ACE(Adaptive Communication Environment): 他把很多平台的service包裝成一致的Wrapper Facade。如Socket，thread，mutex等。

• JAVA: 事實上就是一個Wrapper Facade。

可怕的東西 - ettercap

http://ettercap.sourceforge.net/
HTTPS跟SSH1都難逃一死
而且他可以跑在switched lan下
用的是ARP meet in the middle的方式
這種東西放在sf.net上實在太可怕了

LOG4J + MX4J

0. 前言
前面一篇介紹了JMX，此篇將以Log4j以及MX4J這個組合讓大家來感覺一下JMX是什麼樣的東西。可以做些什麼事情。

1. Log4j
首先介紹一下這兩個OpenSource project。Log4j大家應該比較耳熟能詳，他是一個log的utility。此project是掛在apache jakarta之上。使用起來非常簡單，在log4j中最重要的有三個元素。

• logger: log的一個基本元件。可以提供不同層級的logging，如fatal, error, warn, info, debug..。

• appender: appender是logger的log所要輸出的位置，最簡單的就是Console，另外也可能是file, network,..。

• layout: Appender輸出時，所呈現的layout。

log4j把這三個主要元件都包成一個MBean，除此之外，還包括了一個HierarchyMBean，可以看成Log4j中所有MBean的入口，他會自動把所有的logger，Appender，Layout產生對應的MBean，所以我們不需要把每個log4j的元件都註冊進MBeanServer，只要註冊一個HierarchyMBean就可以把所有log4j的元件丟進HierarchyMBean所註冊的MBeanServer了。

2. MX4J
MX4J是一個JMX的implemenation，目前是實作JMX1.1的版本。目前版本的MX4J題供了以下幾點功能:

• 透過XDoclet自動產生StandardMBean的管理介面

• HTTP adaptor (also over SSL)

• RMI over JRMP adaptor (also over SSL)

• RMI over IIOP adaptor

• StandardMBeanProxy以容易的方式呼叫Standard MBeans

• AbstractDynamicMBean以容易的開發Dynamic MBeans

而此篇最主要的是使用到他的HTTP adaptor。

3. Unmanaged Application
以下是一個使用log4j但是還沒有加上JMX的程式

//Main.java
import org.apache.log4j.*;
public class Main implements Runnable{
    private static final Logger log = Logger.getLogger(Main.class);
    public Main(){
        try{        
            while(true){            
                log.debug("is pop here?");
                Thread.sleep(1000);
                log.info("yes.. he is here!!");
                Thread.sleep(1000);
                log.warn("pop is singing!!");
                Thread.sleep(1000);
                log.error("pop is crazy...!!");
                Thread.sleep(1000);
                log.fatal("pop is popping");
                Thread.sleep(1000);
            }
        }catch(InterruptedException e){
            //ignore
        }
    }
    public static void main(String[] args){
         new Main();
    }
}

很傳統的log4j的寫法。比較需要注意的是，log4j還必須要有一個Configuration File，
此file必須放在%classpath%/log4j.properties中
檔案內容如下

log4j.rootLogger=WARN, console
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.layout=org.apache.log4j.SimpleLayout

此程式跑起來會發現，info跟debug這兩個level的log都不會出現，因為我們把level設在WARN，所以WARN以下的都不會出現。

4. 加上JMX，並且使用MX4J的Http Adaptor
承襲上面的程式碼，加上了粗體字的部分：

import javax.management.*;
import org.apache.log4j.*;
import org.apache.log4j.jmx.*;
import mx4j.adaptor.http.HttpAdaptor;

public class Main implements Runnable{
    private static final Logger log = Logger.getLogger(Main.class);
    public Main(){
        try{
           new Thread(this).start();      
            while(true){            
                log.debug("is pop here?");
                Thread.sleep(1000);
                log.info("yes.. he is here!!");
                Thread.sleep(1000);
                log.warn("pop is singing!!");
                Thread.sleep(1000);
                log.error("pop is crazy...!!");
                Thread.sleep(1000);
                log.fatal("pop is popping");
                Thread.sleep(1000);
            }
        }catch(InterruptedException e){
            //ignore
        }
    }
    
   
    public void run(){    
        try{
            MBeanServer server = MBeanServerFactory.createMBeanServer();
            ObjectName hdmName = new ObjectName("log4j:hiearchy=default");
            ObjectName name = new ObjectName("Server:name=HttpAdaptor");
            ObjectName processorName = new ObjectName("Server:name=XSLTProcessor");
            server.createMBean("org.apache.log4j.jmx.HierarchyDynamicMBean", hdmName, null);
            server.createMBean("mx4j.adaptor.http.HttpAdaptor", name, null);
            server.createMBean("mx4j.adaptor.http.XSLTProcessor", processorName, null);
            server.setAttribute(name, new Attribute("ProcessorName", processorName));
            server.setAttribute(name, new Attribute("Port", new Integer(8082)));
            server.invoke(name, "start", null, null);
        }catch(Exception e){
             log.error("Can't register MBean to MBean server", e);   
             System.exit(-1);     
        }                   
    }    
    
    
    public static void main(String[] args){
         new Main();
    }
}

在這段程式中的run()method中做了幾件是

1. 產生一個MBean Server。

2. 註冊一個Http Adaptor，把MBean的介面轉成http protocol。而比較特別的是此Http Adaptor是產生XML，而非HTML。

3. 註冊一個XSLT Processor。由於Http Adator產生的是xml，若我們不註冊此service的話，我們用brower看到的將是XML的格式。而此service是把Http Adaptor輸出的XML轉換成HTML，則可透過brower直接作操作。

4. 註冊HierarchyDynamicMBean，此MBean會把所有的logger、appender、layout一併註冊到MBean Server中。

5. 執行程式
可以在此抓下檔案

一開始我們執行這個程式
如我們所願，只印出WARN以上的LEVEL的log

之後我們連到http://localhost:8082/的位置，也就是我們註冊的Http Adaptor的位址。
我們會看到下面的網頁，感動吧...

我們點入[Domain: log4j]>[log4j:logger=root]
找到[Attributes]>[priority] 把值改成FATAL
如下圖所示

回到我們原本的程式去看
果然只出現了Fatal... 萬歲...^^y

JMX at a glance

0.前言
隨著軟體需求越來越複雜，軟體通常不會從無到有重新打造。通常我們的程式會架構在一個middleware之上，在上面寫一些應用程式而使我們的程式享有middleware所提供的system service。但是隨著架構越來越複雜，元件越來越多，所開發的應用程式也越來越難管理。有些middleware會提供一些管理程式來管理每個元件，但是一方面管理介面不是最重要的考量，所以介面通常做的不是非常的好用；另一方面，我們自己開發的應用程式也無法或是很難在他們的管理程式中被管理。再者，每個元件開發的程式開發者必須撰寫自己的元件以外，還要另外開發管理介面，這些功夫導致很多程式都不能被重複利用。因此，管理這個領域的標準化就變成非常重要。而這篇介紹的JMX - Java Management eXtension就是針對這個需求因應而生的。

1.簡介
JMX的官方網站在這，他是在JSR#3所定出來的標準。

在JMX中，他把管理這個領域分成三個層級。由下面這張圖可以看的很清楚：

1. Instrumentation Layer

這是最底層的一個layer，但是卻是大多數程式設計師最容易接觸到的一層。所謂的Instrumentation就是可以被管理的service或是application。在JMX中稱之為Managed Bean，簡稱MBean。我們的元件要符合一個MBean，必須符合JMX的規則。JMX目前的版本題供四種MBean，分別是StandardMBean，DynamicMBean，ModelMBean，及OpenMBean。但是這個要細講可能又要好幾個版面了，所以這方面請自行去翻閱JMX相關文件或書籍。
2. Agent Layer

Agent Layer這一層是Management Application跟MBean中間的橋樑。Agent Layer中最核心部分是一個MBean Server，可以看成一個Registry。所有的MBean必須用一個獨一無二的名字去跟MBean Server註冊。而MBean Server會透過Adpator及Connector來跟管理程式作溝通。Adaptor應該說是Protocol Adaptor，他把MBean的介面轉成某種特定的protocol，最常見的例子就是Html Adaptor，他把這些MBean的介面轉成可以透過browser所管理。而Connector是連結local mbean跟remote management application的一個管道，通常會提供MBean相同的API讓遠端去呼叫，底層實作的Protocol完全不用知道，最簡單的方法就是用RMI，此部分是JMX Remoting的範疇，由JSR#160所定義。
3. Distributed Service Layer

這個Layor就是管理者所接觸的部分。通常是一個管理程式，或是一個brower。而這部分不需要是java的application，可以是任意的application。因此此部分在JMX中不做任何的規範。

待續....

很像也是一個不錯的Plugin - MTMacro

網址在這
MTMacro可以定義一些macro來幫助我們把這些macro轉換成html格式
最常見的就是笑臉...還有一些container tag..
如[code]... [/code] [b]...[/b] 等等....
雖然我已經用了quickcode
但是感覺陽春了一點
改天來研究研究這個plugin

裝好quickcode

以下是個範例...

public class Main{
    public static void main(String[] args){
        System.out.println("helloworld");
    }
}

不過不知道為什麼..
用IE跑起來常常會看不到
這應該是IE的問題
因為我用scrollbar上下拉一下就出現了

裝quickcode還滿簡單的
就連到那個網址抓下.zip檔後
解開來
把.pl檔放在movable type的plugins目錄下就可以了...

而要用的時候要注意一下
在貼文章的時候
記得要把Text Formatting改成quickcode...
才會有這些效果

另外我也改了一些樣式
剛開始他沒有套CSS
所以要去改那個.pl檔
在處理"code"的tag上 在<pre>的tag加上<pre class="code>
之後在去改css就可以了
最後面加上一個.code 的class
再加上這一塊 (這是我改的..)

	        .code{
		padding-right: 0.5em;
		margin-top: 1em;
		padding-left: 0.5em; 
		font-size: 8pt;
		margin-bottom: 1em;
		padding-bottom: 0.5em;
		margin-left: 0pt; 
		padding-top: 0.5em; 
		font-family: Courier New; 
		border:1px solid #CCC;
		background-color: #FFFFCC; 
		color:#666; 
		}

quickcode

明天來裝這個plugin
網址在這
感謝JiaYun的題供
不過今天太晚了
明天再來裝吧..:D

膜拜圖案...

哈哈...我超喜歡這個圖的

<img alt="膜拜" src="http://www.cis.nctu.edu.tw/~gis91530/blog/archives/images/worship.gif" width="29" height="15" border="0" />

好久沒去天瓏...

今天為了去買Forth介紹的一本書特地到天瓏
應該有三四個月沒去天瓏了吧
這本書泛稱POSA2
全名是Pattern-Oriented Software Architecture Volumn 2
Patterns for Concurrent and Networked Object
由於最近在寫相關的程式
所以就買一本來拜..

大概看了一下內容...
還算滿喜歡的
但是美中不足的是大部分都用C++當作範例
java就少了一點
如果多一點java就好了..

去的時候還遇到台灣正名大遊行
真佩服他們怎麼可以號招那麼多人
滿街的遊覽車...
感覺上台灣對於政治特別熱情
但是我一點都對政治不感興趣
反正都是看誰比較會作秀
然後敵對陣營一有什麼瑕疵...
馬上就找砲轟...
看久了就覺得很無聊....

分享真的是會上癮

最近開始喜歡分享自己的研究成果
能夠把自己的讀書心得拿出來做個整理 分享給大家
之後獲得別人的迴響
也挺有成就感的...

真的很敬佩那些把自己研究整理成一個網站
讓後進者可以馬上學習上手
有時候再接觸一些新技術的時候真的很需要這種網站的幫助
省了很多摸索時間...

但是總覺得自己還是挺懶的...
頂多偶而在公開論壇po po技術文件
要我自己搞個網站 或是半個電子報...
我真的沒那個時間 也沒那麼勇氣 ><

當初會想要架一個blog也是想把讀書心得po在這裡吧
一方面是一種分享
另一方面也可以整理
先走出第一步吧
若量多的話 在考慮要不要開個電子報囉..:D

道路駕駛

今天去道路駕駛
第一次開車開上路
還挺不錯玩啦...^^y

跟我同車的還有一個媽媽
他也是學員啦.
教練要我們開車到竹北去接一個學員
過去先是那個媽媽開
那個媽媽不太趕開 都不敢加油
才踩一下油們就說太快...真是無言. = =||
一路上慢雖慢...但是還停安全的啦....

到了竹北... 接了那個學員後
就換我開啦...
齁齁...我覺得我太有天份了
如果我開的是一般的車的話
應該不會認為我是新手吧...哈哈....

覺得還挺好玩的..
教練說下次要帶我們去西濱
有點小期待....
現在開始有點想要有一台車了...

大逆轉....

昨天才說想說算了...賠錢了事
結果今天去學車時...
結果大逆轉... ^^y

一到那邊..那邊的主管洪主任已經在那邊等我了
他把我叫過去跟我說他已經幫我換教練了
而且不用賠錢....
oh... yeah~~
洪主任真的是大好人

新的教練是一個女教練
講的清楚多了
走到哪裡哪裡要注意..
哪邊可能會發生什麼危險都講的一清二楚...
一切都完美多了...

這幾天心理的陰影總算撥雲見日了...
前幾天還特別去拜土地公
今天回來馬上去還願....
看來土地公還是有眷顧我的...:)

:)

今天心情比較好。..
之前因為被撞車事件搞的心情不太好
不過我有點想讓步了
不是因為我有錯
而是我覺得真的沒有那個價值跟他爭辯這些
1200就給他吧
對我來講這個錢沒有那麼重要
心情好對我來講比這個重要許多
而且我更不想在還有一個月的學車日子裡跟教練不愉快

也許有人覺得我沒錯..沒必要給他錢 是一股氣的問題...
但是想想人生中那麼多重要的事情要我去做
我沒必要為這個爭執那麼多。.
我真的爭贏了又怎麼樣???
面子嘛? 1200嘛? 公理嘛?
但卻換來了之後跟教練的更不愉快...
以及一個月的心中陰影...
這個代價我覺得不划算....

反正人生嘛.. 快樂就好...
學著放下自己的一些矜持...
承認世界上是有一些不公平的 不完美的..
試著讓自己接受這個事實
有時候以我們常理認為對的方式解決問題...
但是帶來的不是最好的結果...

就以這個例子..
表面上最好的結果是我不用賠錢
但是事實上最好的結果是快快樂樂的學完車..考上駕照...
那我一直爭取我沒錯.. 後者的結果就越不可能達成...

也算是種學習吧..
之前我不愉快.. 其實最大的來源是我擔心之後學車時會有陰影..
根本不是擔心我要賠錢..
當我決定要賠錢時..
我覺得我輕鬆多了... :)

blog了一整天

yeah~~ yeah~~ 總算是blog起來了..
弄雙作業系統支援弄好久
弄css弄了好久...
但是自認美工不強... 還是放棄好了..
或是改天再來用...

其實以前已經習慣在bbs上發表文章了
但是畢竟bbs有需多限制
一來只能文字 有時候不夠生動
二來東西都放在站上.. 站一掛..東西就可能不見了...

以後可能比較覺得有價值的文章就兩邊方好了
而一些比較技術性的文章主要就放這邊
也比較好收藏...

就先這樣啦
美工改天再來弄好了...:D