SOA に基づくシステムのための共通プラットフォームの妥当性の検証
M2011MM076 若尾明日香
指導教員：野呂昌満

1

はじめにService-Oriented Architecture[1](以下, SOA) はビジネ
ス環境の変化に対して柔軟に変更可能なシステムの開発技術である．エンタープライズ系システムに要求される非機能要求のひとつとしてビジネス環境の変化に対応する柔軟性が挙げられ，近年では多くのエンタープライズ系システムが SOA に基づいて開発されている．SOA に基づくシステムの開発では，各ベンダから提供されているミドルウェアを利用する．ミドルウェアを利用したシス
テムのアーキテクチャはミドルウェアに依存した構造となりがちであり，非機能特性を実現することが困難である．この問題を解決するために，SOA に基づくシステムのための共通プラットフォームとして，アプリケーションプラットフォームが提案されている．共通プラットフォー
ムは，ミドルウェアをラッピングすることで，アプリケーションのアーキテクチャをミドルウェア独立にすることを目的としている．共通プラットフォームでは，SOA に基づくシステムの横断的関心事を分離したアスペクト指向アーキテクチャと，可変性を表したフィーチャモデルが定義されている．
本研究の目的は，SOA に基づくシステムのための共通プラットフォームの他ドメインにおける妥当性の検証である．他ドメインにおけるシステムを事例としてケーススタディをおこなうことで，共通プラットフォームの妥当性を考察する．
定義に用いた事例とは異なるドメインにおける共通プラットフォームのアーキテクチャを考察することで，共通プラットフォームとしての一般性について考察する．事例として，現在 OJL(On the Job Learning) として開発をおこなっている医療情報システムを用いる．医療情報シ
ステムは，共通プラットフォームの主な可変要因であるOS，ミドルウェア，言語について，共通プラットフォームの定義に用いた事例における選択とは異なるので，検証に用いる事例として妥当であると考える．これら医療情報システムへの要求を整理し，要求を考慮しながら共通プラットフォームの可変性の選択をおこなう．選択した可変性を考慮した医療情報システムにおける共通プラットフォーム上において，可変性の選択が共通プラットフォームに与える影響について分析をおこなうことで，共通プラットフォームの一般性について考察する．
結果として，可変性による影響がアーキテクチャ上で吸収されていることを確認し，共通プラットフォームのアーキテクチャの妥当性を確認することができた．

2

SOA に基づくシステムのための共通プラットフォーム

SOA に基づくシステムは，各ベンダが提供するミドルウェアを利用して開発される．各ミドルウェアには想定された構造が存在することから，SOA に基づくシステムのアーキテクチャはミドルウェア依存となりがちである．
また，ミドルウェア依存なアーキテクチャとなることで，非機能特性を考慮したアーキテクチャの実現が困難となる．これを解決するために，SOA に基づくシステムのための共通プラットフォームであるアプリケーションプラットフォームが提案されている．アプリケーションプラッ
トフォームは，ミドルウェアをラッピングし，ミドルウェア独立なアプリケーションのアーキテクチャを実現する．
アプリケーションプラットフォームのアーキテクチャは，SOA に基づくシステムにおける横断的関心事を分離したアスペクト指向アーキテクチャである．また，異なるドメイン間でのアプリケーションプラットフォームの可変性が整理されており，可変性を表したフィーチャモデルが定義されている．
各ミドルウェアで提供されている API の構文や実現方法には差異がある．アプリケーションプラットフォーム
では，ミドルウェアごとに特化したアダプタを定義する
ことで，API の構文や実現方法の差異を，アダプタ内の実装で吸収することができる．アーキテクチャ上の変動部分にインタフェースを定義し，可変部品としてインタフェースを実装する各ミドルウェアに特化したアダプタを定義する．これにより，変動部分のコンポーネントの利用側は，異なるミドルウェアに対しても同一に扱うことが可能となる．

3

医療情報システムの概要

本研究では共通プラットフォームの妥当性を確認するための事例として医療情報システムを用いる．この医療情報システムは，診療所のスタッフがおこなう業務を支援することを目的としたシステムである．本システムの実現手段としてハードウェア構成とソフトウェア構成が指定されている．

3.1

医療情報システムのハードウェア構成

医療情報システムを実現するハードウェア構成を図 1 に示す．オンライン請求 Network はレセプトをオンラインで提出するときに用いるネットワークである．外部システムからの悪影響を遮断するために，オンライン請求専用の環境を用意する．本研究におけるアプリケーションプラットフォームは，院内 LAN の範囲におけるサービス連携を実現する．患者の個人情報の漏洩を防ぐなどのセキュリティを実現するために，院内にアプリケーションサーバを配置し，院内専用のネットワーク環境上でシステムを稼働させる．

図 1 医療情報システムのハードウェア構成

3.2

医療情報システムのソフトウェア構成

