Java EEアプリケーション設計

Question

JCoを使用してSAP BAPI/RFCを使用し、それらを他のダウンストリームシステムにWebサービスとして公開するJava EEアプリケーションを作成しています。アプリケーションは、数万人と数千人の同時ユーザーの膨大な量に拡張する必要があります。

このアプリケーションを設計して、必要な音量を満たす方法を提案したいと思います。

Answer 1

スケーラビリティを設計段階から考えていることは良いことです。 Martin AbbottとMichael Fisher（PayPal/eBayの名声）は、Webアプリケーションを拡張するためのAKF Scaleというフレームワークをレイアウトしています。主な原則は、3軸でアプリを拡大縮小することです。

1. X軸：インスタンス間で作業を簡単に分散できるサービス/データのクローニング。 Webアプリケーションの場合、これはWebサーバーを追加する機能（クラスタリング）を意味します。

2. Y軸：仕事の責任、行動またはデータの分離。例えば、あなたのケースでは、異なるサーバー上で異なるAPI呼び出しを行うことができます。

3. Z軸：顧客またはリクエスタによる作業の分離。あなたのケースでは、あなたが言うことができる、領域1からの依頼者は、サーバ1にアクセスし、領域2からリクエスタは、サーバ2にアクセスする、など

あなたがする必要がある場合は、上記のすべての3に従うことができるようにシステムを設計します。しかし、最初にデプロイするときは、3つの方法すべてを使用する必要はありません。

上記の著者が「スケーラビリティの芸術」という本をチェックアウトすることができます。 http://amzn.to/oSQGHb

Answer 2

最終回答は不可能ですが、提供された情報に基づいて、アプリケーションがステートレスなので、SAPにリクエストを転送して応答を返す限り問題はないようです。この場合、それはまったく状態を維持しません。例えば、非同期メッセージ処理、一時的なデータベースストレージまたはセッション状態管理がより複雑になります。これが当てはまり、状態を維持する必要がない場合は、アプリケーションアーキテクチャを変更することなく、アプリケーションを数十のアプリケーションサーバーに容易にスケールアウトすることができます。

私の経験では、これは必ずしもSAPの統合に関するものではなく、SAPで利用可能な製品に基づいて記入したいショッピングカートを考えてください。アプリケーションでこのカートを管理し、最後のカートをSAPに提出するだけです。さもなければ、バックエンドの内部に電子商取引アプリケーションを構築することになります。

最も重要なのは、アプリケーションのCPU使用率を減らし、「大き過ぎる」クラスタを避け、可能な限りすべての種類のI/Oを減らすことです。ネットワークI/Oを削減するための小さなSOAPメッセージ

さらに、接続プーリング用のJCO.PoolManagerを含め、JCoの上に適切な抽象レイヤーを設計することをお勧めします。 1人のテクニカルユーザだけが管理する接続プールで作業する場合は、十分に考慮された認証コンセプトが必要な場合もあります。私は、内蔵のSAPの原因応じて、必要ないくつかのカスタム翻訳にウェブ・サービス機能としてBAPI/RFCを公開を使用していない

ただ、いくつかの（ないだけでなく、構造化）の考え...