前面采取的似乎是一種完美的方法。沒有CGI編程，所以在服務器啟動一個CGI程序時不會出現延遲。數據報方式似乎能產生非常快的響應。此外，一旦Java 1.1得到絕大多數人的采納，服務器端的那一部分就可完全用Java編寫（盡管利用標准輸入和輸出同一個非Java程序連接也非常容易）。
但必須注意到一些問題。其中一個特別容易忽略：由於Java應用在服務器上是連續運行的，而且會把大多數時間花在Datagram.receive()方法的等候上面，這樣便為CPU帶來了額外的開銷。至少，我在自己的服務器上便發現了這個問題。另一方面，那個服務器上不會發生其他更多的事情。而且假如我們使用一個任務更為繁重的服務器，啟動程序用“nice”（一個Unix程序，用於防止進程貪吃CPU資源）或其他等價程序即可解決問題。在許多情況下，都有必要留意象這樣的一些應用——一個堵塞的receive()完全可能造成CPU的癱瘓。
第二個問題涉及防火牆。可將防火牆理解成自己的本地網與因特網之間的一道牆（實際是一個專用機器或防火牆軟件）。它監視進出因特網的所有通信，確保這些通信不違背預設的規則。
防火牆顯得多少有些保守，要求嚴格遵守所有規則。假如沒有遵守，它們會無情地把它們拒之門外。例如，假設我們位於防火牆後面的一個網絡中，開始用Web浏覽器同因特網連接，防火牆要求所有傳輸都用可以接受的http端口同服務器連接，這個端口是80。現在來了這個Java程序片NameSender，它試圖將一個數據報傳到端口8080，這是為了越過“受保護”的端口范圍0-1024而設置的。防火牆很自然地把它想象成最壞的情況——有人使用病毒或者非法掃描端口——根本不允許傳輸的繼續進行。
只要我們的客戶建立的是與因特網的原始連接（比如通過典型的ISP接駁Internet），就不會出現此類防火牆問題。但也可能有一些重要的客戶隱藏在防火牆後，他們便不能使用我們設計的程序。
在學過有關Java的這麼多東西以後，這是一件使人相當沮喪的事情，因為看來必須放棄在服務器上使用Java，改為學習如何編寫C或Perl腳本程序。但請大家不要絕望。
一個出色方案是由Sun公司提出的。如一切按計劃進行，Web服務器最終都裝備“小服務程序”或者“服務程序片”（Servlet）。它們負責接收來自客戶的請求（經過防火牆允許的80端口）。而且不再是啟動一個CGI程序，它們會啟動小服務程序。根據Sun的設想，這些小服務程序都是用Java編寫的，而且只能在服務器上運行。運行這種小程序的服務器會自動啟動它們，令其對客戶的請求進行處理。這意味著我們的所有程序都可以用Java寫成（100%純咖啡）。這顯然是一種非常吸引人的想法：一旦習慣了Java，就不必換用其他語言在服務器上處理客戶請求。
由於只能在服務器上控制請求，所以小服務程序API沒有提供GUI功能。這對NameCollector.java來說非常適合，它本來就不需要任何圖形界面。
在本書寫作時，java.sun.com已提供了一個非常廉價的小服務程序專用服務器。Sun鼓勵其他Web服務器開發者為他們的服務器軟件產品加入對小服務程序的支持。
