JP2012527707A

JP2012527707A - アプリケーションのコンポーネントをバージョン管理するシステム、方法及びコンピュータプログラムプロダクト

Info

Publication number: JP2012527707A
Application number: JP2012512073A
Authority: JP
Inventors: ウェイスマン，クレイグ; スミス，アンドリュー
Original assignee: セールスフォースドットコムインコーポレイティッド
Priority date: 2009-05-21
Filing date: 2010-05-21
Publication date: 2012-11-08
Anticipated expiration: 2030-05-21
Also published as: EP2433200A1; WO2010135696A1; US20100299663A1; US8510729B2; EP2433200A4; EP2433200B1; JP5730290B2

Abstract

実施例によれば、アプリケーションのコンポーネントをバージョン管理する機構及び方法が提供される。アプリケーションのコンポーネントをバージョン管理するこれらの機構及び方法は、アプリケーションの複数の前のバージョンをサポートしつつ、アプリケーション開発者が単一のアプリケーションを維持管理し得るように、アップデートされたアプリケーションが後方互換性を維持することを確保することができる。

Description

この特許文献の開示の一部は、著作権保護の対象である資料を含む。著作権所有者は、特許商標庁の特許ファイル又は記録に表れる誰かによる特許文献又は特許の開示のファクシミリ複製に異議はないが、如何なるものであっても全ての著作権を保持する。

本発明は、概してアプリケーションのアップデートに関し、特にアプリケーションの複数のバージョンのサポートに関する。

背景技術の部分に記載される内容は、単に背景技術の部分での言及の結果として従来技術であると仮定されるべきではない。同様に、背景技術の部分に記載される問題又は背景技術の部分の内容に関連する問題は、従来技術において以前から認識されているものであると仮定されるべきではない。背景技術の部分の内容は、単に異なる手法を表しており、それ自体が発明になることもある。

典型的には、アプリケーションは、様々な理由で各アプリケーション開発者によりアップデートされる。例えば、アプリケーションは、一般的にはアプリケーション内のエラー（例えば、バグ）に対する修正を提供するため、アプリケーション内での新たな機能を提供するため等の理由でアップデートされる。アップデートをアプリケーションに適用した結果は、アプリケーションの新たなバージョンの存在になる。

不都合なことに、異なるアプリケーションのバージョンの存在は、一般的には、アプリケーション開発者が全ての利用可能なバージョンのサポートを維持管理及び継続すること、或いは、アプリケーションのユーザが最新のバージョンをインストールすることを必要とする。多くの場合、アプリケーション開発者は、アプリケーションのそれぞれ個々のバージョンの維持管理及びサポートを行う必要を回避するため、アプリケーションのユーザに最新のバージョンをインストールさせることを希望する。しかし、このことは、（例えば、ユーザの使用又はアプリケーションの統合が損なわれないように）特定のアップデートに含まれる可能性がある変更に関してアプリケーション開発者をしばしば制限する。

実施例によれば、アプリケーションのコンポーネント（component）をバージョン管理（versioning）する機構及び方法が提供される。アプリケーションのコンポーネントをバージョン管理するこれらの機構及び方法は、アプリケーションの複数の前のバージョンをサポートしつつ、アプリケーション開発者が単一のアプリケーションを維持管理し得るように、アップデートされたアプリケーションが後方互換性を維持することを確保することができる。

実施例では、一例として、アプリケーションのコンポーネントをバージョン管理する方法が提供される。使用中に、アプリケーションの少なくとも一部にアクセスする要求は、呼び出しコード（calling code）から受領される。更に、アプリケーションのバージョンは、呼び出しコードにより提供される。更に、要求に応じて、呼び出しコードは、提供されたバージョンに対応するアプリケーションのコンポーネントへのアクセスを与えられる。

アプリケーションのコンポーネントをバージョン管理する技術が複数のマルチテナント・データベース（multi-tenant database）のオンデマンドサービスのフロントエンドを提供するアプリケーションサーバに実装される実施例を参照して、本発明について説明するが、本発明は、マルチテナント・データベース又はアプリケーションサーバへの配置に限定されない。実施例は、特許請求の範囲の実施例の範囲を逸脱することなく、他のデータベースアーキテクチャ（すなわち、ORACLE（登録商標）、DB2（登録商標）等）を使用して実施されてもよい。

前述の実施例のいずれかは、単一で使用されてもよく、いずれかの組み合わせで互いに一緒に使用されてもよい。この明細書に含まれる発明はまた、部分的にのみ言及又は暗示されるが、発明の概要又は要約で全く言及又は暗示されない実施例を含んでもよい。本発明の様々な実施例は、この明細書の１つ以上の箇所で説明又は暗示され得る従来技術の様々な欠点により動機付けられている可能性があるが、本発明の実施例は、必ずしもこれらの欠点のいずれかに対処するとは限らない。換言すると、本発明の実施例は、明細書で説明し得る異なる欠点に対処することがある。いくつかの実施例は、いくつかの欠点に部分的にのみ対処してもよく、明細書で説明し得る１つのみの欠点に対処してもよい。いくつかの実施例は、これらの欠点のいずれにも対処しなくてもよい。

一実施例に従ってアプリケーションのコンポーネントをバージョン管理する方法を示す図他の実施例に従ってアプリケーションのコンポーネントをバージョン管理するシステムを示す図更に他の実施例に従って呼び出しコードのアクセス可能な範囲内のバージョンを有するアプリケーションのコンポーネントへのアクセスを呼び出しコードに提供する方法を示す図オンデマンドデータベースサービスが使用され得る環境の例のブロック図図４の要素の実施例及びこれらの要素の間の様々な可能な相互接続のブロック図

＜概要＞
アプリケーションのコンポーネントをバージョン管理（versioning）するシステム及び方法が提供される。

現在まで、アプリケーション開発者は、アプリケーションのバージョン管理に制限を受けてきており、これにより、アプリケーションのそれぞれのアップデートがアプリケーションの新たなバージョンを導入している。その結果、アプリケーション開発者は、アプリケーションの各バージョンを維持管理及びサポートすることに制限を受けている。

従って、アプリケーションのコンポーネントをバージョン管理する機構及び方法が提供される。アプリケーションのコンポーネントをバージョン管理するこれらの機構及び方法は、最新のバージョンでアプリケーションの複数の前のバージョンをサポートしつつ、アプリケーション開発者が単一のアプリケーションを維持管理し得るように、アップデートされたアプリケーションが後方互換性を維持することを確保することができる。

次に、例示的な実施例を参照して、アプリケーションのコンポーネントをバージョン管理する機構及び方法について説明する。

図１は、一実施例に従ってアプリケーションのコンポーネントをバージョン管理する方法100を示している。動作302に示すように、アプリケーションの少なくとも一部にアクセスする要求は、呼び出しコード（calling code）から受領される。この説明に関して、アプリケーション（例えば、パッケージ等）は、少なくとも一部が呼び出しコードによるアクセスを要求され得る如何なるパッケージ、コンピュータコード等を含んでもよい。このため、アクセスを要求されたアプリケーションの一部又はそれより多くは、アプリケーションの特定のメソッド、インタフェース（例えば、アプリケーションプログラムインタフェース、ユーザインタフェース等）、テーブル、フィールド、データ等を含んでもよい。

一実施例では、アプリケーションは、マルチテナント（multi-tenant）・オンデマンドデータベースサービスを利用して開発、維持管理、公開等されるコンピュータコードを含んでもよい。このようなマルチテナント・オンデマンドデータベースサービスは、ネットワークでアクセス可能なデータベースシステムに依存する如何なるサービスを含んでもよい。データベースシステムのハードウェア及びソフトウェアの様々な要素は、１人以上の顧客（例えば、テナント）により共有されてもよい。例えば、所与のアプリケーションサーバは、多数の顧客の要求を同時に処理してもよく、所与のデータベーステーブルは、潜在的にかなり多数の顧客のために行を格納してもよい。このようなマルチテナント・データベースサービスは、以下の図面を参照して説明される異なる実施例に関して示される。

他の実施例では、アプリケーションは、前述のマルチテナント・オンデマンドデータベースサービスのテナントにより開発されてもよい。例えば、アプリケーションは、マルチテナント・オンデマンドデータベースサービスの他のテナントにより使用するため、テナントにより開発されてもよい。従って、マルチテナント・オンデマンドデータベースサービスは、アプリケーションが他のテナントによりアクセスされることを許可するため、アプリケーションを開発したテナントによる受領時にアプリケーションを格納してもよい。

更に、要求が受領される呼び出しコードは、アプリケーションプログラムインタフェース（例えば、マルチテナント・オンデマンドデータベースサービスのアプリケーションプログラムインタフェース）、グラフィカルユーザインタフェース（例えば、マルチテナント・オンデマンドデータベースサービスのグラフィカルユーザインタフェース）のようなユーザインタフェース、又はアプリケーションの一部へのアクセスを要求可能な他のコードを含んでもよい。例えば、呼び出しコードは、前述のマルチテナント・オンデマンドデータベースサービスの他のテナントの１つにより開発された他のアプリケーションの一部を含んでもよい。従って、呼び出しコードは、アプリケーションを、マルチテナント・オンデマンドデータベースサービスの他のテナントにより開発された他のアプリケーションと統合するために利用されてもよい。

任意選択で、呼び出しコードから受領した要求は、アプリケーションの一部への呼び出しを含んでもよい。他の選択肢として、要求は、アプリケーションの一部を読み取るためのもの、アプリケーションの一部に書き込むためのもの等でもよい。しかし、当然に、要求は、アプリケーションの一部への如何なる種類のアクセスでもよい。

更に、動作104に示すように、呼び出しコードにより提供されるバージョンが識別される。呼び出しコードにより提供されるバージョンは、アプリケーションのバージョンの如何なるインジケータ（例えば、識別子等）を含んでもよい。例えば、バージョンは、アプリケーションの複数の既存の状態の中からアプリケーションの特定の状態を示してもよい。ただし、各状態は、アプリケーションに適用されたアップデート（例えば、パッチ等）に基づいて異なる。

一実施例では、呼び出しコードにより提供されるバージョンは、要求のヘッダから判定されてもよい。例えば、要求のヘッダは、呼び出しコードにより提供されるバージョンを指定してもよい。他の実施例では、呼び出しコードにより提供されるバージョンは、要求に関連する（例えば、要求が生じた）ユニフォーム・リソース・ロケータ（URL：uniform resource locator）から判定されてもよい。

更に他の実施例では、呼び出しコードにより提供されるバージョンは、呼び出しコードの開発者に関連する設定により指定された初期設定バージョンから判定されてもよい。例えば、バージョンは、呼び出しコードについて特に必ずしも設定される必要はなく、その代わりに、呼び出しコードの開発者に関して初期設定バージョンが指定されてもよい。従って、初期設定バージョンは、このようなアプリケーションの開発者により指定されていないバージョンを有する全てのアプリケーションに適用されてもよい。このような初期設定バージョンは、任意選択で呼び出しコードを含むアプリケーションのインストール済みバージョンを含んでもよい点に留意すべきである。

更に他の実施例では、バージョンは、未指定のバージョンでもよい。例えば、前述の初期設定バージョンが使用されない場合、有効でない場合等、呼び出しコードにより提供されるバージョンが指定されていない場合、バージョンは、未指定のバージョンであるとして識別されてもよい（例えば、“未指定（unspecified）”として識別されてもよい）。未指定のバージョンは、呼び出しコードに関連するテナントによりインストールされた最新のバージョンに従って自動的に判定されてもよい。当然に、呼び出しコードにより提供されるバージョンが識別され得る方法に関して様々な実施例について前述したが、呼び出しコードにより提供されるバージョンは、如何なる所望の方法で識別されてもよい点に留意すべきである。

