第3章 米国政府支援SDP（Software Design and Productivity）研究開発の動向
（1）デザイン・パターン
デザイン・パターン[21]は、ソフトウェアの拡張性・再利用性を高める構成法のカタログである。
ソフトウェア開発の生産性を高める有効な手段の一つが再利用である。繰り返し使われる機能を集めた関数ライブラリやオブジェクト指向に基づき機能とデータを一つにまとめて内部を隠蔽したクラスライブラリといったコンポーネントは、再利用形態の例である。
この他の再利用の形態として、フレームワークがある。フレームワークは、コンポーネントのように完成品ではなく、半完成品である。繰り返し使われる枠組み（半完成品）だけを提供し、開発者が目的に応じて、その枠組みに拡張を施し、最終的に完成品を効率よく作成することを目指している。通常、互いに関係を持つクラスを集めたクラスライブラリとして提供され、開発者はそれらを継承するなどして独自のクラスを作成し、フレームワークが用意した枠組みに沿ったアプリケーションを作成する。
しかし、フレームワークは、大きな問題を抱えている。それは、その設計アイデアをよく理解し、クラス間の約束事などの仕掛けを理解しなければ、フレームワークを使いこなすことはできないということである。その問題を解決するのがデザイン・パターンである。設計の中で繰り返し使われる設計アイデアをデザイン・パターンとして取り出して名前を付け、ボキャブラリを多くの人々の間で共有することによって、設計アイデアや、それによる構築法の理解を助け、再利用を可能にするのがデザイン・パターンである。
[GOFのデザイン・パターン]
ソフトウェアのデザイン・パターンのアイデアは、1991年のOOPSLA（Object-Oriented Programming System, Languages and Applications）で出され、Erich Gamma、Richard Helm、Ralph Johnson、John Vlissidesの4名による『Design Patterns』が出版されて、世の中に広まった。これには、表3.3に示す23個のデザイン・パターンが記述されおり、4人組になぞらえて、GOF（Gang Of Four）の23パターンと呼ばれている。
表3.3 GOFの23デザイン・パターン
| 分類 | 生成 | 構造 | 振る舞い |
| クラス | Factory Method | Adapter（クラス） | Interpreter |
| オブジェクト | Abstract Factory | Adapter（オブジェクト） | Cham of Responsibility |
各デザイン・パターンについて、目的、別名、動機、適用可能性、構造、構成要素、強調関係、結果、実装、サンプルコード、使用例、関連するパターンの説明がなされている。例えば、Observerパターンの目的、適用可能性、構造は、以下のように示されている。
[目的]
あるオブジェクトが状態を変えたときに、それに依存するすべてのオブジェクトに自動的にそのことが知らされ、また、それらが更新されるように、オブジェクト間に一対多の依存関係を定義する。
[適用可能性]
次のような状況で Observer パターンを使う。
[構造]
（2）Webサービス
Webサービスとは、広義には、インターネットの標準的なプロトコルを使ってアクセスできるサービス全般を意味する。狭義には、インターネットの標準的なプロトコルとして、サービスの通信プロトコルを規定するSOAP（Simple Object Access Protocol）、サービスのインタフェース定義を規定するWSDL（Web Services Description Language）、サービスディレクトリを規定するUDDI（Universal Description, Discovery, and Integration）を使ってアクセスできるサービスを意味する。
そのコンセプトは、サービス指向アーキテクチャに基づいて、サービスとして表されるソフトウェア・コンポーネントを疎結合でつなぐものである。技術的には、オブジェクト指向、コンポーネントウェア、及び分散処理技術の延長線上にある漸進的な技術であるが、しかし、ソフトウェアアーキテクチャ的には、プラットフォーム独立の実現、クラサバモデルからP2Pへ、ビジネス的には、ソフトウェアからサービスへ、ソフトウェアエコシステムの登場、無料Webから有料Web時代へ、といった革新的な変革をもたらすものである。
以下に、Webサービスの基本技術であるSOAP、WSDL、UDDIについて説明する。
[SOAP]
SOAP[22]は、XMLを用いてメッセージ交換するための通信規約であり、サービスを実行するときに用いられる。下位の通信層は通常HTTPを用いるが、これに限定した仕様ではなく、例えばSMTPを用いることもできる。
SOAPによって送受信されるXMLは、ルートにEnvelope要素があり、その下位要素に、HeaderとBody要素が存在する構造を持つ。Header 部は、主にメッセージの制御のために扱われ、例えば、署名情報などが格納される。Body要素に、通信したい内容が格納される。このBodyの中身は、XML Schemaで定義した任意のXML文書が記述できる。
特に SOAPには、RPC（Remote Procedure Call）を実現するために用いる表現の規約があり、要求側では、Body 要素の中に、メソッド名、引数に関するXML情報が記述され、一方、応答側に、結果を表すXML情報が記述される。このRPCに用いる引数や結果の値に利用できる型は、XML Schemaで定義された基本データ型（byte, short, integer, double など）と、その複合型（構造体と配列）である。構造体は、XML Schemaの文書型定義を用いて表現し、配列は、SOAP encodingによる特別な表現が用意されている。
この他、SOAP には、SOAP Messages with Attachmentsという仕様があり、MIMEなどでエンコーディングした複数のパートにまたがる文書を転送することができる。
[WSDL]
WSDL[23]は、WebサービスのサービスインタフェースをXMLで定義するための言語であり、サービスがどのようなものであるかを理解するために用いられる。また、このWSDLによって、Javaのinterface定義等のプログラミング言語からWSDLを自動生成したり、SOAPのクライアントプログラム用プロキシクラスを生成したりする支援ツールが可能となり、ソフトウェア開発が容易となる。WSDLのXML文書は、definitions要素の中に次のような要素を記述する。
●types
引数や返却値に現れる型を宣言する部分。XML Schemaによる文書型の規定を行う。●message
交換する一つのメッセージのフォーマットを規定する。message要素の中にpart要素があり、これが引数のひとつずつに対応する。●portType
まとまった操作の集合を表す。portTypeの中には、一つの操作を表すoperation要素がある。さらに、operation要素の中には、input要素、output要素が記述され、これが、それぞれmessage要素と結び付けられる。●binding
転送プロトコルへのバインディングを行う。例えば、SOAP bindingでは、WSDLで定義したインタフェースと SOAPメッセージの関係を定義する。●service
service要素はport要素を持ち、サービスのエンドポイントなどを指定する。
[UDDI]
UDDI[24]は、Webサービスの公開と検索を行うレジストリの仕様を規定し、主にレジストリのデータ構造とレジストリへのアクセスインタフェースの定義を行っており、どのようなサービスがあるかを検索するために用いられる。
その内容は、businessEntity, businessService, bindingTemplateの3階層からなるXML文書と、tModelを表現するXML文書からなる。
●BusinessEntity
サービスを提供する企業に関する情報（企業名、所在地、企業コードなど）を記述する。●businessService
サービスの内容や種類に関する情報を記述する。●bindingTemplate
サービスに接続するための情報（tModelへのリンク、エンドポイント）を記述する。●tModel
サービスにアクセスするためのインタフェース情報（WSDL等）へのリンクを記述する。
そして、これらの情報を登録、検索するためのAPIとしては、次のものが用意されている。（_XXXは検索対象を示す）
●参照API （Inquiry API）
�ﾓfind_XXX キーワードなどを用いた検索のためのAPI。検索の結果は対象となった要素のキーがリスト形式で返される。
�ﾓget_XXX: find_XXXで検索されたキーから、その実体（内容）を取り出すときに使用するAPI。
●発行API （Publication API）
�ﾓsave_XXX: オブジェクトを登録するためのAPI。
�ﾓdelete_XXX: レジストリのエントリを削除するためのAPI。