さまざまなシステム統合戦略を評価する中で、私はいくつかの励ましの言葉に出くわしましたが、BizTalk Server に対する不満の言葉もいくつかありました。
(開発者の観点とビジネス ユーザーの両方の観点から) BizTalk Server を使用することの長所と短所は何ですか?また、企業はオープン ソースの代替手段も検討する必要がありますか? そこにはどのような実行可能な代替案がありますか?
編集: Jitterbitは興味深い選択のようです。オープンソースであり、うまく設計されているようです。ここにいる人は、それを使った経験がありますか?
BizTalk Server の主な利点は、展開、管理、パフォーマンス、およびスケーラビリティに関する多くの「配管」を提供することです。また、Visual Studio を通じて、多くの場合比較的少ないコードでソリューションを開発するための包括的なフレームワークも提供します。
他の人が言及するフラストレーションと急激な学習曲線は、多くの場合、BizTalk を間違った目的で使用したり、BizTalk およびメッセージ指向システム全般の操作方法を誤解したりすることによって発生します。学習曲線は、ほとんどの人が示唆するほど急ではありません。基礎となる学習の本質的な部分は、手続き型のアプローチからステートレスなメッセージベースのアプローチへと考え方を変えることに実際に焦点を当てています。
よく挙げられる欠点はコストです。ステッカーの価格はかなり高いようです。ただし、独自の機能の開発とサポートに費やす金額と比較すると、これは安価です。
代替手段を検討する前に、または BizTalk サーバーを検討する前に、組織の統合へのアプローチとそれが長期的な目標であることを検討する必要があります。BizTalk Server は、BizTalk が多くのアプリケーションのアクティビティを調整するハブ アンド スポーク モデルを使用してシステムを統合する場合に最適です。
他にも統合モデルがあります。最も一般的なモデルの 1 つは分散バスです (これを「エンタープライズ サービス バス」または ESB という用語と混同しないでください)。また、BizTalk を分散バスとして機能させることもできます。より直接的なサポートを提供する代替ソリューションがあります。代替ソリューションの 1 つは、nServiceBus と呼ばれるオープン ソース ソリューションです。
BizTalk のような商用製品を使用するかどうかを検討するときは、他の製品 (オープン ソースまたは社内で開発されたもの) と比較して、メンテナンスと機能強化、および市場で必要なスキル セットの入手可能性についても検討してください。
ここで説明したポイントについて詳しく説明した記事をいくつか書きました。リンクは次のとおりです。
BizTalk での私の経験は、基本的にイライラする時間の無駄でした。
B2B データ統合 (おそらくエンタープライズ アプリケーションの中で最も困難な部分) を行う際には、非常に多くのエッジ ケースと奇妙なビジネス ロジックの微調整が必要になるため、独自のソリューションを導入する必要があります。
データ ファイルを解析して別の形式に変換するのはどれくらい難しいですか? それほど難しくありません。Biztalk のような肥大化したミドルウェア システムをその中間に挿入しようとしている場合を除きます。
BizTalk コンサルタントとして、私は Eric Z Beard に少なくとも部分的に同意する必要があります。多くの時間を費やす多くのエッジ ケースがあります。しかし、かなりの数のシナリオも非常にスムーズに処理されるため、すべて IMO に依存します。しかし、あなた (エリック) が BizTalk を肥大化したと呼ぶとき、私は反対しなければなりません! パフォーマンスと信頼性が優れており、柔軟性があり、すぐに使用できる多くの優れたアダプターが付属していることがわかりました.
BizTalk は正しく使用する必要があります。私は BizTalk 開発者であり、BizTalk の経験は非常に優れています。信頼性が高く、パフォーマンスが高く、スケーラブルで、多くの組み込みアーキテクチャ パターンと組み込みコンポーネントが含まれており、統合を簡単かつ迅速に行うことができます。セキュリティ、再試行、セカンダリ トランスポート、検証、変換などを取得できます。 BizTalk を使用すると、.NET コードを使用して簡単にカスタマイズできます。これは、基本的に苦労して獲得した統合システムであり、これらすべてを 1 つのボックスで入手できます。しかし、BizTalk を正しく実装する方法を知る必要があります。これは、実装され、しばしば正しく設計されていないソリューションに出くわしたときではありません。
しかし、BizTalk の本当の利点は、小規模なソリューションを実装してスケールアップできることです。一方、大手ベンダーの他のほとんどの統合システムは統合パック全体しか販売しないため、はるかに費用がかかります。
BizTalk は、Microsoft が提供する最も複雑なサーバーと見なされています。
したがって、BizTalk が良くないと言っている団体は、BizTalk の期間を知りません。
社内で BizTalk を評価しましたが、本当にがっかりしました。
私たちは IBM WebSphere Transformation Extender を使用しています (これにも (その他の) 問題がたくさんあります)。BizTalk のマッピング ツールは、WTX と比較すると冗談です。
グラフィカル ツールは、複雑なマッピングには実際には使用できません (繰り返しグループに数百のフィールドを持つスキーマがあります)。通常の「名と姓を名前に連結する」マッピング以上のことを行うと、グラフィカル ツールに飽きてしまいます。アプローチ (たとえば、グラフィカル マッパーの Functoid の引数はラベル付けされておらず、フィールドをこれらの引数に接続する順序が重要です)。
XSLT-Mapper は使用可能でしたが、あまり説得力がありませんでした。Microsoft の担当者でさえ、XSLT 用の XMLSpy などのツールを使用して、結果の XSL ファイルを BizTalk にロードするように言われました。
マッピングへの 3 番目のアプローチは、マッピングに C# コードを使用することです。これは、一般的なアプローチとしては受け入れられませんでした (全員に C# を教えたくありません)。
マッピング ツールに加えて、BizTalk での展開が気に入りませんでした。プロセスをデプロイするには、さまざまなツールや場所で多くの設定を行う必要があります。私たちは、BizTalk の Java Web アプリケーション用の WAR ファイルのようなメカニズムを見つけて、プロセス ソリューション全体の 1 つのアーカイブを管理者に渡して、管理者が展開できるようにしたいと考えていました。
バージョン 2004 から BizTalk を使用しており、現在はバージョン 2006 R2 と 2004 が混在しています。学習曲線は非常に厳しく、ソリューションの開発時間は必ずしも迅速ではないことがわかりました。それらは間違いなく欠点です。BizTalk が本当に優れているのは、そのフォールト トレランス、保証された配信、およびパフォーマンスです。データが失われることはありませんのでご安心ください。再試行機能とフォールト トレランスの堅牢性が組み込まれているため、一般的に言えば、システムがダウンした場合、BizTalk がそれを処理し、システムがオンラインに戻ると配信が成功します。統合シナリオで重要なダウンタイムなどの問題はすべて、BizTalk によって処理されます。
さらに、一般的に言えば、ソリューションを開発するとき、BizTalk はすべてを xml として処理することにより、ネイティブ システムの通信プロトコルとデータ形式を抽象化します。そのため、ソリューションを開発するとき、通常、それらのシステムに固有のコードを記述する必要はなく、BizTalk xml を使用します。フレームワーク。
昨年、HL7 ルーティング用にMirthという Java オープン ソース エンジンを実装しました。HL7 の目的では、BizTalk 用の HL7 アダプターを使用するのは難しいことがわかりました。経営陣は、HL7 ルーティングに Mirth を使用することを指示しました。学習曲線の点で BizTalk が劣っているところを、Mirth が補っています。ソリューションを開発する方がはるかに簡単です。笑いの問題は、保証された配信が実際にないことです。ほとんどのアダプター (hl7 を除く) には再試行機能がないため、必要に応じて独自に作成する必要があります。第二に、Mirth は、ダウンすると日付を失う可能性があります。非常に使いやすいと言えますが (ドキュメントはありません)、エンタープライズ ソリューションとは言い難いでしょう。ジッタービットを調べてみますそれは他の誰かによって言及されました。
私たちは数年間 BizTalk を使用していましたが、より柔軟な独自のカスタム フレームワークを使用することを断念しました。
Sun (現在は Oracle) のOpenESBフレームワークが常に存在します。一般的に言えば、Biztalk の小型で軽量なバージョンですが、ほぼすべて同じ機能を備えています。
ただし、それを使用してより多くのコードを記述できます。
そのオープンソースも同様です。
私の BizTalk と B2B 統合の経験によると、ほとんどの組織は真にスキーマ ファーストの設計を行っていないか、その点について XML 標準を完全に理解していません。ほとんどの人は、オブジェクトを織り込み、意味のあるスキーマに具現化することを望んでいます。エンタープライズ環境では、これは逆です。
BizTalk には学習曲線がありますが、一度習得すると、耐久性、パフォーマンス、真のスケーラビリティ、および拡張性が得られます。ただし、ほとんどの人が言っているように、それが自分のニーズを満たしていることを確認し、ニーズを BizTalk にゆがめることをお勧めします。
過去に、BizTalk 2004 から 2009 まで、および webMethods という別の製品を使用してきました。
OSS スペースでは (個人的には BizTalk の代替として使用したことはありませんが、これは逸話です)、OpenMQなどの Java/J2EE メッセージング エンジンの 1 つを使用できます(これは Sun エンタープライズのバッジが付け直され、サポートされていません)。これに加えてオーケストレーション/コレオグラフィー (つまり、SOA/ESB ピース) が必要な場合は、 Apache Muleのようなものを調べることができます。
BizTalkよりも安価なソリューションを探しているときに、Apatar（URLを投稿できませんが、Googleはそれを見つけました）に出くわしました。私はまだこれを試していません。
私の最後の会社は、BizTalkが複雑すぎて隆起しているという多くの問題を抱えていましたが、これは主にコンサルタントが行った実装にかかっていると思わざるを得ません。
私は JitterBit を直接使用した経験はありませんが、同僚から非常に良いことを聞いています。