更に、動作106に示すように、呼び出しコードは、要求に応じて、呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントへのアクセスを与えられる。この説明に関して、このようなコンポーネントは、アクセスを要求されたアプリケーションの一部のうち、呼び出しコードにより提供されるバージョンに対応する如何なる下位区分を含んでもよい。例えば、コンポーネントは、オブジェクト、フィールド、クラス、メソッド、識別子、テーブル等を含んでもよい。従って、呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントへのアクセスを与えることは、アプリケーションのバージョンに対応するアプリケーションの一部に関連するコンポーネントへのアクセスを与えることにより、（例えば、アプリケーションのコンポーネントの読み取り、アプリケーションのコンポーネントへの書き込み、アプリケーションのコンポーネントの呼び出し等を許可することにより）、アプリケーションの一部にアクセスする要求を満たすことを含んでもよい。

一実施例では、呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントは、アクセスを呼び出しコードに提供するために判定されてもよい。コンポーネントは、以下に説明するような方法で、呼び出しコードにより提供されるバージョンに特有にすること、所定のルールに従って呼び出しコードにより提供されるバージョンによりアクセスされることを許可されること等により、呼び出しコードにより提供されるバージョンに対応してもよい。

任意選択で、このようなコンポーネントは、アプリケーションの複数のコンポーネントから判定されてもよく、従って、アプリケーションの要求された部分に関連する全てのコンポーネントの一部のみを含んでもよい。例えば、アクセスを要求されたアプリケーションの一部の複数のバージョンは、アプリケーションの各コンポーネントのバージョンの指示を提供することにより、アプリケーション内に存在してもよい（例えば、アプリケーションによりサポートされてもよい）。従って、選択肢として、複数のコンポーネントは、同様の機能を提供してもよいが、異なるバージョンに関連してもよい（例えば、第１の機能を提供する第１のコンポーネントは、アプリケーションの元のコンポーネントを含むため、アプリケーションの第１のバージョンに関連してもよく、第１の機能を提供する第２のコンポーネントは、第１のコンポーネントのアップデートされたバージョンを含むため、アプリケーションのアップデートされたバージョンに関連してもよい等である）。このため、呼び出しコードは、呼び出しコードの前述の要求に応じて、呼び出しコードにより提供されるバージョンに対応するバージョンを有するコンポーネントへのアクセスを与えられてもよい。

例えば、アプリケーションは、アプリケーションの最新のバージョンでもよい。アプリケーションの最新のバージョンは、各コンポーネントに関連するバージョン管理コメント（注釈）と共に、アプリケーションに関してこれまでにリリースされた全てのコンポーネントのスーパーセット（上位集合）を含む。このように、アプリケーションの最新のバージョンは、形式及び動作上で前の（例えば、古い）バージョンをエミュレーションするために、このようなコメントを利用してもよい。一実施例では、アプリケーションは、呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントを（例えば、実行時に）判定してもよく、これらの判定されたコンポーネントへのアクセスを呼び出しコードに提供してもよい。このように、アプリケーションは、どのコンポーネントが呼び出しコードにより提供されるバージョンに対応すると判定されたかに基づいて、アプリケーション内の手続上のロジックを切り替えることが可能でもよい。

一実施例では、呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントは、所定のルールに基づいて判定されてもよい。選択肢として、所定のルールは、呼び出しコードの種類に特有でもよい。このような呼び出しコードの種類は、アプリケーションプログラムインタフェース、ユーザインタフェース等を含んでもよい。このため、アプリケーションの一部へのアクセスを要求したアプリケーションプログラムインタフェースに適用可能な所定のルールの第１のセットが、アプリケーションの一部へのアクセスを要求したユーザインタフェースに適用可能な所定のルールの第２のセットと異なってもよい。

他の実施例では、所定のルールは、（呼び出しコードによるアクセスを要求された）アプリケーションの一部の種類に特有でもよい。例えば、アプリケーションの一部の種類は、マルチテナント・オンデマンドデータベースサービスにより管理される標準コンポーネント、アプリケーションの開発者により生成されるカスタムコンポーネント、又はアプリケーションの一部としてインストールされたコンポーネントを含んでもよい。任意選択で、所定のルールは、呼び出しコードの種類とアプリケーションの一部の種類との双方に特有でもよい。

単に一例として、アプリケーションのコンポーネント毎に、コンポーネントは、前述のようにコンポーネントのバージョンでコメントを付けられてもよい。コメントは、コンポーネントが対応するアプリケーションのバージョンの範囲を示す、アプリケーションの最低バージョン及びアプリケーションの最高バージョンを含んでもよい。しかし、当然に、コメントは、コンポーネントが呼び出しコードにより提供されるバージョンに対応するか否かを判定する際に使用されるコンポーネントのバージョンの如何なるインジケータを含んでもよい。

一実施例では、所定のルールは、呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントが、呼び出しコードにより提供されるバージョンに一致するバージョンでそれぞれコメントを付けられたアプリケーションのコンポーネントのみを含むことを示してもよい。従って、例えば、所定の種類のアプリケーションの一部にアクセスを要求している所定の種類の呼び出しコードに適用可能であると予め決められたルールは、（呼び出しコードがアクセスを許可された）呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントが、呼び出しコードにより提供されるバージョンに正確に一致するバージョンでそれぞれコメントを付けられたアプリケーションのコンポーネントのみを含むことを示してもよい。

他の実施例では、所定のルールは、呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントが、呼び出しコードにより提供されるバージョンに一致するバージョン又はそれ以降のバージョンでそれぞれコメントを付けられたアプリケーションのコンポーネントのみを含むことを示してもよい。例えば、所定の種類のアプリケーションの一部にアクセスを要求している所定の種類の呼び出しコードに適用可能であると予め決められたルールは、（呼び出しコードがアクセスを許可された）呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントが、呼び出しコードにより提供されるバージョンに正確に一致するバージョン又はそれ以降のバージョンでそれぞれコメントを付けられたアプリケーションのコンポーネントのみを含むことを示してもよい。

アクセスを呼び出しコードに提供するために呼び出しコードにより提供されるバージョンに対応するアプリケーションのコンポーネントを判定する複数の例は、図３を参照して以下に詳細に記載される点に留意すべきである。アプリケーションのそれぞれ個々のコンポーネントが対応する呼び出しのバージョンの指示を提供することにより（例えば、前述のようにコンポーネントをバージョン管理することにより）、アプリケーションの後方互換性が維持され得る。前述のように後方互換性を提供することにより、アプリケーションの複数の前のバージョンをサポートしつつ、アプリケーションの開発者が単一のアプリケーションを維持管理することが可能になり得る。

図２は、他の実施例に従ってアプリケーションのコンポーネントをバージョン管理するシステム200を示している。選択肢として、このシステム200は、図１の機能に関連して実装されてもよい。しかし、当然に、システム200は如何なる所望の環境において実装されてもよい。前述の定義は、この記載の中にも当てはまり得る。

図示のように、クライアントモジュール202は、ブローカ（broker）モジュール204を介して開発者（developer）モジュール206と通信する。この実施例に関して、クライアントモジュール202、開発者モジュール206及びブローカモジュール204は、それぞれマルチテナント・オンデマンドデータベースサービスのアプリケーション（例えば、インタフェース）を含んでもよい。例えば、クライアントモジュール202は、マルチテナント・オンデマンドデータベースサービスの第１のテナント（例えば、クライアントテナント）により管理、使用のための維持管理等されてもよく、開発者モジュール206は、マルチテナント・オンデマンドデータベースサービスの第２のテナント（例えば、開発者テナント）により管理、使用のための維持管理等されてもよく、ブローカモジュール204は、第１のテナント及び第２のテナントのそれぞれによる使用のため、マルチテナント・オンデマンドデータベースサービスにより提供されてもよい。

従って、ブローカモジュール204は、開発者モジュール206のアプリケーションの一部にアクセスするためのクライアントモジュール202による要求を仲介するために、マルチテナント・オンデマンドデータベースサービスにより使用されてもよい。このような仲介は、如何なる取り次ぎ、処理等を含んでもよい。この実施例で特に示すように、クライアントモジュール202は、開発者モジュール206のアプリケーション（呼び出されるアプリケーション）を呼び出す呼び出しコードを含んでもよい。

一実施例では、クライアントモジュール202は、開発者モジュール206のアプリケーションの一部へのアクセスを要求する。要求は、アプリケーションの一部を読み取るためのもの、アプリケーションの一部に書き込むためのもの、アプリケーションの一部を呼び出すもの等でもよい。クライアントモジュール202が要求を発行したことに応じて、ブローカモジュール204は、要求が少なくとも一時的に開発者モジュール206に送出されることを回避するため、要求を受領（例えば、傍受）する。

要求に応じて、ブローカモジュール204は、呼び出しコード202により提供されるバージョンを識別する。例えば、ブローカモジュール204は、要求のヘッダ、クライアントモジュール202の初期設定バージョン設定等から、呼び出しコード202により提供されるバージョンを識別してもよい。一実施例では、ブローカモジュール204は、呼び出しコード202により提供されるこのようなバージョンを判定するためのコードを起動してもよい。

ブローカモジュール204は、呼び出しコード202により提供されるバージョンのインジケータを開発者モジュール206に提供する。このように、開発者モジュール206は、呼び出しコード202により提供されるバージョンを利用して、呼び出しコード202により提供されるバージョンに対応する呼び出されるアプリケーション206のコンポーネントを判定してもよい。呼び出しコード202により提供されるバージョンに対応する呼び出されるアプリケーション206のコンポーネントの判定に基づいて、開発者モジュール206は、判定されたコンポーネントへのアクセスを呼び出しコード202に提供する。例えば、開発者モジュール206は、判定されたコンポーネントを使用して、クライアントモジュール202により発行された要求を満たす。

図３は、更に他の実施例に従って呼び出しコードのアクセス可能な範囲内のバージョンを有するアプリケーションのコンポーネントへのアクセスを呼び出しコードに提供する方法300を示している。選択肢として、方法300は、図１〜２の機能に関して実行されてもよい。しかし、当然に、方法300は、如何なる所望の環境で実行されてもよい。この場合も同様に、前述の定義がこの記載の中にも当てはまり得る。

動作302に示すように、アプリケーションの少なくとも一部にアクセスする要求は、呼び出しコードから受領される。更に、呼び出しコードにより提供されるバージョンは、動作304に示すように判定される。例えば、呼び出しコードにより提供されるバージョンは、要求に応じて判定されてもよい。

任意選択で、呼び出しコードにより提供されるバージョンは、呼び出しコードの種類に依存した所定の方法で判定されてもよい。例えば、呼び出しコードが、マルチテナント・オンデマンドデータベースサービスの複数の他のテナントにより使用されるアプリケーションを構築するためにマルチテナント・オンデマンドデータベースサービスのテナントにより使用されるウェブサービス記述言語（WSDL：web service definition language）の形式である場合、呼び出しコードにより提供されるバージョンは、表１に示す順序で識別されてもよい。例えば、バージョンが第１に示す選択肢を使用して識別できない場合、バージョンは、第２に示す選択肢を使用して識別されることを試行されてもよく、以下同様である。当然に、表１に示す順序は例示目的のみで示されており、従って、決して限定するものとして解釈されるべきではない点に留意すべきである。
［表１］
1.要求のヘッダで指定されたバージョンを識別する。
2.呼び出しコードの初期設定バージョン設定で指定されたバージョンを識別する。
3.バージョンを未指定（呼び出しコードに関連するテナントによりインストールされた最新のバージョン）として識別する。

