システムインテグレーションはどのように行うのですか？

https://stackoverflow.com/questions/12008

08-06-2019
|

質問

さまざまな人々がシステムの統合をどのように解決するかに興味があります。ここ数年、システムの統合に向けた作業がますます増えており、この種の作業のニーズも同様に増加すると感じています。

独自の小さなサービスを開発して接続することで解決するのか、それとも何らかの製品 (WebSphere、BizTalk、ラバ等）。また、この種のソリューションがどのように管理および維持されているか (セキュリティ、インストルメンテーションなどをどのように解決しているかなど)、ソリューションでどのような問題が発生したかなどを知ることも興味深いと思います。

解決

うわー、わかりました。これについては投稿されるでしょうが、大きくなるでしょう。

統合には、ビジネスによるメリットに関する十分な理解が裏付けられる必要があります。運用モデルを整理します。ビジネスではコストがかかるため、実際には統合ではなく標準化が必要になる可能性があります。これが、ほとんどの SOA が失敗する理由です。エンタープライズアーキテクチャ：著者からビジネスの利益を促進する：ジャンヌ W.ロス

統合が必要な場合は、統合のタイプを決定する必要があります。

速度とパフォーマンスの指標は何ですか?

BizTalk 2006 を使用する複合アプリケーションを備えた .NET SOA と、基幹業務アプリケーションを備えた Web サービスがあります。複合側 (消費側) でのアプリケーションのパフォーマンスは、基幹業務アプリケーションの Web サービス (およびその実装) の速度に制限されます。結果のリターンが 3 秒未満であるケースのリストが必要です。Webサービスでは達成できなかったため、最初の検索のためにデータベースに直接アクセスする必要があります。次に、Web サービス経由でケースを作成します。ここではコストとメンテナンスが問題になります。

ここでのポイントは、仕様とビジネス要件のパフォーマンス基準を確認することです。これは、Web サービス (HTTP)、ファイルドロップ/EDI など、実行する必要がある統合のタイプを検討するのに役立ちます。

機能的に統合するには、提案されたアーキテクチャの障害点を確認する必要があります。これは、SLA/OLA における責任の連鎖につながるためです。統合/障害ポイントを制御対象にラップする必要がある場合があります。

基幹業務との統合に関する同様の点は、統合する前に他の製品についてどの程度知っておく必要があるかということです。そうですね、Web サービスは契約に基づいて設計されるはずですが、実装には漏洩が多いため、何が起こっているのかをよく理解する必要があります。Web サービスがあっても抽象化を制御できない製品の場合、BizTalk とも呼ばれるインターゲーションテクノロジに漏洩します。

これら 2 つのポイントを組み合わせると、BizTalk のような統合ハブタイプを取得することをお勧めします。これは、作成した Web サービスの基幹業務アプリケーションをラッパーにするものです。これにより、BizTalk 側で漏洩する抽象化がなくなり、障害点も減らすことができます。これは、基幹業務アプリケーションを統合ハブから切り離し、オーケストレーション内ではなく単一ソースへの障害点を分離したためです。

SOA および Intergation プロジェクトのインストルメンテーションと診断を実現するのは困難です。- 優秀な営業マンに違う言い方をさせようとしないでください。そう、MOM と MOM Ent ならこれができます。UniCenter ならなんとかできます。

主な問題は、インターゲーションでのエラー、別名ゲップの意味と、それらからの回復方法を理解することです。結局メッセージが滞留してしまうので、それがビジネスプロセスにとって何を意味するのかを理解する必要があります。「プロセッサーは 100% Ram、100% オーケストレーションは失敗しました」というアラートが表示されることがありますが、実際の意味はありません。最初からこれらの要素をソリューションに組み込む必要があります。できれば障害点も組み込む必要があります。

統合パターンの種類とその実行方法も考慮する必要があります。

上記は、LIVE 実装における BizTalk を使用した .NET SOA の実際の世界観です。しかし、これはアーキテクチャ上の制限によるものでもあります。BizTalk は主に HUB と SPOKE のパターンです。

チェックアウトエンタープライズアプリケーションパターン (Martin Fowler 著)

タスクの皮を剥ぐ方法はたくさんあります。

その他の考慮事項...プラットフォーム/開発者言語など

私たちにとって大きな要因の 1 つは、これを始めるのに必要なスキルでした。Java と C# を理解している OO 開発者がいましたが、主に C# を理解していました。そこで私たちは MS スタックを選びました。しかし、これを管理するための統合タイプと製品を選択する場合、そのテクノロジーを理解するためのより多くのスキルが必要になります。でも、これは私たち開発者にとっては普通のことですよね?多くの開発者は、経験の有無に関係なく、BizTalk などで行き詰まってしまうことがあります。パラダイムの大きな変化 - 部分的には、コードではなくメッセージングの変化によるものです。

最後に最高の一品！

このすべての最大の要因は、おそらく統合で直面する可能性のあるトランザクションの数です。これは、どのようなパターン、失敗点、およびそのようなものに対する許容度をガイドするためです。

予想されるボリュームに最適な、正しいボリュームを選択する必要があります。スケールアップとスケールアウトができるもの!BizTalk を選択したのは、他のものよりも正確にスケールアップおよびスケールアウトできるため、よりよく理解できるためです。

ボリュームがない場合は、ボリュームを管理する手段がないことを検討し、管理を行わない Web サービス間タイプのスタイルを選択してください。パフォーマンスと障害の理解をコード化する必要があります。

.net 3 を搭載した Windows プラットフォームを使用している場合は、Web サービス間で役立つ WWF/WCF を検討してください。実際のプラットフォームでは、BizTalk などのオーバーヘッドなしで、これらすべての懸念事項を解決できるようになりました。

お役に立てれば。

他のヒント

私の経験では、どのような種類の問題に取り組んでいるかによって異なります。

私の経験から言えば、BizTalk 2006 R2 を上回るコストはありませんが、Microsoft テクノロジスタックの使用を意味します。

Websphere MQ は大企業に売り込みやすいようで、おそらくエンタープライズレベルでより多く使用されると思われます。

どちらも優れたインスツルメンテーションを提供しますが、これを顧客の要件に合わせてカスタマイズできるかどうかは開発者次第です。

場合によっては、オーダーメイドのソリューションが最適であるか、MSMQ などのテクノロジーを活用してコストを抑えることができることがわかりました。

WebSphere、BizTalk、Mule について言及しました。それぞれに非常に異なる特徴があり、良い点と悪い点があります。統合だけを求めている場合は、Mule をお勧めします。私はこれに関して非常に良い経験をしました。そしてさらに重要なのは、アーキテクトが非侵襲的であるため、いつでも別の ESB やその他のバズワード苦情ソリューションに移行できることです。Mule の優れた点の 1 つは、Mule をアプリケーション内に埋め込むことができ、最終的なアーティファクトを 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)

