fiorano soa 技術紹介ノート

30
© 200Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 1

Upload: shigeru-aoshima

Post on 19-Jul-2015

243 views

Category:

Technology


3 download

TRANSCRIPT

Page 1: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 1

Page 2: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 2

このセクションでは、Fiorano SOA プラットフォームのデザイン コンセプトを説明します。

SOA とは

Fiorano SOA プラットフォームのレイヤー コンセプト

SOA が登場してきた初期の考え方は、サービス コンシューマとサービス プロバイダーというの 2 つの機能

によってアプリケーションを構築しようとするものでした。つまり、SOA とは、サービス コンシューマがメッセ

ージ (リクエスト) をサービス プロバイダーに送ることでバックエンドの業務ロジックを実行し、その結果をメッ

セージ (リプライ) としてフロントエンドに返す形で業務アプリケーションを構築するという方法を指していまし

た。

現在では、1対1の呼出し関係ではなく、一連の業務プロセスとして SOA を捉えることが主流となっていま

す。個々のアプリケーション (サービス) に注力するよりも、ビジネス プロセスを中心とした構築方法のほう

が、ビジネス環境の変化により迅速に対応可能な IT システムを構築できるからです。

このため、BPEL に代表されるビジネス プロセスの記述、実行言語が注目されています。

Fiorano では、BPEL などのプロセス記述とその実行エンジンによる方法は、処理負荷や障害が一極集中

する “ハブ&スポーク” の欠点を持っており、あまり効果的な方式ではないと判断しています。Fiorano SOA

プラットフォームでは、実際に実行可能なサービス コンポーネントを結び合わせてビジネス プロセスを構成

し、それを分散された拠点にまたがって敷設された ESB の上で実行する方式を採用しています。

Page 3: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 3

一般的な SOA 製品は、既存製品のサーバー (アプリケーション サーバー、EAI ブローカー) 上に実装さ

れたプロセス エンジンによってサービス (アプリケーションや Web サービス) を呼出します。この形態は、

ハブ&スポークの欠点である処理負荷と障害の一極集中を招いてしまいます。

図から、現在の一般的な製品は次の特徴を持っていることが分かります。

ビジネス プロセスを中心とした SOA アプリケーションの構築が可能

ただし、中央のプロセス エンジンをハブとした集中型の形態であり、処理負荷と障害の一極

集中を招きやすい

ESB をプロトコルおよびデータ スキーマの差異の吸収に利用しているが、バス形式という

ESB 本来の利点を活かしきれていない

製品として販売している既存の アプリケーション サーバーを前提としており、呼出すサービス

も アプリケーション サーバーのフレームワーク (J2EE または .NET) に規定される

フレームワークに則っていないものは、専用のアダプターやラッパーを別途付け加えることで

呼出す

Page 4: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 4

多くのハブ・スポーク型のミドルウェアにおいては、アプリケーション間を行き来する各メッセージ

はハブである中央の “インテグレーション サーバ”を通らなければなりません。また、ビジネス プ

ロセスのコントロールもこのサーバー上で集中して行われます。

このため、この HUB として機能しているサーバーが、処理負荷のボトルネックとなります。

さらに、このサーバーに障害が発生すると、ビジネス プロセスのすべてが停止してしまいます。

ハブ&スポーク形式のミドルウェアを導入する場合、処理負荷に対処するため HUBとなるサー

バーに相応の規模と処理性能が必要となり、導入コストが高くなりがちです。

負荷分散の目的でサーバーのクラスター構成を採用する場合でも、各クラスター サーバーにも

相応のパフォーマンスが求められメインテナンスも含めてコストの増大は大きなものとなります。

また、障害発生時に対処にサーバーの二重化も必要となりますが、大型サーバーの二重化はさ

らにコストの負担が大きくなります。

Page 5: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 5

図は、Fiorano SOA プラットフォームのコンセプトを図式化したものです 。

Fiorano SOA プラットフォームのコンセプトには、以下に挙げる 3つのキー ポイントがあります。

ネットワーク的にも地理的にも分散された拠点 (企業内の部門や取引先企業) を一本の ESB

