Fiorano SOA 技術紹介ノート

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

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

SOA が登場してきた初期の考え方は、サービスコンシューマとサービスプロバイダーというの 2 つの機能
によってアプリケーションを構築しようとするものでした。つまり、SOA とは、サービスコンシューマがメッセ
ージ (リクエスト) をサービスプロバイダーに送ることでバックエンドの業務ロジックを実行し、その結果をメッ
セージ (リプライ) としてフロントエンドに返す形で業務アプリケーションを構築するという方法を指していまし
た。

現在では、１対１の呼出し関係ではなく、一連の業務プロセスとして SOA を捉えることが主流となっていま
す。個々のアプリケーション (サービス) に注力するよりも、ビジネスプロセスを中心とした構築方法のほう
が、ビジネス環境の変化により迅速に対応可能な IT システムを構築できるからです。
このため、BPEL に代表されるビジネスプロセスの記述、実行言語が注目されています。

Fiorano では、BPEL などのプロセス記述とその実行エンジンによる方法は、処理負荷や障害が一極集中
する “ハブ&スポーク” の欠点を持っており、あまり効果的な方式ではないと判断しています。Fiorano SOA
プラットフォームでは、実際に実行可能なサービスコンポーネントを結び合わせてビジネスプロセスを構成
し、それを分散された拠点にまたがって敷設された ESB の上で実行する方式を採用しています。


一般的な SOA 製品は、既存製品のサーバー (アプリケーションサーバー、EAI ブローカー) 上に実装さ
れたプロセスエンジンによってサービス (アプリケーションや Web サービス) を呼出します。この形態は、
ハブ&スポークの欠点である処理負荷と障害の一極集中を招いてしまいます。
図から、現在の一般的な製品は次の特徴を持っていることが分かります。

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

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

ESB をプロトコルおよびデータスキーマの差異の吸収に利用しているが、バス形式という
ESB 本来の利点を活かしきれていない

製品として販売している既存のアプリケーションサーバーを前提としており、呼出すサービス
もアプリケーションサーバーのフレームワーク (J2EE または .NET) に規定される
フレームワークに則っていないものは、専用のアダプターやラッパーを別途付け加えることで
呼出す


多くのハブ・スポーク型のミドルウェアにおいては、アプリケーション間を行き来する各メッセージ
はハブである中央の “インテグレーションサーバ”を通らなければなりません。また、ビジネスプ
ロセスのコントロールもこのサーバー上で集中して行われます。
このため、この HUB として機能しているサーバーが、処理負荷のボトルネックとなります。
さらに、このサーバーに障害が発生すると、ビジネスプロセスのすべてが停止してしまいます。

ハブ＆スポーク形式のミドルウェアを導入する場合、処理負荷に対処するため HUBとなるサー
バーに相応の規模と処理性能が必要となり、導入コストが高くなりがちです。
負荷分散の目的でサーバーのクラスター構成を採用する場合でも、各クラスターサーバーにも
相応のパフォーマンスが求められメインテナンスも含めてコストの増大は大きなものとなります。

また、障害発生時に対処にサーバーの二重化も必要となりますが、大型サーバーの二重化はさ
らにコストの負担が大きくなります。


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

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

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

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

ビジネスプロセスは、記述言語によって定義するのではなく、実際に実行可能なソフトウェア
コンポーネントを繋ぎ合わせることで構築する


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 プラットフォームのビジネスプロセスとして機能するようになります。


このセクションでは、サービスコンポーネントによるビジネスプロセスとはどのようなものであり、ピアサーバ
ーによる ESB との関係がどのようになっているかを説明します。

 サービスコンポーネントの概念
 ピアサーバーによる ESB 上でのビジネスプロセスの実行
 ピアサーバーとコンポーネントとの関係
 管理サーバーとツール
 Fiorano SOA プラットフォームのアーキテクｊチャ (全体構成)


個々のサービスコンポーネントは、
インプットポート
アウトプットポート
エラーポート
の３種類のポートを備えています。
各コンポーネントは、インプットポートからメッセージ (データ) を受信し、必要な処理を行った後アウトプット
ポートからメッセージ (データ) を送信します。コンポーネントの処理内容によっては外部のアプリケーション
(ERP、CRM、EJB、データベースなど多種多様なものがあります) を呼出して処理を行うものもあります。こ
のようなコンポーネントでは、外部アプリケーションを呼出すためのアダプターポートを持っています。
また、コンポーネントには固有のプロパティを有しており、プロパティを設定することで稼動環境や業務処理
に合わせた変更が行えるようにもなっています。

個々のサービスコンポーネントが実行する処理ロジックは、SOA でいうところのサービスとは少し異なりま
す。SOA におけるサービスとは、ビジネスロジック (あるいは業務処理ロジック) を指します。通常、ビジネ
スロジックは既存のアプリケーション (ERP や CRM のようなパッケージアプリケーション、ユーザーが独
自開発したソフトウェア、アプリケーションサーバーに構築されたコンポジットアプリケーションなど) によっ
て既に開発され運用されています。このようなアプリケーションをコンポーネント化することには困難が伴い
ますし、運用上も非効率なものとなってしまいます。Fiorano では、本来のビジネスロジックは既存のアプリ
ケーションをそのまま変更せずに活用することが基本的な考え方です。そのため、アプリケーションを呼出
すためのアダプターポートを持ったサービスコンポーネントのタイプも用意しています。このタイプのコンポ
ーネントでは、データを受信すると外部のアプリケーションを呼出してデータを処理してもらい、アプリケー
ションからの実行結果をアウトプットポートから送信します。


コンポーネントのアウトプットポートを別のコンポーネントのインプットポートに繋げることで、ビジネスプロセ
スを構築していきます。図は、この様子を示したものです。

サービスコンポーネントという呼称を用いていますが、コンポーネントは SOA でいうところのサービスに該
当するものではありません。例えば、コンポーネントが Web サービスの変わりにあるのではなく、Web サー
ビスを呼出すコンポーネントがビジネスプロセスの一ステップとして配置されるのです。

図中に示した斜線のコンポーネントは、メディエーション機能を実行するコンポーネントです。メディエーショ
ン機能とは、ESB での基本機能とされる
データ変換 (スキーマ間のマッピング、暗号化、圧縮、データフォーマットの変換など)
ルーティング
を指します。

Fiorano SOA プラットフォームでは、数多くの種類のメディエーション用コンポーネントが用意され、さまざ
まな要求に応えられるようになっています。


Fiorano SOA プラットフォームでのビジネスプロセスは、Fiorano ESB 上でサービスコンポーネント
を実行することで実現されます。Fiorano ESB の内部は、ピアサーバーからなるメッセージングバス
の構造となっています。

ピアサーバーの peer という言葉の意味は、各サーバーの機能が同等で、サーバー間に上下関係
などの区別がないことを指しています。Peer-to-Peer のコミュニケーションとは、同等のサーバー間
でのコミュニケーションを意味し、ハブやブローカーといった何らかの制御を司る中心的なサーバーを
介しないことを意味しています。ポイントツーポイント (Point-to-Point) と混同されがちですが、これ
とは異なる意味をもったものです。
Fiorano ESB では、分散された拠点にピアサーバーを配置することで、すべての拠点をカバー
するメッセージングバスを形成します。分散配置されたピアーサーバー上で、同じように分散配置され
たコンポーネントが実行されます。
Fiorano SOA プラットフォームでは、ピアサーバーによるメッセージングバスとそこで稼動するコン
ポーネントをも含めて、仮想的ではありますが ESB と呼んでいます。この ESB は、ハブ&スポーク
の形態に内在する一極集中という問題を解消し、分散された拠点を一本のバスでカバーするという


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


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

各コンポーンネントのインプットポートおよびアウトプットポートは、JMS (Java Message Service) のプロト
コルに準拠してメッセージ (データ) を送受信します。ピアサーバーは、JMS プロバイダーとしての機能を
果たし、ストア&フォワード方式によってメッセージ (データ) の配信を保障しています。分散された他の拠点
で稼動しているコンポーネントへのメッセージ (データ) は、ピアサーバー間の通信 (TCP、HTTP) によっ
てターゲットのピアサーバーに送られ、コンポーネントには JMS によって配信されます。

外部アプリケーションを呼出す場合には、そのアプリケーションが備えているプロトコルを用います。各プロ
トコル毎に、それに適合したサービスコンポーネントが用意されています。例えば、SAP R/3 を呼出す場
合には、BAPI 用のコンポーネントもしくは IDOC 用のコンポーネントを使用します。


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

メッセージ配信性能は、次の 2つの指標で評価します。
時間当たりのメッセージ送信数
レイテンシー

ここで示したグラフは、秒あたりの送信メッセージの数を表しています。
FioranoMQ と他社の類似製品を Fiorano 社内で比較テストした結果を表したものです。


レイテンシーには遅延時間という訳があてられていますが、メッセージングにおけるレイテンシーとはメッセ
ージプロデューサが送信してからメッセージコンシューマが受信するまでの時間差を指します。業務処理
の観点からみると、この値が小さいほど、ビジネスイベントの処理がよりリアルタイムに行われることを意味し
ています。

メッセージが届くまでの時間差は、当然ながら、ネットワークや CPU の状況によってその都度異なってきま
す。あるメッセージは 50ms で、別のメッセージは 200ms で届くといったことが発生します。レイテンシーの
値を考察する場合には、数百から数万のメッセージの送信テストを実施して、次の値をチェックする必要が
あります。
平均時間 (メッセージが受信されるまでに要した平均時間)
最長時間 (メッセージが受信されるまでに要した最も長い時間)
最短時間 (メッセージ受信までの最短時間)

注目すべき値は最長時間と平均時間、および平均時間と最長/最短時間との差です。
多数のサブスクライバーが参加しているパブリッシュ/サブスクライブ (Pub/Sub) のアプリケーションでは、す
べてのサブスクライバーが同時にメッセージを受け取ることが強く求められるケースがあります。例えば、株
価情報を複数のトレーダー (サブスクライバ) に配信しているアプリケーションを考えてみてください。メッセ
ージの受信時間に差が生じると、最後のトレーダーが株価情報を受け取った時には先にメッセージを受け
取っていたトレーダーが既にアクションを起こしていたというような事態が発生する可能性が大きくなります。
メッセージを同時に受け取ることが条件となる金融トレーディングなどでは、非常に重要な要素となります。
FioranoMQ では、レイテンシーを最少のものとし、さらにすべてのサブスクライバーの受信差を最少とする
ためサブスクライバへの配信アルゴリズムを独自に開発しています。最新バージョン (FioranoMQ 2007) で
は、サブスクライバやパブリッシャの数にかかわらず、平均 1 ～ 3 ミリ秒のレイテンシーに抑えています。


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

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

通常のビジネスデータ (メッセージ) は、ピアサーバー間およびピアサーバーとコンポーネントの間でのみ
直接的に送受信され、中央のサーバーを経由しません。ハブ&スポークの中央集中型の場合だと、拠点 B
から拠点 C に送信するデータもいったん中央の拠点 A に送られます。すなわち拠点 B  拠点 A  拠
点 C という具合に配信され、拠点 A に通信が集中してしまうのと同時に通信経路も増えてしまうことになり
ます。


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

ESB サーバー (管理サーバ) には、ピアサーバーやサービスコンネーントの管理 / 監視機能やセキュリテ
ィ設定などのコンフィグ機能があります。

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

Web サービスの呼出しや、ビジネスプロセスを Web サービスとして公開するために Web Gateway サー
バーが設けられています。Web Gateway サーバーの機能は、ピアサーバーに組み込まれた jetty が担っ
ています。


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

図は、最少の構成を示しています。ロケーション A のピアサーバーがハブとして機能する “ハブ&スポーク”
の形態となりますが、サービスコンポーネントの数が少ない単純なビジネスプロセスやデータ (メッセージ)
の量や発生頻度が小さい場合には、充分に対処できます。


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

ピアサーバーは、負荷の状況によって１つづつ増減させることができます。この例では、拠点毎に 1 つの
ピアサーバーを配置していますが、負荷の大きな拠点にピアサーバーを 2 つ配置するなど柔軟な構成が
行えます。


このセクションでは、ひじょうに簡単な受注処理のプロセスを例に、Fiorano SOA プラットフォームによるビ
ジネスプロセスの構築方法を説明します。


サンプルの受注処理プロセスを、BPMN によってモデル化したものです。
処理ステップは、次のようになっています。

1. 顧客が Web ブラウザから注文書を送信する
2. HTTP リクエストとして注文書を受信し、リクエストにリプライを返す
3. 注文のあった商品の数量を在庫データベースから確認する
4. 注文書に記されているクレジットカードについてカード会社の Web サービスをよびだして審
査する
5. 注文確定の確認書をメールで送信する


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

HTTP リクエストの受信 --- HTTPReciver コンポーネント
在庫データベースの検索 --- DB コンポーネント
クレジット審査の Web サービス呼び出し --- WebServiceConsumer コンポーネント
確認書のメール送信 --- POP3 コンポーネント


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

注文書と在庫データベースのテーブルスキーマの間のデータ変換 --- XSLT マッパー
在庫の有無の確認 --- CBR (コンテンツベースルーティング) コンポーネント


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

基本的に次の手順でビジネスプロセスを構築していきます。
1. コンポーネントパレットからコンポーネントをドラッグ&ドロップし、
2. コンポーネントのプロパティ設定を行い
3. コンポーネント間のルートを設定

構築したビジネスプロセスは、このツール上の実行ボタンをクリックするだけで、ピアサーバーへのコンポ
ーネントのデプロイメントと起動が行われ、ビジネスプロセスが起動します。


リクエスト – リプライ方式は、次の特徴を持っています。
リクエスト – リプライとは、自身の処理ロジックの一部を他のシステムに依頼する方式である
依頼した処理の実行結果を受け取る
依頼先 (サービス) の呼び出しタイミングやどの条件で呼び出すかなどの制御は、サービスコ
ンシューマ側で行う
依頼先のサービスも含めて、全体が業務処理上の同じステートで実行される。
例えば注文書の受注処理の場合、呼出されるどのサービスも、またサービスの呼出し側も同じ
注文書に対する処理を行い、あるサービスだけ別の注文書の処理をおこなうということがありませ
ん。

リクエスト – リプライとは、自身の処理の一部を他のシステムに依頼 (もしくは委譲) する方式で、依頼した処
理の結果は原則として自身の側で利用するという業務処理の方法です。他のシステムの処理結果を自身
の側に持ってくるもので、いわゆるプル型の業務方式です。この考えかたは、サブルーチンコールやメソッ
ドインボケーションと同じアナロジーとして、IT 技術者にとっても理解しやすいものとなっています。Web サ
ービスや BPEL などの標準仕様もこのリクエスト – リプライに基づくものです。


現実の業務処理では、何らかの事象 (イベント) が発生するとそれに応じた業務処理が実行される、という
ケースが数多くあります。イベントには、例えば、次のようなものがあります。
倉庫に部品が入庫した
製造ラインで不良品を検出した
株価が変化した
新規顧客がデータベースに登録された
在庫数が閾値を超えた
POS 端末で特定商品の売上げを検出した

イベントドリブンとは、イベントに発生によって特定の業務処理が駆動される方式を指しています。EDA (イ
ベントドリブンアーキテクチャ) も、この方式を指している言葉です。リクエスト – リプライは未だ為されてい
ない処理の実行を依頼するものですが、イベントドリブンは、これとは違い、既に発生した事柄を他のシス
テムに通知することで発生した事柄の処理を促すものです。この観点から、リクエスト – リプライをプル型、
イベントドリブンをプッシュ型の業務処理方法と呼びます。


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

