Java EE應用程序設計

我正在編寫一個Java EE應用程序，它應該使用JCo使用SAP BAPI/RFC並將它們作爲Web服務公開給其他下游系統。應用程序需要擴展到數以萬計的同時用戶的規模。Java EE應用程序設計

我想如何設計這個應用程序，以便它可以滿足所需的體積建議。

來源

2011-09-16 Nirmal Patel

我沒有使用內置SAP的BAPI暴露/ RFC作爲網絡服務功能，由於需要應對一些自定義的翻譯。 –

最重要的是 - 您的SAP基礎架構本身可以處理負載嗎？ – home

讓我們假設SAP基礎架構將被縮放以處理以加載... –

從設計階段就開始考慮可伸縮性的好處。 Martin Abbott和Michael Fisher（PayPal/eBay成名）爲縮放網絡應用程序而設計了一個名爲AKF Scale的框架。主要原則是在3軸上縮放應用程序。

X軸：克隆服務/數據，以便可以輕鬆地跨實例分配工作。對於Web應用程序，這意味着可以添加更多Web服務器（集羣）。 Y軸：工作責任，行爲或數據的分離。因此，舉例來說，您可以在不同的服務器上使用不同的API調用。
Z軸：客戶或請求者分離工作。你的情況，你可以說，從區域1請求者將訪問服務器1，從區域2請求者將訪問服務器2等

設計您的系統，讓你可以按照所有3上面，如果你需要。但是當你最初部署時，你可能不需要使用全部三種方法。

您可以通過上述作者簽出「可伸縮性的藝術」一書。 http://amzn.to/oSQGHb

來源

2011-09-19 15:42:08

最終答案是不可能的，但根據您提供的信息，只要您的應用程序是無狀態的，這樣它就只會將請求轉發到SAP並返回響應，這似乎不成問題。在這種情況下，它根本不保持任何狀態。如果涉及到例如異步消息處理，臨時數據庫存儲或會話狀態管理，它變得更加複雜。如果這是真的，並且不需要維護狀態，則可以輕鬆地將您的應用程序擴展到幾十臺應用程序服務器，而無需更改您的應用程序體系結構。

根據我的經驗，SAP集成並不一定是這種情況，您可以根據SAP中提供的產品來考慮購買購物車。您可能希望在您的應用程序中保留此購物車，並僅向SAP提交最終購物車。否則，你最終將在後端構建一個電子商務應用程序。

最重要的是，您可以減少應用程序中的CPU利用率，以避免「太大」的羣集並儘可能減少各種I/O，例如，小SOAP消息以減少網絡I/O。此外，我建議在JCo之上設計一個適當的抽象層，包括用於連接池的JCO.PoolManager。如果您使用僅由一名技術用戶管理的連接池，則您可能還需要經過深思熟慮的授權概念。

只是一些（不是結構良好）的想法...

來源

2011-09-20 11:53:06 home

Java EE應用程序設計

回答

相關問題