（1）アプリケーションインテグレーション技術
現在の社会は、膨大な既存アプリケーションを抱えている。しかも、その多くの既存アプリケーションは、脆弱であり、スパゲティ状態である。SDPが目指すものが実現したとしても、これらの既存アプリケーションを即座に捨てるわけにはいかない。SDPが実現する新しいソフトウェアアーキテクチャを核としたインフラ上に既存アプリケーションを追加・統合し、段階的に消滅させていかねばならない。このために、アプリケーションインテグレーション技術が必要となってくる。
アプリケーションインテグレーション技術は、図3.7に示す5つのレベルがある。
| 統合ミドルウェア |
ビジネスプロセスマネジャ |
| インテグレーションブローカ |
| スーパーサービス |
| ゲートウェイ |
| 基本ミドルウェア |
データ管理 |
通信管理 |
プラットフォーム管理 |
図3.7 アプリケーションインテグレーション技術の階層
基本ミドルウェアのデータ管理は、リモートのファイル、DBを論理的にローカルにあるかのように扱う。たとえば、JDBC、ODBC、NFS、MicrosoftのWindowsなどである。通信管理は、RPC、メッセージ指向ミドルウェアのように、リモートとの通信を同じシステム上の通信のようにする。プラットフォーム管理は、通信管理のスーパーセットで、サーバとサーバ間、サーバとクライアント間のプログラムローディング、メモリ管理等のリソース管理を同一のシステム上の管理のように行う。
統合ミドルウェアのゲートウェイは、異なったDBシステム、通信システム、プロットホームを共通のインタフェースで扱えるようにする。スーパーサービスは、異なった複数のOS、サーバにまたがって、ディレクトリ、セキュリティ、トランズアクションマネジャといった共通の機能を提供する。インテグレーションブローカは、二つのアプリケーション間のメッセージの内容を変換したり、コンテンツの内容に応じて宛先を決定したりして、アプリケーションの統合をサポートする。ビジネスプロセスマネジャは、アプリケーション統合をマルチステップまで広げて自動化し、ビジネスプロセスのワークフローをサポートする。
繋ぎ方として、メッセージバス方式とハブ方式がある。統合のパターンには、システムが物理的も論理的にも独立で一方向のデータ同期の方式と、システムが物理的には独立であるが、論理的にはワークフロー的に複数のプロセスが一方向に繋がるマルチプロセス方式と、システムが物理的にも論理的にも繋がり、双方向のデータの同期を取り遅延なく整合性をとる複合アプリ方式とがある。今後は、複合アプリ方式が重要となっていく。
繋ぐ時の通信のモデルには、対話型、リクエスト・リプライ型、メッセージ・パッシング型、ストア＆フォワード型、パブリッシュ・サブスクライブ型の5つがある。
ストア＆フォワード型は、キューを持つことにより、メッセージの完全性、配信保証をし、パブリッシュ・サブスクライブ型は、送信者は宛先を指定しなく、受信者が受信したい情報を論理的に指定する方式で、送受信者の相互作用を最も柔軟にできる。この2つの通信型のサポートによって、イベントベースのビジネスプロセス統合を実現できることに特徴がある。例えば、新しい注文を受けると、販売報告システム、製造システム、請求伝票システムへ即時に通知され、ビジネスプロセスの統合が遅延なくデータの同期を取って実現できる。
以上のようなアプリケーションインテグレーション技術で既存アプリケーションを統合していくには、脆弱でスパゲティ状態の既存アプリケーションを標準化、部品化、抽象化、再構築するのを自動化、支援するツールとして、コンバータ、アダプタ、ラッパー、リバースエンジニアリング等で構成されるアプロケーションインテグレーション環境が必要となってくる。
（2）CBS（COTS−Based Systems Initiative）
CBS[25]は、カネーギーメロン大のSEI（Software Engineering Institute）で研究開発中のプロジェクトで、商業的ソフトウェア・コンポーネント（COTS：Commercial Off The Shelf）、既存ソフトウェア・コンポーネントを用いて、システムを構築するための開発手法に取り組んでいる。CBSは、従来のシステムコンテンツ（要求、価格、スケジュール、OS・サポート環境等のシステムに求められる性格）の選択、アーキテクチャと設計、実装の工程を順次に行うウォータ・フォールモデルではなく、システムコンテンツ、アーキテクチと設計、市場の於ける製品の能力を同時に検討するアプローチを目指している。
図3.8 CBSの開発手法のアプローチ
COTS、既存コンポーネントからシステムを構築するには、以下のような質問に答えて行かねばならない。
このような難しい質問に答えるためにCBSは次の3つの領域をキーポイントとしている。
1）製品と技術の評価の実施
製品と技術の評価に際しては、直接的なシステム要求に応えると同時に、その技術、ソフトウェアの進化が途切れることがないかを考慮しなければならない。そのため、候補となる製品、技術は、関係する製品、技術との関連のなかで評価されなければならない。したがって、問題領域での実験に着手して、クリティカルな質問に答え、COTSの製品、技術の適用に対するガイドラインを作成していくようにしなければならない。
2）入手とマネジメントの実施
CBSでは、システムの開発者という立場からシステムの消費者、インテグレータという立場へと変化し、コンポーネントのライセンシング、知的財産権の交渉、開発・メンテナンスコストの見積もり、スケジュールの予測、人材の管理、リスクの同定と軽減といったことに対する戦略が必要となる。さらに、システムに柔軟性を持たせるための知識、いろいろな創造的なソルーションを可能とするドキュメントも要求される。このために、CBSは、CBSをうまく活用した組織の実践例の情報、あるいは、CBSにおける入手の失敗を避ける情報を提供し、CBSに対する要求の作成、リスクの同定等、CBSプロセスを支援する。
3）設計とソフトウェア・エンジニアリングの実施
CBSシステムでは、コンポーネントをインテグレートするために「つぎはぎのコード」が使われ、このため、可読性、発展性、信頼性に欠ける傾向がある。これを克服するため、CBSコンポーネントの人工的な見せかけを記述する参照モデルを開発、提供している。
CBSのシステムエンジニアリングでは、図3.9に示すようなプロセスを経てシステム開発が行われる。最初はコンポーネントの多くのプロパティは未知であり、ブラックボックスとして扱われ、システマティクな調査によって、プロパティが明らかにされる。プロパティが明らかにされると、他のコンポーネントと矛盾したり、対立したりするものが明らかになり、その矛盾、ミスマッチがコンポーネントの改造プロセスで除かれる。ミスマッチが除かれると、コンポーネントはシステムに組み込まれ、そして、他のコンポーネントと共に再構成されて、進化していく。
図3.9 CBSのエンジニアリング・フレームワーク
この参照モデルは、順次的な段階で行われるものでなく、コンポーネントのプロパティによってアーキテクチャ・パターンが決められるものである。
[参考文献]
[1] “Information Technology Research: Investing in Our Future”, http://www.ccic.gov/ac/report/（日本語版はhttp://www.icot.or.jp/FTS/REPORTS/H10-reports/AITEC9903Re1_Folder/AITEC9905R1-a8-fm.html）
[2] “Planning Workshop on New Visions for Software Design and Productivity”,
http://www.itrd.gov/iwg/sdp/planning/index.html
[3] “Networking and Information Technology Research and Development – Supplement to the President's Budget for FY2003”, http://www.hpcc.gov/pubs/blue03/index.html（日本語版はhttp://www.icot.or.jp/FTS/Ronbun/BlueBook2003-J.pdf）
[4] Simulink, http://www.mathworks.com/products/simulink/
[5] Ptolemy, http://ptolemy.eecs.berkeley.edu/
[6] MDA, http://www.omg.org/mda/
[7] “Business Process Execution Language for Web Services, Version 1.0”,
http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/
[8] Gregor Kiczales,Eric Hilsdale,Jim Hugunin,Mik Kersten, Jeffrey Palm, and William G. Griswold, “Getting Started with AspectJ”, Communications of the ACM, Vol.44 No.10 pp59-65（2001）
[9] 軽い形式的枠組み、Benjamin C. Pierce, “Software Research: Where do we go from here?” , http://www.itrd.gov/iwg/sdp/planning/presentations/UPenn-Pierce.pdf
[10] TIM BERNERS-LEE, JAMES HENDLER and ORA LASSILA, “The Semantic Web” http://www.sciam.com/2001/0501issue/0501berners-lee.html
[11] David C. Fallside,“XML Schema Part 0: Primer” http://www.w3.org/TR/xmlschema-0
[12] Ora Lassila, Ralph R Swick, “Resource Description Framework（RDF） Model and Syntax Specification”, http://www.w3.org/TR/REC-rdf-syntax/
[13] Dan Brickley, R.V. Guha、”Resource Description Framework（RDF） Schema Specification 1.0”、 http://www.w3.org/TR/rdf-schema/
[14] “Dublin Core Metadata Element Set, Version 1.1: Reference Description” http://dublincore.org/documents/dces/
[15] “Dublin Core Qualifiers”、 http://dublincore.org/documents/dcmes-qualifiers/
[16] “Annotated DAML+OIL （March 2001） Ontology Markup” http://www.daml.org/2001/03/daml+oil-walkthru.html
[17] “Reference description of the DAML+OIL （March 2001） ontology markup language” http://www.daml.org/2001/03/reference.html
[18] オープンソースソフトプロセス、http://www.opensource.org/halloween.html （日本語版はhttp://www.post1.com/home/hiyori13/freeware/halloween.html）
[19] “伽藍とバザール”, http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
（日本語版はhttp://www.post1.com/home/hiyori13/freeware/cathedral.html）
[20] ケント ベック,“XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手”, ピアソンエデュケーション
[21] エリック ガンマ, ラルフ ジョンソン, リチャード ヘルム, ジョン ブリシディース, “オブジェクト指向における再利用のためのデザインパターン”, ソフトバンクパブリッシング
[22] “Simple Object Access Protocol （SOAP） 1.1”, http://www.w3.org/TR/SOAP/
[23] “Web Services Description Language （WSDL） 1.1”, http://www.w3.org/TR/wsdl
[24] “UDDI Version 3.0“, http://uddi.org/pubs/uddi-v3.00-published-20020719.pdf
[25] CBS, http://www.sei.cmu.edu/cbs/cbs_description.html