他の例として、呼び出しコードが、当該テナントのみにより使用されるアプリケーションを構築するためにマルチテナント・オンデマンドデータベースサービスのテナントにより使用されるWSDLの形式である場合、呼び出しコードにより提供されるバージョンは、表２に示す順序で識別されてもよい。例えば、バージョンが第１に示す選択肢を使用して識別できない場合、バージョンは、第２に示す選択肢を使用して識別されることを試行されてもよく、以下同様である。当然に、表２に示す順序は例示目的のみで示されており、従って、決して限定するものとして解釈されるべきではない点に留意すべきである。
［表２］
1.要求のヘッダで指定されたバージョンを識別する。
2.エンドポイントURLで指定されたバージョンを識別する。
3.呼び出しコードの初期設定バージョン設定で指定されたバージョンを識別する。
3.バージョンを未指定として識別する。

表２に示すエンドポイントURLに関して、呼び出しコードのWDSLを生成したユーザは、インストールされたアプリケーション毎に使用されるバージョンを指定することを要求されてもよい。任意選択で、初期設定の選択肢は、常に最新のものでもよい。どのバージョンを当該呼び出しコードのWSDLからの呼び出しに使用するかの判定を可能にし得るIDは、エンドポイントURLに埋め込まれてもよい（例えば、https://www-blitz03.soma.salesforce.com/services/Soap/c/16.0/[id]）。

前述のように、呼び出しコードにより提供されるバージョンは、呼び出しコードの初期設定バージョン設定を介して識別されてもよい。初期設定バージョンは、呼び出しコードが元々インストールされた時点において呼び出しコードにより提供されたバージョンを含んでもよい（例えば、このため、呼び出しコードへのアップデートを反映しなくてもよい）。選択肢として、初期設定バージョンは、当該テナントのみにより使用されるためのテナントにより開発された呼び出しコードに自動的に設定されてもよい。他のテナントにより使用されるためのテナントにより開発された呼び出しコードは、未指定であるように自動的に設定されてもよい。

他の選択肢として、（Salesforce.com^TMにより提供される）Apexコードを使用して記述された呼び出しコードのバージョンが判定される方法は、前述のものと異なってもよい。例えば、匿名の実行のため、バージョンは未指定であると仮定されてもよい。他の例として、Apex呼び出しコードは、他のテナントのアプリケーション（すなわち、１つ以上のインストールされたアプリケーション）を参照してもよく、これにより、参照アプリケーションが呼び出しコードにより提供されるバージョンを判定する基礎として使用されてもよい。表３は、呼び出しコードに含まれてもよい様々な種類の参照（reference）の例を示している。当然に、このような参照は、例示目的のみで示されており、従って、決して限定するものとして解釈されるべきではない点に留意すべきである。
［表３］
1.明示的な参照：コードは、他のインストールされたアプリケーションからスキーマ（schema）又はコードを明示的に参照する。これらの参照は、コンパイル時に検出されてもよい。Apexテストは、スキーマ又はコードに依存し、常に合格しなければならない。
2.明示として動作する動的なApex：明示的な参照の変わりに動的なApex（dynamic Apex）を使用するコードである。参照されるスキーマ／コードの範囲は有限であり、コンパイル時に開発者に知られている。コンパイル時にこれらの依存性を検出しない。テストは動的を使用して記述されてもよく、常に合格することが想定される。
3.動的なApex：これは、コンパイル時に開発者が参照され得るスキーマの有限集合を知らない真の動的なユースケースである。

表４は、表３に示す参照の種類の例示的なユースケースを示している。この場合にも同様に、このようなユースケースは例示目的のみで示されており、従って、決して限定するものとして解釈されるべきではない点に留意すべきである。
［表４］
1.パートナー（すなわち、テナント）が他のパートナーのパッケージ（すなわち、アプリケーション）を拡張する。
パートナーBは、パートナーAのパッケージの機能を拡張している。パートナーBは、開発組織（development org）にパートナーAのパッケージをインストールしている。パートナーBは、基礎のパッケージ（明示的な参照として動作する明示的且つ動的なApex）からのスキーマ及びグローバルクラス／メソッドに依存する。特定の場合には、パートナーBは、パートナーAのパッケージからApexトリガーにより投げかけられた妥当性エラーを取得している。パートナーBのテストは、これらのエラーを予期するように書き込まれる。パートナーAがパッケージに変更を行い、新たなバージョンをプッシュした（出した）場合、パートナーBは、アプリケーションが動作し続けてテストが合格し続けることを予期する。
2.独立ソフトウェアベンダ（ISV：Independent Software Vendor）が検索／置換アプリケーションを構築する。
ISVは、いずれかのオブジェクト（理想的には、ビジネスオブジェクトのみの範囲にある）で検索／置換を実行可能なユーティリティを生成する。このユーティリティは、Visualforce^TM及び動的なApexを使用して記述される。このツールを使用する顧客は、いつインストール／生成されたかに拘らず、組織内の全ての標準及びカスタムオブジェクトへのアクセスすることを予期する。これは廃止されるスキーマ（deprecated shema）をも含む。理想的には、これらのオブジェクトの背後のいずれかの動作は、ユーザインタフェース（UI）で経験されるもの（パッケージの最新のバージョン）をエミュレートする。典型的には、顧客及びISVは、ツールがSalesforce.com^TM（SFDC）を含む他のパッケージにより新たに追加されたスキーマを使うための如何なる動作も行いたくない。ISVは、新たなデータタイプ等を使うために、SFDCのアプリケーションプログラムインタフェース（API）の後のバージョンにコードをアップデートしなければならないことを認識する。
3.顧客が複数のパッケージを統合する。
顧客は、複数のインストールされたパッケージから様々な他のオブジェクトでデータ操作（DML：data manipulation）を実行するApexトリガーを生成する。顧客が何のオブジェクトを参照しているかを認識していても、顧客は、依然として動的なApexを有するコードを要求する。この理由は、これが最も快適であるからである。パッケージの様々な公開者がスキーマを廃止して動作を変更したとしても、顧客はコードが動作し続けることを予期する。

一実施例では、第１の明示的な参照時に、クラス／トリガーが参照するインストールされたアプリケーションのバージョンが記録されてもよい。記録されたバージョンは、最後にインストールされたバージョンでもよい。開発者は、そのアプリケーションの全ての明示的な参照が削除されるまで、そのバージョンへの結びつき（binding）を削除することを妨げられてもよい。開発者は、記録されたバージョンをインストールされた他のバージョンに自由に変更できる。任意選択で、コードは、これが生じたときに再コンパイルされることが要求されてもよい。参照が試みられるapex／スキーマが廃止されているが（以下に説明するように非アクティブされるが）、以前にアプリケーションに利用可能であった（アクティブとしてインストールされた）という場合が存在する。この場合、この識別子が現在のバージョンで利用可能ではないことを開発者に伝えるエラーメッセージが投げかけられてもよいが、利用可能であるバージョンを含んでもよい。

選択肢として、開発者はまた、明示的な参照が検出されなくても、呼び出しコードにより提供されるバージョンを更なるインストールされたアプリケーションに手動で結びつけてもよい。動的なApexの使用は、バージョンの結びつきを記録させなくてもよい。この理由は、これらの参照はコンパイル時に検出されなくてもよいからである。

他の実施例では、開発者が管理された拡張アプリケーション（例えば、限られた変更が許可されたアプリケーション）を生成した場合、アプリケーションは、基礎の特定のバージョンに依存してもよい。この場合、動的なapexですら、基礎のバージョンに結びつくことを要求され得る。この問題に対処するために、拡張組織（extension org）でapex/vfを生成する際に、バージョン結びつき情報は、全てのインストールされたアプリケーションの保存時に記録されてもよい。これは、コードが参照していないアプリケーションを含んでもよい。拡張のアップロード時に、バージョン結びつき情報は、拡張の基礎ではないアプリケーションについて省略されてもよい。このことは、拡張アプリケーションが全ての時点で基礎の指定されたバージョンの結びつきを有することを確保し得る。任意選択で、既存のコードの結びつき情報は、新たなアプリケーションが拡張にインストールされたときに拡張されなくてもよい。記録されるバージョンの結びつきについて、コードが編集及び保存されることを要求されてもよい。

Visualforce^TMコードは、前述のようにApexコードと同様に扱われてもよい点に留意すべきである。例えば、第１の明示的な参照時に、Visualforce^TM呼び出しコードは、現在インストールされているアプリケーションのバージョンに結びつけられてもよい。他の実施例では、Visualforce^TM又はApexコンポーネントのクローン生成時（コピー時）に、全ての関係するバージョン管理情報がクローン内でコピーされてもよい。

呼び出しコードにより提供されるバージョンを判定するときに、呼び出しコードにより提供されるバージョンによるアクセスを許可されるものと予め決められたコンポーネントのバージョンの範囲が識別される。動作306を参照のこと。コンポーネントのバージョンは、特定のコンポーネントに特有のバージョンを示してもよい点に留意すべきである。例えば、コンポーネントは、アクセス可能なバージョンの範囲でコメントを付けられてもよい。

一実施例では、コンポーネントは、コンポーネントがアクセス可能な最低のアプリケーションバージョン及びコンポーネントがアクセス可能な最高のアプリケーションでコメントを付けられてもよい。最低のアプリケーションバージョンは、コンポーネントがアプリケーションにおいてリリースされたときに（例えば、使用のために公開されるとき、活性化されるとき等）記録されてもよい。最高のアプリケーションバージョンは、コンポーネントが廃止（例えば、開発者が既存のリリースされたコンポーネントを除去することを許可するインジケータ）としてアップロードされるときに記録されてもよい。このような廃止についての更なる情報は、以下に提供される。

この実施例では、呼び出しコードにより提供されるバージョンによるアクセスを許可されるものと予め決められたコンポーネントのバージョンの範囲は、所定のルールに基づいて識別されてもよい。呼び出しコードにより提供されるバージョンによるアクセスを許可されたコンポーネントのバージョンの範囲を識別するために利用される所定のルールのセットは、複数の要因に基づいて識別されてもよい。一実施例では、所定のルールのセットは、呼び出しコードの種類（例えば、呼び出しコードがAPIであるかUIであるか）に特有でもよい。他の実施例では、所定のルールのセットは、アクセスを要求されたアプリケーションの一部の種類（例えば、アクセスを要求されたアプリケーションの一部がマルチテナント・オンデマンドデータベースサービスにより管理される標準コンポーネントを含むか、アプリケーションの開発者により生成されたカスタムコンポーネントを含むか、アプリケーションの一部としてインストールされたコンポーネントを含むか）に特有でもよい。

