[Cloud] Second CAMP 1.1 Public Review

原文はこちら。
https://blogs.oracle.com/wsinterop/entry/second_camp_1_1_public

---

本日OASISはCloud Application Management for Platforms (CAMP) の仕様のSecond Public Reviewを発表しました。

15-day Public Review for Cloud Application Management for Platforms (#CAMP) V1.1 - ends 17 March
https://www.oasis-open.org/news/announcements/15-day-public-review-for-cloud-application-management-for-platforms-camp-v1-1-end

CAMP Technical Committeeはこのバージョン(1.1)に関する作業を終了したようです。レビューコメントに対処するために必要な実質的な変更を洗い出し、実装要件の履行を保留してはいるものの、将来Committee Specificationとして承認され、うまく行けば、OASIS Standardになるドラフト仕様です。この領域に興味があるならば、このドラフトをレビューし、懸念や問題がある場合は、公開メーリングリストでコメントすることをお勧めします。

OASIS Cloud Application Management for Platforms (CAMP) TC
Providing Feedback to Members of the OASIS Cloud Application Management for Platforms (CAMP) TC
http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=camp

以前の記事の焼き直しをしないために、私はオリジナルの発表と最初のPublic Rreviewに関するブログエントリをご案内し、今回のバージョンの仕様における主な変更点を取り上げます。

Cloud Application Management for Platforms
https://blogs.oracle.com/wsinterop/entry/cloud_application_management_for_platforms
http://orablogs-jp.blogspot.jp/2012/09/cloud-application-management-for.html
CAMP 1.1 Public Review Announced
https://blogs.oracle.com/wsinterop/entry/camp_1_1_public_review

One-step deployment process

以前の仕様ぼドラフト版では、アプリケーションの展開のために2段階のプロセスを定義していました。

1. PDPもしくはPlanファイルをPlatformリソースにPOSTし、Assembly Templateリソースを作成する
2. このAssembly TemplateリソースにPOSTして、（Assemblyリソースが表す）アプリケーションをインスタンス化する

Technical Committeeが最初のPublic Reviewで次のようなフィードバックを戴きました。

「どういうつもり？商用PaaSの機能にこんな２段階のプロセスは不要だよ」

ごもっともです。そんなわけで、CAMPは１回のデプロイメントプロセスをサポートしています。クライアントはPDPもしくはPlanファイルをassembliesリソースコレクションにPOSTするだけで、成功時には（assemblyリソースで表される）新しいアプリケーションが作成されます。

Resource model simplification

最初のPublic Reviewのドラフトには、リソースモデルが複雑という別の問題がありました。コンポーネントを「アプリケーション」と「プラットフォーム」のコンポーネントに分離しました。全てのコンポーネントには対応するテンプレートがあり、そのため、Application Component Template、Platform Component Templateといった感じで、これらの各々に対応するRequirementやCapabilitiesリソースがありました。仕様になれるためとはいえ、全体としていささか面食らいました。これに対処するため、TCはテンプレートや要件、機能を除去することでリソースモデルをシンプルにしました。そうしてassemblyリソース（インスタンス化されたアプリケーション）、componentリソース（アプリケーションのコンポーネント。アプリケーションとプラットフォームコンポーネントは分離しない）、serviceリソース（基盤プラットフォームが提供するサービス）といった、3個の主要なCAMPリソースができました。プラットフォームがサポートする型や拡張子などの公表や発見をサポートする様々なメタデータリソースは、最初のPublic Reviewドラフトから大きく変わっていません。

Resource type inheritance

CAMPリソースは強い型付けがされており、拡張可能です。このバージョンの仕様には継承モデル（inheritance model）が追加されており、プロバイダーが一つ以上の別のリソースタイプの属性や挙動を継承するリソースを定義することができます。例えば、プロバイダーは、CAMPが定義したcomponentリソースを継承し、必要な属性としてdatabase_uriとcache_sizeを追加したDatabase Componentリソースを定義することができます。この新しいリソースタイプはCAMPがcomponentリソースの利用を指定している箇所であればどこででも利用できます。リソースタイプを説明するためのメタデータリソースアップデートし、こうした継承関係を含めたり、冗長な情報を取り除いたりしてきました。

The plan resource

CAMPのPlanは、アプリケーションを形成するアーティファクト、こうしたアーティファクトの実行および利用に必要なサービス、アー的ファクトとサービスの関係を説明しています。このバージョンの仕様では、PlanをJSONリソースもしくはYAMLファイルとして表現します。Planリソースは、古いテンプレートやrequirement、およびcapabilityリソースが実現しようとした機能を達成しています。つまり、開発者や管理者がこうしたアーティファクトをこうしたアーティファクトをサポートする必要のあるサービスと紐付けることができます。これは最初のPlanファイルに記載している要件とターゲットプラットフォームが提供するサービスの間に一致点がない場合に特に便利です。Planへの参照をassembliesリソースのコレクションにPOSTすることによって、Planファイルを使うのと同じように、Planリソースを使って、アプリケーションを作成することができます。
CAMP 1.1システムがどのようなものかを知りたいのであれば、Solumプロジェクトをご覧いただくのがよいでしょう。これはCAMP仕様に記述されているコンセプトをベースにして設計されました。これに加えて、PoC実装（Proof of Concept）であるnCAMPがあります。

Solum Project
https://wiki.openstack.org/wiki/Solum
nCAMP
http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/