でカバーする

ビジネス プロセスは、中央のプロセス エンジンで実行するのではなく、各拠点をまたがって敷

設された ESB 上で実行する

ビジネス プロセスは、記述言語によって定義するのではなく、実際に実行可能なソフトウェア

コンポーネントを繋ぎ合わせることで構築する

Page 6: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 6

Fiorano SOA プラットフォームでは、前述のコンセプトを実行するためのアーキテクチャとして、

以下のレイヤー コンセプトをベースとしています。

1. Peer to Peer ESB

Fiorano ESB は、複数の peer サーバーを分散配置することで JMS (Java Message Service) によ

るメッセージング バスを形成します。

これによって、分散された拠点や取引先など企業内外を一本のバスでカバーすることが可能となりま

す。

Fiorano ESB には、ビジネス プロセス構築ツール、ビジネス プロセスの実行管理ツール、ピア サー

バの管理ツール、セキュリティやフェイルオーバーなど SoQ を高める機能が備わっています。

2. コンポーネントによるビジネス プロセス

ビジネス プロセスの実行は、プロセス記述をエンジンによって解釈実行する方法を採りません。BPEL

に代表されるプロセス エンジン方式は、処理負荷や障害が一驚集中する “ハブ&スポーク” 形態となり、

ESB のバス形式の利点を活かしきれないためです。

Fiorano のビジネス プロセスは、実際に稼動するソフトウェア コンポーネントを結びつけることでビジネ

ス プロセスを実現します。ビジネス プロセスに組み込まれたコンポーネントは、指定されたピア サーバ

ーにデプロイメントされ、分散されて実行されます。

3. 既存のアプリケーションや Web サービスは、ビジネス プロセス内のコンポーネントからアプリケーショ

ンが元々備えているプロトコルによって呼出されます。

こうすることで、既存アプリケーションの Web サービス化 (ラッピング) や SOA に対応させるための変

更が不要になり、Fiorano SOA プラットフォームのビジネス プロセスとして機能するようになります。

Page 7: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 7

このセクションでは、サービス コンポーネントによるビジネス プロセスとはどのようなものであり、ピア サーバ

ーによる ESB との関係がどのようになっているかを説明します。

サービス コンポーネントの概念

ピア サーバーによる ESB 上でのビジネス プロセスの実行

ピア サーバーとコンポーネントとの関係

管理サーバーとツール

Fiorano SOA プラットフォームのアーキテクjチャ (全体構成)

Page 8: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 8

個々のサービス コンポーネントは、

インプット ポート

アウトプット ポート

エラー ポート

の3種類のポートを備えています。

各コンポーネントは、インプット ポートからメッセージ (データ) を受信し、必要な処理を行った後アウトプット

ポートからメッセージ (データ) を送信します。コンポーネントの処理内容によっては外部のアプリケーション

(ERP、CRM、EJB、データベースなど多種多様なものがあります) を呼出して処理を行うものもあります。こ

のようなコンポーネントでは、外部アプリケーションを呼出すためのアダプター ポートを持っています。

また、コンポーネントには固有のプロパティを有しており、プロパティを設定することで稼動環境や業務処理

に合わせた変更が行えるようにもなっています。

個々のサービス コンポーネントが実行する処理ロジックは、SOA でいうところのサービスとは少し異なりま

す。SOA におけるサービスとは、ビジネス ロジック (あるいは業務処理ロジック) を指します。通常、ビジネ

ス ロジックは既存のアプリケーション (ERP や CRM のようなパッケージ アプリケーション、ユーザーが独

自開発したソフトウェア、アプリケーション サーバーに構築されたコンポジット アプリケーションなど) によっ

て既に開発され運用されています。このようなアプリケーションをコンポーネント化することには困難が伴い

ますし、運用上も非効率なものとなってしまいます。Fiorano では、本来のビジネス ロジックは既存のアプリ

ケーションをそのまま変更せずに活用することが基本的な考え方です。そのため、アプリケーションを呼出

すためのアダプター ポートを持ったサービス コンポーネントのタイプも用意しています。このタイプのコンポ

