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应用程序设计

回答

相关问题