図 3 医療情報システムにおけるアプリケーションプラッ
本システムを実現するソフトウェア構成を図 2 に示す．
トフォームのフィーチャモデル
クライアント側のブラウザとして IE，Firefox，Safari が指定されており，これらのブラウザ上で.NET Framework[2]で提供されている WebApplicationFramework である Sil- れているフレームワークやライブラリ，機能を選択した．
verlight が動作する．サーバ側の OS は WindowsServer メッセージングの実現については，ミドルウェアで提供であり，サーバソフトとして IIS を用いる．サーバ上で されるメッセージング方法からメッセージ形式を SOAP，通信プロトコルを HTTP とする，また，クライアントがは.NET Framework が動作する．
プロバイダの処理が完了するまで待つことによる資源効率性の低下を防ぐために非同期通信とする．院内で使うことから，アクセス頻度は低く，スレッド生成による資源効率への影響はないと考える．セッション管理の実現
方法，Registry の実現方法は，時間効率性を考慮しそれぞれ選択をおこなった．Topology については，院内で使うことからアクセス頻度は低く時間効率性や資源効率性への悪影響はないと考え，ハブ型を選択した．
．また，コンポーネントの分割については，C#ではインライン展開がサポートされておらず，実現には手書きでメソッドを記述する必要があり，保守性や，信頼性を損ねる可能性
図 2 医療情報システムのソフトウェア構成があると考え，オブジェクト指向による分割を選択した．
アプリケーションプラットフォームのコンポーネントの配
4 医療情報システムにおける共通プラットフ 置については，院内にサーバを設置できる数に限りがあォームると考え，Web サービスと同一のアプリケーションサーバ上に配置することとする．MessageServiceProvider は
4.1 共通プラットフォームの可変性の選択
Server 上に配置され，クライアントのマシン上で稼働す3 章にて説明した医療情報システムへの要求を考慮し，る Silverlight アプリケーション上からリモートアクセス
共通プラットフォームにおいて定義されている可変性をされることから，WS 化をおこなう．
選択し，フィーチャモデルの枝刈りをおこなう．フィー
チャモデルの枝刈りをおこなった結果を図 3 に示す．
4.2 医療情報における共通プラットフォームのアーキテ
各可変性の選択理由を述べる．アプリケーションプラッ
クチャトフォームは院内 LAN の範囲においての実現であること選択した可変性を考慮した医療情報システムにおけるアから，アプリケーションプラットフォームの機能のうちのプリケーションプラットフォームのアーキテクチャを示す．
一つである Routing は必要ないと判断した．OS と言語に
図 4 に，医療情報システムにおけるアプリケーションプついては開発に対する要求から決定した．開発に用いるミラットフォームの静的構造を，Views and Beyond の Modドルウェア (WS Framework，DBMS，OR Mapper，シule Viewrtype で示す．色のついたモジュールは，医療情リアル化ライブラリ，Logger) は，3.2 章で示したソフト
報システムのドメインに特化したコンポーネントであるこウェア構成に基づき，.NET Framework において提供さとを表している．MessageServiceProvider インタフェー
スの実装は，WCF をラッピングするコンポーネントにより実現する．MessageComponent は，.NET Frameworkで提供されているスタブとしての役割を果たすチャネルにより実現する．ServiceConsumer は Silverlight，PrimitiveService は WCF により実現することから，それぞれのミドルウェアをラッピングするコンポーネントを用意し，MessageComponent インタフェースを実装する．

図 4 医療情報システムにおけるアプリケーションプラットフォームの静的構造
図 5 に，アプリケーションプラットフォームを実現する
各コンポーネントの配置について，Views and Beyond のAllocation Viewrtype の Deployment style で示す．Silverlight により実現された WebApplication はクライアン
トの Web ブラウザ上で稼働する．Web サービスとアプリ
ケーションプラットフォームのコンポーネントは ApplicationServer 上に配置され，クライアントの WebApplication は MessageServiceProvider にリモートアクセスをおこなう．

ウェアを用いて実現する．ミドルウェアによって前提とされているメッセージングの実現方法や用いるスタブが異なる，本研究では，ミドルウェアによって前提とされているメッセージングの実現方法や用いるスタブの違いを，アプリケーションプラットフォームのアーキテクチャ上でどのように吸収しているかについて分析することで，アプリケーションプラットフォームの妥当性を考察する．

5.1.1

ミドルウェアが前提とするメッセージングの実現
方法

医療情報システムにおいて，アプリケーションプラットフォームのコンポーネントと，Web サービスを実現するミドルウェアには WCF，クライアント側の Web アプリケーションを実現するミドルウェアには Silverlight を用いる．本節では，WCF と Siverlight が前提とするメッセージングの実現方法を説明する．
WCF が提供するメッセージングの仕組みについて説明する．Web サービスは，ABC(Address，Binding，Contract) を定義したエンドポイントを公開する．Address はサービスを配置する URL，Binding はサービスへの通信方式，Contract は提供するサービスのインタフェースを意味する．Web サービスへのアクセスは，ABC を指定しスタブとなる Channel を作成し，Channel を通してメッセージを送信することで実現することができる．Channelの作成方法は，.NET の IDE である VisualStudio から自動生成された Proxy を用いて生成する方法と，ChannelFactory を用いて手動で ABC を指定し Channel オブジェクトを生成する方法の，２通り存在する．WCF が提供するメッセージングの仕組みを図 6 に示す．