ーネントでは、データを受信すると外部のアプリケーションを呼出してデータを処理してもらい、アプリケー

ションからの実行結果をアウトプット ポートから送信します。

Page 9: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 9

コンポーネントのアウトプット ポートを別のコンポーネントのインプット ポートに繋げることで、ビジネス プロセ

スを構築していきます。図 は、この様子を示したものです。

サービス コンポーネントという呼称を用いていますが、コンポーネントは SOA でいうところのサービスに該

当するものではありません。例えば、コンポーネントが Web サービスの変わりにあるのではなく、Web サー

ビスを呼出すコンポーネントがビジネス プロセスの一ステップとして配置されるのです。

図中に示した斜線のコンポーネントは、メディエーション機能を実行するコンポーネントです。メディエーショ

ン機能とは、ESB での基本機能とされる

データ変換 (スキーマ間のマッピング、暗号化、圧縮、データフォーマットの変換など)

ルーティング

を指します。

Fiorano SOA プラットフォームでは、数多くの種類のメディエーション用コンポーネントが用意され、さまざ

まな要求に応えられるようになっています。

Page 10: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 10

Fiorano SOA プラットフォームでのビジネス プロセスは、Fiorano ESB 上でサービス コンポーネント

を実行することで実現されます。Fiorano ESB の内部は、ピア サーバーからなるメッセージング バス

の構造となっています。

ピア サーバーの peer という言葉の意味は、各サーバーの機能が同等で、サーバー間に上下関係

などの区別がないことを指しています。Peer-to-Peer のコミュニケーションとは、同等のサーバー間

でのコミュニケーションを意味し、ハブやブローカーといった何らかの制御を司る中心的なサーバーを

介しないことを意味しています。ポイント ツー ポイント (Point-to-Point) と混同されがちですが、これ

とは異なる意味をもったものです。

Fiorano ESB では、分散された拠点にピア サーバーを配置することで、すべての拠点をカバー

するメッセージング バスを形成します。分散配置されたピアー サーバー上で、同じように分散配置され

たコンポーネントが実行されます。

Fiorano SOA プラットフォームでは、ピア サーバーによるメッセージングバスとそこで稼動するコン

ポーネントをも含めて、仮想的ではありますが ESB と呼んでいます。この ESB は、ハブ&スポーク

の形態に内在する一極集中という問題を解消し、分散された拠点を一本のバスでカバーするという

Page 11: Fiorano SOA 技術紹介ノート

ESB 本来の利点を実現したものとなっています。

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 10

Page 12: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 11

図は、サービス コンポーネントがピア サーバー上で実行されている様子を示しています。

各コンポーンネントのインプット ポートおよびアウトプット ポートは、JMS (Java Message Service) のプロト

コルに準拠してメッセージ (データ) を送受信します。ピア サーバーは、JMS プロバイダーとしての機能を

果たし、ストア&フォワード方式によってメッセージ (データ) の配信を保障しています。分散された他の拠点

で稼動しているコンポーネントへのメッセージ (データ) は、ピア サーバー間の通信 (TCP、HTTP) によっ

てターゲットのピア サーバーに送られ、コンポーネントには JMS によって配信されます。

外部アプリケーションを呼出す場合には、そのアプリケーションが備えているプロトコルを用います。各プロ

トコル毎に、それに適合したサービス コンポーネントが用意されています。例えば、SAP R/3 を呼出す場

合には、BAPI 用のコンポーネントもしくは IDOC 用のコンポーネントを使用します。

Page 13: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 12

ピアサーバーは、メッセージ配信性能の高さで広く認められている FioranoMQ をベースに機能を追加拡

張して開発されました。

メッセージ配信性能は、次の 2つの指標で評価します。

時間当たりのメッセージ送信数

レイテンシー

ここで示したグラフは、秒あたりの送信メッセージの数を表しています。

FioranoMQ と他社の類似製品を Fiorano 社内で比較テストした結果を表したものです。

Page 14: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 13

レイテンシーには遅延時間という訳があてられていますが、メッセージングにおけるレイテンシーとはメッセ

ージ プロデューサが送信してからメッセージ コンシューマが受信するまでの時間差を指します。業務処理