私たちはオラクル契約を結んでいます。そこで、Oracle スタックを使用します。SOA スイート 10.1.3.4。大部分は BPEL ソリューションであり、単純な変換には ESB の使用を試みます。

ESB には不適切な障害処理メカニズムがあります。BPEL ではエラーを処理する方法が数多くあります。私たちは SOA Suite に接続するための Java Web サービスの開発を試みており、主要なシステムは Oracle EBS システムです。これらは、SOA Suite に同梱されているデフォルトの EBS アダプターを介して、レガシーシステムまたは他の EBS 環境と通信します。

私たちが遭遇した問題は、EBS アダプターに関する知識が不足していることです。EBS システムから情報を受信する BPEL ソリューションでいくつかの問題が発生しました。ソリューションの作成を準備するのは大変な仕事でした。

Web サービスのセキュリティを確保することは大きな問題ではありません。Oracle スタックには、Oracle Web Service Manager が付属しています。これにより、セキュリティを確保したり、ログを記録したりすることができます。すべてのウェブサービス。

私たちが遭遇する最大の問題は、独自の基準がないことです。企業に、SOA ソリューションも構築できると感じてもらう。SOA ソリューションによって得られるメリットを説明することはできません。もっと早く？いいえ！もっと安い？いやいや！もっと簡単な解決策は？まあ、おそらく、再利用可能な優れたサービスが提供されるようになると...まあ、その簡単な部分には問題があります:どのアプリケーションが再利用可能な Web サービスを使用しているかをどのように確認すればよいでしょうか?

この種の情報を表示できるレジスターが必要です。適切なオープンソースソリューションが見つからないため、独自のレジスターを構築しようとしています。シンプルな APEX ソリューション (これも Oracle スタックからのもの)。;)

誰かこの種の情報を登録するのに良い製品を知っていますか？

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow