日時：2006年 6月 1日(木) 18:30 から
場所：慶應義塾大学理工学部（矢上キャンパス）14棟-201教室（セミナールーム１）
話者：
名倉 正剛 (慶應義塾大学大学院理工学研究科)
話題：
異種分散コンポーネントの統合を実現するシステム
概要：
近年，EAI (Enterprise Application Integration) と呼ばれるアプリケーショ
ン開発アプローチによって，既存の分散コンポーネントを組み合わせて，新し
いアプリケーションを開発することができる．
しかし，色々なベンダによって開発された様々なコンポーネントを組み合わ
せる場合には，それぞれのコンポーネントが独自に開発されていることに起因
して，(1) 組み合わせるコンポーネント間の異種性の問題が発生する．また，
組み合わせるコンポーネントが分散していることに起因して，(2) 開発したア
プリケーションプログラムを運用する際の信頼性が低下する．
本発表では，これらの問題を解決し，異種分散コンポーネントの統合を実現
する 2 つのシステムを紹介する．
まず，ワークフロー情報を用いて異種分散コンポーネントを利用するアプリ
ケーションの開発を支援する EAI システムを設計し，実装した．このシステ
ムでは，同じ機能を持つ複数の異種分散コンポーネントを指定して開発する．
開発したアプリケーションは，呼び出そうとするコンポーネントが利用できな
かった時に，同じ機能を持つ他のコンポーネントに自動的に処理を切り替える．
EAI を利用した開発アプローチでは，一般的にアプリケーションの開発時に
コンポーネントの組み合わせが決定する．従って，この開発支援システムを利
用して開発したアプリケーションを実行中には，指定されたコンポーネントが
利用できず，処理が切り替えられない可能性もある．そこで次に，このような
開発アプローチによらずに解決する方法を考えた．そして異種分散コンポーネ
ントの存在するサーバやそれを利用するクライアントをネットワークに接続す
るだけで，利用時にそれら自動的に連携する，いわゆる "Plug and Play" が
できる環境を提案し，それを実現するシステムを実装した．
出席者：14名
伊知地宏（ラムダ数教研）、田中哲朗（東京大）、樋口直志（NEC）、石畑清（明治大）、 飯島正、篠沢佳久、竹前嘉修、佐藤琢紀（慶應大）、東達軌（東京理科大）、 千葉雄司（日立製作所）、古賀康則、齋藤正伸（IIJ）、寺田実、丸山一貴（電気通信大）
Q1. 「コンポーネントの配置」とはどういうことを指しているか?
A1. コンポーネントをサーバ上の公開できるディレクトリにコピーして，
外部から利用できるように設定を変更することを指している．
Web Service で言うところの，deploy に相当する動作．
Q2. Web Service等は標準化が進んでおり，コンポーネントの異種性の吸収は
標準化が達成されるまでの間に合わせにすぎないのではないか?
標準化はうまくいかないという考えの下に研究を行っている?
A2. 指摘の通りである．
CORBA → EJB → Web Service といろいろな技術が提案されてきたように，
これからも別の技術で標準化が進むのかも知れない．
また，仮に Web Service で統一されたとしても，仕様のバージョン間で互換
が取れていなかったり，実装間で interoperability が保証できなかった
りすることも考えられる．それらも本提案での「異種」と考えることがで
きる．
(Q3〜Q5:「ワークフロー情報を用いて異種分散コンポーネントを利用するアプ
リケーションの開発を支援する EAI システム」について)
Q3. UMLアクティビティ図に統一してしまうことで，記述能力に制限ができて
しまうのでは?
例外処理や補償処理を BPEL で表すことができるのに，UML アクティビティ
図の記述能力制限を受けてしまうのではないか?
A3. 例外処理の記述を，コードとして記述することができるようなツールにし
ても良いが，それを開発者が記述することは大変なので，直接アクティビ
ティ図から指定することで開発できるような方法を提案した．
Q4. 呼び出しができない時点で切り替えているが，単に今負荷が高いだけであ
るとか，そういう場合も考慮できないのか?
A4. 呼び出しができない理由を問い合わせるような方法は考えていない．
Q5. 既存の EAI システムで記述するワークフローど，提案したシステムで記
述したものとは，変わってしまうのか?
A5. 既存のものだと，コンポーネント技術によってそれぞれ EAI ツールがで
きていて，それぞれに別々の記述方法を使っているので，習熟が用意では
なかった．提案した方法では，ワークフローの記述方法を統一している．
図の記法自体は若干異なるが，本質的に表しているワークフローに関する
情報は，同じである．
(Q6〜Q13: 「異種分散コンポーネントの Plug and Play を実現するシステム」
について)
Q6. マルチキャストはブロードキャストとどう違うのか?
A6. マルチキャストとは IP マルチキャストのことを指す．
ネットワークの構成が，L3 レベルでマルチキャストを理解できる機器で構
成されていれば意味があるが，普通には結果的にブロードキャストと同じ
ことになる．
Q7. マルチキャストの範囲はどこまでか?
A7. 同一ネットワークの範囲内
Q8. 「アプリケーション開発時にコンポーネントの組み合わせが決定する」と
いう前提はどうなのか? 無理にそう仮定する必要があるのか?
A8. 現状では開発されたコンポーネントを組み合わせる場合は，それらを組み
合わせるアプリケーションの開発 (Q9 を参照) は，利用者がアプリケーショ
ンを利用する時点ではなく，アプリケーションを組み合わせようとする段
階でやっている．無理に仮定をしたのではなく，組み合わせたアプリケー
ションを作る段階で，利用するコンポーネントが自ずと決定してしまうこ
とを，前提として挙げた．(Q9 で「アプリケーションの開発」についての
質問があるが，「開発」の言葉の捉え方に相違があったために，Q8 の疑問
が生じた)
Q9. 「アプリケーションの開発」とは既存のコンポーネント群のセットアップ
を指しているのか? 組み合わせることを指しているのか?
A9. 既存のコンポーネントのどれとどれを組み合わせるかということを想定し
てコードを記述することを指している．
Q10. DNSルートキャッシュのような機構を用意する方法でも探索は実現できる
のでは?
A10. そのような方法でももちろん可能だが，クライアントはルートサーバの
場所を予め知っている必要がある．インターネットに接続できるような環
境ならば，唯一のルートサーバさえ予め設定されていれば良いが，そうで
はない環境の場合は，ルートサーバに類するものを用意して，その存在を
クライアントに通知する必要がある．
Q11. 最初にレジストリさえ発見できればコンポーネントも発見できるのでは?
レジストリを動的に更新すれば同じことでは?
A11. その方法も検討しているが，最初にレジストリを発見することを解決す
る必要がある．また，レジストリが存在しない場合も考慮に入れる必要も
ある．結局どちらの場合でも探索の考え方が必要になる．
Q12. 次には多分セキュリティの問題が出てくるが，DNSルートキャッシュをグ
ローバルネットワークにおいてそれを利用するように設定して，そこまで
セキュアなルートができればそれで良いのでは?
A12. 常に同じネットワークに接続して，同じコンポーネントを利用するよう
なものならばそれでも良いが，携帯端末のような移動するようなものの場
合は，常に同じものを使うわけではないので，探す必要がある．
探さなくてもすむものの場合は，1 つ目に提案した開発支援環境のような
EAI ツールで，予め指定して開発をすれば良い．
そうではないような場合に，2 つ目の提案の Plug and Play 環境を利用す
る．
Q13. コンポーネントを探す際のセマンティクスはどうやって共有しているのか?
A13. サービス名をつけて，両方で把握しあっていることを前提としている．
そのサービス名に対して，文字列マッチングをしている．
オントロジを使うことも考えられるが，その場合は完全に一致しないもの
も探索してしまう可能性が出てくるので，完全な Plug and Play の自動化
ができなくなってしまうので，今回は想定していない．