の観点からみると、この値が小さいほど、ビジネス イベントの処理がよりリアルタイムに行われることを意味し

ています。

メッセージが届くまでの時間差は、当然ながら、ネットワークや CPU の状況によってその都度異なってきま

す。あるメッセージは 50ms で、別のメッセージは 200ms で届くといったことが発生します。レイテンシーの

値を考察する場合には、数百から数万のメッセージの送信テストを実施して、次の値をチェックする必要が

あります。

平均時間 (メッセージが受信されるまでに要した平均時間)

最長時間 (メッセージが受信されるまでに要した最も長い時間)

最短時間 (メッセージ受信までの最短時間)

注目すべき値は最長時間と平均時間、および平均時間と最長/最短時間との差です。

多数のサブスクライバーが参加しているパブリッシュ/サブスクライブ (Pub/Sub) のアプリケーションでは、す

べてのサブスクライバーが同時にメッセージを受け取ることが強く求められるケースがあります。例えば、株

価情報を複数のトレーダー (サブスクライバ) に配信しているアプリケーションを考えてみてください。メッセ

ージの受信時間に差が生じると、最後のトレーダーが株価情報を受け取った時には先にメッセージを受け

取っていたトレーダーが既にアクションを起こしていたというような事態が発生する可能性が大きくなります。

メッセージを同時に受け取ることが条件となる金融トレーディングなどでは、非常に重要な要素となります。

FioranoMQ では、レイテンシーを最少のものとし、さらにすべてのサブスクライバーの受信差を最少とする

ためサブスクライバへの配信アルゴリズムを独自に開発しています。最新バージョン (FioranoMQ 2007) で

は、サブスクライバやパブリッシャの数にかかわらず、平均 1 ~ 3 ミリ秒のレイテンシーに抑えています。

Page 15: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 14

分散されたピア サーバーからなる Fiorano ESB 全体を中央で監視、管理するために管理サーバー (ESB

サーバー) を設けています。

図は、Fiorano ESB の管理用サーバーとピア サーバーおよびそこに流れるデータの種類を示しています。

通常のビジネス データ (メッセージ) は、ピア サーバー間およびピア サーバーとコンポーネントの間でのみ

直接的に送受信され、中央のサーバーを経由しません。ハブ&スポークの中央集中型の場合だと、拠点 B

から拠点 C に送信するデータもいったん中央の拠点 A に送られます。すなわち 拠点 B 拠点 A 拠

点 C という具合に配信され、拠点 A に通信が集中してしまうのと同時に通信経路も増えてしまうことになり

ます。

Page 16: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 15

図は、Fiorano SOA プラットフォームのアーキテクチャ全体を図式化したものです。

ESB サーバー (管理サーバ) には、ピア サーバーやサービス コンネーントの管理 / 監視機能やセキュリテ

ィ設定などのコンフィグ機能があります。

Fiorano Studio は、コンフィグ設定やビジネス プロセスの構築を行うツールです。

Web サービスの呼出しや、ビジネス プロセスを Web サービスとして公開するために Web Gateway サー

バーが設けられています。Web Gateway サーバーの機能は、ピア サーバーに組み込まれた jetty が担っ

ています。

Page 17: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 16

Fiorano SOA プラットフォームでは、ピア サーバーを自由に増減することができます。

図は、最少の構成を示しています。ロケーション A のピア サーバーがハブとして機能する “ハブ&スポーク”

の形態となりますが、サービス コンポーネントの数が少ない単純なビジネス プロセスやデータ (メッセージ)

の量や発生頻度が小さい場合には、充分に対処できます。

Page 18: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 17

各拠点にピア サーバーを配置した例です。

ピア サーバーは、負荷の状況によって 1つづつ増減させることができます。この例では、拠点毎に 1 つの

ピア サーバーを配置していますが、負荷の大きな拠点にピア サーバーを 2 つ配置するなど柔軟な構成が

行えます。

Page 19: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 18

このセクションでは、ひじょうに簡単な受注処理のプロセスを例に、Fiorano SOA プラットフォームによるビ

ジネス プロセスの構築方法を説明します。

