WSO2 に基づいてイベント処理スタックをデプロイしたいのですが、機能のインストール プロセスがわかりません。
最新の Carbon (4.0.2) をダウンロードしましたが、おそらく ESB、BRS、CEP、BAM、そしておそらくそれ以降の API Management をインストールしたいと考えています。
Turing 機能リポジトリに接続しました
2 つの質問:
ESB、CEP、および API はありますが、利用可能な機能のリストに BAM または BRS が表示されません。これらの他の部分を見るには何が必要ですか?
インストールに CEP と ESB を選択すると、「変更されたインストール」が表示され、機能が選択されていません。これは、機能バージョンの非互換性に関係していると思います
ESB を選択しただけでは、インストールは進行しているように見えますが、サーバーは再起動しません (Synapse サービスの 1 つを待機してハングします。
必要な機能/バージョンのセットを決定するプロセスが間違っているように感じます。どうすればよいですか？
カーボンは、他のコンポーネントとうまく連携するのが好きではありません。Carbon を使用して WSO2 スタックをうまく管理できたことは一度もありません。WSO2 スタックをセットアップ/展開するたびに、個別のコンポーネント構成ファイルを個別に手動で構成することになりました。通常、最初に ESB から開始し、次に CEP を追加してから BAM を追加します。
また、それらが正しい順序で開始され、構成ファイルが互いに踏みつけられないようにする必要があります (ポート オフセットが設定されていることを確認してください)。
WSO2 スタックのインスタンスを実行するために Carbon は必要ありません。単純に「インストール」(wso2X.zip ファイルを解凍) してから、サービスが開始されていることを確認し ( を呼び出しますwso2X/bin/wso2server.sh start)、一般的なセットアップはこれで終わりです。各コンポーネントが他のコンポーネントとうまく連携するように構成するには (つまり、BAM と CEP を ESB にフックする必要があることを意味します)、多くの「自動」構成や検出がないため、通常は手動ルートを使用する方が簡単です。 WSO2で。
また、WSO2 製品は、他の Apache 製品 ( Tomcat / Synapseなど) の Java 拡張機能 (本質的にはラッパー) であるため、通常、WSO2 に問題がある場合は、基盤となるシステム (Tomcat/Synapse) が適切に構成されていないことが原因であることに注意してください (ただし、 WSO2 のドキュメントには、基本システムが適切に構成されていることを確認することについて何も言及されていないため、あなた自身の責任ではありません)。
また、私の WSO2 製品のテストでは、大量のメモリを消費し (それぞれが 8GB 以上のメモリを消費するため、ESB と BAM を 1 台のマシンで実行することはできませんでした)、問題を修正するためにトラブル チケットを提出する必要がありました。 WSO2 の Java モジュールでメモリ リークが見つかりました。修正されたかどうかは不明です。
WSO2 を否定しようとしているわけではありませんが、それはかなりの作業ではなく、選択できる場合は他の「クラウド」オプションを使用した方がうまくいく可能性があることに注意してください。
編集：さまざまな「クラウド」スタック (さまざまな種類の「プラグイン」または Web サービスを使用) と、それらの相互運用性をテストする必要がありました。結局のところ、個々のスタックを完全に制御できる場合、それらはかなり相互運用可能です。それ以外の場合、私が見つけたスタックの最大の欠点は、単にドキュメントでした...プログラムにバグや問題があるかどうかは気にしません、スタックで何が起こっているかを認識できるように、可能な回避策（ある場合）とともに適切に文書化されている限り。WSO2 の製品は、提供する製品の Apache バージョン (つまり、WSO2 の ESB == Apache Synapse) の単なる Java ラッパーであったため、発生した問題は通常、Apache のドキュメントで解決されていました (特定の問題に対して彼らが持っていたものはほとんどありませんでした)。s のドキュメントには、コピー/貼り付けに関する多くの問題がありました (バージョン 1 以降のドキュメントがある場合)。通常は、WSO2 の製品よりも実際の Apache 製品をダウンロードしてインストールし、後で WSO2 の製品をインストールして有効な Apache 構成/インストールを指定する方が簡単でした。
Azureと同等のサービスの一般的な IIS/.NET 製品 (見つかったものについては、ESB/CEP/BAM/etc. の IIS/.NET 同等物) を使用して、Microsoft スタックでいくつかのテストを行いました。MS 側では、ドキュメンテーションは十分であり (そして現在、クラウドの誇大広告に賛同している人は十分にいます)、ほとんどのサービスをやや簡単に立ち上げることができました。「クラウド」サービスの「使いやすさ」の誤称 (または私の誤解) のために、私はやや簡単と言います。また、.NET ESB オファリングであるNeuron ESBという製品も見つけましたが、テスト中に何もしなかったので、それについて話すことはできません。
Amazon の製品をテストしたところ、セットアップと構成がより簡単であることがわかりました。私が AWS でテストしていたことの最大の問題は、一般的なインターネットのレイテンシーでした。
これのほとんどは個人的な推測であり、「クラウド」スペースは常に変化しており、各クラウド プラットフォームには提供できるものがわずかに異なるため、それぞれを評価することを強くお勧めします。
TLDR:クラウド空間には提供できるものがたくさんあり、長期的に達成しようとしていることを実際に検討し、各プラットフォームの提供を評価して、どれが適合するかを確認する必要があります。そうは言っても、ドキュメンテーションと内部ベンダーの相互運用性 (つまり、ベンダーの製品が互いに簡単に通信できる能力) は、製品の「再利用可能性」要因に確実に役立ちます。
Turing フィーチャー リポジトリは、Carbon カーネル 4.0.2 と互換性がありません。Carbon カーネル 4.2.0 をダウンロードして、Turing 機能リポジトリに接続できます。