図 6 WCF が提供するメッセージングの仕組み

図 5 医療情報システムにおけるアプリケーションプラッ
トフォームの配置

5考察

5.1

共通プラットフォームの妥当性の考察

Web サービス，Web アプリケーション，アプリケーショ
ンプラットフォームを実現するコンポーネントはミドル

Silverlight により実現された Web アプリケーションへのメッセージングの仕組みについて説明する．Silverlightにより実現されたアプリケーションは，クライアントのWeb ブラウザ上で動作することを前提としており，URLを指定したアクセス方法は提供されていない．Silverlightにより実現された Web アプリケーションへのメッセー
ジングは，メッセージ送信元の情報を保持する OperationContext オブジェクトから CallbackChannel を生成し，この CallbackChannel を介すことでメッセージングをおこなう．CallbackChannel の生成時は，シリアル化やエンコーディングの指定をおこなうことはできない．また，Silverlight の Web アプリケーションにはあらかじめコールバック用のインタフェースを定義しておく必要がある．Silverlight が提供するメッセージングの仕組みを
図 7 に示す．

図 7 Silverlight が提供するメッセージングの仕組み

5.1.2

ミドルウェアの想定する構造を吸収する仕組みの分析

ponent の登録時に登録する Component に合わせて MessagingComponent を生成し，Component に保持させる．
目的のコンポーネントへのメッセージングは，Componentに保持される MessagingComponent を用いておこなう．
MessagingComponent インタフェースを実装する MessagingComponent という継承関係を用いることで，メッセージ送信側は Messaging 送信先の想定するメッセージング方法を意識せずに，メッセージングを実現することが可能となる．

前節において説明したミドルウェアの提供するメッセー
ジングの仕組みの違いは，アプリケーションプラットフォー
ムのアーキテクチャ上ではアダプタにより吸収されている．
医療情報システムのアプリケーションプラットフォーム
において，アダプタによりミドルウェアをラッピングしているのは，MessageServiceProvider の実現と MessageComponent の実現である．この２カ所について，ミドルウェアをどのようにラッピングしているかについて分析をおこなう．
MessageServiceProvider を実現する静的構造を図 8 に
図 9 MessagingComponent の静的構造示す．MessageServiceProvider インタフェースを実装する MessageServiceProvider コンポーネントは WCF を用
5.2 アプローチの妥当性についての考察いて自作する．WCF を用いたことから，受け取るメッ本研究のアプローチの妥当性について考察をおこなう．
セージ形式は SOAP である．
本研究では，OJL として開発をおこなっている医療情報システムのドメインにおいて共通プラットフォームの一般性を考察した．医療情報システムでは共通プラットフォー
ムの定義に用いた ATM 監視システムと実現に用いる OSやミドルウェアが異なり，共通プラットフォームにおける可変性の選択が異なる，本事例を用いることで，可変性のひとつであるシステムの実現に用いるミドルウェアの選択によって，共通プラットフォームのアーキテクチャへの影響はないことが確認できた．このことから，本研究に用いる事例として医療情報システムを用いたことが図 8 MessageServiceProvider を実現する静的構造妥当であったと考える．

MessagingComponent を実現する静的構造を図 9 に示
6 おわりにす．MessagingComponent インタフェースを実装する
本研究では，OJL として開発をおこなっている医療情MessagingComponent と し て ，MessagingComponent報システムを用いて，提案されている SOA に基づく共通ForWCFProxy，MessagingComponentForWCFChanプラットフォームの妥当性の検証をおこなった．医療情
nel，MessagingComponentForSilverlight の３つを定義する．MessagingComponentForWCFProxy は，WCF に 報システムに求められるハードウェアとソフトウェアのより実現されたサービスへの VisualStudio により自動生 構成要求から，共通プラットフォームで定義されている成された Proxy を保持しており，この Proxy 用いてメッ 可変性を選択し，アーキテクチャ上でどのようにミドルセージングをおこなう．MessagingComponentForWCF- ウェアをラッピングしているか分析をおこなった．結果とProxy は，WCF により実現されたサービスの URL を して，ミドルウェアの想定するメッセージングの実現方保持しており，Channel を生成することでメッセージン 法の違いにもアーキテクチャを崩すことなく対応できた
グをおこなう．MessagingComponentForSilverlight は， ことから，共通プラットフォームが妥当であるといえる．
Silverlight を用いて実現された Web アプリケーションの 参考文献
OperationContext を保持しており，OperationContext
から CallbackChannel を生成することでメッセージング [1] D. Georgakopoulos, and M. Papazoglou, ServiceOriented Computing, The MIT Press, 2009.
をおこなう．
図 4 において示した通り，WebRegisty は Component [2] Microsoft, “.NET Framework，”
http://www.microsoft.com/ja-jp/net/, 2013.と Name を関連を保持している．WebRegistry は，Com-