Page 20: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 19

サンプルの受注処理プロセスを、BPMN によってモデル化したものです。

処理ステップは、次のようになっています。

1. 顧客が Web ブラウザから注文書を送信する

2. HTTP リクエストとして注文書を受信し、リクエストにリプライを返す

3. 注文のあった商品の数量を在庫データベースから確認する

4. 注文書に記されているクレジットカードについてカード会社の Web サービスをよびだして審

査する

5. 注文確定の確認書をメールで送信する

Page 21: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 20

ビジネス プロセスのモデルから、それに見合った Fiorano のプリビルト コンポーネントをあてはめていきま

す。

HTTP リクエストの受信 --- HTTPReciver コンポーネント

在庫データベースの検索 --- DB コンポーネント

クレジット審査の Web サービス呼び出し --- WebServiceConsumer コンポーネント

確認書のメール送信 --- POP3 コンポーネント

Page 22: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 21

次に、データ変換などの必要なメディエーション機能を行うコンポーネントを補っていきます。

注文書と在庫データベースのテーブルスキーマの間のデータ変換 --- XSLT マッパー

在庫の有無の確認 --- CBR (コンテンツ ベース ルーティング) コンポーネント

Page 23: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 22

Fiorano のオーケストレーション ツールは、グラフィカルにビジネス プロセスを構築するためのツールです。

基本的に次の手順でビジネス プロセスを構築していきます。

1. コンポーネント パレットからコンポーネントをドラッグ&ドロップし、

2. コンポーネントのプロパティ設定を行い

3. コンポーネント間のルートを設定

構築したビジネス プロセスは、このツール上の実行ボタンをクリックするだけで、ピア サーバーへのコンポ

ーネントのデプロイメントと起動が行われ、ビジネス プロセスが起動します。

Page 24: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 23

Page 25: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 24

リクエスト – リプライ方式は、次の特徴を持っています。

リクエスト – リプライとは、自身の処理ロジックの一部を他のシステムに依頼する方式である

依頼した処理の実行結果を受け取る

依頼先 (サービス) の呼び出しタイミングやどの条件で呼び出すかなどの制御は、サービス コ

ンシューマ側で行う

依頼先のサービスも含めて、全体が業務処理上の同じステートで実行される。

例えば注文書の受注処理の場合、呼出されるどのサービスも、またサービスの呼出し側も同じ

注文書に対する処理を行い、あるサービスだけ 別の注文書の処理をおこなうということがありませ

ん。

リクエスト – リプライとは、自身の処理の一部を他のシステムに依頼 (もしくは委譲) する方式で、依頼した処

理の結果は原則として自身の側で利用するという業務処理の方法です。他のシステムの処理結果を自身

の側に持ってくるもので、いわゆるプル型の業務方式です。この考えかたは、サブルーチン コールやメソッ

ド インボケーションと同じアナロジーとして、IT 技術者にとっても理解しやすいものとなっています。Web サ

ービスや BPEL などの標準仕様もこのリクエスト – リプライに基づくものです。

Page 26: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 25

現実の業務処理では、何らかの事象 (イベント) が発生するとそれに応じた業務処理が実行される、という

ケースが数多くあります。イベントには、例えば、次のようなものがあります。

倉庫に部品が入庫した

製造ラインで不良品を検出した

株価が変化した

新規顧客がデータベースに登録された

在庫数が閾値を超えた

POS 端末で特定商品の売上げを検出した

イベント ドリブンとは、イベントに発生によって特定の業務処理が駆動される方式を指しています。EDA (イ

ベント ドリブン アーキテクチャ) も、この方式を指している言葉です。リクエスト – リプライは未だ為されてい

ない処理の実行を依頼するものですが、イベント ドリブンは、これとは違い、既に発生した事柄を他のシス

テムに通知することで発生した事柄の処理を促すものです。この観点から、リクエスト – リプライをプル型、

イベント ドリブンをプッシュ型の業務処理方法と呼びます。

Page 27: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 26

図のシステムは、次の処理ステップで実行されます。

1. 倉庫には、完成した製品が不定期に運送されてきます。不特定数の製品が箱の中に梱包されており、

