需要一個應用程序服務器 - Java

我來自客戶端編程背景（主要是C++）。但是，我現在偶爾需要進入一些Java的小型服務器端項目&，因此需要來自有經驗的服務器端人員的一些建議。我對應用程序服務器並不十分了解。需要一個應用程序服務器 - Java

是否有任何拇指規則或注意事項來決定程序何時需要應用程序服務器（如GlassFish或JBoss）？

我有兩臺使用Java編寫的服務器，都運行在專用機器上。一臺服務器在沒有任何App Server的情況下在Tomcat上運行第二臺服務器在應用程序服務器（Glassfish）上運行。

我需要寫一個相當簡單的程序，坐在中間。這是程序將要做的事

在套接字上偵聽。當連接來自第一臺服務器時，它會創建一個線程來接受連接&繼續收聽。
線程從第一個服務器獲取少量數據（比如100-200字節），數據格式很小&通過web服務調用將它傳遞給第二個服務器。它會返回webservice調用的返回值，並基於它進行一些處理 - 可能大約有10-20行代碼 - 這不是一些主要的處理 - 只是在不同的（第3）服務器上調用一些web服務調用。在此之後，它將一些數據返回給第一臺服務器 - 再次不多 - 可能是50個字節。
我的程序不是web服務。它僅以特定格式從第一臺服務器獲取消息&根據從第一臺服務器接收到的數據向第二臺服務器發出web服務調用。在某些情況下，您可以用這種方式思考它 - 它充當第一臺服務器的代理，以便將Web服務調用到第二臺服務器。

所有主要的工作是由第一臺服務器運行在Tomcat服務器上運行& GlassFish上運行的Web服務應用程序來完成。這兩個都是測試良好的程序。我想寫的中間程序非常簡單&我可以在半天內完成。但是，我擔心的是它是否能夠承受負擔。

有什麼樣的規則/考慮因素可以確定我是否可以將此Java程序作爲常規Windows服務運行，或者是否需要Glassfish或任何其他應用程序服務器之類的東西。

我應該考慮每分鐘/小時進入的連接數量嗎？我將爲每個連接分配一個線程，但線程本身不會很長壽。我應該在什麼樣的連接數閾值下考慮應用服務器？還有其他的考慮嗎？如果可能的話，我寧願避免使用Application Server。

是否在App Server下運行它只是一個問題 - 我還有什麼問題嗎？

來源

2012-12-10 user93353

不確定這是否適合您的用例，但此類服務連接的一種標準方式是通過使用JMS隊列的發佈 - 訂閱模型。每個服務都有一個消息隊列。您會在隊列中堆積消息，處理消息並將結果發佈到其他服務的隊列中。 –

@Singularity - 第一臺服務器以特定格式發送消息，並期望以特定格式回覆。我將研究JMS隊列，但我認爲JMS隊列有自己的格式。 – user93353

是JMS使用XML（Soap），但CDATA標籤允許將任何原始數據放入XML中。 –

應用程序服務器並不神奇，因爲它們不會創造更好的性能。事實上，對於一個簡單的應用程序，如您所概述的，應用程序服務器可能會產生相反的效果，因爲大多數應用程序服務器引入的額外開銷。

應用程序服務器提供基礎架構組件，用於企業級開發的實用模式以及標準規範的實現。它們主要用於組織更大規模的開發工作，併爲較大數量的相對較短壽命的連接設置規模。也就是說，如果您已熟悉它們提供的基礎架構，則可以使用輕量級服務器（如Tomcat或Jetty）。特別是，他們會爲您提供入站HTTP連接處理。

雖然我認爲根據你的問題描述，你最好使用像Apache HttpComponents這樣的庫來編寫獨立的java服務來處理HTTP和WebService客戶端功能。目前還不清楚您需要多少額外的工作來處理入站連接。如果插座簡單，那麼自己編程就很容易。

您的描述關於需要同時支持多少個連接是模糊的（而且都是相對的）。如果每個連接需要一個線程並且希望支持數百個連接，那麼我會建議使用線程連接池來實現連接處理，確保在耗盡服務器功能之前阻止新連接。如果要走這條路線，請查看Java 5+ ExecutorService和相關的類。