表５は、所定のルールのセットが（例えば、呼び出しコードの種類及びアクセスを要求されたアプリケーションの一部の種類に基づいて）呼び出しコードにより提供されるバージョンによるアクセスを許可されたコンポーネントのバージョンの範囲を識別するために利用され得る例を示している。表５では、厳密な結びつき（strict binding）は、呼び出しコードにより提供されるバージョンが一致するバージョンを有するコンポーネントにアクセスすることのみを許可することを示し、緩やかな結びつき（loose binding）は、呼び出しコードにより提供されるバージョンが一致するバージョン又はそれ以降のバージョンを有するコンポーネントにアクセスすることのみを許可することを示す。表５に示す例は例示目的のみで示されており、従って、決して限定するものとして解釈されるべきではない点に留意すべきである。

ここに示すように、標準のSalesforce.com^TMスキーマのみが、厳密な結びつきの手法を採用してもよい。厳密な結びつきでは、開発者は、後のAPIバージョンで公開されるいずれかの新たなオブジェクトへのアクセスが望まれる場合、APIエンドポイントを変更しなければならない可能性がある。このことにより、開発者は、置換が取り入れられる場合、記述の呼び出しを実行するときに、唯一のエンティティのみが一度に見られ得るように、既存のエンティティを隠すことが可能になり得る。しかし、UIに関しては、新たなビジネスオブジェクトが取り入れられた場合、レポート、ワークフロー、リストビュー等がこれに対して自動的に構築されてもよい。

また、ここに示すように、顧客により生成されたスキーマ又はパッケージの一部としてインストールされたスキーマは、開発者が新たなエンティティにアクセスするためにほとんどAPIバージョンを変更する必要がないように、緩やかに結びつけられてもよい。このことにより、一般ユーティリティは、API記述呼び出し（すなわち、データローダ）を使用して如何なるスキーマとも相互作用することが可能になり得る。

他の実施例では、呼び出しコードにより提供されるバージョンによるアクセスを許可されたコンポーネントのバージョンの範囲を識別するために利用される所定のルールのセットが識別されるときの要因は、呼び出しコードが指定のバージョンであるか（例えば、要求のヘッダ、呼び出しコードの初期設定バージョン設定等を介して識別可能であるか）、未指定のバージョンであるかを含んでもよい。

任意選択で、APIに関して、そのAPIバージョンで公開されたオブジェクト及びメソッドのみが利用可能でもよい。例えば、後のバージョンで追加されたいずれかの新たなコンポーネントは、前のバージョンで利用可能でなくてもよい。コンポーネントの可用性は、ローカルのカスタムオブジェクト及びフィールドに適用しない点に留意すべきである。この理由は、これらは、前述の表５に示すように、APIバージョンへの特別の結びつきを有さない可能性があるからである。特に、これらは、これらのオブジェクト及びフィールドの基礎となるデータタイプをサポートする全てのAPIバージョンで利用可能になってもよい。

呼び出しコードのバージョンが指定された場合、所定のルールは、そのバージョンの時点で利用可能な全てのコンポーネント又は後のバージョンで追加された全てのコンポーネントが利用可能であることを示してもよい。これは、将来のバージョンで廃止されるコンポーネントを含んでもよい。任意選択で、そのバージョンで利用可能なapex識別子が公開され、Apex動作はそのバージョンの時点のものでもよい。

呼び出しコードのバージョンが未指定である場合、呼び出しコードを含むアプリケーションがインストールされると、インストールされた最新のバージョンが記録されてもよい。そのバージョンの時点で利用可能な全てのコンポーネント又は後のバージョンで追加された全てのコンポーネントが利用可能でもよい。コンポーネントの可用性は、静的な参照及び記述の呼び出しに影響を及ぼしてもよい。唯一の例外は、呼び出しで使用された対のAPIバージョンによりサポートできないスキーマでもよい（例えば、新たなデータタイプが取り入れられた場合）。一般的に、アプリケーションAPIは、Salesforce.com^TMのAPIと比較して緩やかに結びつけられてもよい。

更に他の実施例では、呼び出しコードにより提供されるバージョンによるアクセスを許可されたコンポーネントのバージョンの範囲を識別するために利用される所定のルールのセットが識別されるときの要因は、呼び出しコードがオンデマンドデータベースサービスの複数のテナントによる使用に利用可能なアプリケーション（パートナーAPIと呼ばれる）に含まれるか、アプリケーションを開発したテナントのみによる使用に利用可能なアプリケーション（エンタープライズAPIと呼ばれる）であるかを含んでもよい。パートナーAPIに適用される所定のルールは、前述の緩やかに結びつけられたルールセットを含んでもよい。エンタープライズAPIに適用される所定のルールは、前述の厳密に結びつけられたルールセットを含んでもよい。

エンタープライズアプリケーションに含まれる呼び出しコードにより発行された記述呼び出しは、その特有のアプリケーションのバージョンに利用可能な全てのコンポーネントを戻してもよい。例えば、コンポーネント（例えば、オブジェクト、フィールド等）の記述呼び出しは、名前空間のプレフィックスとコンポーネントが廃止されるか否かの指示とを戻してもよい。前のバージョンで廃止されたコンポーネントは、アプリケーションに存在しているとしても、公開されなくてもよい。後のアプリケーションのバージョンで取り入れられたスキーマは、利用可能でなくてもよい。動作は、指定された特有のバージョンを示してもよい。

従って、前述の所定のルールは、呼び出しコードが、呼び出しコードと同じバージョンを有するコンポーネントに厳密に結びつけられているか、呼び出しコードと同じバージョン又はそれ以降のバージョンを有するコンポーネントに緩やかに結びつけられているかを判定するために利用されてもよい。このような判定に基づいて、呼び出しにより提供されるバージョンによるアクセスを許可されるものとして予め決められたコンポーネントのバージョンの範囲が識別されてもよい。例えば、前者の場合、コンポーネントのバージョンの範囲は、呼び出しコードにより提供されるバージョンに一致するものに制限されてもよい。後者の場合、コンポーネントのバージョンの範囲は、呼び出しコードにより提供されるバージョンに一致するもの又はそれ以降のものに制限されてもよい。

呼び出しコードにより提供されるバージョンによるアクセスを許可されるものとして予め決められたコンポーネントのバージョンの範囲が識別されると、範囲内のバージョンを有する呼び出しコードによるアクセスを要求されたアプリケーションの一部のコンポーネントが識別される。動作308を参照のこと。一実施例では、アプリケーションの一部のコンポーネントのバージョンと、呼び出しコードにより提供されるバージョンによるアクセスを許可されるものとして予め決められたコンポーネントのバージョンの範囲とを比較するために、数式が利用されてもよい。このように、範囲内に入るアプリケーションの一部のコンポーネントのみが識別されてもよい。

更に、動作310に示すように、呼び出しコードは、識別されたコンポーネントへのアクセスを与えられる。例えば、呼び出しコードにより発行された要求は、識別されたコンポーネントを利用して満たされてもよい。このため、アプリケーションのコンポーネントのバージョン管理は、呼び出しコードにより提供されるバージョンに関連するアプリケーションの機能を提供するために利用されてもよい。

前述のように、アプリケーションのコンポーネントは、対応するアプリケーションにより提供されるバージョン（従って、アクセス可能な呼び出しコードのバージョン）を判定するためにコメントを付けられてもよい。また、前述に簡単に記載したように、このようなコメントは、コンポーネントの廃止時に設定された最高のアプリケーションバージョンを含んでもよい。例えば、マルチテナント・オンデマンドデータベースサービスのテナントは、既存のリリースされたコンポーネントを除去する機能を含み、開発されたアプリケーションが進展することを望むことがある。単に一例のみとして、テナントは、Visualforce^TMに移行してアプリケーションから全ての制御（scontrol）を除去したいと思うことがあり、テナントは、不正確なフィールドタイプを選択したことを発見して異なるタイプの新たなフィールドに移行させたいと思うこと等がある。コンポーネントの廃止により、テナントは、既にアプリケーションを利用しているテナントに直近の変更を取り入れることなく、アプリケーションを進展させることが可能になり得る。

廃止は、様々なカテゴリのコンポーネントで提供されてもよい。表６は、廃止が提供され得るコンポーネントのカテゴリの数例を示している。表６に示す例は、例示目的のみで示されており、従って、決して限定するものとして解釈されるべきではない点に留意すべきである。
［表６］
・アップグレード不可能なコンポーネント
開発者及び加入者（すなわち、ユーザ）の双方は、自由に変更を行ってもよく、削除してもよい。開発者は、リリースされた後にパッケージからコンポーネントを除去するために、コンポーネントを削除しなければならない。開発者は、削除状態でリリースされるまで、パッケージの詳細集版（detail page up）からコンポーネントを削除できない。
・アップグレード可能なコンポーネント
開発者及び加入者の双方は、リリースされた後にこれらのコンポーネントを削除できない。開発者は、コンポーネントをアップデートし続けることができる。コンポーネントの開発者により制御されたアトリビュートの値は、加入者の組織（organization）においてアップデートされる。他のアトリビュートはアップデートされない。
・保護されたコンポーネント
カスタムラベル及びワークフロー動作のように、アップグレード可能なコンポーネントの小さい部分が存在する。これらはアップグレード可能なコンポーネントと同様に動作する。加入者は、組織内でこれらのコンポーネントを見ることができるが、参照することはできない。このことにより、開発者はいつでもこれらのコンポーネントを削除することが可能になる。開発者は、コンポーネントが削除状態でリリースされるまで、パッケージの詳細集版からコンポーネントを削除できない。管理されてリリースされたパッケージでアップロードされ、そのパッケージのバージョンが既存の加入者の組織にインストールされた場合、削除されたコンポーネントは、加入者の組織から除去される。
・パブリック／プライベートApexクラス／トリガー
パブリック又はプライベートのアクセス装飾子を有するいずれかのapexクラスは、保護されたコンポーネントと同様に削除可能である。このコンポーネントは、開発者の組織から“削除”されない。これは依然としてUIに現れる。状態のみが削除として印を付けられる。加入者が削除されたコードを有するアップグレードを受領すると、これらの組織から除去される。

更に、一例のみとして表７に示すように、コンポーネントは、特定のライフサイクルを有してもよい。
［表７］
・コンポーネントが生成される。
・コンポーネントがパッケージに追加される。
・コンポーネントがベータとしてアップロードされる。管理上の制限は、開発組織（dev org）に強制されない。コンポーネントの開発名は変更できない。開発者はパッケージからコンポーネントを除去できる。
・コンポーネントがリリースとしてアップロードされる。管理上の制限が強制される。開発者はパッケージからコンポーネントを除去できない。可能な場合に、パッケージから除去するコンポーネントを削除しなければならない。
・コンポーネントがパッケージから廃止／削除される。