この箱の数もまた搬入ごとに異なります。搬入された箱は直ちにベルトコンベヤーに載せられ、製品に

貼り付けられている RFID (IC タグ) をスキャンすることで、箱の中に梱包されている製品の種類とその

数を判別します。スキャン データは、倉庫管理システムに送られます。

2. 倉庫管理システムでは、製品毎の在庫数を管理しています。あらかじめ定められている在庫数の閾値

を超えるようであれば、本社の ERP システムに通知します。

3. ERP には、2 ヶ所の倉庫から在庫数オーバーの通知が届きます。ERP は、2 箇所の倉庫から届く在庫

数オーバーの状況を判断し、次の処理を行います。

1. 配送システムに、在庫数の少ない倉庫に搬送するよう指示を送る

2. 両倉庫とも在庫がオーバーしている場合には、工場の生産管理システムに生産計画を変更

するよう指示を送る

さて、この例題をリクエスト – リプライ方式で構築することを考えてみてください。

リクエスト – リプライで構築する場合、一番の問題は、だれが全体のフローを制御を行うかという点です。

中央に位置する ERP がその候補として考えられますが、スキャン システムにリクエストを送る場面を

想定してみてください。製品の搬入が不定期であるため、スキャンを実施するタイミングと ERP が

リクエストを出すタイミングをシンクロさせることは不可能です。これは ERP からスキャン システムに

ポーリングを繰り返すことである程度解消可能です。ただ、スキャン中にリクエストを受け取った場合の

処理方法など、スキャン システムにも ERP にも複雑な処理ロジックが必要になり、処理のオーバーヘッド

も発生します。

Page 28: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 27

また、別の問題として、次々と届く製品にどう対処するかという問題があります。ある一つのリクエストに対す

る処理を行っている間にもベルトコンベヤー上を製品が流れていきますので、スキャン システムがスキャン

し損なう可能性もでてきます。倉庫管理システムに対するリクエストについても、同じことが言えます。イベン

ト ドリブンでは、イベントを通知した後は通知先のアプリケーションがいつどのようにイベントを処理するのか

関知しません。通知先のアプリケーションがどこまで処理したかを気にすることなく、次々とイベントを渡すこ

とができます。メッセージング機能におけるストア & フォワード メカニズムは、このイベント渡しに非常によく

マッチしたメカニズです。別の言い方すれば、メッセージングをベースとしている ESB は、イベント ドリブン

の処理に適した基盤であると言えます。

この在庫管理の例題のように、関係する他のシステムが関知できないタイミングである処理が為されたり、予

期できないタイミングである事象が発生するケースでは、処理が為された時点や事象の発生を検知した時

点で他の関係するシステムに通知するイベント ドリブン方式が適しています。これをリクエスト – リプライ方

式で実装すると、システムのどこかに大きな無理を強いられたものとなってしまいます。

図は、この例題のイベント ドリブン方式による連携の様子を示しています。

Page 29: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 28

下の図は、ESB を用いたイベント ドリブン方式による連携を図示しています。リクエスト – リプライにおける

ESB の位置づけとは異なり、各ローケーションをまたがった 1 本の ESB が配置され、そこをイベントが流

れていきます。中央でフローを制御するものはなく、イベントはアプリケーションからアプリケーションへ送ら

れます。フロー制御は、ESB の基本機能であるメッセージング メカニズムとメディエーション機能 (ルーティ

ング機能) によって実現されます。このため、ハブ & スポークにおける一極集中の問題がなく、また、ビジネ

ス プロセスの参加者はすべて非同期で動きます。あるロケーションで障害が発生した場合でも、他のロケ

ーションには影響せず、障害が発生していないロケーションでは処理を続行することができます。

Page 30: Fiorano SOA 技術紹介ノート

© 2008 Entire Contents, Fiorano Software Kabushiki Kaisha. All rights Reserved 29

資料センター

http://www.fiorano.com/jp/whitepapers/whitepapers.php

Fiorano SOA マニュアル センター

http://www.fiorano.com/jp/whitepapers/wp_fsoa_doc.php