さまざまな人々がシステムの統合をどのように解決しているかに興味があります。ここ数年、システムを統合する作業がますます増えており、この種の作業の必要性も同様に増加していると感じています。
接続される独自の小さなサービスを開発して解決するのか、それとも何らかの製品 (WebSphere、BizTalk、Muleなど) を使用するのか疑問に思っています。また、これらの種類のソリューションがどのように管理および保守されているか (セキュリティ、計測などをどのように解決するか)、ソリューションでどのような問題を経験したかなどを知ることも興味深いと思います。
うわー-わかりました-これに関する投稿を取得しますが、大きくなります。
統合は、メリットについてビジネスが十分に理解してバックアップする必要があります-運用モデルを整理します-ビジネスは統合ではなく標準化する必要がある場合があるため、これにはコストがかかる可能性があります-そのため、ほとんどのSOAは失敗します！エンタープライズアーキテクチャ：ITによるビジネス上のメリットの促進著者：Jeanne W. Ross
統合が必要な場合は、統合のタイプを決定する必要があります。
速度とパフォーマンスの指標は何ですか？
BizTalk2006を使用する複合アプリケーションを備えた.NETSOAと、基幹業務アプリケーションを備えたWebサービスがあります。複合エンドでのアプリケーションのパフォーマンス（消費）-基幹業務アプリケーションでのWebサービス（およびその実装）の速度に制限されます！結果の3秒未満のリターンが必要です-ケースのリスト。Webサービスでは達成できなかったため、最初の検索のためにデータベースに直接アクセスする必要があります。次に、ケース作成のためにWebサービスを介して。ここでは、コストへの影響と保守が問題になります。
ここでのポイントは、仕様とビジネス要件のパフォーマンス基準を確認することです。これは、実行する必要のある統合のタイプ（Webサービス（HTTP）、ファイルドロップ/ EDIなど）を確認するのに役立ちます。
機能的に統合するには、提案されたアーキテクチャの障害点を確認する必要があります。これにより、SLA/OLAの責任の連鎖が発生します。統合/障害ポイントを、自分が制御するものにラップする必要がある場合があります。
基幹業務との統合に関する同様の点は、統合する前に他の製品についてどれだけ知っておく必要があるかということです。ええ、Webサービスは契約によって設計されることになっていますが、実装はリークが多いことが多く、何が起こっているのかをよく理解する必要があります。これが、WebサービスがBizTalkとも呼ばれる統合テクノロジにリークしても、抽象化を制御できない製品である場合。
これらの2つのポイントを組み合わせると、BizTalkのような統合ハブタイプ（作成したWebサービスで基幹業務アプリケーションをラッパー化する）を入手することをお勧めします。これにより、BizTalk側から漏れのある抽象化をなくし、障害点を減らすことができます。基幹業務アプリケーションを統合ハブから切り離し、障害点をオーケストレーション内ではなく単一のソースに切り離したためです。
SOAおよびIntergationPorjectsのインストルメンテーションと診断は、達成するのが困難です。-光沢のある営業担当者に別の言い方をさせないでください。ええ、MOMEntを使用したMOMはこれを実行できます。UniCenterは何とか実行できます。
主な問題は、インターゲーションのエラー、別名げっぷが何を意味するのか、そしてそれらから回復する方法を理解することです...メッセージがスタックしてしまい、それがそのビジネスプロセスにとって何を意味するのかを理解する必要があります。アラートを受け取ることができます-プロセッサは100％Ram 100％オーケストレーションは失敗しました-しかし本当の意味はありません。このようなものを最初からソリューションに組み込む必要があります。できれば、障害点に組み込む必要があります。
統合パターンの種類とその方法も考慮する必要があります。
上記は、LIVE実装でのBizTalkを使用した.NETSOAの実際のビューです。ただし、これにはアーキテクチャ上の制限もあります。BizTalkは主にHUBおよびSPOKEパターンです。
MartinFowlerによるエンタープライズアプリケーションパターンをチェックしてください
タスクをスキンする方法はたくさんあります！
その他の考慮事項...プラットフォーム/開発者の言語など。
私たちにとって大きな要因の1つは、このようなことを始めるために必要なスキルでした。JavaとC＃を理解しているOO開発者がいましたが、主にC＃です。そこで、MSスタックを選びました。ただし、統合タイプとこれを管理する製品を選択する場合、そのテクノロジーを理解するためのスキルがさらに必要になります。しかし、これは私たち開発者にとっては正常なことですよね？経験に関係なく、多くの開発者が間違っていると、BizTalkのようなものにとらわれる可能性があります。パラダイムの大きな変化-これは、コードではなくメッセージングの変化に一部起因しています。
最後に最高のビット！
統合で直面する可能性のあるトランザクションの数は、これらすべての中で最大の要因である可能性があります。これにより、そのようなもののパターン、障害点、および許容度が決まります。
予想されるボリュームに最適なものを選択する必要があります。スケールアップおよびスケールアウトできるもの！BizTalkを選択したのは、スケールアップとスケールアウトが正しく、他のいくつかよりもよく理解できるためです。
ボリュームがない場合は、ボリュームを管理するものがないことを確認し、管理のないWebサービスからWebサービスタイプのスタイルに移行します。パフォーマンスと障害の理解をボリュームにコーディングする必要があります。
.net3を使用するWindowsプラットフォームの場合はWWF/WCFを確認してください。これは、WebサービスからWebサービスへの移行に役立ちます。BizTalkなどのオーバーヘッドなしで、これらすべての懸念事項について、実際のプラットフォームでさらに多くのことが可能になります。
お役に立てれば。
Oracleとの契約があります。そのため、OracleStackを使用しています。SOASuite10.1.3.4。主にBPELソリューションであり、単純な変換にはESBを使用しようとします。
ESBの障害処理メカニズムは不良です。BPELの場合、エラーを処理する方法はたくさんあります。私たちはSOASuiteに接続するためのJavaWebサービスの開発を試みており、主なシステムはOracleEBSシステムです。これらは、SOASuiteに付属しているデフォルトのEBSアダプタを介してレガシーシステムまたは他のEBS環境と通信します。
私たちが遭遇した問題は、EBSアダプターに関する知識が不足していることです。EBSシステムから情報を受け取ったBPELソリューションでいくつかの問題が発生しました。ソリューションの生産を準備するのは大変な仕事でした。
Webサービスの保護は大きな問題ではありません。Oracleスタックには、Oracle WebServiceManagerが付属しています。これにより、すべてのWebサービスを保護したりログに記録したりできます。
私たちが遭遇する最大の問題は、私たち自身の基準の欠如です。ビジネスにSOAソリューションも構築できると感じさせる。彼らがSOAソリューションで得られるメリットを説明することはできません。もっと早く？いいえ ！安い？地獄！より簡単な解決策？まあ、おそらく私たちが良い再利用可能なサービスを手に入れるとき...まあ、その簡単な部分には問題があります：どのアプリケーションが再利用可能なWebサービスを使用しているかをどうやって知るのですか？
このような情報を表示できるレジスターが必要です。優れたオープンソースソリューションが見つからないため、独自のレジスタを構築しようとしています。シンプルなAPEXソリューション。これもOracleスタックからのものです。;）
それで、誰かがこの種の情報を登録するための良い製品を知っていますか？
私の経験では、どのような問題に取り組んでいるかによって異なります。
私の経験では、費用対効果で BizTalk 2006 R2 に勝るものはありませんが、Microsoft テクノロジ スタックの使用を暗示しています。
Websphere MQ は大企業に販売しやすいようで、おそらくエンタープライズ レベルでより多くの使用が見られます。
どちらも優れたインストルメンテーションを提供しますが、顧客の要件に合わせてこれをカスタマイズするのは開発者の責任です。
場合によっては、オーダーメイドのソリューションが最も適切であるか、MSMQ などのテクノロジを活用してコストを抑えることがわかっています。
WebSphere、BizTalk、Mule について言及されました。それぞれに良い点と悪い点があり、非常に異なる特性を持っています。統合だけを考えているなら、Mule をお勧めします。私はそれについて非常に良い経験をしており、さらに重要なことは、アーキテクトが非侵襲的であるため、いつでも別の ESB または他の Buzz ワード クレーム ソリューションに移行できることです。Mule の優れた点の 1 つは、アプリケーション内に埋め込むことができ、最終的なアーティファクトを Webshpere、WLS、Glassfish などにデプロイできることです。ESB が埋め込まれていることを示すことさえありません。その後、この ESB はすべての統合プラミング (接続タイプとプロトコルの管理) を実行できます。一部のエンドポイントは、あなたが言及した他の統合ソリューションである可能性があります。
しばらくの間、Mule を使用しています (現在、1.4 から 2.1.x バージョンへの移行を検討しています)。
それは、ライブ コミュニティとベンダー側からの迅速な反応を備えた最高の ESB の 1 つですが、IMO バージョン 2.1.x はまだ少し未加工です (または、CXF Web を呼び出すためにそれを使用する会社にすぎません :) 詳細については、私の投稿も参照してください。http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320 )