コンポーネント（すなわち、スキーマ）の廃止により、廃止についてのテナントの意図が確実になってもよい。意図は、廃止されるコンポーネントがコンポーネントを含むアプリケーションの既存のユーザにとって動作することをどのくらいテナントが望むかを変更してもよい。表８は、３つの例示的なユースケースを示している。この場合にも同様に、表８に示す例は、例示目的のみで示されており、従って、決して限定するものとして解釈されるべきではない。
［表８］
・中核のスキーマ
パートナー（すなわち、開発者）は、アプリケーションで積極的に使用されるフィールド（すなわち、好機の段階）を廃止したいと思う。おそらく、異なるデータタイプの新たなフィールドで置換しているか、これを複数のフィールドに分離している。アップグレード時に、データをスキーマに移行するアップグレードスクリプトを実行する。後方互換性のために、廃止されたフィールドへの入力を扱うトリガーを追加する。
フィールドが廃止された後に、パートナーは、既存の顧客（例えば、ユーザ）にフィールドの使用を中止するように促したいと思う。加入者がフィールド（ワークフロー、承認処理等）への新たな参照を生成することを妨げたいと思う。レポート、電子メールテンプレート等のような柔軟な参照は、除去時に体裁良く劣化する限り、大丈夫である。新たな顧客は、廃止されたフィールドを決して受領しない。完全な世界では、フィールドは、全ての加入者について直ちに削除される。これは可能ではないため、パートナーは、既存の顧客のために後方互換性を維持する猶予期間を提供したいと思う。その時点の後に、全ての顧客の組織からフィールドの除去を強制したいと思う。その時点で、アプリケーションの全ての参照を除去し、その形跡からフィールドを完全に削除する。
・中核でないスキーマ
パートナーは、将来的にオブジェクトを拡張する可能性があるという概念により、オブジェクトをアプリケーションに追加する（所有物で我々のことを考えてみると、大きい工場であるがほとんど配送しない）。パートナーが市場でその立場を見つけると、これらのオブジェクトがその製品にもはや意味を持たないことを発見する。パートナーはこのスキーマを前進的に除去したいと思うが、既存の顧客にとって、他のようにオブジェクトを使用可能にし続けるべきである。
この場合、廃止は全く異なる意味を有する。既存の顧客は他のスキーマのようにこれらを使用可能にするべきである。パートナーは既存の顧客の組織からスキーマを削除することを意図しない。パートナーの目的は、新たな顧客がスキーマを受領することを妨げることである。パートナーはまた、スキーマをその開発形跡から除去したいと思う。
・テンプレートのスキーマ
パートナーは、アプリケーションで数個のテンプレートオブジェクト／フィールドを提供したいと思う。これらをアップグレードする計画はない。これらは単なるテンプレートである。これらは100%加入者により制御される。将来の或る時点で、パートナーは、もはやこのスキーマをアプリケーションの一部にしたくないと判断する。この場合、新たな顧客は、このスキーマを受領しない。既存の顧客は、削除する用意ができるまで、このスキーマを使用可能にし続ける。パートナーは、その開発環境でスキーマを削除する。

このため、廃止されるコンポーネントでのユーザ及び開発者の経験は、開発者の意図によって異なってもよい。表８に示す前述のシナリオ毎に、各関係者のライフサイクル及び動作が、一例のみとして表９に示されている。
［表９］
中核のスキーマ：
1.開発者がオブジェクト／フィールドを廃止する。

○開発者は、残りの参照を識別するために「どこでこれが使用されているか」という機能を使用してもよい。これは、全てのアップグレード不可能なコンポーネントを含む。

○全てのアップグレード不可能なコンポーネントの参照は、自動的に除去される（削除動作中に典型的に残されるものを除く）。これは、主にレポート、リストビュー、ページレイアウト等である。これはまた、いくつかのコンポーネントを削除させてもよい。
2.加入者が廃止されるスキーマを有するアプリケーションのバージョンにアップグレードする。

○バージョン管理及びスキーマの公開に関して前述したルール以外の変更はない。
3.開発者は、廃止されるスキーマを有するバージョンが９ヶ月で寿命となる（削除される）という通知を次のアップグレードでリリースする。

○誰かがコンポーネントが完全に廃止されたバージョンへのアップグレードをプルした（引き出した）可能性が存在する。アップグレードのインストール時に通知されてもよい。

○この通知をリリースするためにプッシュ型のアップグレードを使用しているという要件が存在してもよい。

○加入者は、保留中の削除について警告される。加入者は、その組織においてそのバージョンの寿命（EOL：end of life）を強制されてもよい（roll orgパッケージの最低条件がバージョンを前進させる）。

○開発者は、どの組織が古いバージョンへの参照を依然として含んでいるかを認識するために、パートナーを使用してもよい。
4.全ての顧客の全ての組織の最低条件は、廃止されたバージョンより大きい。

○開発者は、開発組織においてこれらの廃止されたコンポーネントを“削除”できる。通常の削除ブロックロジックが使用される。
5.拡張がEOLバージョンに依存する場合に起こり得る状態
○拡張は、寿命の日まで機能し続ける。

○拡張がEOLバージョンに依存する場合、インストール／アップグレードを妨げる（ブロックする）。開発者がその後にapexコードを除去した場合に破られてもよい。

○任意選択で、廃止されたコンポーネントを使用するバージョンをリリースする際のアップロード時に、拡張提供者に警告する。

○インストールされた拡張がEOLの期日まで機能しない可能性がある。
中核でないスキーマ：
1.開発者は、既存の加入者がスキーマを制御することを可能にしたいと思う。

○開発者は、スキーマを開発制御（dev controlled）からサブ制御（sub controlled）に変更するインスタンスレベル管理機能を使用する。

○開発制御のコンポーネントは、サブ制御のスキーマを参照できない。

○サブ制御のスキーマを参照している変更に関係するコンポーネントもサブ制御されるようにカスケード接続（cascade）する。
2.加入者は、サブ制御のスキーマを有するアプリケーションのバージョンにアップグレードする。

○加入者は、開発名及びNSを除き、いずれかを変更してもよい。

●コンポーネントがインストールされた拡張により参照される場合、当然に、変更への影響は妨げられる。
3.開発者は、その開発組織からスキーマを除去し、新たなインストールを受領することを妨げたいと思う。

○開発者は、スキーマ及び関係するコンポーネントを開発組織から削除する。

○削除されたスキーマを有するパッケージをアップロードする。

○新たなインストールはスキーマを受領しない。
4.拡張がサブ制御のスキーマに依存する場合に起こり得る状態
○既存の顧客は大丈夫である。

○拡張の新たなインストールは妨げられてもよい。

○拡張のアップグレードはブロックされる必要があってもよい。新たな参照は、基礎のサブ制御のスキーマになる。
テンプレートのスキーマ：
1.開発者は、常に加入者により制御される新たなスキーマを取り入れる。

○開発制御のコンポーネントは、サブ制御のスキーマを参照できない。
2.加入者はサブ制御のスキーマを有するアプリケーションのバージョンをインストール／アップグレードする。

○開発名は依然としてロックされる。コンポーネントは依然として名前空間にある。
3.開発者はその開発組織からスキーマを除去し、新たなインストールを受領することを妨げたいと思う。

○開発者は、スキーマ及び関連するコンポーネントを開発組織から削除する。

○新たなインストールはスキーマを受領しない。
4.拡張はこの種類のスキーマを参照しなくてもよい。

任意選択で、コンポーネントを廃止する場合、開発者は、コンポーネントを使用することを許可され続けてもよい。開発者は、それを参照している他のコンポーネントの廃止時点で通知されてもよい。開発者は、全ての参照を判定するために、「どこでこれが使用されているか」ボタンを使用してもよい。通知及びどこで使用されているかは、同じリストでもよい。アップグレード不可能なコンポーネントの場合、参照は隠されてもよい。他の選択肢として、コンポーネントは、アプリケーションのアップロード前に廃止されなくてもよい。このことは、全ての関係するコンポーネントを廃止しないことを生じてもよい。

オブジェクトを廃止する場合、同じリリースで廃止される必要があり得る特定の関係するコンポーネントが存在する可能性がある。これらのコンポーネントについて、廃止されるコンポーネントへの参照を除去する方法が存在しない可能性がある。唯一の選択肢は、そのコンポーネントをも廃止することでもよい。オブジェクトを参照するものとして表１０に示す以下のコンポーネントは、例えば、同じアップロードで廃止されなければならない。
［表１０］
・オブジェクトのカスタムタブ
・中核の参照としてのオブジェクトを有するレポート
・最上位レベルのオブジェクトとしてのオブジェクトを有するカスタムのレポートタイプ
・オブジェクトのフィールド
・オブジェクトの確認ルール
・オブジェクトのページレイアウト
・オブジェクトのリストビュー
・オブジェクトのカスタムボタン／リンク
・オブジェクトのApex共有理由／再計算（recalc）
・オブジェクトのトリガー
・オブジェクトの記録タイプ
・オブジェクトのタブスタイル又は標準コントローラを使用したVFページ
・オブジェクトのワークフロールール
・オブジェクトのワークフローのフィールドアップデート
・オブジェクトのワークフローの外部メッセージ
・オブジェクトのワークフローの警告
・オブジェクトのワークフローのタスク
・どこでオブジェクトが対象となっているかの分析スナップショット
選択肢として、以下の加入者制御のコンポーネントは、存在し続けてもよいが、削除を反映するためにアップデートされる必要があってもよい。
(1)中核でないオブジェクト（マスター詳細レポートにおける詳細なオブジェクト）としてのオブジェクトを有するレポート
(2)中核のオブジェクトとして使用されないオブジェクトを有するカスタムレポートタイプ
フィールドを廃止する場合、表１１に示す以下のものが、例えば、同じアップロードで廃止される必要があってもよい。
［表１１］
・カスタムレポートタイプ（参照フィールドの除去により、レポートタイプが廃止される）。
・ワークフローのフィールドアップデート（異なるオブジェクトを示すために交差オブジェクト（cross object）がアップデートされてもよい）。

フィールドを廃止する場合、同じリリースで廃止されなければならない特定の関係するコンポーネントが存在する可能性がある。これらのコンポーネントについて、廃止されるスキーマへの参照を除去する方法が存在しない可能性がある。唯一の選択肢は、そのコンポーネントをも廃止することでもよい。更に、以下の加入者制御のコンポーネントが存在し続けてもよいが、削除を反映するためにアップデートされる必要があってもよい。
(1)レポート
(2)リストビュー
(3)ページレイアウト
コードが廃止の指示を使用したapexを含む場合、管理されていないアプリケーションのアップロードは妨げられてもよい。

パッケージ拡張に関して、テナントは、基礎で参照する全てのコンポーネントが顧客の組織に存在する限り、安全に拡張をインストールすることを許可されてもよい。基礎のオブジェクト又はコードがもはや存在しない場合（廃止された場合）、このことは、拡張についての問題を提示し得る。従って、インストール／アップグレードは、拡張コンポーネントが廃止されるコンポーネントを参照しているとしても、許可されてもよい。これは、加入者の組織での最初のインストールの前に廃止されたコンポーネントを含んでもよい。これは、拡張が使用するフィールドを加入者が見ない可能性すらあることを意味する。

基礎のパッケージが拡張における詳細なオブジェクトのマスターである廃止されるオブジェクトを含む場合、廃止されるオブジェクトが組織の最低バージョンより低い場合に、拡張のインストール／アップグレードは妨げられてもよい（例えば、拡張が実行時に壊れることを妨げるため）。パートナーAPIに呼び出す拡張は、組織の最低限より前のパッケージのバージョンを参照することを許可されてもよい。しかし、エンタープライズAPIを介して同じことを行うことは、許可されなくてもよい。拡張は、スキーマ及びコードの完全なEOLをサポートするように再訪問されてもよい。

