1.用戶注冊：用戶填寫基本信息，系統自動生成TmiTalker號碼，然後用戶可以利用此號登錄
2.用戶登錄：使用注冊的號碼登錄
3.加好友：用戶可以查找注冊的用戶，並且加為好友
4.即時聊天：收到消息後好友的名字將以橙色顯示。
5.離線留言：如果好友不在線，可以留言，好友上線後就會看到留言；
程序主要實現了服務器和客戶端兩個部分。
服務器：服務的啟動；列出在線用戶以及所有注冊用戶；修改偵聽端口；
客戶端：
登錄界面（注意登錄時設置正確的服務器地址與端口）
注冊界面
程序主界面，收到新消息後好友的名字以橙色顯示
添加好友界面
注：個人感覺，像這種即時聊天類的程序，用RMI實現，不是很合適，畢竟是建立在一個類似於中間件之上，相對於用socket實現，增加了一層，使設計簡單了但是效率應該不高。還是直接用socket實現效率高點吧，當然Java也應該被直接排除……感覺rmi比較適合於面向服務的系統，和web service有點類似，但是web service又在rmi上加了一層，效率可想而知……
最近正在看TCP/IP，網絡協議的設計也是采用了分層，從物理層一直到應用層，一層層的包裝，應用層的數據是實際有用的數據，然後經過各個層之後，每層都在上一層數據的上面加一個首部，當然這是為了完成該層的功能，直到最後，經過實際的物理網絡，把帶有各個層首部的數據發送出去，然後到目的地之後就是一層層的脫去首部，得到應用程序實際需要的數據。
再看看應用之上的軟件體系結構，RMI（或者RPC）按照一定的格式調用遠程方法，但是到底層，還是要把各種形式調用以數據包發送到目標應用程序（服務器），然後服務器解析數據包，得到遠程對象和方法後調用之，之後把結果以某種形式格式化，發送回調用方。可見，RMI也可以看做是一種協議，它建立在網絡協議之上層，當然具體到實現，它可以看做一種中間件，因為它提供了要實現遠程調用需要的各種基礎服務。協議，對於通信雙方，本身就是一種約定，大家按照一種規定好的格式進行一系列的交互。而之後的web service，它利用soap，采用了xml對數據進行格式（因為XML的自解釋性？），底層好像也是采用RMI（或者RPC）來完成交互，當然，歸根到底，最後還是采用socket進行數據傳輸。
這使我不禁想起算法老師說的一句話，軟件工程（或者軟件體系架構）就是純粹的以浪費程序的運行效率來解決大規模的軟件系統的復雜性（大意是這樣子，原話記不清了）。現在想想，此話深有道理。這倒不是說軟件工程不好，對於大型的系統，軟件工程對於軟件的成功還是很重要的，但是同時也提醒我們，不能因為軟件工程給我們帶來的方便而濫用之，畢竟這是以犧牲效率為代價的。養成寫高效的代碼的習慣還是很重要的。
呵呵，好像跑題了，最後奉上源代碼，希望大家多提意見……
