そのプロジェクトで解決しようとしたことは以下のようなことでした。
- システム間連携のインターフェースの標準化
- プロトコル変換
- ソース・ターゲットシステム間でのデータマッピング
- 補償ロジックによるトランザクションの整合性
EAIのパターンは以下のようです。
- ハブ&スポーク(Hub-and-Spoke)一つのビジネスシステム(Hub)を使う親会社や持ち株会社のような考え方。このシステムはビジネスユニットが使うシステムと連携されている
- バス(Bus)メッセージバスは以下のものを組み合わせたもの
- 共通データモデル
- 共通コマンドセット
- 異種システムが共通インターフェースを介して通信することのできるメッセージング基盤
- 特に中小企業(SMBs)にとって初期投資のコストが高い。
- かなりの先行事業設計が必要だが、多くの管理者にとって想像できないものであり、投資をためらうものである。
- ほとんどのEAIプロジェクトはポイント・ツー・ポイント(P2P)連携からスタートすることが通常だが、アプリケーションが増えると早晩管理不能になる。
- P2P連携で密結合しているために維持管理が高コストで時間がかかる
- プロプライエタリな統合ブローカー実装を進化させるためのサービス料（つまり標準技術ではない、ということ）
- プロプライエタリなインターフェースを用いた静的なデータ統合はWebに展開することが難しい
最近、古いEAIベースのハブ・スポーク型EAIからSOA Suiteへの移行プロジェクトに参加していました。明らかになったのは、我々の使命がプロプライエタリなEAIシステムからSOA Suiteへ完全移行することであったとしても、SOAの原則とSOAベースのツールを使えば非常に複雑なソリューションを簡単にできるということでした。
15のシステム間を200本の連携があったものをSOA Suiteに移行する必要があったのですが、要件をシステムの振る舞いから抽出する一方で、分析フェーズにて2つの原則から浮かび上がった個別の連携パターンを見つけました。
- 使用しているプロトコルとメッセージタイプ
- ソース－ターゲット間でマッピングするシステムのデータ構造
- Inbound Reader Service: このサービスは要求されているメッセージプロトコルやメッセージタイプを使ったインバウンドメッセージを受け付ける。Oracle Service bus (OSB) はこのようなサービスを実装するには最良。OSBがこういうサービスを実装する上では最良であり、プロキシサービスの形で多くのプロトコル間で入力を読み取るよう構成することができる。
- Structural Validator Service: メッセージが構造的に問題がないかを検証するサービス。これはメッセージプロセッササービスが有効なメッセージだけを処理することを保証する。スキーマの検証やファイル構造の検証などが該当する。
- Message processor Service: オーケストレーションをベースにした、業務の妥当性と変換を実施する詳細のビジネスロジックを提供するサービス。SCAベースのSOA Suiteを使ってBPELで実装する。このプロセスを作成するためには、一般的なBPEL XPath関数を使って動的変換を実現する。
- Message Publisher: 動的なコンテンツベースルーティングを使ってメッセージをターゲットシステムに配信するサービス。SCA (Mediator)もしくはOSBを使う。
原文はこちら。
0 件のコメント:
コメントを投稿