1. 倉庫には、完成した製品が不定期に運送されてきます。不特定数の製品が箱の中に梱包されており、
この箱の数もまた搬入ごとに異なります。搬入された箱は直ちにベルトコンベヤーに載せられ、製品に
貼り付けられている RFID (IC タグ) をスキャンすることで、箱の中に梱包されている製品の種類とその
数を判別します。スキャンデータは、倉庫管理システムに送られます。

2. 倉庫管理システムでは、製品毎の在庫数を管理しています。あらかじめ定められている在庫数の閾値
を超えるようであれば、本社の ERP システムに通知します。

3. ERP には、2 ヶ所の倉庫から在庫数オーバーの通知が届きます。ERP は、2 箇所の倉庫から届く在庫
数オーバーの状況を判断し、次の処理を行います。
1. 配送システムに、在庫数の少ない倉庫に搬送するよう指示を送る
2. 両倉庫とも在庫がオーバーしている場合には、工場の生産管理システムに生産計画を変更
するよう指示を送る

さて、この例題をリクエスト – リプライ方式で構築することを考えてみてください。
リクエスト – リプライで構築する場合、一番の問題は、だれが全体のフローを制御を行うかという点です。
中央に位置する ERP がその候補として考えられますが、スキャンシステムにリクエストを送る場面を
想定してみてください。製品の搬入が不定期であるため、スキャンを実施するタイミングと ERP が
リクエストを出すタイミングをシンクロさせることは不可能です。これは ERP からスキャンシステムに
ポーリングを繰り返すことである程度解消可能です。ただ、スキャン中にリクエストを受け取った場合の
処理方法など、スキャンシステムにも ERP にも複雑な処理ロジックが必要になり、処理のオーバーヘッド
も発生します。


また、別の問題として、次々と届く製品にどう対処するかという問題があります。ある一つのリクエストに対す
る処理を行っている間にもベルトコンベヤー上を製品が流れていきますので、スキャンシステムがスキャン
し損なう可能性もでてきます。倉庫管理システムに対するリクエストについても、同じことが言えます。イベン
トドリブンでは、イベントを通知した後は通知先のアプリケーションがいつどのようにイベントを処理するのか
関知しません。通知先のアプリケーションがどこまで処理したかを気にすることなく、次々とイベントを渡すこ
とができます。メッセージング機能におけるストア & フォワードメカニズムは、このイベント渡しに非常によく
マッチしたメカニズです。別の言い方すれば、メッセージングをベースとしている ESB は、イベントドリブン
の処理に適した基盤であると言えます。

この在庫管理の例題のように、関係する他のシステムが関知できないタイミングである処理が為されたり、予
期できないタイミングである事象が発生するケースでは、処理が為された時点や事象の発生を検知した時
点で他の関係するシステムに通知するイベントドリブン方式が適しています。これをリクエスト – リプライ方
式で実装すると、システムのどこかに大きな無理を強いられたものとなってしまいます。

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


下の図は、ESB を用いたイベントドリブン方式による連携を図示しています。リクエスト – リプライにおける
ESB の位置づけとは異なり、各ローケーションをまたがった 1 本の ESB が配置され、そこをイベントが流
れていきます。中央でフローを制御するものはなく、イベントはアプリケーションからアプリケーションへ送ら
れます。フロー制御は、ESB の基本機能であるメッセージングメカニズムとメディエーション機能 (ルーティ
ング機能) によって実現されます。このため、ハブ & スポークにおける一極集中の問題がなく、また、ビジネ
スプロセスの参加者はすべて非同期で動きます。あるロケーションで障害が発生した場合でも、他のロケ
ーションには影響せず、障害が発生していないロケーションでは処理を続行することができます。


資料センター
http://www.fiorano.com/jp/whitepapers/whitepapers.php

Fiorano SOA マニュアルセンター
http://www.fiorano.com/jp/whitepapers/wp_fsoa_doc.php


Fiorano SOA 技術紹介ノート

Recommended

Recommended

More Related Content

Similar to Fiorano SOA 技術紹介ノート

Similar to Fiorano SOA 技術紹介ノート (20)

Recently uploaded

Recently uploaded (9)

Fiorano SOA 技術紹介ノート