前述の機能をサポートするため、様々なユーザインタフェースが提供されてもよい。表１２は、（例えば、マルチテナント・オンデマンドデータベースサービスにより）実装され得るユーザインタフェースの様々な例を示している。当然に、表１２に記載の例は、例示目的のみで示されており、従って、決して限定するものとして解釈されるべきではない点に留意すべきである。
［表１２］
●Apexコード／VF／VF電子メールテンプレート
○クラス／トリガー／ページ／コンポーネントにバージョン情報を設定する機能
○加入者／開発者のプロトタイプモードでのバージョン情報の閲覧
○“削除”されたapexコード／vf（無関係のアイテム）を隠すことの検討
●API
○エンタープライズWSDLの生成のためのバージョン情報の選択
○エンタープライズ及びパートナーWSDLのバージョン情報の初期設定の設定
●フィールド／オブジェクト
○加入者におけるバージョン範囲情報の提示（例えば、バージョン1.2.0〜3.5.0が利用可能、バージョン3.0.0〜現在のものが利用可能、コンポーネントが廃止されていることの提示）
○コンポーネントを廃止する場合、開発者におけるコンポーネントが使用されている全ての場所の列挙。廃止は、確認ページのボタンを通じて生じてもよい。
●設定
○リストから廃止されたコンポーネントの識別
●パッケージのアップロード
○パッケージがSchema.Version又は@deprecatedを使用したapexを含む場合、開発者のブロック。この理由は、これらが管理されていないパッケージにインストールされると、意味を有さない可能性があるからである。
●開発パッケージの詳細ページ
○コンポーネント毎のバージョンの範囲の提示
○コンポーネントが廃止された場合におけるそのリストにおけるその廃止のハイライト
●サブパッケージの詳細ページ
○パッケージの最初にインストールされたバージョン及び現在のバージョンの提示
○現在廃止されているコンポーネントのハイライト
○コンポーネントがどのバージョンで利用可能であるかの列挙
●パッケージのインストール
○拡張パッケージが組織の基礎のパッケージの最低条件より下の廃止されたマスターオブジェクトを参照する場合における拡張パッケージのインストールの回避（詳細は前述の拡張の部分を参照のこと）
＜システム概要＞
図４は、オンデマンドデータベースサービスが使用され得る環境410のブロック図を示している。選択肢として、前述の図面の前述の実施例のいずれかは、環境410に関して実装されてもよく、実装されなくてもよい。環境410は、ユーザシステム412と、ネットワーク414と、システム416と、プロセッサシステム417と、アプリケーションプラットフォーム418と、ネットワークインタフェース420と、テナントデータ記憶装置422と、システムデータ記憶装置424と、プログラムコード426と、処理空間428とを含んでもよい。他の実施例では、環境410は、前述の全てのコンポーネントを有さなくてもよく、及び／又は前述のものの代わりに若しくは前述のものに加えて他の要素を有してもよい。

環境410は、オンデマンドデータベースサービスが存在する環境である。ユーザシステム412は、データベースユーザシステムにアクセスするためにユーザにより使用される如何なる機械又はシステムでもよい。例えば、いずれかのユーザシステム412は、ハンドヘルドコンピュータ装置、移動電話、ラップトップコンピュータ、ワークステーション及び／又はコンピュータ装置のネットワークでもよい。図４に示すように（詳細には図５に示すように）、ユーザシステム412は、システム416であるオンデマンドデータベースサービスとネットワークを介して相互作用してもよい。

システム416のようなオンデマンドデータベースサービスは、外部ユーザに利用可能になるデータベースシステムである。外部ユーザは、必ずしもデータベースシステムの構築及び／又は維持管理に係わる必要はないが、ユーザがデータベースシステムを必要とするときに（例えば、ユーザの要求時に）ユーザの使用のために利用可能になってもよい。或るオンデマンドデータベースサービスは、共通データベースイメージのテーブルに格納された１つ以上のテナントからの情報を格納し、マルチテナント・データベースシステム（MTS：multi-tenant database system）を形成してもよい。従って、“オンデマンドデータベースサービス416”及び“システム416”は、ここでは同義的に使用される。データベースイメージは、１つ以上のデータベースオブジェクトを含んでもよい。リレーショナルデータベース管理システム（RDMS：relational database management system）又は同等のものは、データベースオブジェクトに対して情報の格納及び取得を実行してもよい。アプリケーションプラットフォーム418は、システム416のアプリケーションがハードウェア及びソフトウェア（例えば、オペレーティングシステム）等で実行することを可能にするフレームワークでもよい。実施例では、オンデマンドデータベースサービス416は、オンデマンドデータベースサービスのプロバイダ、ユーザシステム412を介してオンデマンドデータベースサービスにアクセスするユーザ、又はユーザシステム412を介してオンデマンドデータベースサービスにアクセスする第三者のアプリケーション開発者により開発された１つ以上のアプリケーションの生成、管理及び実行を可能にするアプリケーションプラットフォーム418を含んでもよい。

ユーザシステム412のユーザは、それぞれの機能（能力）において異なってもよく、特定のユーザシステム412の機能は、現在のユーザの許可（許可レベル）により完全に判定されてもよい。例えば、販売員がシステム416と相互作用するために特定のユーザシステム412を使用している場合、そのユーザシステムは、その販売員に割り当てられた機能を有してもよい。しかし、管理者がシステム416と相互作用するためにそのユーザシステムを使用している場合、そのユーザシステムは、その管理者に割り当てられた機能を有してもよい。階層的役割モデルを有するシステムでは、１つの許可レベルのユーザは、低い許可レベルのユーザによりアクセス可能なアプリケーション、データ及びデータベース情報にアクセスしてもよいが、高い許可レベルのユーザによりアクセス可能な特定のアプリケーション、データベース情報及びデータにアクセスしなくてもよい。従って、異なるユーザは、ユーザのセキュリティ又は許可レベルに依存して、アプリケーション及びデータベース情報へのアクセス及び変更に関して異なる機能を有する。

ネットワーク414は、相互に通信する装置のいずれかのネットワーク又はネットワークの組み合わせである。例えば、ネットワーク414は、LAN（local area network）、WAN（wide area network）、電話ネットワーク、無線ネットワーク、ポイント・ツー・ポイント・ネットワーク、スター型ネットワーク、トークンリングネットワーク、ハブネットワーク又は他の適切な構成のうちいずれか１つ又はいずれかの組み合わせでもよい。ここで使用される最も一般的な種類のコンピュータネットワークは、大文字“I”により“インターネット”としてしばしば呼ばれるネットワークのグローバル相互接続ネットワークのようなTCP/IP（Transfer Control Protocol and Internet Protocol）ネットワークである。そのネットワークは、ここでの多くの例で使用される。しかし、TCP/IPが頻繁に実装されるプロトコルであるが、本発明が使用し得るネットワークはこれに限定されないことがわかる。

ユーザシステム412は、TCP/IPを使用してシステム416と通信してもよく、高ネットワークレベルで、HTTP、FTP、AFS、WAP等のような通信用の他の一般的なインターネットプロトコルを使用してもよい。HTTPが使用される例では、ユーザシステム412は、システム416においてHTTPサーバにHTTPメッセージを送出してHTTPサーバからHTTPメッセージを受領するため、一般的に“ブラウザ”と呼ばれるHTTPクライアントを含んでもよい。このようなHTTPサーバは、システム416とネットワーク414との間の単一のネットワークインタフェースとして実装されてもよいが、同様に又はその代わりに他の技術が使用されてもよい。或る実装では、システム416とネットワーク414との間のインタフェースは、負荷を分散して複数のサーバ間で入来するHTTPリクエストを均等に分配するために、ラウンドロビン型HTTPリクエスト分配器（round-robin HTTP request distributor）のような負荷分散機能を含む。少なくともそのサーバにアクセスしているユーザについては、複数のサーバのそれぞれはMTSのデータにアクセスするが、他の別の構成もその代わりに使用されてもよい。

一実施例では、図４に示すシステム416は、ウェブに基づく顧客関係管理（CRM：customer relationship management）システムを実装する。例えば、一実施例では、システム416は、CRMソフトウェアアプリケーションを実装及び実行し、ユーザシステム412に及びユーザシステム412から関係するデータ、コード、フォーム、ウェブページ及び他の情報を提供し、関係するデータ、オブジェクト及びウェブページコンテンツをデータベースシステムに格納してデータベースシステムから取得するように構成されたアプリケーションサーバを含む。マルチテナントシステムでは、複数のテナントのデータは、同じ物理的データベースオブジェクトに格納されてもよいが、典型的には、テナントのデータは、１つのテナントのデータが他のテナントのデータから論理的に別々に保持されるように構成される。これにより、データが明示的に共有されない限り、１つのテナントは他のテナントのデータにアクセスしない。或る実施例では、システム416は、CRMアプリケーション以外のアプリケーション又はCRMアプリケーションに追加のアプリケーションを実装する。例えば、システム416は、CRMアプリケーションを含み、複数のホストされた（標準及びカスタム）アプリケーションへのテナントのアクセスを提供してもよい。CRMを含んでもよく、CRMを含まなくてもよいユーザ（又は第三者の開発者）のアプリケーションは、アプリケーションプラットフォーム418によりサポートされてもよい。アプリケーションプラットフォーム418は、１つ以上のデータベースオブジェクトへのアプリケーションの生成、格納、及びシステム416の処理空間における仮想機械でのアプリケーションの実行を管理する。

ネットワークインタフェース420と、アプリケーションプラットフォーム418と、テナントデータ423用のテナントデータ記憶装置522と、システム416及び場合によっては複数のテナントにアクセス可能なシステムデータ用のシステムデータ記憶装置424と、システム416の様々な機能を実装するプログラムコード426と、アプリケーションホスティングサービスの一部としてのアプリケーションの実行のようなMTSシステム処理及びテナント特有の処理を実行する処理空間428とを含む、システム416の要素の１つの構成が図５に示されている。

図４に示すシステムの複数の要素は、ここで簡単にのみ説明される通常の周知の要素を含む。例えば、各ユーザシステム412は、デスクトップ型パーソナルコンピュータ、ワークステーション、ラップトップ、PDA、携帯電話若しくは如何なる無線アクセスプロトコル（WAP：wireless access protocol）可能な装置、又はインターネット若しくは他のネットワークに直接的若しくは間接的にインタフェース接続可能な他のコンピュータ装置を含んでもよい。典型的には、ユーザシステム412は、MicrosoftのInternet Explorerブラウザ、NetscapeのNavigatorブラウザ、Operaのブラウザ、又は携帯電話、PDA若しくは他の無線装置の場合のWAP可能ブラウザ等のようなHTTPクライアント（例えば、ブラウザプログラム）を実行し、ユーザシステム412のユーザ（例えば、マルチテナント・データベースシステムの加入者）がネットワーク414でシステム416から利用可能な情報、ページ及びアプリケーションにアクセスして処理して閲覧することを可能にする。典型的には、各ユーザシステム412はまた、システム416又は他のシステム若しくはサーバにより提供されるページ、フォーム、アプリケーション及び他の情報に関してディスプレイ（例えば、モニタ画面、LCDディスプレイ等）上のブラウザにより提供されるグラフィカルユーザインタフェース（GUI）と相互作用するために、キーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペン等のような１つ以上のユーザインタフェース装置を含む。例えば、ユーザインタフェース装置は、システム416によりホストされるデータ及びアプリケーションにアクセスするために使用されてもよく、格納されたデータで検索を実行するために使用されてもよく、ユーザがユーザに提示され得る様々なGUIページと相互作用することを可能にするために使用されてもよい。前述のように、実施例は、ネットワークの特定のグローバル相互接続ネットワークであるインターネットでの使用に適する。しかし、イントラネット、エクストラネット、仮想プライベートネットワーク（VPN）、非TCP/IPに基づくネットワーク、いずれかのLAN又はWAN等のように、他のネットワークがインターネットの代わりに使用されてもよいことがわかる。