我懷疑如果您的需求很簡單，應用程序服務器將提供很多好處。

來源

2012-12-10 17:51:11 kaliatech

謝謝你的回覆。幾個澄清 - 我正在使用Axis來進行web服務調用。它滿足了我的所有需求。另外我需要每個連接1個線程 - 將查看ExecutorService。當你詢問「需要支持數百個連接」時 - 我假設你正在談論併發，對吧？ – user93353

關於負載，它確實取決於您的方案。如果線程在等待IO響應時主要被阻塞，那麼很容易實現100個併發連接。如果您的線程始終處於活動狀態，那麼100個_active_線程可能需要嚴重的硬件。但是如果你的線程壽命短並且新的conten可以等待很短的時間，那麼你可以有一個最多50個線程的池，但是有1000個連接的隊列可以被服務。「併發連接」的定義可能非常棘手。 – kaliatech

評估任何工具時的基本規則也應適用於此：它是否會使我的工作更輕鬆。

所以問題是：應用程序服務器提供的功能是否滿足我的用例和限制將不會與我接壤。

基礎上的用戶情況說明：

的JavaEE應用服務器提供的Servlet抽象來輕鬆管理HTTP請求（在理論上其他類型的請求，可以實現通過您將需要做你的自我添加新的東西來實現應用服務器）。它還將通過Jax-WS或Jax-RS抽象提供Web服務端點創建。

這些抽象的代價是應用程序服務器將管理線程。大多數實現將使用線程池進行HTTP連接，因此每個請求無需創建線程成本。

此外全JavaEE將爲您提供簡單的聲明式交易和安全（EJB），與JMS和其他人的遠程消息。

它取決於您平衡提供的抽象的附加價值和它們的成本（更少的控制，在大多數情況下，更少的控制會導致更好的行爲，因爲已經制定了Java標準來匹配大多數用例，然後執行比一般的程序員代碼好...）。

因此，在您的情況下，您應該查看您所需的功能，使用最簡單的方法（快速）來滿足您的功能，並使POC進行一些負載測試。

順便說Tomcat的是應用服務器，它只是沒有實現所有的JavaEE的一部分，它只是實現了basique網絡相關的功能（servlet中，但默認情況下沒有WS或WS REST類型，但這可以很容易地由libs添加）。新的Jboss和Glassfich提供了比Tomcat更大的功能（在部署時易於加載），具有與Tomcat類似的大小和性能。

來源

2012-12-10 18:00:57 Kazaag

我的程序不是一個web服務。它只是監聽一個套接字。它期望以特定格式（而不是SOAP或任何其他格式）的消息通過進行web服務調用轉發到web服務。我也做了一些處理。 – user93353

我認爲性能問題會受到您的網絡拓撲和機器硬件的影響，而不是您選擇的應用服務器。一些應用服務器（如JBoss）提供了用於創建和管理羣集的管理工具，但所有應用服務器都可以使用正確的工具進行類似的設置。也就是說，我認爲你會得到一個嵌入式servlet容器，如jetty或grizzly。這將爲您提供應用服務器提供的配置和可移植性優勢，而無需額外負擔您不太需要的EE兼容性任務，並且可以輕鬆設置您的開發配置。

來源

2012-12-10 18:14:28

你的意思是「配置和便攜性」的好處。還需要付出多少努力才能像我描述的那樣採用簡單的程序並將其修改爲在'jetty'或'grizzly'下運行。 – user93353

配置的一個很好的例子是能夠通過Jetty xml文件管理線程池設置，例如：http://docs.codehaus.org/display/JETTY/Newbie+Guide+to+Jetty#NewbieGuidetoJetty-ThreadPooloptional –

In修改現有應用程序以使用它的條款，檢查關於嵌入Jetty的文檔，我想你會發現創建一個類來啓動服務器並添加上下文非常簡單：http://wiki.eclipse.org/碼頭/教程/ Embedding_Jetty –

需要一個應用程序服務器 - Java

回答

相關問題