這次想談談Java Message Service。其實我參加了這次
2002/7/3-2002/7/4的JavaTwo研討會之後，對Java Message
Service的感觸相當深刻。幾乎有1/3以上的場次，演講者
都會提到Java Message Service，甚至在提到WebService的時候，
也有一位演講者提到將WebService底層的SOAP over HTTP
這樣的協定改成SOAP over JMS(Java Message Service)!
        其實JMS的觀念相當簡單，最基本的概念，就是希望能改善
傳統在傳遞訊息時的模式。過去要傳遞訊息的時候，我們一定
要知道server所在的位置，甚至還要知道所在的port number，
還要知道應該採取哪一種連線協定，這些準備動作，其實跟
"傳訊息"這件事情沒有什麼關係，而成了程式設計師額外的負擔，
更重要的是，由於必須配合底層機制，因此程式的移植會相當
困擾。
        JMS的想法是，把傳訊息過去的對象，使用Destination來表示，
把建立連線的方法，用ConnectionFactory來簡化。程式設計師要
作的事情，就是從JNDI(Java Naming and Directory Interface)裡面去
取得Destination物件和ConnectionFactory物件，然後再利用ConnectionFactory
物件產生所需要的Connection物件，並且以此建立連線到Destination
，然後再傳遞訊息。至於像server位址、連線協定這些困擾，由於
可以事先在ConnectionFactory中設定，所以對於專注在"訊息傳遞"
這件事的程式設計師，可以不必理會。
        除此之外，JMS支援兩種傳遞訊息的方式，一個是所謂的Point-to-Point
一個是Subscribe/Publish這種模式，前者是一對一的同步傳輸方式，而後者
則是類似廣播的非同步傳輸，這樣所提供的彈性似乎也讓軟體開發業
相當感興趣。而且，JMS還提供了selector這一類的機制，可以使用
SQL語法來在Subscribe的主題中篩選所需要的訊息，功能相當強大。
       當然，現在JMS還不算很完美，由於使用JMS必須依賴一個JMS provider
，簡單的說，就是另外需要一個JMS server，無形中增加了整合的困難，
而且每一家公司所寫的JMS provider實作規格的程度不同，多少也造成一點
困擾，而JMS相當依賴JNDI，也造成了還需要一個額外的JNDI provider，
看來，有一陣子工程師們真的得在整合上傷腦筋了。