一実施例によれば、各ユーザシステム412及び全てのそのコンポーネントは、Intel Pentium（登録商標）プロセッサ等のような中央処理装置を使用して実行するコンピュータコードを含むブラウザのようなアプリケーションを使用して、オペレータにより設定可能である。同様に、システム416（及び１つより多くが存在する場合にはMTSの更なるインスタンス）及び全てのそのコンポーネントは、図４のプロセッサシステム417のような中央処理装置を使用して実行するコンピュータコードを含むアプリケーションを使用して、オペレータにより設定可能でもよい。図４のプロセッサシステム417のような中央処理装置は、Intel Pentium（登録商標）プロセッサ等及び／又は複数の処理ユニットを含んでもよい。コンピュータプログラムプロダクトの実施例は、コンピュータがここに記載の実施例の処理のいずれかを実行するようにプログラムするために使用され得る格納された命令を有する機械可読記憶媒体を含む。相互に通信させてここに記載のようにウェブページ、アプリケーション及び他のデータ並びにメディアコンテンツを処理するようにシステム416を動作及び構成するコンピュータコードは、ハードディスクにダウンロード及び格納されることが好ましいが、完全なプログラムコード又はその一部はまた、ROM又はRAMのような周知の他の揮発性又は不揮発性メモリ媒体又は装置に格納されてもよく、フロッピーディスク、光ディスク、DVD（digital versatile disk）、CD（compact disk）、マイクロドライブ及び光磁気ディスクを含むいずれかの種類の回転媒体、磁気若しくは光カード、ナノシステム（分子メモリICを含む）、又は命令及び／又はデータを格納するのに適したいずれかの種類の媒体若しくは装置のように、プログラムコードを格納可能な如何なる媒体に提供されてもよい。更に、完全なプログラムコード又はその一部は、周知のように伝送媒体上で（例えば、インターネットで）ソフトウェア送信元又は他のサーバから送信及びダウンロードされてもよく、周知のいずれかの通信媒体及びプロトコル（例えば、TCP/IP、HTTP、HTTPS、Ethernet等）を使用して周知の他の通常のネットワーク接続（エクストラネット、VPN、LAN等）で送信されてもよい。また、本発明の実施例を実装するコンピュータコードは、例えば、C、C++、HTML、他のマークアップ言語、Java（登録商標）、JavaScript、ActiveX、他のスクリプト言語（VBScript等）のように、クライアントシステム及び／又はサーバ若しくはサーバシステムで実行可能な如何なるプログラム言語で実装されてもよく、周知の多くの他のプログラミング言語が使用されてもよいことがわかる（Java（登録商標）はSun Microsystems, Inc.の登録商標である）。

一実施例によれば、各システム416は、ウェブページ、フォーム、アプリケーション、データ及びメディアコンテンツをユーザ（クライアント）システム412に提供し、システム416のテナントとしてのユーザシステム412によるアクセスをサポートするように構成される。従って、システム416は、データが共有されない限り、各テナントのデータを別々に保持するセキュリティ機構を提供する。１つより多くのMTSが使用される場合、これらは、相互に近くに（例えば、単一のビル又はキャンパスにあるサーバファームに）配置されてもよく、相互に離れた場所に分散されてもよい（例えば、１つ以上のサーバが都市Aに配置され、１つ以上のサーバが都市Bに配置される）。ここで使用される各MTSは、ローカルに又は１つ以上の地理的位置を通じて分散された１つ以上の論理的及び／又は物理的に接続されたサーバを含んでもよい。更に、“サーバ”という用語は、当該分野において周知のように、処理ハードウェア及び処理空間を含むコンピュータシステムと、関連する記憶システム及びデータベースアプリケーション（例えば、OODBMS又はRDBMS）とを含むことを意味する。“サーバシステム”及び“サーバ”は、ここではしばしば同義的に使用される。同様に、ここに記載されるデータベースオブジェクトは、単一のデータベース、分散データベース、分散データベースの集合、冗長のオンライン若しくはオフラインバックアップ又は他の冗長性を備えたデータベース等として実装されてもよく、分散データベース又はストレージネットワークと関連する処理インテリジェンスとを含んでもよい。

図５も、環境410を示している。しかし、図５では、実施例におけるシステム415の要素及び様々な相互接続が更に示されている。図５は、ユーザシステム412が、プロセッサシステム412Aと、メモリシステム412Bと、入力システム412Cと、出力システム412Dとを含んでもよいことを示している。図５は、ネットワーク414及びシステム416を示している。図５はまた、システム416が、テナントデータ記憶装置422と、テナントデータ423と、システムデータ記憶装置424と、システムデータ425と、ユーザインタフェース（UI）530と、アプリケーションプログラムインタフェース（API）5332と、PL/SOQL534と、保存ルーチン536と、アプリケーション設定機構538と、アプリケーションサーバ500₁〜500_Nと、システム処理空間502と、テナント処理空間504と、テナント管理処理空間510と、テナント記憶領域512と、ユーザ記憶装置514と、アプリケーションメタデータ516とを含んでもよいことを示している。他の実施例では、環境410は、前述のものと同じ要素を有さなくてもよく、前述のものの代わりに又は前述のものに加えて他の要素を有してもよい。

ユーザシステム412、ネットワーク414、システム416、テナントデータ記憶装置422及びシステムデータ記憶装置424については、図４で前述した。ユーザシステム412に関しては、プロセッサシステム412Aは、１つ以上のプロセッサの如何なる組み合わせでもよい。メモリシステム412Bは、１つ以上のメモリ装置、短期及び／又は長期メモリの如何なる組み合わせでもよい。入力システム412Cは、１つ以上のキーボード、マウス、トラックボール、スキャナ、カメラ及び／又はネットワークへのインタフェースのような入力装置の如何なる組み合わせでもよい。出力システム412Dは、１つ以上のモニタ、プリンタ及び／又はネットワークへのインタフェースのような出力装置の如何なる組み合わせでもよい。図５に示すように、システム416は、一式のHTTPアプリケーションサーバ500、アプリケーションプラットフォーム418、テナントデータ記憶装置422及びシステムデータ記憶装置424として実装されたネットワークインタフェース420（図４）を含んでもよい。また、個々のテナント処理空間504とテナント管理処理空間510とを含むシステム処理空間502が示されている。各アプリケーションサーバ500は、ユーザシステム412の要求にサービス提供するために、テナントデータ記憶装置422及びその中のテナントデータ423と、システムデータ記憶装置424及びその中のシステムデータ425で構成されてもよい。テナントデータ423は、個々のテナント記憶領域512に分割されてもよい。個々のテナント記憶領域512は、データの物理的構成及び／又は論理的構成でもよい。各テナント記憶領域512内で、ユーザ記憶装置514及びアプリケーションメタデータ516は、ユーザ毎に同様に割り当てられてもよい。例えば、ユーザの最も最近使用された（MRU：most recently used）アイテムのコピーがユーザ記憶装置514に格納されてもよい。同様に、テナントである全体の組織のMRUアイテムのコピーがテナント記憶領域512に格納されてもよい。UI530は、ユーザシステム412のユーザ及び／又は開発者に、ユーザインタフェースを提供し、API532は、システム416内の処理に対するアプリケーションプログラマーインタフェースを提供する。テナントデータ及びシステムデータは、１つ以上のOracle^TMデータベースのような様々なデータベースに格納されてもよい。

アプリケーションプラットフォーム418は、アプリケーション開発者によるアプリケーションの生成及び管理をサポートするアプリケーション設定機構538を含む。これは、例えばテナント管理処理510により管理される１つ以上のテナント処理空間504として加入者により実行される保存ルーチン536により、メタデータとしてテナントデータ記憶装置422に保存されてもよい。このようなアプリケーションの起動は、プログラミング言語形式のインタフェースの拡張をAPI532に提供するPL/SOQL534を使用してコード化されてもよい。いくつかのPL/SOQL言語の実施例の詳細な説明は、2006年10月4日にCraig Weissmanにより出願された同一出願人の“PROGRAMMING LANGUAGE METHOD AND SYSTEM FOR EXTENDING APIS TO EXECUTE IN CONJUNCTION WITH DATABASE APIS”という題の米国仮出願60/828,192に記載されている。この出願の全内容を援用する。アプリケーションの起動は、１つ以上のシステム処理により検出されてもよい。１つ以上のシステム処理は、起動を行う加入者のアプリケーションメタデータ516の取得と、仮想機械でのアプリケーションとしてのメタデータの実行とを管理する。

各アプリケーションサーバ500は、データベースシステムに通信可能に結合され、例えば、異なるネットワーク接続を介してシステムデータ425及びテナントデータ423にアクセスしてもよい。例えば、１つのアプリケーションサーバ500₁はネットワーク414（例えば、インターネット）を介して結合されてもよく、他のアプリケーションサーバ500_N-1は直接のネットワークリンクを介して結合されてもよく、他のアプリケーションサーバ500_Nは更に異なるネットワーク接続により結合されてもよい。TCP/IP（Transfer Control Protocol and Internet Protocol）は、アプリケーションサーバ500とデータベースシステムとの間で通信するための典型的なプロトコルである。しかし、使用されるネットワーク相互接続に応じてシステムを最適化するために、他のトランスポートプロトコルが使用されてもよいことが、当業者に明らかである。

特定の実施例では、各アプリケーションサーバ500は、テナントであるいずれかの組織に関連するいずれかのユーザの要求を扱うように構成される。何らかの理由で如何なる時点においてもサーバプールにアプリケーションサーバを追加可能であり、サーバプールからアプリケーションサーバを削除可能であることが望ましいため、ユーザ及び／又は組織にとって特定のアプリケーションサーバ500へのサーバの密接な関係が存在しないことが好ましい。従って、一実施例では、負荷分散機能（例えば、F5 Big-IP load balancer）を実装するインタフェースシステムが、アプリケーションサーバ500とユーザシステム412との間に通信可能に結合され、要求をアプリケーションサーバ500に分配する。一実施例では、負荷分散器は、ユーザ要求をアプリケーションサーバ500にルーティングするために、最小接続アルゴリズム（least connections algorithm）を使用する。ラウンドロビン及び観測応答時間のような負荷分散アルゴリズムの他の例もまた使用されてもよい。例えば、或る実施例では、同じユーザからの３つの連続する要求は、３つの異なるアプリケーションサーバ500に達してもよく、異なるユーザからの３つの要求は、同じアプリケーションサーバ500に達してもよい。このように、システム416は、マルチテナントであり、システム416は、異なるユーザ及び組織を通じて異なるオブジェクト、データ及びアプリケーションの格納及びアクセスを扱う。

記憶装置の例として、１つのテナントは、販売員を使用する会社でもよく、各販売員は販売プロセスを管理するためにシステム416を使用する。従って、ユーザは、（例えば、テナントデータ記憶装置422内の）そのユーザの個人販売プロセスに利用可能な全ての連絡先データ、主要データ、顧客補足データ、業績データ、目標及び進行データ等を維持管理してもよい。MTS構成の例では、アクセス、閲覧、変更、報告、送信、計算等のためのデータ及びアプリケーションの全てが、ネットワークアクセスしか有さないユーザシステムにより維持管理及びアクセス可能であるため、ユーザは、如何なる多くの異なるユーザシステムから自分の販売努力及びサイクルを管理することができる。例えば、販売員が顧客を訪問しており、顧客がロビー内でインターネットアクセスを有する場合、販売員は、顧客がロビーに到達するのを待機する間に、その顧客に関する重要な最新情報を取得することができる。

各ユーザのデータは、各ユーザの雇用者に拘らず他のユーザのデータとは異なってもよいが、或るデータは、テナントである所与の組織の全てのユーザ又は複数のユーザにより共有又はアクセスされる組織規模のデータでもよい。従って、テナントレベルで割り当てられるシステム416により管理される或るデータ構造が存在してもよく、他のデータ構造は、ユーザレベルで管理されてもよい。MTSは、潜在的な競合相手を含む複数のテナントをサポートしてもよいため、MTSは、データ、アプリケーション及びアプリケーションの使用を別々に保持するセキュリティプロトコルを有するべきである。また、多くのテナントは、自分のシステムを維持管理するのではなく、MTSにアクセスすることを選択し得るため、冗長性、動作可能時間及びバックアップは、MTSに実装され得る更なる機能である。ユーザ特有のデータ及びテナント特有のデータに加えて、システム416はまた、複数のテナントにより使用可能なシステムレベルのデータ又は他のデータを維持管理してもよい。このようなシステムレベルのデータは、テナント間で共有可能な業界レポート、ニュース、ポスティング（メッセージ）等を含んでもよい。

特定の実施例では、ユーザシステム412（クライアントシステムでもよい）は、アプリケーションサーバ500と通信し、システム416からシステムレベル及びテナントレベルのデータを要求及びアップデートする。これは、１つ以上のクエリをテナントデータ記憶装置422及び／又はシステムデータ記憶装置424に送出することを必要としてもよい。システム416（例えば、システム416のアプリケーションサーバ500）は、所望の情報にアクセスするように設計された１つ以上のSQL文（例えば、１つ以上のSQLクエリ）を自動的に生成する。システムデータ記憶装置424は、データベースから要求されたデータにアクセスするためのクエリプランを生成してもよい。

各データベースは、一般的に、所定のカテゴリに適合したデータを含む一式の論理テーブルのようなオブジェクトの集合として見なされてもよい。“テーブル”は、データオブジェクトの１つの表現であり、ここでは本発明によるカスタムオブジェクト及びオブジェクトの概念上の記述を簡略化するために使用されてもよい。“テーブル”及び“オブジェクト”はここでは同義的に使用され得る点に留意すべきである。一般的に、各テーブルは、閲覧可能なスキーマで列又はフィールドとして論理的に構成された１つ以上のデータカテゴリを含む。テーブルの各行又はレコードは、フィールドにより規定されたカテゴリ毎のデータのインスタンスを含む。例えば、CRMデータベースは、名前、住所、電話番号、ファクシミリ番号等のような基本連絡先情報のフィールドを用いて顧客を記述するテーブルを有してもよい。他のテーブルは、顧客、製品、販売価格、日付等のような情報のフィールドを含む購入注文を記述してもよい。或るマルチテナント・データベースシステムでは、標準エンティティのテーブルが全てのテナントによる使用のために提供されてもよい。CRMデータベースアプリケーションでは、このような標準エンティティは、それぞれ所定のフィールドを含む顧客（アカウント）、連絡先、主要、機会データのテーブルを含んでもよい。“エンティティ（entity）”という用語はまた、ここでは“オブジェクト”及び“テーブル”と同義的に使用され得ることがわかる。

或るマルチテナント・データベースシステムでは、テナントは、カスタムオブジェクトを生成及び格納することが許可されてもよく、或いは、例えば、カスタムインデックスフィールドを含む標準オブジェクトのカスタムフィールドを生成することにより、標準エンティティ又はオブジェクトをカスタマイズすることが許可されてもよい。2004年4月2日に出願された“CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEM”という題の米国特許出願第10/817,161は、カスタムオブジェクトを生成し、マルチテナント・データベースシステムで標準オブジェクトをカスタマイズするシステム及び方法を教示している。この出願の内容を援用する。特定の実施例では、例えば、全てのカスタムエンティティデータの行は、単一のマルチテナント物理テーブルに格納される。単一のマルチテナント物理テーブルは、組織毎に複数の論理テーブルを含んでもよい。これらの複数の“テーブル”が実際に１つの大きいテーブルに格納されていること、又はこれらのデータが他の顧客のデータと同じテーブルに格納されてもよいことは、顧客にとって明白である。

ここに記載の異なる実施例のいずれかは、以下の公開出願の１つ以上に記載の特徴のいずれか１つ以上を備えてもよく、備えなくてもよい点に留意すべきである。
・2002年11月4日に出願された“OFFLINE SIMULATION OF ONLINE SESSION BETWEEN CLIENT AND SERVER”という題のUS2003/0233404
・2003年4月17日に出願された“JAVA OBJECT CACHE SERVER FOR DATABASES”という題のUS2004/0210909（現在は米国特許第7,209,929として発行されている）
・2003年9月23日に出願された“QUERY OPTIMIZATION IN A MULTI-TENANT DATABASE SYSTEM”という題のUS2005/0065925
・2004年4月2日に出願された“CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEM”という題のUS2005/0223022
・2004年6月16日に出願された“SOAP-BASED WEB SERVICES IN A MULTI-TENANT DATABASE SYSTEM”という題のUS2005/0283478
・2005年3月8日に出願された“SYSTEMS AND METHODS FOR IMPLEMENTING MULTI-APPLICATION TABS AND TAB SETS”という題のUS2006/0206834、及び／又は
・2007年6月1日に出願された“METHOD AND SYSTEM FOR PUSHING DATA TO A PLURALITY OF DEVICES IN AN ON-DEMAND SERVICE ENVIRONMENT”という題のUS2008/0010243
これらの出願の全内容を援用する。

本発明について、一例として特定の実施例に関して説明したが、本発明は開示の実施例に限定されないことがわかる。これとは対照的に、当業者に明らかになる様々な変更及び同様の構成をカバーすることを意図する。従って、特許請求の範囲は、このような全ての変更及び同様の構成を含むように、最も広い解釈を与えられるべきである。

Claims

有形のコンピュータ可読媒体に具現されたコンピュータプログラムプロダクトであって、
呼び出しコードからアプリケーションの少なくとも一部にアクセスする要求を受領するコンピュータコードと、
前記呼び出しコードにより提供されるバージョンを識別するコンピュータコードと、
前記要求に応じて、前記呼び出しコードにより提供されるバージョンに対応する前記アプリケーションのコンポーネントへのアクセスを前記呼び出しコードに与えるコンピュータコードと
を有するコンピュータプログラムプロダクト。
前記アプリケーションは、マルチテナント・オンデマンドデータベースサービスを利用して開発又は維持管理されるコンピュータコードを含む、請求項１に記載のコンピュータプログラムプロダクト。
前記呼び出しコードは、マルチテナント・オンデマンドデータベースサービスのアプリケーションプログラムインタフェースと、前記マルチテナント・オンデマンドデータベースサービスのユーザインタフェースとのうち１つを含む、請求項１に記載のコンピュータプログラムプロダクト。
前記コンピュータプログラムプロダクトは、前記呼び出しコードにより提供されるバージョンが前記要求のヘッダから判定されるように動作可能である、請求項１に記載のコンピュータプログラムプロダクト。
前記コンピュータプログラムプロダクトは、前記呼び出しコードにより提供されるバージョンが前記呼び出しコードの開発者に関連する設定により指定された初期設定バージョンから判定されるように動作可能である、請求項１に記載のコンピュータプログラムプロダクト。
判定されるバージョンは、未指定のバージョンを含む、請求項１に記載のコンピュータプログラムプロダクト。
前記呼び出しコードにより提供されるバージョンに対応する前記アプリケーションのコンポーネントを判定するコンピュータコードを更に有する、請求項１に記載のコンピュータプログラムプロダクト。
前記コンピュータプログラムプロダクトは、前記呼び出しコードにより提供されるバージョンに対応する前記アプリケーションのコンポーネントが所定のルールに基づいて判定されるように動作可能である、請求項７に記載のコンピュータプログラムプロダクト。
前記所定のルールは、前記呼び出しコードの種類に特有である、請求項８に記載のコンピュータプログラムプロダクト。
前記呼び出しコードの種類は、アプリケーションプログラムインタフェースとユーザインタフェースとのうち１つを含む、請求項９に記載のコンピュータプログラムプロダクト。
前記所定のルールは、前記アプリケーションの一部の種類に特有である、請求項８に記載のコンピュータプログラムプロダクト。
前記アプリケーションの一部の種類は、マルチテナント・オンデマンドデータベースサービスにより管理される標準コンポーネントと、前記アプリケーションの開発者により生成されたカスタムコンポーネントと、前記アプリケーションの一部としてインストールされたコンポーネントのうち１つを含む、請求項１１に記載のコンピュータプログラムプロダクト。
前記アプリケーションのコンポーネント毎に、コンポーネントは、当該コンポーネントのバージョンでコメントを付けられる、請求項８に記載のコンピュータプログラムプロダクト。
前記所定のルールは、前記呼び出しコードにより提供されるバージョンに対応する前記アプリケーションのコンポーネントが、前記呼び出しコードにより提供されるバージョンに一致するバージョンでそれぞれコメントを付けられた前記アプリケーションのコンポーネントのみを含むことを示す、請求項１３に記載のコンピュータプログラムプロダクト。
前記所定のルールは、前記呼び出しコードにより提供されるバージョンに対応する前記アプリケーションのコンポーネントが、前記呼び出しコードにより提供されるバージョンに一致するバージョン又はそれ以降のバージョンでそれぞれコメントを付けられた前記アプリケーションのコンポーネントのみを含むことを示す、請求項１３に記載のコンピュータプログラムプロダクト。
前記コメントは、前記アプリケーションの最低バージョン及び前記アプリケーションの最高バージョンを含み、前記コンポーネントが対応する前記アプリケーションのバージョンの範囲を示す、請求項１３に記載のコンピュータプログラムプロダクト。
最高バージョンは、前記コンポーネントが廃止されるものとしてアップロードされるときに記録され、前記廃止は、前記開発者が前記コンポーネントを除去することを許可するインジケータを含む、請求項１３に記載のコンピュータプログラムプロダクト。
前記コンポーネントの廃止は、前記アプリケーションの既存のユーザに直近の変更を取り入れることなく、前記アプリケーションが進展することを許可する、請求項１７に記載のコンピュータプログラムプロダクト。
呼び出しコードからアプリケーションの少なくとも一部にアクセスする要求を受領し、
前記呼び出しコードにより提供されるバージョンを識別し、
前記要求に応じて、前記呼び出しコードにより提供されるバージョンに対応する前記アプリケーションのコンポーネントへのアクセスを前記呼び出しコードに与えることを有する方法。
呼び出しコードからアプリケーションの少なくとも一部にアクセスする要求を受領し、
前記呼び出しコードにより提供されるバージョンを識別し、
前記要求に応じて、前記呼び出しコードにより提供されるバージョンに対応する前記アプリケーションのコンポーネントへのアクセスを前記呼び出しコードに与えるプロセッサを有する装置。
伝送媒体上でマルチテナント・データベースシステムで使用されるコードを送信する方法であって、
呼び出しコードからアプリケーションの少なくとも一部にアクセスする要求を受領するコードを送信し、
前記呼び出しコードにより提供されるバージョンを識別するコードを送信し、
前記要求に応じて、前記呼び出しコードにより提供されるバージョンに対応する前記アプリケーションのコンポーネントへのアクセスを前記呼び出しコードに与えるコードを送信することを有する方法。