(57)【特許請求の範囲】
【請求項１】
クライアントデバイスのウェブブラウザが実施する方法であって、
サーバに対応するウェブサイトと対話するユーザによって行なわれたユーザアクションを受信するステップを含み、前記サーバはユーザインターフェイス（ＵＩ）をホストし、前記ユーザアクションは前記ＵＩと対話する際に前記ユーザによって行なわれ、前記方法は、
前記ユーザアクションに対応するローカルモデルへの変更命令を記録するステップを含み、
前記ローカルモデルは前記クライアントデバイスが有する前記ＵＩに対応するＵＩ状態を含むモデルであって、前記変更命令は前記ユーザアクションよって当該ローカルモデルの前記ＵＩ状態を変更するための命令を含み、前記方法は、さらに、
前記記録するステップにおいて記録された変更命令を含む変更記録を、前記変更の順序で第１のキューに入れるステップと、
前記第１のキューに入れられる前記変更記録を前記変更の順序で前記サーバで持続させるために、前記変更記録を、前記サーバと通信する第２のキューに入れるステップとを含む、方法。
【請求項２】
１以上の前記変更記録はトランザクションに備えられ、前記トランザクションは、前記ＵＩに対応するモデルを修正するように構成され、前記方法は、さらに、
前記トランザクションに関する条件のもとで、前記トランザクションをコミットするステップと、
前記ＵＩの第１のＵＩ状態および前記モデルの第１のモデル状態を格納するステップと、
第１のユーザ対話に基づいて前記トランザクションをアンドゥすることを判断するステップと、
前記ＵＩを前記第１のＵＩ状態に復元し、前記モデルを前記第１のモデル状態に復元するステップとを含む、請求項１に記載の方法。
【請求項３】
前記ウェブブラウザは、前記第１のモデル状態を前記トランザクションをアンドゥする前に復元し、前記第１のＵＩ状態を前記トランザクションをアンドゥした後に復元する、請求項２に記載の方法。
【請求項４】
前記ウェブブラウザは、前記トランザクションがコミットされた後、および前記第１のユーザ対話の前に、前記ＵＩの第２のＵＩ状態および前記モデルの第２のモデル状態を格納する、請求項２または３に記載の方法。
【請求項５】
第２のユーザ対話に基づいて前記トランザクションをリドゥすることを判断するステップと、
前記ＵＩを前記第２のＵＩ状態に復元し、前記モデルを前記第２のモデル状態に復元するステップとをさらに含む、請求項４に記載の方法。
【請求項６】
前記ウェブブラウザは、前記第２のモデル状態を前記トランザクションをリドゥする前に復元し、前記第２のＵＩ状態を前記トランザクションをリドゥした後に復元する、請求項５に記載の方法。
【請求項７】
前記ウェブサイトはアプリケーション開発ウェブサイトであり、前記サーバはアプリケーション開発サーバである、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記トランザクションは、多くの関連するモデル変更を構成する、請求項２〜６のいずれか１項に記載の方法。
【請求項９】
前記条件は、トランザクションは、その実行中にエラーが生じないとの条件を含む、請求項２〜６のいずれか１項に記載の方法。
【請求項１０】
前記ＵＩは２つ以上のＵＩピースを含み、前記第１のＵＩ状態は、前記ＵＩの各ピースについてのＵＩ状態を含む、請求項２〜６のいずれか１項に記載の方法。
【請求項１１】
前記ウェブブラウザは、前記ＵＩの各ＵＩピースの前記ＵＩ状態を、前記ＵＩの他のＵＩピースから独立して格納し、復元する、請求項１０に記載の方法。
【請求項１２】
前記第１のキューは、前記ウェブサイトと対話する際にアンドゥ動作およびリドゥ動作を行なうために前記変更の順序で変更記録を維持する、順序付けられた持続キューである、請求項１〜１１のいずれか１項に記載の方法。
【請求項１３】
前記ウェブブラウザは、前記第２のキューの変更記録を一度に１つずつ処理し、各変更記録を、前記第２のキューにおける前の変更記録が前記サーバ上に無事記録された場合のみ、サーバへ送信し、前記第２のキューは順序付けられたキューである、請求項１〜１２のいずれか１項に記載の方法。
【請求項１４】
前記ウェブブラウザは、前記変更記録を、前記サーバと無事通信された後に前記第２のキューから除去する、請求項１〜１３のいずれか１項に記載の方法。
【請求項１５】
前記第２のキューは要求／応答メカニズムを通して前記サーバと通信し、前記要求／応答メカニズムでは、前記第２のキューにおける各変更記録は前記サーバへ送信され、前記サーバは次に、前記変更記録が前記サーバで持続されたかどうかを示す対応する応答を送り返す、請求項１〜１４のいずれか１項に記載の方法。
【請求項１６】
前記変更記録は、前記ウェブサイトにおける前記ユーザアクションによって生じたモデル変更を反映しており、前記ウェブブラウザは、関連するモデル変更を構成するトランザクションに追加する、請求項１〜１５のいずれか１項に記載の方法。
【請求項１７】
前記ウェブブラウザは、前記トランザクションをコミットすると、前記トランザクションにおける変更記録を前記第１のキューに配置し、コミットするための前記条件は、トランザクションは、その実行中にエラーが生じないとの条件を含む、請求項２〜６のいずれか１項に記載の方法。
【請求項１８】
前記ウェブブラウザは、前記トランザクションをコミットすると、前記トランザクションにおける変更記録を前記第２のキューに配置し、前記ウェブブラウザは、前記トランザクションを、その変更を対応するクライアント側モデルに適用し、あらゆる必要なユーザインターフェイスを対応する変更を反映するように更新したときにコミットする、請求項１７に記載の方法。
【請求項１９】
請求項１〜１８のいずれか１項に記載の方法をプロセッサに実行させるためのコンピュータプログラム。
【請求項２０】
クライアントデバイスのウェブブラウザが、サーバに対応するウェブサイトと対話するユーザによって行なわれたユーザアクションを受信する手段を含み、前記サーバはユーザインターフェイス（ＵＩ）をホストし、前記ユーザアクションは前記ＵＩと対話する際に前記ユーザによって行なわれ、
前記ユーザアクションに対応するローカルモデルへの変更命令を記録する手段を含み、前記ローカルモデルは前記クライアントデバイスが有する前記ＵＩに対応するＵＩ状態を含むモデルであって、前記変更命令は前記ユーザアクションよって当該ローカルモデルの前記ＵＩ状態を変更するための命令を含み、
前記記録された変更命令を含む変更記録を前記変更の順序で第１のキューに入れる手段と、
前記第１のキューに入れられる前記変更記録を前記変更の順序で前記サーバで持続させるために、前記変更記録を、前記サーバと通信する第２のキューに入れる手段とを含む、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願との相互参照
本願は、「トランザクションシステムにおけるＵＩ状態の復元」（RESTORATION OF UI STATE IN TRANSACTIONAL SYSTEMS）と題された、２０１５年８月１４日に出願された米国仮出願第６２／２０５，２８２号の優先権を主張する。当該仮出願の開示はここに引用により援用される。
【０００２】
分野
一実施形態は一般に、ユーザインターフェイス（user interface：ＵＩ）復元機能性を提供するシステムに向けられ、特に、ＵＩ復元機能性を提供するトランザクションシステムに向けられる。
【背景技術】
【０００３】
背景情報
一般に、広く普及しているモバイルサービスおよび無線接続は、さまざまな個人的ニーズおよびビジネスニーズ用のモバイルデバイスアプリケーション（一般に「アプリ」と呼ばれる）に対する需要をかき立てる。そのような需要は次に、モバイルアプリケーション開発および修正を単純化して促進するとともに、洗練されたアプリケーション特徴も可能にし、ビジネスセキュリティが損なわれないことも保証する、モバイルアプリケーション開発プラットフォーム／手段の望ましさに通じる。
【発明の概要】
【課題を解決するための手段】
【０００４】
概要
一実施形態は、ユーザインターフェイス（ＵＩ）状態を復元するシステムである。システムは、ＵＩと対話するユーザによって行なわれたアクションを受信し、アクションに基づいてトランザクションを判断し、トランザクションは、ＵＩに対応するモデルを修正するように構成される。システムは、ＵＩの第１のＵＩ状態およびモデルの第１のモデル状態を格納し、次にトランザクションをコミットする。システムはその後、第１のユーザ対話に基づいてトランザクションをアンドゥすることを判断する。システムは次に、ＵＩを第１のＵＩ状態に復元し、モデルを第１のモデル状態に復元する。一実施形態では、第１のモデル状態はトランザクションをアンドゥする前に復元され、一方、第１のＵＩ状態はトランザクションをアンドゥした後に復元される。
【図面の簡単な説明】
【０００５】
【図１】本発明の一実施形態に従った、モバイルクラウドサービスを使用するアプリケーションを開発するためのシステムのブロック図である。
【図２】本発明のいくつかの実施形態に従った、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通信を容易にするためのコンピューティング環境のブロック図である。
【図３】本発明の一実施形態に従ったモバイルアプリケーションスプリングボードを示す図である。
【図３Ａ】本発明の一実施形態に従ったモバイルアプリケーションユーザインターフェイス（ＵＩ）を示す図である。
【図３Ｂ】本発明の一実施形態に従ったモバイルアプリケーションユーザインターフェイス（ＵＩ）を示す図である。
【図４】本発明の実施形態に従ったモバイルアプリケーションフレームワーク実行時アーキテクチャのブロック図である。
【図５】本発明の実施形態に従った、モバイルクラウドインフラストラクチャにおいてモバイルアプリケーションを開発するためのシステムのブロック図である。
【図６】本発明の実施形態に従った、モバイルアプリケーションを構築するためのシステムにおけるネットワークコンポーネントのブロック図である。
【図７】本発明の実施形態に従ったモバイルセキュリティスイートコンポーネントのブロック図である。
【図８】本発明の実施形態に従ったモバイルアプリケーション開発のフロー図である。
【図９】本発明の実施形態に従ったウェブアプリケーション開発のためのシステムのブロック図である。
【図１０】本発明の実施形態に従った自動保存機能性のフロー図である。
【図１１】一実施形態に従った例示的なユーザインターフェイス（ＵＩ）を示す図である。
【図１２】いくつかの実施形態に従った例示的なコミットフロー、アンドゥフロー、およびリドゥフローを示す図である。
【図１３】本発明の実施形態に従ったＵＩ復元機能性のフロー図である。
【発明を実施するための形態】
【０００６】
詳細な説明
アプリケーションとはソフトウェアプログラムを指し、それは実行時、特定の所望のタスクを行なう。一般に、いくつかのアプリケーションは、１つ以上のオペレーティングシステム（operating system：ＯＳ）、（たとえばＪａｖａ（登録商標）プログラミング言語をサポートする）仮想マシン、デバイスドライバなどを含む実行時環境において実行される。開発者はしばしば、所望のアプリケーションを実現／開発するためのアプリケーション開発フレームワーク（Application Development Framework：ＡＤＦ）（それら自体がアプリケーションである）を使用する。ＡＤＦは、アプリケーションの開発において直接的／間接的に使用され得る１組の予め定義されたコード／データモジュールを提供する。ＡＤＦはまた、統合開発環境（integrated development environment：ＩＤＥ）、コード生成部、デバッガなどのツールを提供してもよい。一般に、ＡＤＦは、再使用可能なコンポーネントを提供することによって、アプリケーション開発を単純化する。再使用可能なコンポーネントは、たとえば、所望のタスクを行なうためのコンポーネントを選択し、選択されたコンポーネントの外観、挙動、および対話を定義することにより、ユーザインターフェイス（ＵＩ）およびアプリケーションロジックを定義するために、アプリケーション開発者によって使用され得る。オラクル社（Oracle Corp.）からの「オラクルＡＤＦ」（Oracle ADF）といったいくつかのＡＤＦは、緩い結合とより容易なアプリケーション開発および保守とを促進するモデル・ビュー・コントローラ（model-view-controller：ＭＶＣ）設計パターンに基づいている。
【０００７】
一般に、多くの会社は、出張中の従業員がエンタープライズコンピュータシステム上に格納された情報にアクセスできるように、従業員がモバイルデバイスを用いて社外の場所からセキュアなエンタープライズアプリケーションにアクセスできるようにする必要性を表明してきた。そのような能力があれば、たとえば、営業担当者は出先から仕事してもよく、サービス技術者は顧客サイトにいる間に部品を調べてもよく、従業員は自宅から仕事してもよい。いくつかの会社はまた、最終顧客がエンタープライズコンピュータシステムに存在するデータにアクセスできるようにすることを望んでいる。そのようなアクセスは、顧客体験を向上させ、コストを下げることにより、ある会社を競合他社から差別化し得る。たとえば、そのようなアクセスを実現することにより、ある店舗は、顧客がいつでも都合のよい時にあるアイテムについて店舗在庫をリモートでサーチして買い物できるようにしてもよく、それにより、顧客体験を向上させ、営業担当者、オペレータ、および他のスタッフの必要性を低下させる。
【０００８】
さまざまなエンタープライズアプリケーションベンダーは従来より、会社所有のセキュアなモバイルデバイスまたはカスタムモバイルアプリケーションと組合された特殊なポータルを提供することにより、この必要性を満たしてきた。しかしながら、利用可能なさまざまなパーソナルモバイルデバイスの現在の爆発的増加により、これらの従来のソリューションはすぐに時代遅れになる。なぜなら、ベンダーが単に、利用可能になるすべての最新のＯＳおよびハードウェアに遅れずについていくことができないためである。
【０００９】
また、アプリケーションは、アプリケーションタイプおよび／またはアプリケーションによって使用されるデータのタイプに依存して、さまざまなエンタープライズコンピュータシステムと接続して同期する必要があるかもしれない。これらのエンタープライズコンピュータシステムは、同様にアプリケーションタイプおよびデータタイプに基づいて変わり得るさまざまなバックエンドコンピュータシステムによってサポートされるかもしれない。しかしながら、さまざまなバックエンドエンタープライズシステムは、デバイスへデータを通信するためにさまざまな通信プロトコルおよびメカニズムを使用するかもしれず、それにより、さまざまなアプリケーションを実行するモバイルコンピューティングデバイスは、エンタープライズコンピュータシステムをサポートするさまざまなバックエンドコンピュータシステムと通信するための課題に直面するようになる。
【００１０】
さらに、セキュリティは、エンタープライズの内部コンピュータシステムへのアクセスを許可する際に懸念となり得る。モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間でのサポートされる通信プロトコルの違いは、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通信のためのセキュリティアクセス管理をさらに複雑にし得る。たとえば、専用セキュリティプロトコルを有する特定のエンタープライズコンピュータシステムにアクセスするためのアプリケーションの認証を保証するために、さまざまなメカニズムが実現され得る。いくつかの公知のシステムは、既製の消費者モバイルデバイスを会社のバックエンドエンタープライズシステムと接続することにより、この問題に対処しようと試みてきた。これらのデバイスは、エンタープライズバックエンドコンピュータシステムとの通信専用の特殊なポータルを通してエンタープライズネットワークに接続するアプリケーションまたはＯＳを用いて構成されてもよい。しかしながら、モバイルデバイスの製造業者、アプリケーション開発者、およびエンタープライズは、アプリケーションを開発し、モバイルデバイスをエンタープライズバックエンドコンピュータシステムに接続するためのより柔軟で頑強な手法から利益を得てもよい。
【００１１】
公知のシステムとは対照的に、本発明の実施形態は、「クラウド」サービスにおける迅速でビジネスユーザフレンドリなモバイルアプリケーション構成のための宣言的なブラウザベースのクライアントアプリケーション開発ツールを提供する。一実施形態では、クラウドサービスは、オラクル社からの「モバイル・クラウド・サービス」（Mobile Cloud Service：ＭＣＳ）である。実施形態は、バックエンドサービスのためにクラウドサービスを使用する予め定義されたテンプレートを使用してモバイルアプリケーションを構築することを可能にし、そのため、アプリケーション開発中に開発者にサービス定義を提示することができ、ＵＩ設計とバックエンドサービスとの間の迅速な接続を可能にする。
【００１２】
ＭＣＳ
ＭＣＳを使用する実施形態では、ＭＣＳは、クラウドコンピュータシステムを介した、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通信を容易にする。ＭＣＳは、モバイルデバイスと会社のエンタープライズネットワークとの間の第三者クラウドベースのインターフェイスを使用する。クラウドベースのインターフェイスは、さまざまなエンタープライズコンピュータシステム用のセキュアなアダプタを集中化して、さまざまなプロトコルを、標準化されたレプレゼンテーショナル・ステート・トランスファ（Representational State Transfer：ＲＥＳＴ）アーキテクチャに翻訳する。会社は、本発明の実施形態を使用して、それら自体のカスタムモバイルアプリケーションを、ＭＣＳ上で利用可能なツールを使用して作成することができ、そのようなアプリケーションは、固有のフォームでモバイルユーザデバイス上にダウンロードされ得る。アプリケーションがいったんインストールされると、それは、ＭＣＳのクラウドベースのインターフェイスにアクセスして、ＭＣＳによって提供されるセキュアなアダプタを通してさまざまなエンタープライズコンピュータシステムに到達することができる。
【００１３】
ＭＣＳを使用する実施形態におけるアプリケーション開発のために、ＭＣＳは、モバイル・バックエンド・アズ・ア・サービス（Mobile Backend as a Service：ＭＢａａＳ；ＢａａＳとも呼ばれる）モデルの下でバックエンドサービスを提供する。ＭＢａａＳは、ウェブおよびモバイルアプリケーション開発者が、自分のアプリケーションを、バックエンドアプリケーションによって公開されたバックエンドクラウドストレージおよびＡＰＩにリンクすることを可能にするとともに、ユーザ管理、プッシュ通知、ソーシャルネットワーキングサービスとの統合なども提供する。ＭＢａａＳモデルの下でＭＣＳにおいて提供されるバックエンドサービスを使用することにより、実施形態は、コード化に精通していない専門外のユーザによるモバイルアプリケーション開発のために構成された宣言的なウェブベースのＵＩを提供する。
【００１４】
一実施形態では、ユーザが新しいアプリケーションの開発を開始すると、ウィザードが開始され、ユーザは、新しいアプリケーションについて名前および記述を与えるよう求められる。次に、ユーザは、アプリケーションの第１のページについてＵＩをプレシード（pre-seed）できる一組の予め定義されたテンプレート（たとえば、タブ、底部タブ、ページネーションなど）から選択することにより、第１のページを設計するよう求められる。ＵＩは次に、変更を示すようにプレビューが自動的に更新される間に、テンプレートにおいて詳細を指定することによって完成される。ＵＩ設計が完成すると、ユーザはパレットを使用して、モバイルアプリケーションがＭＣＳを通して利用可能である、利用可能なサービスおよびデータソースのカタログ（たとえばサービスカタログ）をブラウズすることができる。ＵＩに追加されるカタログの各アイテムについて、ユーザには属性のリストが提示され、１つ以上のジェスチャ（たとえばドラッグ・アンド・ドロップなど）を使用して、ユーザは属性をＵＩ要素にバインドすることができる。ユーザは、モバイルアプリケーションを作成するために、特徴定義およびデータバインディングのプロセスを繰返すことができる。マップ、グラフといった他のＵＩコンポーネントも、ＵＩに追加され得る。アプリケーションをテストする準備ができると、ユーザは、（ｉＯＳ、アンドロイド（登録商標）、または任意の他のモバイルデバイスＯＳ用の固有の実行ファイルを構築して）対応するバイナリが作成されるようにアプリケーションを発行してもよく、その後、クイックレスポンス（Quick Response：ＱＲ）コード（登録商標）が生成されてユーザに提供される。ユーザがモバイルデバイスによってＱＲコードをスキャンする場合、アプリケーションは無線でモバイルデバイス上にインストールされる。
【００１５】
実施形態は、ＡＤＦにおいて予め構築されたコンポーネントを使用する。コンポーネントは、データ対話、データ視覚化、およびカプセル化されたブラウザ側動作を提供し、リッチクライアントプリケーション開発を単純化する。ＡＤＦはまた、カメラ、全地球測位システム（Global Positioning System：ＧＰＳ）、連絡先などといったデバイス特徴にアクセスするために、アパッチ・コルドバ（Apache Cordova）プラグインなどのプラグインを実現してもよい。
【００１６】
一実施形態では、ＡＤＦがモバイルデバイス用のアプリケーションを構築する要求を受信すると、それは、すでに開発された１つ以上のアプリケーションのうち、ツールキットを使用してプリコンパイルされた部分を判断し、それらの既存のアプリケーションに関連付けられた宣言的情報を修正する。この実施形態は次に、修正された宣言的情報と既存のアプリケーションの１つ以上のバイナリアーティファクトとに基づいて、要求されたアプリケーションを構築する。これは、所望のオペレーティングシステム（ｉＯＳ、アンドロイドなどの「ＯＳ」）のために要求されたアプリケーションを表わす当該バイナリアーティファクトをパッケージングすることによる。ＡＤＦは次に、要求されたアプリケーションをコンパイルして、１つ以上のバイナリアーティファクトおよび一組の定義ファイルを生成する。エンドユーザ開発では、アーティファクトとは、プログラミング言語を知る必要なくエンドユーザによって作成されるアプリケーションまたは複合データオブジェクトである。
【００１７】
モバイルセキュリティ
いくつかの実施形態は、オラクル社からの「オラクル・モバイル・セキュリティ・スイート」（Oracle Mobile Security Suite：ＯＭＳＳ）などのモバイルセキュリティスイートによって提供されるセキュリティサービスを使用する。ＯＭＳＳは、従業員中心の包括的なエンタープライズモビリティ管理（Enterprise Mobility Management：ＥＭＭ）ソリューションと、消費者中心のモバイルおよびソーシャルサービスとを提供する、モバイルデバイスおよびモバイルアプリケーションセキュリティソリューションである。ＥＭＭは、既存のユーザアイデンティティにシームレスに繋がって、モバイルアクセスのためのエンタープライズバックエンドアイデンティティ管理インフラストラクチャの高度な特徴を利用することにより、モバイルデバイス管理（mobile device management：ＭＤＭ）、モバイルアプリケーション管理（mobile application management：ＭＡＭ）、モバイルコンテンツ管理（mobile content management：ＭＣＭ）、およびモバイルアイデンティティポリシーを提供する。企業ニーズに準拠するセキュリティポリシーは、（典型的には企業所有のデバイスについて）完全なデバイスロックダウンを実施するように、および／または、（個人所有のデバイスの持ち込み（bring your own device：ＢＹＯＤ）について）セキュアな「コンテナ化された」企業アプリケーションおよびデータからパーソナルアプリケーションを分離するように、定義され得る。モバイルおよびソーシャルサービスはソフトウェア開発キット（software development kit：ＳＤＫ）を提供して、企業の開発者がｉＯＳおよびアンドロイドデバイス用のカスタムエンタープライズアプリケーションをセキュアにすることを可能にし、モバイルデバイス、ソーシャルネットワーク、およびエンタープライズバックエンドアイデンティティ管理インフラストラクチャ間の隙間を埋める。
【００１８】
ＯＭＳＳは、アプリケーションおよびコンテンツのセキュリティのためにセキュアコンテナをモバイルデバイスに提供して、企業のアプリケーションおよびデータを分離、保護、およびワイプする。モバイルデバイスとエンタープライズイントラネットリソースとの間の通信はすべて、モバイルデバイスの吟味された（または「コンテナ化された」）アプリケーションによってのみ使用され得る、認証されたトランスポート層セキュリティ（transport layer security ：ＴＬＳ）／セキュアソケット層（secure socket layer：ＳＳＬ）トンネル（AppTunnel）を通過する。AppTunnelは、企業の非武装ゾーン（demilitarized zone：ＤＭＺ）に位置するモバイルセキュリティアクセスサーバで終端される。このサーバは、モバイルデバイスへのセキュアなイントラネットアクセスを提供し、セキュアコンテナからのAppTunnelのみを終端させ、それにより、不正アプリケーションのリスクとデバイスレベルＶＰＮについての必要性とを減少させる。
【００１９】
ＡＤＦによって提供されるものを利用して、実施形態は、コード化を必要とせず、ビジネスサービスに容易にマッピングされる、ブラウザベースのアプリケーション開発を提供する。実施形態はまた、（たとえばアプリケーションの開発中に）アプリケーションをインラインでプレビューすること、ならびに、アプリケーションを編集し、テストし、ブラウザから発行することを可能にする。したがって、実施形態は、プロの開発者によって使用されるように構成されるオラクル社からの「Jdeveloper」などのＩＤＥではなく、ビジネスユーザ（たとえば専門外のユーザ）によって使用されるように構成される。
【００２０】
サービスカタログ
ＭＣＳを使用する本発明の実施形態をサポートするために、ＭＣＳは、オラクル社からの「オラクルＡＰＩカタログ」（Oracle API Catalog：ＯＡＣ）などのＡＰＩカタログへのアクセスを提供する。ＯＡＣは、ある組織における利用可能なＡＰＩへの可視性を提供して、それらのＡＰＩがアプリケーション開発のために再使用され得るようにする。ＯＡＣは、ＡＰＩアセットのための単純なメタモデル、ＯＡＣにＡＰＩをポピュレートするための自動化、および、ユーザがＡＰＩについてＯＡＣをサーチし、ＡＰＩの詳細を理解して、それらのアプリケーションにおけるそれらの適合性を評価するための能力を含む。ＯＡＣは、ＯＡＣにおいてＡＰＩアセットを作成するハーベスタを含む。いくつかの実施形態では、プロジェクトの構築時間にハーベスティングが行なわれる。ハーベスタは、デプロイメントされたサービスをイントロスぺクション（introspection）して、プロジェクトにおいて発見されたサービスを表わすＡＰＩアセットを作成する。これらのサービスには、サービス指向アーキテクチャ（service oriented architecture：ＳＯＡ）サービスおよびサービスバスプロキシ、ウェブサービス記述言語（Web Services Description Language：ＷＳＤＬ）ベースのウェブサービス、ならびに、ウェブアプリケーション記述言語（Web Application Description Language：ＷＡＤＬ）ベースのＲＥＳＴサービスなどがある。作成されたアセットは、ＯＡＣにおいて収集される。
【００２１】
ＡＰＩアセットがハーベスタによって作成された後に、キュレータが、単純なエディタを使用してＡＰＩアセットを編集して、ＡＰＩの発見および理解を容易にするための追加のメタデータを提供する。キュレータは、名前を変更し、記述を追加し、キーワードをタグ付けし、またはＯＡＣにおけるＡＰＩアセットに文書リファレンスを追加することができる。このメタデータは、ユーザによる各ＡＰＩアセットの発見および理解を単純化する。ＡＰＩメタデータが編集された後に、キュレータは、ＯＡＣにおいてＡＰＩをユーザに見えるようにすることによって、ＡＰＩを発行する。発行されたアセットは、ＯＡＣコンソールにおいて、オラクルJDeveloperオラクル・エンタープライズ・リポジトリ（Oracle Enterprise Repository）プラグインを介して利用可能である。ユーザは、ＯＡＣをサーチしてＡＰＩを発見し、キュレータによって提供されるメタデータを調査して、ＡＰＩについてさらに学習することができる。
【００２２】
各ＯＡＣユーザには、各ユーザにとってどのＯＡＣ特徴およびコンテンツが利用可能であるかを判断する役割が割当てられている。ＯＡＣには、開発者、キュレータ、および管理者を含む、予め定義された役割がある。開発者の役割を有するユーザは、発行されたＡＰＩについてＯＡＣをサーチし、ＡＰＩをよりよく理解するためにＡＰＩメタデータを調べ、ＡＰＩへの関心を宣言し、ＡＰＩについての格付けおよびレビューを提示する能力を有する。開発者の役割に利用可能な能力に加えて、キュレータの役割を有するユーザは、ハーベスタを実行して、ＯＡＣにおいて新しいＡＰＩアセットを作成し、ＡＰＩを編集してそれらのメタデータを更新し、それらを発行することができる。キュレータおよび開発者に利用可能な能力に加えて、管理者の役割を有するユーザは、ＯＡＣにおける管理ページへのアクセスを有しており、システム設定を編集し、新しいユーザを作成し、新しい部門を作成し、セッションを管理し、インポート／エクスポートツールを使用することによって、ＯＡＣのインフラストラクチャを管理する。管理者はまた、ＯＡＣに含まれるセキュリティ特徴を構成することができる。
【００２３】
いくつかの実施形態では、アプリケーションが、固有アプリケーションまたはホスト型アプリケーションとして開発され、モバイルデバイスにデプロイメントされてもよい。固有アプリケーションのデプロイメントについては、完全なアプリケーションがデバイス上にインストールされる。ホスト型アプリケーションの開発については、ユーザは「アップストア」（app store）からホスティングアプリケーションをダウンロードする必要があり、そのようなホスティングアプリケーションは、ホスティングアプリケーション上に「特徴」としてインストールされるであろうホスト型アプリケーションを「ホストする」。この実施形態は、宣言的メタデータがデバイスへ送信され、既存のアプリケーションの上に重ねられて、当該アプリケーションを、この新しいメタデータに対して実行するように更新することができるように、サーバからの実行中のホスティングアプリケーションを更新することを可能にしてもよい。
【００２４】
図１は、ＭＣＳ１２２をバックエンドサービスとして使用することを可能にする予め定義されたテンプレートを使用することによってアプリケーションを開発するためのシステム環境１００のブロック図である。アプリケーション開発中にユーザにサービス定義を提示することができ、ＵＩ設計とバックエンドサービスとの間の迅速な接続を可能にする。
【００２５】
図示された実施形態では、システム環境１００は、１つ以上のクライアントコンピューティングデバイス１０４、１０６、および１０８にクラウドサービスを提供するクラウドインフラストラクチャシステム１０２を含む。クライアントコンピューティングデバイス１０４、１０６、および１０８は、クラウドインフラストラクチャシステム１０２と対話するためにユーザによって使用されてもよい。クライアントコンピューティングデバイス１０４、１０６、および１０８は、クラウドインフラストラクチャシステム１０２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム１０２と対話するためにクライアントコンピューティングデバイスのユーザによって使用され得る、ウェブブラウザ、専用クライアントアプリケーション（たとえば、オラクル・フォームズ（Oracle Forms））、または何らかの他のアプリケーションといったクライアントアプリケーションを動作させるように構成されてもよい。
【００２６】
クラウドインフラストラクチャシステム１０２は、図示されたもの以外のコンポーネントを有していてもよい。また、図１に示す実施形態は、この発明の一実施形態を取入れ得るクラウドインフラストラクチャシステムの単なる一例である。いくつかの他の実施形態では、クラウドインフラストラクチャシステム１０２は、図１に示すものよりも多い、または少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組合せてもよく、もしくは、異なる構成または配置のコンポーネントを有していてもよい。
【００２７】
クライアントコンピューティングデバイス１０４、１０６、および１０８は、携帯型ハンドヘルドデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（personal digital assistant：ＰＤＡ））、またはウェアラブルデバイス（たとえば、グーグル・グラス（Google Glass）（登録商標）頭部装着型ディスプレイ）であってもよく、マイクロソフト・ウィンドウズ・モバイル（Microsoft Windows Mobile）（登録商標）などのソフトウェア、および／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド、ブラックベリー（登録商標）１０、パームＯＳなどのさまざまなモバイルＯＳを実行し、インターネット、電子メール、ショートメッセージサービス（short message service：ＳＭＳ）、ブラックベリー（登録商標）、または他の通信プロトコルに対応している。クライアントコンピューティングデバイス１０４、１０６、および１０８は、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはＬｉｎｕｘ（登録商標）ＯＳのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを例として含む、汎用パーソナルコンピュータであり得る。クライアントコンピューティングデバイス１０４、１０６、および１０８は、たとえばグーグル・クロームＯＳなどのさまざまなＧＮＵ／ＬｉｎｕｘＯＳを何ら限定されることなく含む、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ様ＯＳのうちのいずれかを実行するワークステーションコンピュータであり得る。それに代えて、またはそれに加えて、クライアントコンピューティングデバイス１０４、１０６、および１０８は、ネットワーク１１０を通して通信可能である、シンクライアントコンピュータ、インターネット対応ゲーミングシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャー入力デバイスを有する、または有さない、マイクロソフトＸｂｏｘゲーミングコンソール）、および／またはパーソナルメッセージングデバイスといった、任意の他の電子デバイスであってもよい。
【００２８】
例示的なシステム環境１００は３つのクライアントコンピューティングデバイスを有して図示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを有するデバイスなどの他のデバイスが、クラウドインフラストラクチャシステム１０２と対話してもよい。
【００２９】
ネットワーク１１０は、クライアント１０４、１０６、および１０８とクラウドインフラストラクチャシステム１０２との間のデータの通信および交換を容易にしてもよい。ネットワーク１１０は、伝送制御プロトコル／インターネットプロトコル（transmission control protocol/Internet protocol：ＴＣＰ／ＩＰ）、システムネットワークアーキテクチャ（systems network architecture：ＳＮＡ）、インターネットパケット交換（Internet packet exchange：ＩＰＸ）、アップル・トーク（Apple Talk）などを何ら限定されることなく含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。単なる例として、ネットワーク１１０は、イーサネット（登録商標）、トークンリング（Token-Ring）などに基づくものといった、ローカルエリアネットワーク（local area network：ＬＡＮ）であり得る。ネットワーク１１０は、ワイドエリアネットワークおよびインターネットであり得る。それは、仮想プライベートネットワーク（virtual private network：ＶＰＮ）を何ら限定されることなく含む仮想ネットワーク、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、電気電子技術者協会（the Institute of Electrical and Electronics：ＩＥＥＥ）８０２．１１プロトコルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのうちのいずれかの下で動作するネットワーク）、ならびに／もしくは、これらのおよび／または他のネットワークの任意の組合せを含み得る。
【００３０】
クラウドインフラストラクチャシステム１０２は、１つ以上のコンピュータおよび／またはサーバを含んでいてもよい。これらのコンピュータシステムまたはサーバは、１つ以上の汎用コンピュータ、専用サーバコンピュータ（パーソナルコンピュータ（ＰＣ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを例として含む）、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せで構成されてもよい。さまざまな実施形態では、クラウドインフラストラクチャシステム１０２に関連付けられた１つ以上のコンピュータシステムまたはサーバは、前述の開示で説明された１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、クラウドインフラストラクチャシステム１０２に関連付けられた１つ以上のコンピュータシステムまたはサーバは、この開示の一実施形態に従った、ここに記載された処理を行なうためのサーバに対応していてもよい。
【００３１】
クラウドインフラストラクチャシステム１０２に関連付けられた１つ以上のコンピュータシステムまたはサーバは、上述のもののうちのいずれかを含むＯＳ、および商業的に入手可能な任意のサーバＯＳを実行してもよい。クラウドインフラストラクチャシステム１０２に関連付けられた１つ以上のコンピュータシステムまたはサーバはまた、ハイパーテキスト伝送プロトコル（hypertext transport protocol：ＨＴＴＰ）サーバ、ファイル転送プロトコル（file transfer protocol：ＦＴＰ）サーバ、コモンゲートウェイインターフェイス（common gateway interface：ＣＧＩ）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む、さまざまな追加のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行してもよい。
【００３２】
ある実施形態では、クラウドインフラストラクチャシステム１０２によって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどといった、クラウドインフラストラクチャシステム１０２のユーザにとってオンデマンドで利用可能にされる多数のサービスを含んでいてもよい。クラウドインフラストラクチャシステム１０２によって提供されるサービスは、そのユーザの必要性を満たすために動的にスケール変更され得る。クラウドインフラストラクチャシステム１０２によって提供されるサービスの特定のインスタンス化は、ここに「サービスインスタンス」と呼ばれる。一般に、クラウドサービスプロバイダのシステムから、インターネットなどの通信ネットワークを介してユーザに利用可能とされる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを作り上げるサーバおよびシステムは、顧客自身の構内サーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドでアプリケーションをオーダーし、使用してもよい。
【００３３】
いくつかの例では、クラウドインフラストラクチャ１０２によってインスタンス化されたサービスインスタンスは、クラウドベンダーによってユーザに提供されるかまたは当該技術分野において他の態様で公知であるようなストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、もしくは他のサービスへの、保護されたコンピュータネットワークアクセスを含んでいてもよい。たとえば、クラウドインフラストラクチャ１０２によってインスタンス化されたサービスインスタンスは、インターネットを通した、クラウド上のリモートストレージへの、パスワードで保護されたアクセスを含み得る。別の例として、クラウドインフラストラクチャ１０２によってインスタンス化されたサービスインスタンスは、ネットワーク化された開発者による私的使用のための、ウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、クラウドインフラストラクチャ１０２によってインスタンス化されたサービスインスタンスは、クラウドベンダーのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含み得る。
【００３４】
ある実施形態では、クラウドインフラストラクチャシステム１０２は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼でき、高可用性で、かつセキュアな態様で顧客に提供される、アプリケーション、ミドルウェア、開発サービス、およびデータベースサービス提供物一式を含んでいてもよい。クラウドインフラストラクチャサービス１０２において具現化されたような、そのようなクラウドインフラストラクチャシステムの一例は、オラクル社からの「オラクル・パブリック・クラウド」（Oracle Public Cloud）である。
【００３５】
クラウドインフラストラクチャシステム１０２は、さまざまなデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム１０２がクラウドサービスを販売する組織によって所有され（たとえば、オラクル社によって所有され）、サービスが一般大衆またはさまざまな産業企業にとって利用可能とされる、パブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム１０２が単一の組織のためにのみ動作され、その組織内の１つ以上のエンティティのためのサービスを提供し得る、プライベートクラウドモデルの下で提供されてもよい。クラウドサービスはまた、クラウドインフラストラクチャシステム１０２、およびクラウドインフラストラクチャシステム１０２によって提供されるサービスが、関連するコミュニティにおけるいくつかの組織によって共有される、コミュニティクラウドモデルの下で提供されてもよい。クラウドサービスはまた、２つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルの下で提供されてもよい。
【００３６】
いくつかの実施形態では、クラウドインフラストラクチャシステム１０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）カテゴリー、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリー、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）カテゴリー、ＭＢａａＳカテゴリー、または、ハイブリッドサービスを含むサービスの他のカテゴリーの下で提供される、１つ以上のサービスを含んでいてもよい。いくつかの実施形態では、クラウドインフラストラクチャシステム１０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、インフラストラクチャサービス、バックエンドサービスなどを、何ら限定されることなく含んでいてもよい。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介して、クラウドインフラストラクチャシステム１０２によって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、統合された開発およびデプロイメントプラットフォーム上にオンデマンドアプリケーション一式を構築し、配信するための能力を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための根底的なソフトウェアおよびインフラストラクチャを管理し、制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得できる。さまざまな異なるＳａａＳサービスが提供されてもよい。例は、大型組織のための販売実績管理、企業統合、およびビジネス柔軟性についてのソリューションを提供するサービスを、何ら限定されることなく含む。
【００３７】
いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介して、クラウドインフラストラクチャシステム１０２によって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例は、（オラクルなどの）組織が共有の共通アーキテクチャ上で既存のアプリケーションを統合できるようにするサービスと、プラットフォームによって提供される共有のサービスを活用する新しいアプリケーションを構築するための能力とを、何ら限定されることなく含んでいてもよい。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための根底的なソフトウェアおよびインフラストラクチャを管理し、制御してもよい。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステム１０２によって提供されるＰａａＳサービスを取得できる。プラットフォームサービスの例は、オラクル社からの「オラクルＪａｖａクラウド・サービス」（Java Cloud Service：ＪＣＳ）、オラクル社からの「オラクル・データベース・クラウド・サービス」（Database Cloud Service：ＤＢＣＳ）などを、何ら限定されることなく含む。
【００３８】
ＰａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム１０２によってサポートされるプログラミング言語およびツールを採用するとともに、デプロイメントされたサービスを制御することができる。いくつかの実施形態では、クラウドインフラストラクチャシステム１０２によって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえば、オラクル・フュージョン・ミドルウェア（Oracle Fusion Middleware）サービス）、およびＪａｖａクラウドサービスを含んでいてもよい。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形をしたデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発してデプロイメントするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイメントするためのプラットフォームを提供してもよい。
【００３９】
クラウドインフラストラクチャシステム１０２において、さまざまな異なるインフラストラクチャサービスが、ＩａａＳプラットフォームによって提供されてもよい。これらのインフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のための、ストレージ、ネットワーク、ならびに他の基礎的コンピューティングリソースなどの根底的なコンピューティングリソースの管理および制御を容易にする。
【００４０】
ある実施形態では、クラウドインフラストラクチャシステム１０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえば、ＳａａＳ、ＰａａＳ、ＩａａＳ、およびＭＢａａＳサービス）の包括的管理を提供してもよい。一実施形態では、クラウド管理機能性は、クラウドインフラストラクチャシステム１０２によって受信された顧客のサブスクリプションをプロビジョニングし、管理し、追跡するための能力などを含んでいてもよい。さまざまな実施形態では、クラウドインフラストラクチャシステム１０２は、クラウドインフラストラクチャシステム１０２によって提供されるサービスへの顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するように適合されてもよい。顧客は、クラウドインフラストラクチャシステム１０２によって提供される１つ以上のサービスを、サブスクリプションオーダーを介してオーダーしてもよい。クラウドインフラストラクチャシステム１０２は次に、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を行なう。
【００４１】
一実施形態では、クラウド管理機能性は、オーダー管理および監視モジュール１１４などの１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せであり得る、１つ以上のコンピュータおよび／またはサーバを含んでいてもよく、もしくはそれらを使用して提供されてもよい。
【００４２】
例示的な動作では、クライアントコンピューティングデバイス１０４、１０６または１０８を使用する顧客は、クラウドインフラストラクチャシステム１０２によって提供される１つ以上のサービスを要求することにより、クラウドインフラストラクチャシステム１０２と対話してもよい。顧客は、さまざまな手段を使用して、サービス要求１３４をクラウドインフラストラクチャシステム１０２に発行してもよい。サービス要求１３４は、クラウドインフラストラクチャシステム１０２によって提供される１つ以上のサービスについてサブスクリプションオーダーを出すこと、クラウドインフラストラクチャシステム１０２によって提供される１つ以上のサービスにアクセスすること、などを含んでいてもよい。ある実施形態では、顧客は、クラウドＵＩ１３２、１３４、１３８にアクセスし、これらのＵＩを介してサブスクリプションオーダーを出してもよい。顧客がオーダーを出したことに応答してクラウドインフラストラクチャシステム１０２が受信したオーダー情報は、顧客を識別する情報と、顧客が申し込むつもりである、クラウドインフラストラクチャシステム１０２によって提供される１つ以上のサービスを識別する情報とを含んでいてもよい。顧客によってオーダーが出された後で、オーダー情報がクラウドＵＩ１３２、１３４、および／または１３８を介して受信される。
【００４３】
この例では、オーダー管理および監視モジュール１１２が、顧客から受信した情報をオーダーデータベースへ送信して、顧客によって出されたオーダーを格納させる。オーダーデータベースは、クラウドインフラストラクチャシステム１０２によって動作され、他のシステム要素とともに動作される、いくつかのデータベースのうちの１つであり得る。オーダー管理および監視モジュール１１２は、オーダーデータベースに格納されたオーダー情報のすべてまたは一部を含む情報をオーダー管理モジュールへ発送してもよい。場合によっては、オーダー管理モジュールは、オーダーを検証し、検証後にオーダーを予約するといった、オーダーに関連する請求および課金機能を行なうように構成されてもよい。
【００４４】
ある実施形態では、クラウドインフラストラクチャシステム１００は、アイデンティティ管理モジュール１１４を含んでいてもよい。アイデンティティ管理モジュール１１４は、クラウドインフラストラクチャシステム１０２においてアクセス管理および認証サービスなどのアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態では、アイデンティティ管理モジュール１１４は、クラウドインフラストラクチャシステム１０２によって提供されるサービスを利用したい顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのアクションを行なうことが認可されているかを記述する情報とを含み得る。アイデンティティ管理モジュール１１４はまた、各顧客についての記述的情報と、その記述的情報が誰によってどのようにアクセスされ、修正され得るかについての記述的情報との管理を含んでいてもよい。
【００４５】
ある実施形態では、クラウドインフラストラクチャシステム１０２はまた、クラウドインフラストラクチャシステム１０２の顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース１１６を含んでいてもよい。一実施形態では、インフラストラクチャリソース１１６は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージ、およびネットワーキングリソースといったハードウェアの予め統合され最適化された組合せを含んでいてもよい。
【００４６】
いくつかの実施形態では、クラウドインフラストラクチャシステム１０２におけるリソースは、複数のユーザによって共有され、要望ごとに動的に再割当てされてもよい。加えて、リソースは、異なる時間帯におけるユーザに割当てられてもよい。たとえば、クラウドインフラストラクチャシステム１０２は、第１の時間帯における第１の一組のユーザが、特定数の時間、クラウドインフラストラクチャシステムのリソースを利用することを可能にし、次に、異なる時間帯に位置する別の一組のユーザへの同じリソースの再割当てを可能にして、それによりリソースの利用を最大化してもよい。
【００４７】
ある実施形態では、クラウドインフラストラクチャシステム１０２の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム１０２が提供するサービスによって共有される、多くの内部共有サービス１１８が提供されてもよい。これらの内部共有サービス１１８は、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウィルススキャニングおよびホワイトリストサービス、高可用性、バックアップおよび復元サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを、何ら限定されることなく含んでいてもよい。
【００４８】
ある実施形態では、クラウドインフラストラクチャシステム１０２の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム１０２が提供するサービスによって共有される、多くの外部共有サービス１２０が提供されてもよい。これらの外部共有サービス１２０は、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウィルススキャニングおよびホワイトリストサービス、高可用性、バックアップおよび復元サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを、何ら限定されることなく含んでいてもよい。
【００４９】
さまざまな実施形態では、外部共有サービス１２０は、アクセス、データ変換、自動化などをエンタープライズコンピュータシステム１２６に提供する１つ以上のコンポーネントを含んでいてもよい。エンタープライズコンピュータシステム１２６へのアクセスは、クラウドインフラストラクチャシステム１０２の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム１０２が提供するサービスによって、共有されてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム１２６へのアクセスは、１人以上のサブスクライバに制限される、クラウドインフラストラクチャシステム１０２が提供するサービスインスタンスによって、共有されてもよい。
【００５０】
さらなる実施形態では、外部共有サービス１２０は、クラウドインフラストラクチャシステム１０２の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム１０２が提供するサービスによって共有される、外部アプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）サービス１２８を含んでいてもよい。これらの外部ＡＰＩサービス１２８は、他の第三者サービスまたはエンティティによって提供されるＡＰＩを、何ら限定されることなく含んでいてもよい。
【００５１】
クラウドインフラストラクチャシステム１０２では、ＭＣＳ１２２によって、さまざまな異なるモバイルクラウドサービスが提供されてもよい。本発明のいくつかの実施形態によれば、ＭＣＳ１２２は、モバイルコンピューティングデバイスとエンタープライズコンピュータシステム（たとえば、エンタープライズコンピュータシステム１２４および１２６）との間の通信を容易にする。ＭＣＳ１２２は、エンタープライズデータおよび認証情報を格納するために使用される１つ以上のメモリ記憶装置（ローカルストレージ）を含んでいてもよい。エンタープライズデータは、エンタープライズコンピュータシステム１２６から、あるいはクライアントコンピューティングデバイス１０４、１０６、または１０８から受信されてもよく、もしくは、クラウドインフラストラクチャシステム１０２によって変換されたエンタープライズデータを含んでいてもよく、もしくはそれらの組合せであってもよい。認証情報は、アイデンティティ管理システム１１６から受信されてもよく、および／または、クラウドインフラストラクチャシステム１０２によって生成されてもよい。いくつかの実施形態では、認証情報は、サービスについての要求に関するユーザのセキュリティ認証を示す情報を含んでいてもよい。
【００５２】
エンタープライズコンピュータシステム１２６などのエンタープライズコンピュータシステムは、クラウドインフラストラクチャシステム１０２のファイアウォールを越えて、クラウドインフラストラクチャシステム１０２とは異なる地理的場所（たとえば、リモートの地理的場所）に物理的に位置していてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム１２６は、１つ以上の異なるコンピュータまたはサーバを含んでいてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム１２６は、単一のコンピュータシステムの一部であってもよい。
【００５３】
ある実施形態では、エンタープライズコンピュータシステム１２６は、１つ以上の異なるプロトコルを使用して、クラウドインフラストラクチャシステム１０２と通信してもよい。エンタープライズコンピュータシステム１２６の各々は、異なる通信プロトコルを使用して、クラウドインフラストラクチャシステム１０２と通信してもよい。エンタープライズコンピュータシステム１２６は、同じまたは異なるセキュリティプロトコルをサポートしてもよい。いくつかの実施形態では、ＭＣＳ１２２は、エンタープライズコンピュータシステム１２６との通信を取扱うためのエージェントシステムを含んでいてもよい。
【００５４】
プロトコルは、ＳＰｅｅＤＹ（ＳＰＤＹ）などの通信プロトコルを含んでいてもよい。プロトコルは、ＨＴＴＰベースのプロトコルなどのアプリケーションプロトコルを含んでいてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム１２６は、ＲＥＳＴまたはシンプル・オブジェクト・アクセス・プロトコル（Simple Object Access Protocol：ＳＯＡＰ）などの通信プロトコルを使用して、クラウドインフラストラクチャシステム１０２と通信してもよい。たとえば、ＲＥＳＴプロトコルは、ユニフォームリソース識別子（uniform resource identifier：ＵＲＩ）またはユニフォームリソースロケータ（uniform resource locator：ＵＲＬ）を含むフォーマットをサポートしてもよい。ＲＥＳＴプロトコルを使用する通信のためにフォーマット化されたエンタープライズデータは、ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記法（JavaScript Object Notation：ＪＳＯＮ）、コンマ区切り形式（comma-separated values：ＣＳＶ）、およびリアリー・シンプル・シンジケーション（really simple syndication：ＲＳＳ）などのデータフォーマットに容易に変換されてもよい。エンタープライズコンピュータシステム１２６とクラウドインフラストラクチャシステム１０２とは、リモート・プロシージャ・コール（remote procedure call：ＲＰＣ）（たとえば、拡張マークアップ言語（extended markup language：ＸＭＬ）ＲＰＣ）などの他のプロトコルを使用して通信してもよい。
【００５５】
いくつかの実施形態では、ＭＣＳ１２２は、クラウドインフラストラクチャサービス１０２によって提供される１つ以上のサービスとの通信をサポートするように構成されたアダプタインターフェイスを含んでいてもよく、それらのサービスのうちのいくつかは、通信用の異なるプロトコルまたは手法をサポートしてもよい。いくつかの実施形態では、ＭＣＳ１２２は、エンタープライズコンピュータシステム１２６との通信をサポートするように構成されたアダプタインターフェイスを含んでいてもよく、エンタープライズコンピュータシステム１２６のうちのいくつかは、通信用の異なるプロトコルまたは手法をサポートしてもよい。ＭＣＳ１２２は、通信プロトコル、エンタープライズコンピュータシステムのタイプ、アプリケーションのタイプ、サービスのタイプ、またはそれらの組合せに従って通信するように各々構成され得る１つ以上のアダプタを含んでいてもよい。アダプタによってサポートされる通信プロトコルは、サービスに、またはエンタープライズコンピュータシステム１２６のうちの１つ以上に特有のものであってもよい。
【００５６】
ある実施形態では、クライアントコンピューティングデバイス１０４、１０６、および１０８は各々、ＭＣＳ１２２と通信するための特定のＵＩを提供できるアプリケーションを実装してもよい。特定のＵＩは、特定の通信プロトコルを使用して通信するように構成されてもよい。いくつかの実施形態では、特定のＵＩは、ＭＣＳ１２２と通信するために呼出され得る、呼出し可能インターフェイス、機能、ルーチン、方法、および／または動作を含んでいてもよい。特定のＵＩは、エンタープライズデータのために、および／またはサービスを要求するために、クラウドインフラストラクチャサービス１０２によって提供されるサービスと通信するためのパラメータ、またはエンタープライズコンピュータシステム１２６と通信するためのパラメータを、入力として受け入れてもよい。いくつかの実施形態では、ＭＣＳ１２２を通した通信は、カスタム通信プロトコルを使用する通信のために変換されてもよい。いくつかの実施形態では、特定のＵＩは、アプリケーションにおいてカスタムクライアントに対応していてもよい。
【００５７】
ＭＣＳ１２２は、１つ以上の呼出し可能インターフェイス、たとえばＡＰＩを含んでいてもよい。ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは、モバイルコンピューティングデバイス上のアプリケーションがＭＣＳ１２２に要求を通信することを可能にしてもよい。ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは共通または標準インターフェイスをサポートしてもよく、それは、パラメータを含む要求が、標準化プロトコル、アーキテクチャスタイル、および／またはフォーマット（たとえばＲＥＳＴプロトコル）に従って、アプリから受信されることを可能にしてもよい。ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは、コンピューティングデバイス１０４、１０６、または１０８のうちのいずれか１つのユーザによって構成可能であってもよい。ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは、通信プロトコルに従って、サービスについての要求を受信してもよい。デバイスアプリケーション開発者は、自分のカスタムアプリケーションのためにＭＣＳ１２２に接続することができる。いくつかの実施形態では、ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは、アプリを開発したのと同じ人によって構成され、その人が、ＭＣＳ１２２と通信するためのカスタムアプリケーションを実現できるようになっていてもよい。
【００５８】
ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスはさらに、エンタープライズコンピュータシステム１２６が、標準化プロトコルまたはフォーマットに従ってＭＣＳ１２２と通信することを可能にしてもよい。アプリケーション開発者と同様に、エンタープライズコンピュータシステムを管理する人は、１つ以上の呼出し可能インターフェイスを介してＭＣＳ１２２と通信するように構成されたコード（たとえばエージェントシステム）を実現することができる。ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは、コンピューティングデバイスのタイプ、エンタープライズコンピュータシステムのタイプ、アプリ、エージェントシステム、サービス、プロトコル、または他の基準に基づいて実現されてもよい。いくつかの実施形態では、ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは、認証、圧縮、暗号化、カーソルを用いたページネーション、クライアントベースのスロットリング、否認不可、ロギング、およびメトリック収集を含むサービスについての要求をサポートしてもよい。いくつかの実施形態では、ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは、認証、ポリシー実施、応答のキャッシング、ＭＣＳ１２２への呼出しのスロットリング、非同期パターンと同期パターンとの間の翻訳、根底的なサービスへの呼出しのロギング、またはそれらの組合せ、といったカスタムビジネス関連サービスのために実現されてもよい。いくつかの実施形態では、ＭＣＳ１２２に関連付けられた呼出し可能インターフェイスは、ユーザが、クラウドインフラストラクチャシステム１０２による実現のためにカスタムコードをロードすることを可能にしてもよい。カスタムコードは、クラウドインフラストラクチャシステム１０２のために、ＭＣＳ１２２に関連付けられた１つ以上の呼出し可能インターフェイスを実現してもよく、それは、ユーザがカスタムサービスまたは他のエンタープライズコンピュータシステムにアクセスすることを可能にできる。
【００５９】
ＭＣＳ１２２に関連付けられたプロトコルトランスレータは、メッセージを処理して、メッセージ用の通信プロトコルを判断し、および／またはメッセージを宛先用の通信プロトコルに変換してもよい。ＭＣＳ１２２に関連付けられたプロトコルトランスレータは、クライアントコンピューティングデバイス１０４、１０６、または１０８から受信された要求を変換してもよい。要求は、クライアントコンピューティングデバイス１０４、１０６、または１０８によってサポートされる通信プロトコルのフォーマットから、クラウドインフラストラクチャサービス１０２またはエンタープライズコンピュータシステム１２６によって提供されるサービスによってサポートされる通信プロトコルのフォーマットに変換されてもよい。ＭＣＳ１２２に関連付けられたプロトコルトランスレータは、クラウドインフラストラクチャサービス１０２またはエンタープライズコンピュータシステム１２６によって提供されるサービスから受信された応答を変換してもよい。応答は、クラウドインフラストラクチャサービス１０２またはエンタープライズコンピュータシステム１２６によって提供されるサービスによってサポートされる通信プロトコルのフォーマットから、クライアントコンピューティングデバイス１０４、１０６、または１０８によってサポートされる通信プロトコルのフォーマットに変換されてもよい。
【００６０】
ＭＣＳ１２２に関連付けられたセキュリティサービスは、クライアントコンピューティングデバイス１０４、１０６、または１０８のうちのいずれかから受信された要求についてのセキュリティ認証を管理してもよい。ＭＣＳ１２２に関連付けられたセキュリティサービスは、顧客プロセスおよびエンタープライズデータの完全性を保護してもよい。システムまたはデータが損なわれないようにするために、クライアントコンピューティングデバイス１０４、１０６、または１０８から要求が受信されると、セキュリティ認証が起こってもよい。セキュリティ認証は、クラウドインフラストラクチャシステム１０２による処理のために要求が発送される前に行なわれてもよい。あるユーザについて判断されたセキュリティ認証は、モバイルコンピューティングデバイスに関連付けられたユーザが、ＭＣＳ１２２を介してサービスを要求するための認証を有することを可能にしてもよい。セキュリティ認証は、ユーザが、ＭＣＳ１２２を介して要求された異なる要求および／またはサービスについて認証するための労力を減少させてもよい。ＭＣＳ１２２に関連付けられたセキュリティサービスは、要求のセキュリティを認証するさまざまな動作を行なうように構成された１つ以上の機能ブロックまたはモジュールとして実現されてもよい。
【００６１】
ＭＣＳ１２２に関連付けられた認証サービスは、クライアントコンピューティングデバイス１０４、１０６、または１０８から受信された要求についてのセキュリティ認証を管理してもよい。ＭＣＳ１２２に関連付けられた認証サービスは、ＭＣＳ１２２に要求を送信するコンピューティングデバイスに関連付けられたユーザについてセキュリティ認証を判断してもよい。セキュリティ認証は期間に基づいて判断されてもよく、期間は、アプリケーションの動作（たとえば、アプリケーションの起動）、要求、コンピューティングデバイス、エンタープライズコンピュータシステム、要求に関連する他の基準、またはそれらの組合せに結び付けられてもよい。セキュリティ認証は、個々の要求、１つ以上のエンタープライズコンピュータシステム、特定のサービス、サービスのタイプ、ユーザ、コンピューティングデバイス、セキュリティ認証を判断するための他の基準、またはそれらの組合せ、などのうちのいずれか１つについて、検証され付与されてもよい。いくつかの実施形態では、クラウドインフラストラクチャシステム１０２は、エンタープライズコンピュータシステム、またはエンタープライズコンピュータシステムをサポートする認証システムから受信されたユーザの認証情報を格納してもよい。クラウドインフラストラクチャシステム１０２は、要求に関連付けられたユーザのアイデンティティがそのような要求を行なう認可を有するかどうかを判断するためにルックアップ機能を行なうことによって、認証を判断してもよい。格納された認証情報は、ユーザがアクセスすることを認可され得る、要求、機能、エンタープライズコンピュータシステム、エンタープライズデータなどのタイプといった情報を含んでいてもよい。いくつかの実施形態では、インフラストラクチャシステム１０２は、認証を判断するために、要求元コンピューティングデバイスとの通信を起動してもよい。
【００６２】
いくつかの実施形態では、セキュリティ認証は、サービスを要求するユーザに関連付けられた役割に基づいて判断されてもよい。役割は、ＭＣＳ１２２へのアクセスを要求するユーザに関連付けられてもよい。いくつかの実施形態では、ユーザは、ＭＣＳ１２２によって提供されるリソースおよび／またはサービスへのアクセスを付与され得るＭＣＳ１２２のサブスクライバまたはテナントとして、サービスを要求してもよい。認証は、ユーザがサブスクライバとしてＭＣＳ１２２を介してサービスを要求することが認可され得るように、ＭＣＳ１２２へのユーザのサブスクリプションに対応していてもよい。いくつかの実施形態では、サブスクリプションは、ＭＣＳ１２２によって提供される特定の一組のリソースに限定されてもよい。セキュリティ認証は、ＭＣＳ１２２のユーザがアクセス可能なリソースおよび／またはサービスに基づいていてもよい。いくつかの実施形態では、「実行時環境」と呼ばれる実行中に、要求にテンプレートがプロビジョニングされてもよい。実行時環境は、要求、ユーザ、またはデバイスに割当てられるリソースに関連付けられてもよい。
【００６３】
いくつかの実施形態では、ＭＣＳ１２２に関連付けられた認証サービスは、アイデンティティ管理システムに、ユーザについてセキュリティ認証を判断するよう要求してもよい。アイデンティティ管理システムは、クラウドインフラストラクチャシステム１０２によって（たとえばアイデンティティ管理１１４として）実現されてもよく、または、クラウドインフラストラクチャシステム１０２の外部の別のコンピュータシステムによって実現されてもよい。アイデンティティ管理１１６は、ＭＣＳ１２２にアクセスするためのユーザの役割またはサブスクリプションに基づいて、ユーザのセキュリティ認証を判断してもよい。役割またはサブスクリプションには、エンタープライズコンピュータシステム、エンタープライズコンピュータシステムによって提供されるサービス、エンタープライズコンピュータシステムの機能または特徴、エンタープライズコンピュータシステムへのアクセスを制御するための他の基準、またはそれらの組合せに対する特権および／または権利が割当てられてもよい。
【００６４】
ＡＤＦ
クラウドインフラストラクチャシステム１０２では、さまざまな異なるＡＤＦ１２４が提供されてもよい。ＡＤＦ１２４は、アジャイルなＳＯＡベースのアプリケーションを実装するためにインフラストラクチャコードを提供する。ＡＤＦ１２４はさらに、１つ以上の開発ツール（たとえば、「オラクルJDeveloper 11g」開発ツール）を通して、開発への視覚的および宣言的アプローチを提供する。ＡＤＦ１２４によって提供される１つ以上のフレームワークは、ＭＶＣ設計パターンを実装してもよい。そのようなフレームワークは、ＭＶＣアーキテクチャのすべての層を、オブジェクト／リレーショナルマッピング、データ持続、再使用可能なコントローラ層、リッチなウェブＵＩフレームワーク、ＵＩへのデータバインディング、セキュリティおよびカスタム化などのエリアに対するソリューションでカバーする、統合的ソリューションを提供する。コアウェブベースのＭＶＣアプローチを超えて、そのようなフレームワークはまた、オラクルＳＯＡおよびウェブセンターポータル（WebCenter Portal）フレームワークと統合して、完全な複合アプリケーションの作成を単純化する。
【００６５】
ある実施形態では、ＡＤＦ１２４は、クラウドインフラストラクチャシステム１０２によって提供されるビルトインビジネスサービスにサービスインターフェイスを結合することによって、サービスとしてデータを公開するアジャイルなアプリケーションを開発することを容易にする。ビジネスサービス実装詳細のこの分離は、ＡＤＦ１２４においてメタデータを介して行なわれる。このメタデータ駆動型アーキテクチャの使用により、アプリケーション開発者は、サービスがどのようにアクセスされるかの詳細にではなく、ビジネスロジックおよびユーザ体験に集中できるようになる。ある実施形態では、ＡＤＦ１２４は、サービスの実装詳細を、モデル層におけるメタデータに格納する。これにより、開発者は、ＵＩを修正することなくサービスを交換できるようになり、アプリケーションが非常にアジャイルになる。加えて、ＵＩを作成する開発者は、ビジネスサービスアクセス詳細に悩まされる必要がない。代わりに、開発者は、アプリケーションインターフェイスおよび対話ロジックの開発に集中することができる。ユーザ体験を作り出すことは、ビジュアルページデザイナ上に所望のビジネスサービスをドラッグ・アンド・ドロップし、どのタイプのコンポーネントがそのデータを表わすべきかを示すのと同じくらい単純であり得る。
【００６６】
さまざまな実施形態では、開発者はＡＤＦ１２４と対話して、エンタープライズアプリケーションを形成するモジュールを作成する。エンタープライズアプリケーションは、クラウドインフラストラクチャシステム１０２のコンテキスト内で実行され得る。さまざまな実施形態では、開発者はＡＤＦ１２４と対話して、モバイルアプリケーションを形成するモジュールを作成する。モバイルアプリケーションは、クラウドインフラストラクチャシステム１０２のコンテキスト内で実行され得る。以下に説明されるこの発明の特徴は、ここに提供される開示を読むことによって当業者には明らかであるように、プログラミング言語とアプリケーション開発フレームワークとの任意の所望の組合せを使用して実現されてもよい。
【００６７】
ＡＤＦ１２４によって提供される１つ以上のフレームワークは、一例ではオラクルＡＤＦとして具現化され得る。したがって、ＡＤＦ１２４におけるフレームワークは、ＭＶＣ設計パターンに基づき得る。ＭＶＣアプリケーションは、１）データソースとの対話を取扱い、ビジネスロジックを実行するモデル層と、２）アプリケーションＵＩを取扱うビュー層と、３）アプリケーションフローを管理し、モデル層とビュー層との間のインターフェイスとして作用するコントローラとに分離される。これら３つの層にアプリケーションを分離することは、アプリケーション間にわたるコンポーネントの保守および再使用を単純化する。各層の他の層からの独立は、緩く結合されたＳＯＡをもたらす。
【００６８】
さまざまな実施形態では、ＡＤＦ１２４は、開発者がアプリケーションを多層の形で作成することを可能にするツールおよびリソースを提供し、各層は、予め定義された仕様に従って所望のロジックを実現するコードモジュール／ファイルを含む。このため、一実施形態では、ＡＤＦ１２４は、アプリケーションが、アプリケーションのＵＩを提供するコードモジュール／ファイルを含むビュー層と、アプリケーションのフローを制御するコードモジュールを含むコントローラ層と、根底的なデータのための抽象化層を提供するデータ／コードモジュールを含むモデル層と、さまざまなソースからのデータへのアクセスを提供し、ビジネスロジックを取扱うコードモジュールを含むビジネスサービス層という４つの層として開発されることを可能にする。
【００６９】
ある実施形態では、ＡＤＦ１２４は、開発者に、層の各々を実装する際に自分が使用したい技術を選択させる。エンタープライズＪａｖａＢｅａｎ（Enterprise JavaBean：ＥＪＢ）（登録商標）、ウェブサービス（Web Services）、ＪａｖａＢｅａｎｓ、ＪＰＡ／エクリプスリンク（EclipseLink）／トップリンク（TopLink）オブジェクト、および他の多くがすべて、ＡＤＦ１２４のためのビジネスサービスとして使用可能である。ビュー層は、Ｊａｖａサーバ・フェイス（Java Server Faces：ＪＳＦ）、デスクトップ・スイング（Desktop Swing）アプリケーション、およびマイクロソフト・オフィス・フロントエンドを用いて実現されるウェブベースのインターフェイスと、モバイル装置用のインターフェイスとを含み得る。
【００７０】
一局面では、ビュー層は、開発中のアプリケーションのＵＩを表わす。ビュー層は、デスクトップビュー、モバイルビュー、およびブラウザベースのビューを含んでいてもよく、それらの各々はＵＩのすべてまたは一部を提供するとともに、ビュータイプに対応するさまざまな態様でアクセス可能である。たとえば、ウェブページが、対応するＵＲＬを含むクライアント要求を受信することに応答して、アプリケーションによって送信されてもよい。ウェブページは次に、要求元クライアントシステムに関連付けられた表示部（図示せず）上にブラウザによって表示されてもよく、それにより、要求元クライアントシステムのユーザがエンタープライズアプリケーションと対話することを可能にする。ＡＤＦ１２４は、ビジネスサービスの再使用を可能にするビジネスサービスへのマルチチャネルアクセスと、ウェブクライアント、クライアント・サーバ・スイング・デスクトップベース・アプリケーション（client-server swing desktop-based application）、マイクロソフト・エクセル・スプレッドシート、スマートフォンなどのモバイルデバイス、などからのアクセスとをサポートする。
【００７１】
（ウェブページなどの）ビュー層を形成するコードファイル／モジュールは、ハイパーテキストマークアップ言語（hypertext markup language：ＨＴＭＬ）、Ｊａｖａサーバ・ページ（Java server page：ＪＳＰ）、およびＪＳＦのうちの１つ以上を使用して実現されてもよい。それに代えて、ＵＩは、スイング（Swing）などのＪａｖａコンポーネント、および／またはＸＭＬを使用して実現されてもよい。さらに述べられるように、ＵＩは、マイクロソフトによるワードおよびエクセルなどのデスクトップアプリケーションについてのユーザの体験および習熟を活用してもよい。
【００７２】
上述のように、ユーザが開発した関連するコード／データモジュールが、層の各々において提供される。しかしながら、各層は典型的には、ＡＤＦ１２４によって提供される他の予め定義されたコード／データモジュールを含む。予め定義されたモジュールのうちのいくつかは、たとえば、ウェブページを開発するためのテンプレート、開発されたコードに所望の機能性を含めるためのテンプレートなどとして、開発中に使用されてもよい。（ＵＲＬ書換モジュールなどの）他の予め定義されたモジュールが、開発されたアプリケーションとともにデプロイメントされてもよく、エンタープライズアプリケーションの実行中に追加の機能性（要求されたＵＲＬの、内部名へのマッピング）をユーザに提供してもよい。
【００７３】
コントローラ層は、アプリケーションのフローを制御するコードモジュール／ファイルを含む。各コントローラオブジェクトは、ビュー層において情報を提示する所望の態様に従って実現されたソフトウェア命令および／またはデータを含む。所望の態様は、別のウェブページにおけるリンクがユーザによってクリック／選択されると表示される特定のウェブページ、実行中にエラーが起こると表示される、格納／検索すべき特定のデータを示すページなどを含んでいてもよい。
【００７４】
一局面では、コントローラ層はアプリケーションのフローを管理し、ユーザ入力を取扱う。たとえば、ページ上でサーチボタンがクリックされると、コントローラは、どのアクションを行なうべきか（サーチを行なう）と、どこにナビゲートすべきか（結果ページ）とを判断する。JDeveloperでは、ウェブベースのアプリケーションについて、標準のＪＳＦコントローラ、またはＪＳＦコントローラ機能性を拡張するＡＤＦコントローラという２つのコントローラオプションがある。どちらのコントローラが使用されても、アプリケーションフローは典型的には、ページおよびナビゲーションルールをダイアグラム上にレイアウトすることによって設計される。アプリケーションのフローは、より小さい再使用可能タスクフローに分割可能であり、方法呼出しおよび判定ポイントなどの非視覚的コンポーネントをフローに含めることでき、単一の含有ページの領域内で実行される「ページフラグメント」フローを作成することができる。
【００７５】
コントローラ層を形成するコードモジュール／ファイルはしばしば、クライアント要求を受信するととともに対応する応答として所望のウェブページを送信するＪａｖａサーブレットとして実現される。コントローラオブジェクトはまた、たとえば、アパッチ・ジャカルタ・ストラット（Apache Jakarta Struts）コントローラとして、またはＪＳＦ規格に従って実現されてもよい。
【００７６】
モデル層は、さまざまなビジネスサービスを、それらを他の層で使用するオブジェクトに、たとえば上述のコントローラオブジェクトに、または直接デスクトップアプリケーションに接続する、データ／コードモジュールを含む。モデル層の各抽象データオブジェクトは、任意のタイプのビジネスサービスにアクセスするために使用され得る対応するインターフェイスを提供し、根底的なビジネスサービス層で実行される。データオブジェクトは、クライアントからのサービスのビジネスサービス実装詳細を抽象化し、および／または、データ制御方法／属性をビューコンポーネントに公開してもよく、このため、ビュー層とデータ層との分離を提供する。
【００７７】
一局面では、モデル層は、データ制御およびデータバインディングという２つのコンポーネントからなり、それらは、インターフェイスを定義するためにメタデータファイルを利用する。データ制御は、クライアントからのビジネスサービス実装詳細を抽象化する。データバインディングは、データ制御方法および属性をＵＩコンポーネントに公開し、ビューとモデルとのクリーンな分離を提供する。モデル層のメタデータアーキテクチャにより、開発者は、任意のタイプのビジネスサービス層実装をビュー層およびコントローラ層にバインドする際に、同じ開発体験を得る。
【００７８】
ある実施形態では、ＡＤＦ１２４は、開発プロセス全体にわたって宣言的プログラミングパラダイムの使用を強調して、ユーザが、実現詳細に手をつける必要なく、アプリケーション作成のロジックに集中できるようにする。高レベルでは、フュージョン・ウェブ（Fusion Web）アプリケーションのための開発プロセスは通常、アプリケーションワークスペースを作成することを伴う。ウィザードを使用して、開発者が選択した技術にとって必要なライブラリおよび構成が自動的に追加され、アプリケーションが、パッケージおよびディレクトリを有するプロジェクトへと構造化される。
【００７９】
データベースオブジェクトをモデル化することにより、オンラインデータベースまたは任意のデータベースのオフラインレプリカが作成可能であり、定義が編集可能であり、スキーマが更新可能である。統一モデリング言語（unified modeling language：ＵＭＬ）モデラーを使用して、使用事例が次に、アプリケーションのために作成可能である。アプリケーション制御およびナビゲーションも設計可能である。アプリケーション制御およびナビゲーションのフローを視覚的に判断するために、ダイアグラマ（diagrammer）が使用可能である。次に、フローを記述する根底的なＸＭＬファイルが自動的に作成可能である。開発者が、インポートされたライブラリを、アプリケーションに単純にドラッグ・アンド・ドロップすることによって閲覧および使用することを可能にするために、リソースライブラリが使用可能である。データベーステーブルから、エンティティオブジェクトが、ウィザードまたはダイアログを使用して作成可能である。それらのエンティティオブジェクトから、ビューオブジェクトが、アプリケーションにおけるページによって使用されるように作成される。検証ルールおよび他のタイプのビジネスロジックが実現可能である。
【００８０】
この例では、ビジネスサービス層は、データ持続層との対話を管理する。それは、データ持続、オブジェクト／リレーショナルマッピング、トランザクション管理、およびビジネスロジック実行などのサービスを提供する。ビジネスサービス層は、シンプルＪａｖａクラス、ＥＪＢ、ウェブサービス、ＪＰＡオブジェクト、およびオラクルＡＤＦビジネスコンポーネント（Oracle ADF Business Components）といったオプションのうちのいずれかで実装可能である。加えて、データは、ファイル（ＸＭＬまたはＣＳＶ）およびＲＥＳＴから直接消費され得る。このため、各ビジネスサービスは、対応するデータ持続層との対話を管理し、また、オブジェクト／リレーショナルマッピング、トランザクション管理、ビジネスロジック実行などのサービスを提供する。ビジネスサービス層は、シンプルＪａｖａクラス、エンタープライズＪａｖａＢｅａｎｓ、ウェブサービスなどのうちの１つ以上を使用して実装されてもよい。
【００８１】
ビジネスコンポーネントは、データベース、ウェブサービス、レガシーシステム、アプリケーションサーバなどとの対話を提供するために、たとえばオラクル社からの「オラクルＡＤＦビジネスコンポーネント」を使用して実装されるビジネスサービスを表わす。一実施形態では、ビジネスサービス層のビジネスコンポーネントは、ビジネスサービス実装を提供するために協働するアプリケーションモジュール、ビュー／クエリオブジェクト、およびエンティティオブジェクトの混合を含む。アプリケーションモジュールは、アプリケーション／トランザクションデータと連携するためにＵＩクライアントが通信するトランザクションコンポーネント／コードモジュールであり得る。アプリケーションモジュールは、更新可能なデータモデルを提供してもよく、また、ユーザトランザクションに関する手順／機能（一般にサービス方法と呼ばれる）を提供してもよい。
【００８２】
エンティティオブジェクトは、データベーステーブルにおける対応する行を表わしてもよく、対応する行に格納されたデータの操作（更新、削除など）を単純化してもよい。エンティティオブジェクトはしばしば、所望のビジネスルールが一貫して実施されることを保証するために、対応する行のためのビジネスロジックをカプセル化する。エンティティオブジェクトはまた、根底的なデータベースに格納された行間に存在する関係を反映するように、他のエンティティオブジェクトに関連付けられてもよい。
【００８３】
図２は、本発明のいくつかの実施形態に従った、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通信を容易にするためのコンピューティング環境２００のブロック図を示す。例示の目的のために、さまざまな例が、モバイルコンピューティングデバイス（たとえば、コンピューティングデバイス２０２）がクラウドエンタープライズコンピュータシステム２４０（たとえば、「serviceprovider.com」）および構内エンタープライズコンピュータシステム２５０などの１つ以上のエンタープライズコンピュータシステムと通信できるようにするための手法を説明するためにここに提供される。そのような通信は、エンタープライズデータを交換または転送すること、エンタープライズコンピュータシステムによって提供されるサービスを要求すること、メッセージを通信すること、もしくはそれらの組合せであってもよい。
【００８４】
メッセージは、サービス呼出しメッセージ、結果メッセージ、要求メッセージ、内部で通信される他のメッセージ、コンピューティングデバイスとエンタープライズコンピュータシステムとの間で通信される他のメッセージ、またはそれらの組合せを含んでいてもよい。メッセージは、メッセージタイプ（たとえば、一組の共有タイプの定数からのタイプ値）、相関ｉｄ（たとえば、このメッセージを１つ以上の他のメッセージと相関させるために使用されるｉｄ）、優先順位ベースのメッセージキューについてサポートするための優先順位情報、タイムアウト、メッセージデータ分離をサポートするための感度指標、メッセージソース（たとえば、送信側のユニフォームリソース識別子）、メッセージ宛先（たとえば、宛先を一意的に識別するユニフォームリソース識別子）、要求コンテキスト（たとえば、ディスパッチャからの要求情報）、および／または、メッセージペイロードを含んでいてもよい。ペイロードは、パラメータデータおよび結果データといった送信中のメッセージのタイプに依存して、異なる属性を有していてもよい。
【００８５】
ここに説明されるようなエンタープライズデータは、エンタープライズコンピュータシステムから受信されるデータ、エンタープライズコンピュータシステムへ送信されるデータ、エンタープライズコンピュータシステムによって処理されるデータ、またはそれらの組合せを含んでいてもよい。エンタープライズデータは、消費者アプリケーションおよび／またはサービスについてのデータとは区別可能であってもよい。いくつかの実施形態では、たとえば、エンタープライズデータはエンタープライズデータの適用または使用に基づいて変化してもよく、一方、消費者アプリケーションについてのデータ（たとえば、消費者データ）は使用を通して静的なままであってもよい。ある実施形態では、エンタープライズデータは、そのエンタープライズデータを格納、使用、および／または管理するための基準を示すルールを含んでいてもよく、または当該ルールに関連付けられてもよい。たとえば、エンタープライズデータは、そのエンタープライズデータを格納、使用、および／または管理するための１つ以上のポリシーを示すポリシー情報に関連付けられてもよい。ある実施形態では、ポリシー情報は、エンタープライズデータに含まれていてもよい。ある実施形態では、エンタープライズデータは、エンタープライズコンピュータシステムにおいて実行されるアプリケーションまたはサービスによって処理、格納、使用、または通信されるデータを含んでいてもよい。たとえば、エンタープライズデータは、エンタープライズアプリケーションからのＪＳＯＮフォーマット化データ、構造化データ（たとえば、キー値ペア）、非構造化データ（たとえば、アプリケーションによって処理または使用される内部データ、ＪＳＯＮフォーマットのデータ、ソーシャルポスト、会話ストリーム、アクティビティフィードなど）、バイナリラージオブジェクト（binary large object：ＢＬＯＢ）、文書、システムフォルダ（たとえば、サンドボックス環境におけるアプリケーション関連フォルダ）、ＲＥＳＴ手法を使用したデータ（ここでは「ＲＥＳＴfulなデータ」と呼ばれる）（たとえば、ＲＥＳＴエンドポイントによって利用可能にされる同期データ）、システムデータ、構成データ、同期データ、またはそれらの組合せ、といったビジネスデータ（たとえば、ビジネスオブジェクト）を含んでいてもよい。いくつかの実施形態では、エンタープライズデータは、ＲＥＳＴフォーマット化されたエンタープライズデータを含んでいてもよい。ＲＥＳＴフォーマット化されたエンタープライズデータは、ＲＥＳＴfulなデータを含んでいてもよい。ＲＥＳＴフォーマット化されたデータは、エンタープライズコンピュータシステムによって実現されるＲＥＳＴ手法に従ってフォーマット化されたデータを含んでいてもよい。構成データまたは同期データは、バージョン、履歴、統合データなどといった、エンタープライズデータの同期のために使用されるデータを含んでいてもよい。エンタープライズデータにおける文書は、ＸＭＬファイル、ビジュアルアセット、構成ファイル、メディアアセットなどを含んでいてもよい。ＢＬＯＢは、画像、マルチメディアオブジェクト、または実行可能コードといった、データベース管理システムにお��る単一のエンティティとして、もしくは当該技術分野において他の態様で公知であるものとして格納された、バイナリデータの集合を含んでいてもよい。
【００８６】
エンタープライズコンピュータシステムは、エンティティまたはエンタープライズのために動作するように構成されたさまざまなコンピューティングシステムを含んでいてもよい。たとえば、エンタープライズコンピュータシステムは、サービスについての要求を処理するための、エンタープライズサーバコンピュータ（たとえば、バックエンドサーバコンピュータ）といった１つ以上のコンピュータシステムを含んでいてもよい。エンタープライズコンピュータシステムは、エンタープライズデータを使用して処理および／または動作できるアプリケーションおよび／またはサービスを含んでいてもよい。たとえば、エンタープライズコンピュータシステム２５０は、エンタープライズを管理または動作させるための１つ以上のサービスおよび／またはアプリケーションを提供してもよい。サービスは、顧客関係管理（customer relationship management：ＣＲＭ）、人的資本管理（human capital management：ＨＣＭ）、人的資源（human resource：ＨＲ）管理、サプライチェーン管理、エンタープライズ通信、電子メール通信、ビジネスサービス、他のエンタープライズ管理サービスまたはアプリケーション、もしくはそれらの組合せを、制限なしで含んでいてもよい。エンタープライズコンピュータシステム２５０は、１つ以上のサービスを提供するための専用の１つ以上のコンピュータシステムを含んでいてもよい。いくつかの実施形態では、あるサービスを提供する異なる各コンピュータシステムが、エンタープライズの構内に位置していてもよく、またはエンタープライズからリモートに位置していてもよい。いくつかの実施形態では、異なるサービスをサポートする複数の異なるコンピュータシステムが、エンタープライズの構内といった単一の地理的場所に位置していてもよい。図２に示す例では、構内エンタープライズコンピュータシステム２５０は、ＨＲシステム２５４およびＣＲＭシステム２５６を含んでいてもよく、それらは双方ともエンタープライズの構内に位置していてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム２５０は、クラウドコンピュータシステム２１０と１つ以上のエンタープライズシステム２５４、２５６との間の通信を容易にし、または取扱うために、エージェントシステム２５２を含んでいてもよく、または実装してもよい。クラウドエンタープライズコンピュータシステム２４０および構内エンタープライズコンピュータシステム２５０などのエンタープライズコンピュータシステムについて、以下にさらに詳細に説明する。
【００８７】
コンピュータ環境２００は、コンピューティングデバイス２０２と１つ以上のエンタープライズコンピュータシステムとの間の通信を容易にし得るセキュアな仲介コンピューティング環境として動作するように実現されたＭＣＳ２１２を含んでいてもよい。なぜなら、コンピューティングデバイス２０２は、そのようなエンタープライズコンピュータシステムと通信するように構成されていないかもしれないためである。たとえば、いくつかのエンタープライズコンピュータシステムは、レガシーまたはバックエンドコンピュータシステムによってサポートされてもよい。そのようなシステムは、さまざまな通信および／またはセキュリティプロトコルを使用して動作するように構成されてもよい。そのようなエンタープライズコンピュータシステムによってサポートされるプロトコルは、モバイルコンピューティングデバイスによってサポートされるものとは異なっていてもよい。ＭＣＳ２１２は、さまざまなタイプのモバイルコンピューティングデバイスとの通信をサポートしてもよい。そのため、ＭＣＳ２１２は、エンタープライズコンピュータシステムとモバイルコンピューティングデバイスとの間の通信を容易にするための手法を実現して、それらが、フォーマットまたは通信プロトコル間の違いといった、通信におけるそれらの非互換性にもかかわらず、互いに通信できるようにしてもよい。たとえば、ＭＣＳ２１２は、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間で通信プロトコルを翻訳してもよい。
【００８８】
クラウドコンピュータシステム２１０は、ＭＣＳ２１２をサポートしてもよい。クラウドコンピュータシステム２１０は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せを使用して実現されてもよい。たとえば、クラウドコンピュータシステム２１０は、サーバコンピュータなどの１つ以上のコンピューティングデバイスを含んでいてもよい。クラウドコンピュータシステム２１０は、１つ以上のメモリ記憶装置と、１つ以上のプロセッサとを含んでいてもよい。メモリ記憶装置は、プロセッサにアクセス可能であってもよく、そこに格納された命令を含んでいてもよく、命令は、プロセッサによって実行されると、プロセッサに、ここに開示された１つ以上の動作を実行させる。いくつかの実施形態では、メモリ記憶装置はローカルストレージ（たとえばキャッシュ）として動作してもよい。クラウドコンピュータシステム２１０は、さまざまな種類のオペレーティングシステムを含んでいてもよい。メモリ記憶装置は、プロセッサにアクセス可能であってもよく、そこに格納された命令を含んでいてもよく、命令は、プロセッサによって実行されると、プロセッサに、ここに開示された１つ以上の動作、方法、またはプロセスを実行させる。メモリ記憶装置はローカルストレージとして動作してもよい。ローカルストレージは、メモリ記憶装置または他のコンピュータ読取可能記憶媒体といった任意のタイプの永続的記憶装置を使用して実現されてもよい。いくつかの実施形態では、ローカルストレージは、１つ以上のデータベース（たとえば、文書データベース、リレーショナルデータベース、または他のタイプのデータベース）、１つ以上のファイルストア、１つ以上のファイルシステム、またはそれらの組合せを含んでいてもよく、もしくは実現してもよい。ローカルストレージはエンタープライズデータを格納してもよい。
【００８９】
ある実施形態では、クラウドコンピュータシステム２１０は、メタデータリポジトリ２２４、診断ストア１２６、および解析ストア２２８といった、１つ以上のデータストアを含んでいてもよい。データストア２２４、２２６、２２８は、クラウドコンピュータシステム２１０におけるどのコンポーネントによってもアクセス可能であってもよい。
【００９０】
メタデータリポジトリ２２４は、ＭＣＳ２１２に関連付けられたメタデータをすべて格納してもよい。この情報は、利用可能性および性能に対する独自の要件を各々有する、実行時データおよび設計時データの双方で構成されてもよい。ＭＣＳ２１２のテナントまたはサブスクライバは、任意の数のアプリケーションを有していてもよい。各アプリケーションはバージョン管理されてもよく、それらのリソースＡＰＩが契約する、関連付けられたゼロ以上のバージョンのリソースＡＰＩおよびゼロ以上のバージョンのサービス実装を有していてもよい。これらのエンティティは、仮想要求（ｍＡＰＩ）を具体的なサービス実装（サービス）にマッピングするために、実行時が使用するものである。このマッピングは、モバイル開発者が自分のアプリケーションを設計し構築する際に実際の実装サービスを知る必要がないという贅沢、および、サービスバグ修正ごとに新しいアプリケーションを再発行しなければならないとモバイル開発者に要求することもないという贅沢を、モバイル開発者に提供する。メタデータリポジトリ２２４は１つ以上の呼出し可能インターフェイスを格納してもよく、それらはコンピューティングデバイス（たとえばコンピューティングデバイス２０２）によって呼出されてもよい。呼出し可能インターフェイスは、ＭＣＳ２１２との通信を容易にするように、アプリケーションのユーザ（たとえば開発者）によってカスタマイズ可能であってもよい。メタデータリポジトリ２２４は、呼出し可能インターフェイスの１つ以上の構成に対応するメタデータを格納してもよい。メタデータリポジトリ２２４は、呼出し可能インターフェイスを実現するためのメタデータを格納するように構成されてもよい。呼出し可能インターフェイスは、通信用の１つのフォーマット、プロトコル、またはアーキテクチャスタイルと、通信用の別のフォーマット、プロトコル、またはアーキテクチャのスタイルとの間で翻訳するように実現されてもよい。メタデータリポジトリ２２４は、認証されたユーザによって、外部ネットワークを介して修正可能であってもよい。
【００９１】
診断ストア２２６は、ＭＣＳ２１２において生じる処理についての診断情報を格納してもよい。診断ストア２２６は、ＭＣＳ２１２を介して通信されるメッセージとログ情報とを格納してもよい。解析ストア２２８は、システムにおける処理中に取込まれたロギングおよび解析データを格納してもよい。
【００９２】
ＭＣＳ２１２のために、クラウドコンピュータシステム２１０は、そのコンピューティングリソースを利用して、カスタムコード２１６（たとえば、動作、アプリケーション、方法、機能、ルーチンなど）の実行を可能にしてもよい。コンピューティングリソースは、ＭＣＳ２１２のサブスクライバまたはテナントとして関連付けられた特定のユーザに対して、使用のために割当てられてもよい。リソースは、ユーザ、デバイス、アプリケーション、または、サブスクライバに関連する他の基準に対して割当てられてもよい。ＭＣＳ２１２は、エンタープライズコンピュータシステムと通信することを求めるモバイルコンピューティングデバイスの要望に依存して、スケールインまたはスケールアウトされてもよい。ＭＣＳ２１２は、それが、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通常のトラフィックよりも大きいサージおよび一時的期間を取扱うために弾力的であるように構成され得る。いくつかの実施形態では、ＭＣＳ２１２は、通信における要望を満足させるためにコンポーネントが追加または置換され得るようにスケーラビリティをサポートする要素を含んでいてもよい。
【００９３】
コンピューティングデバイス２０２は、エンタープライズコンピュータシステムによって提供されるサービスを要求するためにＭＣＳ２１２と通信してもよい（たとえば、要求メッセージを送信してもよい）。コンピューティングデバイス２０２（たとえばモバイルコンピューティングデバイス）は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せを使用して実現されてもよい。コンピューティングデバイス２０２は、ＭＣＳ２１２を介してエンタープライズコンピュータシステム２４０、２５０と通信してもよい。コンピューティングデバイス２０２は、エンドポイントデバイス、ＰＤＡ、タブレットコンピュータ、ラップトップコンピュータ、モバイルコンピューティングデバイス、デスクトップコンピュータ、ウェアラブルコンピュータ、ページャなどを含んでいてもよく、または当該デバイスとして実現されてもよい。コンピューティングデバイス２０２は、１つ以上のメモリ記憶装置と、１つ以上のプロセッサとを含んでいてもよい。コンピューティングデバイス２０２は、さまざまな種類のオペレーティングシステムを含んでいてもよい。メモリ記憶装置は、プロセッサにアクセス可能であってもよく、そこに格納された命令を含んでいてもよく、命令は、プロセッサによって実行されると、プロセッサに、ここに開示された１つ以上の動作、方法、またはプロセスを実行させる。メモリ記憶装置はローカルストレージとして動作してもよい。ローカルストレージは、メモリ記憶装置または他のコンピュータ読取可能記憶媒体といった任意のタイプの永続的記憶装置を使用して実現されてもよい。いくつかの実施形態では、ローカルストレージは、１つ以上のデータベース（たとえば、文書データベース、リレーショナルデータベース、または他のタイプのデータベース）、１つ以上のファイルストア、１つ以上のファイルシステム、またはそれらの組合せを含んでいてもよく、もしくは実現してもよい。ローカルストレージはエンタープライズデータを格納してもよい。
【００９４】
さまざまな実施形態では、コンピューティングデバイス２０２は、ウェブブラウザ、クライアントアプリケーション、専用クライアントアプリケーションといった１つ以上のアプリケーションを実行し、動作させるように構成されてもよい。アプリケーションは、エンタープライズコンピュータシステムによって提供されるエンタープライズデータおよび／またはサービスのために構成された特定のアプリケーションを含み得る。クライアントアプリケーションは、１つ以上のネットワークを介してアクセス可能であってもよく、または動作されてもよい。アプリケーションは、アプリケーションを動作させるためのグラフィカルＵＩ（ＧＵＩ）を含んでいてもよい。
【００９５】
コンピューティングデバイス２０２は、無線通信を使用する１つ以上の通信ネットワークを介して、ＭＣＳ２１２と通信してもよい。通信ネットワークの例は、モバイルネットワーク、無線ネットワーク、セルラーネットワーク、ＬＡＮ、ワイドエリアネットワーク（wide area network：ＷＡＮ）、他の無線通信ネットワーク、またはそれらの組合せを含んでいてもよい。ある実施形態では、コンピューティングデバイス２０２は、カスタム通信プロトコル（たとえばカスタムプロトコル）を使用して、ＭＣＳ２１２との通信接続２１４を確立してもよい。接続２１４は、クラウドコンピュータシステム２１０を通してＭＣＳ２１２と確立されてもよい。カスタムプロトコルは、ＨＴＴＰベースのプロトコルであってもよい。カスタム通信プロトコルを利用することにより、コンピューティングデバイス２０２は、任意のコンピューティングデバイスプラットフォーム上で動作して、クラウドコンピュータシステム２１０と通信してもよい。
【００９６】
コンピューティングデバイス２０２は、１つ以上の呼出し可能インターフェイス、たとえばＡＰＩを介して、クラウドコンピュータシステム２１０と通信してもよい。呼出し可能インターフェイスは、コンピューティングデバイス２０２上で実現されてもよい。呼出し可能インターフェイスは、カスタムアプリケーションがＭＣＳ２１２と通信できるようにするカスタムアプリケーションのために実現されてもよい。いくつかの実施形態では、呼出し可能インターフェイスは、ＭＣＳ２１２のために開発されてもよい。呼出し可能インターフェイスは、アプリケーションが、プロトコル（たとえば、通信プロトコルもしくは開発プロトコル）および／またはアーキテクチャスタイルもしくはフォーマットの違いに適合する必要なく、ＭＣＳ２１２と通信することを可能にしてもよい。
【００９７】
ＭＣＳ２１２は、要求を処理してカスタムコード２１６を実行するためのセキュアな環境を提供するために、１つ以上のファイアウォール２０４、２３０によって保護されてもよい。コンピューティングデバイス２０２とＭＣＳ２１２との間の通信は、外部通信ファイアウォール２０４によって分離されてもよい。ファイアウォール２０４は、ＭＣＳ２１２へのセキュアなアクセスを容易にするために、クラウドコンピュータシステム２１０と接続されてもよい。ファイアウォール２０４は、クラウドコンピュータシステム２１０とコンピューティングデバイス（たとえばコンピューティングデバイス２０２）との間のメッセージの通信を許可してもよい。そのようなメッセージ（たとえば、ＨＴＴＰメッセージまたはＲＥＳＴメッセージ）は、呼出し可能インターフェイスによってサポートされ得る通信プロトコル（たとえば、ＨＴＴＰまたはＲＥＳＴ）に準拠していてもよい。別の例では、クラウドコンピュータシステム２１０とコンピューティングデバイス２０２との間のメッセージは、ＳＰＤＹなどの通信プロトコルに準拠していてもよい。ＭＣＳ２１２は、クラウドコンピュータシステム２１０とエンタープライズコンピュータシステム２４０、２５０との間の通信をセキュアにするために、ファイアウォール２３０を管理してもよい。ファイアウォール２３０は、クラウドコンピュータシステム２１０とコンピューティングデバイス（たとえばコンピューティングデバイス２０２）との間のメッセージの通信を許可してもよい。そのようなメッセージ（たとえば、ＳＰＤＹメッセージ、ＨＴＴＰメッセージ、またはＲＥＳＴメッセージ）は、通信プロトコル（たとえば、ＳＰＤＹ、ＨＴＴＰ、またはＲＥＳＴ）に準拠していてもよい。コンピューティングデバイス２０２とエンタープライズコンピュータシステム２４０、２５０との間の通信は、ＭＣＳ２１２を介して双方向であってもよい。
【００９８】
コンピューティングデバイス２０２およびエンタープライズコンピュータシステム２４０、２５０との通信は、セキュアでないパブリックネットワークを介して生じる場合があるため、ファイアウォール２０４、２３０は、ＭＣＳ２１２へのおよびＭＣＳ２１２からの通信のための追加の保護層を提供する。ファイアウォール２０４、２３０は、ＭＣＳ２１２が、その内部ネットワークと、コンピューティングデバイス２０２およびエンタープライズコンピュータシステム２４０、２５０を接続する外部ネットワークとを区別できるようにしてもよい。いくつかの実施形態では、ファイアウォール２０４、２３０は２つの別個のファイアウォールとして図示されているが、ＭＣＳ２１２をカプセル化する単一のファイアウォールとして実現されてもよい。
【００９９】
クラウドコンピュータシステム２１０はまた、一部が異なる通信プロトコルを有し得るエンタープライズコンピュータシステムと通信することによって、仲介コンピューティング環境として動作してもよい。そのような通信プロトコルは、クラウドコンピュータシステム２１０と通信しているアプリケーションまたはサービスに特化されたもの、または特有のものであってもよい。また、クラウドコンピュータシステム２１０は、エンタープライズコンピュータシステムと通信して、エンタープライズコンピュータシステムによってサポートされるフォーマットに従って、エンタープライズサービスを提供し、および／またはエンタープライズデータを交換してもよい。クラウドコンピュータシステム２１０は、エンタープライズデータのローカルストレージ（たとえば、ローカルキャッシュ）を維持してもよく、そのローカルストレージを使用して、モバイルコンピューティングデバイスとエンタープライズコンピュータシステム２４０、２５０との間のエンタープライズデータの同期を管理してもよい。
【０１００】
コンピューティングデバイス２０２は、エンタープライズコンピュータシステムによって提供されるサービスを要求するために、ＭＣＳ２１２と通信してもよい（たとえば、要求メッセージを送信してもよい）。ファイアウォール２０４を通って受信された要求はまず、セキュリティサービス２３２によって処理されてもよい。セキュリティサービス２３２は、要求に関連付けられたユーザについてのセキュリティ認証を管理してもよい。このため、クラウドコンピュータシステムは、顧客通信およびエンタープライズデータの完全性を保護し得る、ここに説明されるセキュリティメカニズムを提供することを含む技術的利点を提供してもよい。クラウドコンピュータシステムの技術的利点は、損なわれた通信および／またはデータが損なわれることを防止し、または低減させることを含んでいてもよく、認証が最初に起こって、要求されるクレデンシャルを有するものだけにアクセスを制限してもよい。クラウドコンピュータシステムの技術的利点は、要求が入ってくるとそれらはそれらが認可されているサービスにアクセスすることしかできないように、サービスおよびサービス呼出しフローが構造化されることを含んでいてもよい。システム処理の残りから認可を切り離すことにより、別の技術的利点は、「誰によって何が行なわれ得るか」を認可するタスクが、特定の企業顧客によっていかなる追加のカスタムセキュリティ手段が要求されてもそれをサポートするように拡張され得る専用のプロビジョニングされたセキュリティサブシステム（たとえばアイデンティティ管理システム）に委任されることを含んでいてもよい。いくつかの実施形態では、セキュリティ認証は、要求、セッション、ユーザ、デバイス、ユーザに関連する他の基準、またはそれらの組合せについて判断されてもよい。セキュリティ認証は、受信される要求ごとに行なわれてもよい。いくつかの実施形態では、セキュリティサービス２３２は、要求の以前の検証に基づいて認証を判断してもよい。セキュリティ認証は、異なるエンタープライズコンピュータシステム２４０、２５０への要求が単一のセキュリティ検証に基づいて認証され得るように、ユーザまたはデバイスについて判断されてもよい。
【０１０１】
この発明のさらなる技術的利点は、一部が異なったように実現され得るさまざまなエンタープライズコンピュータシステムとコンピューティングデバイスが通信することを、クラウドコンピュータシステムが可能にすることを含んでいてもよい。たとえば、コンピューティングデバイス２０２、クラウドコンピュータシステム２１０、およびエンタープライズコンピュータシステム２５０は、互いから物理的に分離された異なる地理的場所に位置していてもよい。したがって、コンピューティングデバイス２０２はエンタープライズコンピュータシステム２５０と、それらの位置にかかわらず通信することができる。技術的利点は、１つ以上の別個のセキュリティプロトコルをサポートし得るエンタープライズコンピュータシステムへコンピューティングデバイスがサービスについての要求を通信することを、クラウドコンピュータシステムが可能にすることを含んでいてもよい。場合によっては、エンタープライズコンピュータシステムは、異なるセキュリティプロトコルに容易に適合できないバックエンドシステムによってサポートされてもよい。場合によっては、アプリケーションの開発者が、そのようなセキュリティプロトコルの知識を持たずにサービスを要求できるようにアプリケーションを実現できることが、望ましいであろう。エンタープライズコンピュータシステムのユーザ（たとえば、管理者または設計者）が、異なるタイプのアプリケーション、セキュリティプロトコル、および規格に対処することなく要求を受信できることも、同等に望ましいであろう。技術的利点は、要求されているさまざまなエンタープライズコンピュータシステムのセキュリティ対策を要求が満たすことができるようにセキュリティ認証を取扱うことができる、ここに説明されるようなクラウドコンピュータシステムの実現によって、そのような要望が満たされることを可能にし得る。
【０１０２】
いくつかの実施形態では、セキュリティサービス２３２は、要求されたエンタープライズコンピュータシステムについてのセキュリティプロトコルを判断し、それに応じて、そのようなセキュリティプロトコルに従ったセキュリティトークンを生成してもよい。セキュリティトークンは、エンタープライズコンピュータシステムへ要求とともに渡されて、そのエンタープライズコンピュータシステムが生成されたセキュリティトークンに基づいて認証を検証することを可能にしてもよい。エンタープライズコンピュータシステムは、異なるセキュリティプロトコルをサポートしてもよい。セキュリティプロトコルは、セキュリティを判断するための規格であってもよい。セキュリティは、セキュリティサービス２３２によって生成されるセキュリティトークンに基づいて検証されてもよい。セキュリティサービス２３２は、要求について識別されるエンタープライズコンピュータシステム用のセキュリティプロトコルを判断してもよい。いくつかの実施形態では、エンタープライズコンピュータシステム２５０は、ＭＣＳ２１２によってサポートされるカスタムのまたは特有のセキュリティプロトコルに従って構成または実現され得るエージェントシステム２５２を有していてもよい。そのため、ＭＣＳ２１２は、そのようなカスタムセキュリティプロトコルに従ってセキュリティトークンを生成してもよい。
【０１０３】
クラウドコンピュータシステム２１０は、１つ以上の負荷分散システム２０６、２０８を含み、実現し、および／またはそれらと通信してもよい。セキュリティ認証を判断すると、クラウドコンピュータシステム２１０は、負荷分散システム２０６、２０８のうちのいずれか一方に、それが受信する要求を調べて、その要求がどのサービスに向けられているかを検出するよう、要求してもよい。ＭＣＳ２１２は、負荷分散部２０６、２０８を用いて構成されてもよく、起動されたリソースを用いて更新されてもよく、そのため、要求が入ってくると、負荷分散部２０６、２０８は、要求される負荷を異なるリソースにわたって分散させることができる。
【０１０４】
クラウドコンピュータシステム２１０は、要求を取扱い、それらを適切なサービスへ発送し得るディスパッチャ２１８を含んでいてもよい。要求は、発送されると、適切なサービスへルーティングされてもよい。いくつかの実施形態では、サービス自体が、内部の要求を、ＭＣＳ２１２またはエンタープライズコンピュータシステムにおける別の内部サービスへルーティングしてもよい。いくつかの実施形態では、ディスパッチャ２１８は要求を解決して、その宛先を、要求のＵＲＩおよび／またはＵＲＬにおいて識別される宛先の場所（たとえばアドレス）に基づいて判断してもよい。ディスパッチャ２１８は、要求およびそのヘッダを構文解析して、以下の情報、すなわち、テナント識別子、サービス識別子、アプリケーション名、アプリケーションバージョン、要求リソース、動作およびパラメータなどのうちの１つ以上を抽出してもよい。ディスパッチャ２１８は、構文解析された情報を使用して、メタデータリポジトリ２２４においてルックアップを行なうことができる。ディスパッチャ２１８は、対応するアプリケーションメタデータを検索してもよい。ディスパッチャ２１８は、要求されたリソースおよびメタデータにおけるマッピングに基づいて、ターゲットサービスを判断してもよい。メタデータは、最初は非常に基本的なマッピングであるが、より洗練された、ルールベースの発送を提供するために強化され得る。ディスパッチャ２１８は、ディスパッチャ特有の任意のロギング、メトリック収集などを行なってもよい。ディスパッチャ２１８は次に、アプリケーションメタデータに従って初期認可を行なってもよい。ディスパッチャ２１８は、インバウンド要求および任意の他の必要な情報をフォーマット化して、さらなる処理のためにメッセージをルーティングバス２２０上に配置してもよい。ディスパッチャ２１８は、要求をキュー上に配置して、対応する応答を待ってもよい。ディスパッチャ２１８は、ルーティングバス２２０から受信された応答を処理して、応答をコンピューティングデバイス２０２へ返してもよい。
【０１０５】
外部の要求に対する発送を取扱うことに加えて、ディスパッチャ２１８はまた、内部の要求を発送する役割を果たしてもよい。そのような内部の要求は、複合サービス、またはサービスへのカスタムコード呼出しの形で来る場合がある。いずれの場合も、呼出し側は、アプリケーション内で定義されるような論理サービス名を使用可能である。ディスパッチャ２１８は、現在の実行コンテキストを使用してアプリケーションを判断し、その論理名を使用して、呼出すべき適切なサービスを判断してもよい。
【０１０６】
クラウドコンピュータシステム２１０は、ルーティングバス２２０に登録された宛先へのメッセージの配信を管理するために、ルーティングバス２２０を含んでいてもよい。ルーティングバス２２０は、クラウドサービス２１２において通信を管理するための中央システムとして動作してもよい。ルーティングバス２２０を通して通信されたデータは、そのデータを取込んで格納するように処理されてもよい。ルーティングバス２２０は、追加の集中化サービス（追加の認可、デバッグなど）が必要に応じて容易にプラグインされ得るように、フレームワークを提供してもよい。ルーティングバス２２０によって取込まれたデータは、診断ストア２２６および／または解析ストア２２８に格納されてもよい。
【０１０７】
ルーティングバス２２０は、メッセージを１つ以上の宛先へルーティングしてもよい。いくつかの実施形態では、メッセージは、カスタムコード２１６を実行する要求を含んでいてもよい。そのような実施形態では、ルーティングバス２２０はカスタムコード２１６に、呼出されるよう要求してもよい（２３４）。いくつかの実施形態では、ルーティングバス２２０は、要求における情報によって識別される宛先エンタープライズコンピュータシステムへ、要求を渡してもよい。ルーティングバス２２０はアダプタインターフェイス２２２に、必要であれば翻訳を行なって、エンタープライズコンピュータシステム、たとえばエンタープライズコンピュータシステム２４０またはエンタープライズコンピュータシステム２５０へ要求を渡すよう、要求してもよい（２３６）。
【０１０８】
ある実施形態では、クラウドコンピュータシステム２１０は、メッセージを受信側エンタープライズコンピュータシステムによってサポートされるプロトコルに翻訳または変換するために、アダプタインターフェイス２２２を含んでいてもよく、または実装してもよい。アダプタインターフェイス２２２は、エンタープライズコンピュータシステム２４０、２５０の各々と、別々の通信接続を確立してもよい。クラウドコンピュータシステム２１０は、１つ以上のネットワーク（図示せず）を介してエンタープライズコンピュータシステム２４０、２５０と通信するように構成されてもよい。通信ネットワークの例は、インターネット、モバイルネットワーク、パブリックネットワーク、無線ネットワーク、セルラーネットワーク、ＬＡＮ、ＷＡＮ、他の通信ネットワーク、またはそれらの組合せを含んでいてもよい。ある実施形態では、通信接続は、高速通信トランクを使用して容易にされる高速通信接続であってもよい。エンタープライズコンピュータシステム２４０、２５０との通信は、外部ネットワークとの通信が、そのような通信を介するＭＣＳ２１２への不正アクセスを防止するようセキュアであることを保証する、ファイアウォール２３０を通過してもよい。
【０１０９】
いくつかの実施形態では、クラウドコンピュータシステム２１０は、コンピューティングデバイス２０２のユーザへの通知を容易にしてもよい。クラウドコンピュータシステム２１０は、たとえば、ユーザの好みに基づいて警告を１つ以上のチャネルを通して配信し、応答を待ち、その応答に基づいて行動するために、ユーザとのステートフルな対話をサポートする警告管理サービスを含んでいてもよい。１つのチャネル上で送信された警告への応答は、サービスが取扱うことができる必要のある別のチャネルを通して受信されてもよい。プラットフォームは、人気のある対話パターン用のビルトインの状態モデルを備えていてもよく、新しい状態モデルを用いて拡張可能であってもよい。いくつかの警告チャネルは、一方向または双方向の公知の通信リソースを含んでいてもよい。例は、ＳＭＳ、ツイッター（登録商標）、プッシュ通知、およびグーグル・クラウド・メッセージング（登録商標）を含む。
【０１１０】
いくつかの実施形態では、クラウドコンピュータシステム２１０は、コンピューティングデバイスが、オブジェクトストアサービス、データベースサービス、アクセスウェブサービス、ソーシャルサービス、リソースサービス、またはそれらの組合せといった１つ以上のサービスにアクセスすること、および／または当該サービスを要求することを可能にしてもよい。
【０１１１】
クラウドコンピュータシステム２１０は、ＢＬＯＢ用のストレージ設備を提供し得るオブジェクトストアサービスを提供してもよい。ストレージの基本単位はテキストであってもよく、読出動作および書込動作を伴う。ＪＳＯＮオブジェクト用の基本クエリ設備も提供されてもよい。
【０１１２】
クラウドコンピュータシステム２１０は、クエリまたは書込を行なうためにホスト型データベースへの接続性を可能にするために、データベースサービスを提供してもよい。必要とされるパラメータ化は、データベースのための十分な接続ストリング、実行すべきＳＱＬストリングまたは格納された手順、任意のパラメータおよびおそらくはクレデンシャルを必要とし得る。必要な情報は、実行時に提供され得るか、またはアプリケーションメタデータにおいて予め構成され得る。
【０１１３】
クラウドコンピュータシステム２１０は、ＳＯＡＰウェブサービスなどのウェブサービスへのアクセスを提供してもよい。クラウドコンピュータシステム２１０は、任意のＲＥＳＴリソースへの接続性といった、ＲＥＳＴサービスへのアクセスを提供してもよい。
【０１１４】
クラウドコンピュータシステム２１０は、フェースブック（登録商標）、ツイッター（登録商標）といった人気のあるソーシャルサイトの多くとの基本的統合を提供し得るソーシャルサービスへのアクセスを提供してもよい。これらのサービスは、それらのサイトからのユーザのクレデンシャルを使用した第三者認証、およびそれらのサービスへのアクセスを可能にしてもよい。例は、ツイートを送信すること、または自分のステータスを更新することを含む。
【０１１５】
クラウドコンピュータシステム２１０は、ユーザが通信を単純化し最適化することができるように、パブリッククラウドサービスを提供してもよい。たとえば、サービス開発者は、クラウドコンピュータシステム２１０のクラウドサービスを使用してホストされるリソースと、ＭＣＳ２１２の包括的ウェブサービスを使用して通信してもよい。
【０１１６】
ここに説明されるもののようなクラウドコンピュータシステムは、コンピューティングリソースの違いにもかかわらず、モバイルコンピューティングデバイスがエンタープライズコンピュータシステムと通信することを可能にしてもよい。クラウドコンピュータシステムは、頻繁に通信してエンタープライズデータを受信するために、より多くのリソース、および、エンタープライズコンピュータシステムとのより高速で信頼性のある接続を備えていてもよい。クラウドコンピュータシステムは、エンタープライズコンピュータシステムからのサービスについての要求を管理し、調整してもよい。要求をメッセージの受信側によってサポートされるプロトコルに翻訳することにより、クラウドコンピュータシステムは、異なるタイプのバックエンドコンピュータシステムとの通信用のアプリケーションを構成するための開発者の負担を低減する。エンタープライズは、モバイルデバイス用にサポートされる通信プロトコルの進歩または変化に対処する必要なく、それらのバックエンドシステムを維持することができる。異なるエンタープライズコンピュータシステムは、処理される要求および提供されるサービスのタイプに基づいて、異なるセキュリティプロトコルをサポートしてもよい。異なるエンタープライズコンピュータシステムへのアクセスのために集中化された態様でセキュリティ認証を管理することにより、エンタープライズコンピュータシステムは、セキュリティプロトコルの違いに適合しなくてもよい。クラウドコンピュータシステムのユーザを認証することにより、要求の処理はより効率的になり得る。なぜなら、認証はすべてのインスタンスで行なわれるとは限らないためである。
【０１１７】
いくつかの実施形態では、アプリケーションは、当該アプリケーションへのアクセスを制御して極秘データの暗号化を保証するためのビルトインセキュリティを提供するモバイルアプリケーションフレームワーク（mobile application framework：ＭＡＦ）、たとえばオラクル社からのオラクルＭＡＦ（Oracle MAF）などの下でデプロイメントされてもよい。ＭＡＦは、（ウェブビューにおいてＵＩをレンダリングするための）ＨＴＭＬ５およびカスケーディング・スタイル・シート（Cascading Style Sheet：ＣＳＳ）、（アプリケーションビジネスロジックのための）Ｊａｖａ、および（ＧＰＳアクティビティおよび電子メールなどのデバイス特徴にアクセスするための）アパッチ・コルドバを使用する、ハイブリッドモバイルアーキテクチャである。ＭＡＦはこれらのクロスプラットフォーム手法を使用しているため、アンドロイドデバイスおよびｉＯＳデバイス双方のために、プラットフォーム特有のツールを使用する必要なく、同じアプリケーションを構築することができる。アプリケーションがデバイスにデプロイメントされた後、当該アプリケーションは、オブジェクティブＣまたはアンドロイドＳＤＫなどのプラットフォーム特有のツールを使用して作成されたアプリケーションとして挙動する。また、ＭＡＦは、スマートフォンまたはタブレットのために同じアプリケーションを構築することを可能にし、それにより、同じアプリケーションにおけるビジネスロジックの再使用を可能にし、さまざまなタイプのデバイス、画面サイズ、および能力をターゲットとする。
【０１１８】
図３は、「重い（heavy）」アプリケーション（たとえば、アップストアから取得された通常のｉＰｈｏｎｅ「アプリ」と同じ態様でモバイルデバイスに搭載されるモバイルアプリケーション）としてデプロイメントされた「WorkBetter」と呼ばれるＭＡＦアプリケーション３０２を含む、モバイルアプリケーションスプリングボード３００の一例を示す。ＭＡＦアプリケーションは、アプリケーション特徴として追加される１つ以上の埋込み型アプリケーションを含んでいてもよい。そのような追加されるアプリケーション特徴は、メインアプリケーションのスプリングボードまたはナビゲーションバー内のアイコンとして表わされる。アプリケーション特徴は本質的に、そのようなモバイルアプリケーションの構築ブロックである。ＭＡＦアプリケーションへ統合されている各アプリケーション特徴は、特定の一組のタスクを行なう。アプリケーション特徴は、互いの機能性を補完するためにともにグループ化され得る。たとえば、顧客連絡先を提供するアプリケーション特徴は、製品在庫についてのアプリケーション特徴と対にされてもよい。各アプリケーション特徴はそれ自体のクラスローダおよびウェブビューを有しているため、アプリケーション特徴は互いから独立しており、このため、いくつかの異なる開発チームによって作成されたアプリケーション特徴から、単一のＭＡＦアプリケーションを組み立てることができる。アプリケーション特徴はまた、他のＭＡＦアプリケーションにおいて再使用可能である。ＭＡＦアプリケーション自体は、別のアプリケーション用のベースとして再使用可能であり、独立系ソフトウェアベンダー（independent software vendor：ＩＳＶ）が、特定の顧客によって構成可能なアプリケーションを作成することを可能にする。
【０１１９】
デバイス上でローカルで実行されるハイブリッドモバイルアプリケーションに加えて、アプリケーション特徴は、モバイルアプリケーションおよび利用可能なリソースの要件に依存して、以下のモバイルアプリケーションタイプのうちのいずれかとして実現されてもよい：
・サーバ上でホストされるモバイルウェブアプリケーションについては、コードはプラットフォーム間でポータブルであり得るが、これらのアプリケーションはデバイスのブラウザによって管理されるため、デバイス特徴およびローカルストレージへのアクセスは制限され得る；
・固有アプリケーションは、Ｘｃｏｄｅで、またはアンドロイドＳＤＫを通してオーサリングされており、そのため、双方のプラットフォームのために機能するという点で制限される。コードの再利用も同様に制限される。
【０１２０】
ＭＡＦは、アプリケーションにおける特徴レベルでの改良されたセキュリティのための認証およびアクセス制御をサポートし、開発者は、適切なログインサーバ、たとえば、基本的な認証を用いて「オラクルアイデンティティ管理」（Oracle Identity Management）および／または「Oracle WebLogic」を実行するサーバ、ＯＡｕｔｈプロトコルをサポートするサーバなどを指定できる。実行時、ユーザにはログイン画面が提示され、適切なトークンが、さらなるウェブサービス呼出しのためにアクセス可能である。ＭＡＦにより、開発者は、さまざまな特権を有するユーザの必要性を満たす（たとえば、ユーザの役割または特権に基づいてコンポーネントを示す／隠す）個々のＵＩを構築することができる。
【０１２１】
ＭＡＦは、ＳＳＬ／ＴＬＳ（ＨＴＴＰセキュア（ＨＴＴＰＳ））を使用する通信暗号化、オフライン認証をサポートする際に検証のために使用されるべきクレデンシャルを暗号化されたキーストアに保持するためのオンデバイス暗号化、および、ＳＱＬｉｔｅ暗号化拡張を使用することによるＳＱＬｉｔｅデータベース暗号化を実施する。ＭＡＦで構築されたアプリケーションのためにＳＱＬｉｔｅデータベースを暗号化することは、当該アプリケーションが開発される際に構成オプションを介して行なわれてもよい。いくつかの実施形態では、ＭＡＦは、アプリケーションのためのオフラインおよびオンライン動作モードをサポートし、そのため、自立型のアプリケーションがモバイルデバイス上で接続モードおよび非接続モードで実行可能である。データアクセス／格納のために、そのようなアプリケーションは、ローカルの暗号化されたＳＱＬｉｔｅデータベースを利用してもよい。当該アプリケーションは、データへの最初のアクセスがウェブサービスを通してリモートサーバから行なわれ、次にデータがオフラインアクセスのためにローカルのＳＱＬｉｔｅデータベースに格納されるように、構築されてもよい。接続性が再び利用可能になると、データは複製されてサーバと同期され得る。ＭＡＦはまた、セキュアにされたアプリケーションへのオフライン認証／認可を可能にするように、ユーザ認証クレデンシャルのローカルストレージをサポートする。
【０１２２】
図３Ａおよび図３Ｂは、本発明の一実施形態に従ったＨＲモバイルアプリケーションＵＩ３０４を示す。ＵＩ３０４は、図３のモバイルアプリケーションスプリングボード３００などのスプリングボード上でアイコンを開くと提供されてもよい。図３Ａでは、ＵＩ３０４は、ある従業員についてのさまざまなＨＲ関連情報、たとえば、写真、役職、連絡先情報、ソーシャルネットワーキング情報、業績／格付け情報、報酬情報、マネージャ、スキル、位置などを含む。図３Ｂは、ＵＩ３０４における情報が取得され得るさまざまなソース、たとえば構内またはクラウドに位置するサービスを示す。たとえば、基本的な従業員情報は、ＰｅｏｐｌｅＳｏｆｔ、システムズ、アプリケーションおよび製品（Systems, Applications & Product：ＳＡＰ）などの構内コアＨＲサービス３０６から取得されてもよく、一方、位置情報は、グーグルなどのマップサービス３０８から取得される。同様に、業績情報は、ＴＡＬＥＯなどの才能管理クラウドサービス３１０から取得されてもよく、ソーシャルネットワーキング情報３１２（たとえば、ツイッター、フェースブック、LinkedInなど）はウェブから取得されてもよい。一実施形態では、これらのさまざまなソースからの情報は、ＭＣＳ２１２（図２参照）を通されてから、モバイルデバイス２０２（図２参照）上のアプリケーションまで送信される。
【０１２３】
図４は、一実施例に従ったＭＡＦ実行時アーキテクチャ４００のブロック図である。実行時アーキテクチャ４００は、モバイルデバイス４０４にデプロイメントされた「薄型（thin）」のデバイス固有コンテナ４０２を含む。実行時アーキテクチャ４００は、モデル層およびコントローラロジックからプレゼンテーションを分離するＭＶＣ開発アプローチを表わす。デバイス固有コンテナ４０２は、ＭＡＦアプリケーションが、ローカルのＳＱＬｉｔｅデータベース４０６（ＳＱＬｉｔｅ４０８を介する）、モバイルデバイスサービス４２６（アパッチ・コルドバ４１０のコルドバＡＰＩを介する）、ならびに、構成サーバ４４４、サーバ生成ＨＴＭＬ４３０、プッシュサービス４４８、およびウェブサービス４４０などのサーバ側リソース４１２と対話することにより、さまざまなプラットフォーム（たとえばｉＯＳ、アンドロイドなど）上の固有アプリケーションとして機能することを可能にする。
【０１２４】
デバイスサービス４２６は、カメラ、ＧＰＳ、電子メールなどといった、デバイス４０４に固有のサービスおよび特徴である。構成サーバ４４４は、アプリケーション構成サービスによって使用されるウェブ分散オーサリングおよびバージョン管理（Web Distributed Authoring and Versioning：ＷｅｂＤａｖ）およびホスティング構成ファイルに基づいたサーバである。ＷｅｂＤａｖは、たとえば、インターネット・エンジニアリング・タスク・フォース（Internet Engineering Task Force：ＩＥＴＦ）コメント要求（Request for Comments：ＲＦＣ）４９１８において定義される。構成サーバ４４４は、リファレンス実装として提供される。Ｊａｖａ２プラットフォーム、エンタープライス・エディション（Java 2 Platform, Enterprise Edition：Ｊ２ＥＥ）サーバ上でホストされるどの通常のＷｅｂＤａｖサービスも、この目的のために使用可能である。サーバ生成ＨＴＭＬ４３０は、リモートサーバ上でホストされ、ブラウザベースのアプリケーション特徴のために使用される、ウェブコンテンツを含む。プッシュサービス４４８は、たとえば、通知イベントをＭＡＦアプリケーションへ送信する通知プロバイダである、アップルプッシュ通知サービス（Apple Push Notification Service：ＡＰＮ）およびグーグル・クラウド・メッセージング（Google Cloud Messaging：ＧＣＭ）プッシュサービスを含んでいてもよい。Ｗｅｂサービス４４０は、たとえば、リモートでホストされるＳＯＡＰベースのウェブサービスである。
【０１２５】
デバイス固有コンテナ４０２は、モバイルデバイスのウェブエンジンを使用してウェブベースのコンテンツを表示して処理するウェブビュー４１６を含む。ＭＡＦアプリケーションでは、ウェブビュー４１６は、アプリケーションマークアップをＨＴＭＬ５としてレンダリングすることによってＵＩを提供する。ＵＩは、以下のコンテンツタイプのうちのいずれか、すなわち、ＭＡＦアプリケーションモバイルＸＭＬ（Application Mobile XML：ＡＭＸ）ビュー４２０、コントローラ４２２、ローカルＨＴＭＬ４２４、またはサーバＨＴＭＬ４２８を実現することにより、モバイルアプリケーション特徴のために作成されてもよい。ＭＡＦ  ＡＭＸビュー４２０、コントローラ４２２、およびローカルＨＴＭＬ４２４は、ＨＴＭＬ５およびＪａｖａＳｃｒｉｐｔプレゼンテーション４１８を提供する。さまざまなコンテンツタイプから実現されるアプリケーション特徴は、同じモバイルアプリケーション内で共存可能であり、かつ互いと対話することができる。
【０１２６】
ＭＡＦ  ＡＭＸビュー４２０として実現されるコンテンツを有するアプリケーションはデバイス４０４上に常駐しており、デバイスのプラットフォームに特有の言語でオーサリングされるアプリケーションと同様の、最も信頼性のあるデバイス固有のユーザ体験を提供する。ＭＡＦは、ユーザが、モバイルデバイスのフォームファクタに適合されたコンポーネントからＵＩを宣言的に作成することを可能にする、一組のコードエディタを提供する。これらのコンポーネントは、ページレイアウト（たとえばリストビュー）および入力コンポーネント（たとえば入力フィールド）を作成するために使用され得る。ユーザがＭＡＦ  ＡＭＸビュー４２０を開発する際、ユーザは、ユーザがデータにバインドされたＵＩコンポーネントを宣言的に作成し、ウェブサービスおよびモバイルデバイスのサービス（たとえばカメラ、ＧＰＳまたは電子メール）にアクセスすることを可能にする、データ制御を利用することができる。実行時、ウェブビュー４１６におけるＪａｖａＳｃｒｉｐｔエンジンが、ＭＡＦ  ＡＭＸビュー定義をＨＴＭＬ５およびＪａｖａＳｃｒｉｐｔにレンダリングする。
【０１２７】
コントローラ４２２として実現されるコンテンツを有するアプリケーションについては、コントローラ４２２は、モバイルアプリケーションにおけるページ間のフローを管理する。コントローラ４２２は、ユーザがアプリケーションのフローをより小さい再使用可能タスクフローに分解し、方法呼出しおよび判定ポイントなどの非視覚的コンポーネントを含めることを可能にする。図４の実施形態では、コントローラ４２２はＭＡＦ  ＡＭＸビュー４２０に含まれており、たとえば、ページを移行させ、および／またはアクションを起動するために、ＭＡＦ  ＡＭＸビュー４２０によって呼出される。しかしながら、代替的な実施形態では、コントローラ４２２は、ＭＡＦ  ＡＭＸビュー４２０のピアとして実現されてもよい。
【０１２８】
ローカルＨＴＭＬ４２４として実現されるコンテンツを有するアプリケーションについては、ＨＴＭＬページは、ＭＡＦアプリケーションの一部としてデバイス上で実行される。ローカルＨＴＭＬファイルは、アパッチ・コルドバ４１０およびＪａｖａＳｃｒｉｐｔ  ＡＰＩを通して、デバイス固有の特徴およびサービスにアクセスすることができる。
【０１２９】
サーバＨＴＭＬ４２８として実現されるコンテンツを有するアプリケーションについては、ＵＩは、アプリケーション特徴のウェブビュー４１６内で開くことができるサーバ生成ウェブページ（サーバ生成ＨＴＭＬ４３０）から提供される。ＭＡＦのコンテキスト内では、このコンテンツタイプはリモートＵＲＬと呼ばれる。これらのブラウザベースのアプリケーションのためのリソースは、デバイス４０４上に常駐していない。代わりに、ＵＩ、ページフローロジック、およびビジネスロジックは、リモートサーバから提供される。
【０１３０】
リモートでホストされるこれらのウェブアプリケーションのうちの１つがウェブビュー４１６内で開くことが許可されると、それは、コルドバＪａｖａＳｃｒｉｐｔ  ＡＰＩを使用して、カメラまたはＧＰＳ能力といった任意の指定されたデバイス固有の特徴またはサービスにアクセスすることができる。リモートのＵＲＬコンテンツを使用してアプリケーションを実現する場合、ユーザは、モバイル用途のために最適化された既存のブラウザベースのアプリケーションを利用するか、または、特定のタイプのモバイルデバイスのために具体的に書かれたアプリケーションを使用することができる。デスクトップまたはタブレット上のブラウザ内で実行可能なアプリケーションについては、ユーザは、オラクル社からの「オラクルＡＤＦフェース」（Oracle ADF Faces）によって提供されるもののようなリッチクライアントベースのコンポーネントを通して作成されたアプリケーションを使用して、リモートのＵＲＬコンテンツを実現することができる。具体的に携帯電話をターゲットとするアプリケーションについては、リモートのＵＲＬコンテンツは、ＭＡＦを使用して作成されたウェブページから提供され得る。ＭＡＦでオーサリングされたアプリケーションは、さまざまなスマートフォン上でレンダリングできるだけではなく、アパッチ・トリニダード（Apache Trinidad）ＪＳＦコンポーネントおよび動的に選択されたスタイルシートで構築されたＵＩを通して、フィーチャーフォン上で利用可能な低下した能力にまで優雅に質を低下させることができる。コンテンツがリモートで供給されるため、アプリケーションは、サーバ接続がアクティブなままである限りにおいてのみ、利用可能である。
【０１３１】
デバイス固有コンテナ４０２はさらに、デバイス固有の特徴およびサービスをモバイルアプリケーションに統合するＪａｖａＳｃｒｉｐｔ  ＡＰＩを提供する、アパッチ・コルドバ４１０を含む。ユーザは、Ｊａｖａコードからプログラムによって（または、ＭＡＦモバイルアプリケーションをローカルＨＴＭＬ４２４として実現する場合には、ＪａｖａＳｃｒｉｐｔを使用して）これらのＡＰＩにアクセスすることができるが、ユーザは、ＭＡＦ  ＡＭＸページを作成する際にデバイス統合を宣言的に追加することができる。なぜなら、ＭＡＦはこれらのＡＰＩをデータ制御としてパッケージングするためである。
【０１３２】
デバイス固有コンテナ４０２はさらに、Ｊａｖａ仮想マシン（Java Virtual Machine：ＪＶＭ）４３２を含む。Ｊａｖａは、ＭＡＦアプリケーションのためのＪａｖａ実行時環境を提供する。ＪＶＭ４３２は、デバイス固有のコードで実現され、固有アプリケーションバイナリの一部としてＭＡＦアプリケーションの各インスタンスに埋込まれる（またはコンパイルされる）。ＪＶＭ４３２は、Ｊａｖａプラットフォーム、マイクロ・エディション（Java ME）接続デバイス構成（Connected Device Configuration：ＣＤＣ）仕様に基づいている。実行時アーキテクチャ４００では、ＪＶＭ４３２は、ビジネスロジック４３４と、モデル４３６と、Ｊａｖａデータベース接続性（Java database connectivity：ＪＤＢＣ）４３８とを含む。Ｊａｖａは、ＭＡＦアプリケーションにおいてビジネスロジック４３４を可能にする。管理ビーン（Managed Beans：ＭＢｅａｎｓ）とは、サーバから返されたデータを処理するための追加のビジネスロジックを提供するといった、ＭＡＦの能力を拡張するために作成され得るＪａｖａクラスである。ＭＢｅａｎｓは、埋込み型Ｊａｖａサポートによって実行され、ＪａｖａＭＥ  ＣＤＣ仕様に準拠する。モデル４３６は、ビジネスロジックコンポーネントをＵＩと接続するバインディング層を含む。加えて、バインディング層は、リモートでホストされるＳＯＡＰベースのウェブサービスなどのウェブサービス４４０を呼出すために、実行ロジックを提供する。これらのサービスは、Ｊａｖａ層（ＪＶＭ４３２）を通してアクセスされる。ＭＡＦ  ＡＭＸにおいてオーサリングされるアプリケーション特徴は、データ制御を通してＳＯＡＰベースのデータサービスにアクセスする。ＪＤＢＣ４３８は、モデル層が、作成、読取り、更新、削除（Create, Read, Update and Delete：ＣＲＵＤ）動作を通して、暗号化されたＳＱＬｉｔｅデータベース４０６におけるデータにアクセスすることを可能にするＡＰＩである。
【０１３３】
デバイス固有コンテナ４０２はさらにアプリケーション構成４４２を含み、それは、ウェブサービス用のＵＲＬエンドポイントまたは構成サーバ４４４のリモートＵＲＬ接続などのアプリケーション構成がダウンロードされてリフレッシュされることを可能にするサービスを指す。アプリケーション構成サービスは、サーバ側のＷｅｂＤａｖベースのサービスから構成情報をダウンロードする。
【０１３４】
デバイス固有コンテナ４０２はさらに、クレデンシャル管理、シングルサインオン（Single Sign-on：ＳＳＯ）、およびアクセス制御を提供するモジュール４４６を含む。ＭＡＦは、「オラクルアクセス管理モバイルおよびソーシャル」（Oracle Access Management Mobile and Social：ＯＡＭＭＳ）アイデンティティマネージャ（identity manager：ＩＤＭ）ＳＤＫを通して、ユーザ認証およびクレデンシャル管理を取扱う。ＭＡＦアプリケーションは、オフライン認証を行なう。これは、接続中にユーザがアプリケーションにログインすると、ＭＡＦがユーザ名およびパスワードをデバイス４０４上でローカルに維持し、それにより、認証サーバへの接続が利用できなくなっても、ユーザがアプリケーションに引き続きアクセスできるようにすることを意味する。ＭＡＦは、ローカルのＳＱＬｉｔｅデータベース４０６に格納されたデータだけでなく、ローカルに格納されたユーザ情報も暗号化する。ログインサーバに対して認証した後、ユーザは、その接続によってセキュアにされたアプリケーション特徴のすべてにアクセスすることができる。ＭＡＦはまた、ユーザの役割および特権を適用することによってアプリケーション特徴（またはアプリケーション特徴の特定の機能）へのアクセスを制限することにより、アクセス制御の概念をサポートする。リモートで供給されるウェブコンテンツについては、ＭＡＦはホワイトリストを使用して、意図されたＵＲＩだけがアプリケーション特徴のウェブビュー４１６内で開くことができること（およびデバイス特徴にアクセスできること）を保証する。
【０１３５】
デバイス固有コンテナ４０２はまた、サーバ側リソース４１２に含まれるプッシュサービス４４８と通信し、ＭＡＦアプリケーションがｉＯＳまたはアンドロイドの通知サーバなどの通知サーバからイベントを受信することを可能にするプッシュハンドラ４１４を介したプッシュ通知を可能にする。Ｊａｖａ層（ＪＶＭ４３２）は通知処理を取扱う。
【０１３６】
実行時アーキテクチャ４００では、デバイス固有コンテナ４０２は暗号化ＳＱＬｉｔｅデータベース４０６と対話し、それは、ローカルに格納されたデータを保護し、ＪＤＢＣ４３８を使用してモデル層によって呼出される、埋込み型ＳＱＬｉｔｅデータベースである。ＭＡＦアプリケーションは、この軽量のクロスプラットフォームリレーショナルデータベース４０６を生成する。データベース４０６は暗号化されているため、デバイスが紛失または盗難された場合でも、それはデータをセキュアにする。正確なユーザ名およびパスワードを入力するユーザだけが、このデータベースにおけるデータにアクセスできる。
【０１３７】
図５は、本発明の実施形態に従った、モバイルクラウドインフラストラクチャにおいてモバイルアプリケーションを開発するためのシステム５００のブロック図である。システム５００では、ユーザは、ユーザデバイス５２８を使用して、ウェブベースのツールを介してクラウドインフラストラクチャ５０６においてアプリケーションを開発し、構築してもよい。一実施形態では、アプリケーションはモバイルデバイス５２６上に無線でダウンロードされてもよく、このため、アップストアの必要性をなくす。固有アプリケーションは、ＭＣＳ５０２において作成されたバックエンド５０４と通信する。一実施形態では、モバイルデバイス５２６にアプリケーションを提供するために、図４のＭＡＦ実行時アーキテクチャ４００が使用されてもよい。一実施形態では、アプリケーションの宣言的構文がモバイルデバイス５２６上に無線でデプロイメントされ、その宣言的構文は、図４のＭＡＦ実行時アーキテクチャ４００によって、モバイルデバイス５２６上で解釈される。
【０１３８】
クラウドインフラストラクチャ５０６は、アプリケーション開発が行なわれ得る管理（admin）ＵＩ５１６を提供するＭＣＳ５０２を含む。ＭＣＳ５０２はさらに、モバイルアプリケーションが開発され得る生産環境５１２と、モバイルアプリケーションがテストされ得るテスト環境５１４とを含む。これらの環境は、コネクタを介して対応するバックエンド５０４と通信することにより、生産／テスト機能性を提供する。アプリケーションはまず、テスト環境５１４で開発される。当該アプリケーションは、いったん発行されると、生産環境５１２へ移動する。
【０１３９】
一実施形態では、モバイルアプリケーションは、ユーザデバイス５２８を使用してセキュリティ層５２４を通してＭＣＳ管理ＵＩ５１６（ポータルとも呼ばれる）と通信することによって開発される。ＭＣＳ管理ＵＩ５１６は、ＭＣＳ管理ＵＩ５１６を介してインターフェイス接続され得るアプリケーション開発サーバ５１８を含む。ＭＣＳ管理ＵＩ５１６において開発されるアプリケーションは、生産環境５１２および／またはテスト環境５１４と通信することにより、ユーザデバイス５２８のブラウザ上で、またはモバイルデバイス５２６上で実行され得る。一実施形態では、アプリケーションがモバイルデバイス５２６上にデプロイメントされると、モバイルデバイス５２６はテスト環境５１４と通信する。しかしながら、アプリケーションがモバイルデバイス５２６上で更新される場合、そのような更新はＭＣＳ管理ＵＩ５１６を介して行なわれる。
【０１４０】
システム５００において開発されるアプリケーションは、軽いアプリケーションまたは重いアプリケーションとして構築されてもよい。重いアプリケーションとは、アップストアからダウンロードされるアプリなどの完全なアプリケーションである。軽いアプリケーションとは、オラクルアプリなどの、すでにデプロイメントされている完全なアプリケーション（すなわちホスティングアプリケーション）への追加特徴としてデプロイメントされるアプリケーションである。ホスティングアプリケーションは、軽いアプリケーションを保持するコンテナとして作用する。重いアプリケーションおよび軽いアプリケーションはともに、図７を参照してここに説明されるセキュリティコンテナによってさらにコンテナ化され得る。
【０１４１】
図６は、本発明の実施形態に従った、モバイルアプリケーションを構築するためのシステム６００におけるネットワークコンポーネントのブロック図である。システム６００では、第１のデバイス６０２が、構築要求を開始するためにＭＣＳウェブサイト（図６の例示的な実施形態では「https://mcs-tenant-a.cloud.oracle.com」として示される）と対話し、第２のデバイス６０４が、固有アプリケーションの無線インストールを行なうために当該ＭＣＳウェブサイトと通信する。一般に、無線インストールは、アプリケーションと、対応するアプリケーションアーカイブファイル（拡張子「.ipa」を有し、アプリケーションを格納するファイル）をダウンロードするべき位置とを記述する、プロパティリストファイル（拡張子「.plist」を有する「ｐ−リスト」ファイル）などのファイルをダウンロードすることと、次に、その位置からアプリケーションアーカイブファイルをダウンロードすることとを含む。
【０１４２】
第１のデバイス６０２および第２のデバイス６０４は、パブリックオラクルＨＴＴＰサーバ（Oracle HTTP Server：ＯＨＳ）６０６を通してサーバ６１０のＭＣＳポータルＶＭ６１２と通信することにより、ＭＣＳウェブサイトと対話する。パブリックＯＨＳ６０６は、ファイアウォール６０８の背後に位置するＭＣＳポータルＶＭ６１２へトラフィックを向けるパブリックフェイシングオラクルＨＴＴＰサーバである。パブリックＯＨＳ６０６は、オラクル・アクセス・マネージャ（Oracle Access Manager：ＯＡＭ）用のウェブサーバプラグインであるウェブゲート（WebGate）を実現して、ＨＴＴＰ要求を遮り、それらを認証および認可のために対応するアクセスサーバへ発送する。したがって、パブリックＯＨＳ６０６は、第１のデバイス６０２のユーザを認証し、ユーザクレデンシャルをＭＣＳポータルＶＭ６１２へ渡し、第１のデバイス６０２とのＳＳＬ接続を終了させる。図６の例示的な実施形態では、第１のデバイス６０２および第２のデバイス６０４は、ｈｔｔｐｓのためにポート４４３が使用される「https://mcs-tenant-a.cloud.oracle.com」で、パブリックＯＨＳ６０６にアクセスする。
【０１４３】
ＭＣＳポータルＶＭ６１２は、スキーマサービス６１４における単一のテナントスキーマによって支援されるデータを有する標準的なウェブロジック・サーバ（WebLogic Server：ＷＬＳ）アプリケーションであり、その対応するアプリケーション開発クライアントは、オラクル・ジャンプスタート・エンタープライズ・ツールキット（Oracle Jumpstart Enterprise Toolkit：ＪＥＴ）フレームワークを使用して書かれる。ウェブロジック・サーバは、オラクル社によって開発されたＪａｖａＥＥアプリケーションサーバである。データベーススキーマとは、オブジェクト（たとえば、テーブル、ビュー、格納された手順など）のコンテナであり、それらを論理的にグループ化する。
【０１４４】
ＭＣＳポータルＶＭ６１２は単一のテナントであり、そのセキュリティは、（図７を参照してここに説明されるオラクル・ウェブ・サービシーズ・マネージャ（Oracle Web Services Manager：ＯＷＳＭ）を介して提供される。したがって、ＭＣＳポータルＶＭ６１２は、信頼されたゾーンにおいてＷＬＳを実行させる。ＭＣＳポータルＶＭ６１２は、第１のデバイス６０２による要求を取扱い、スキーマサービス６１４への接続を有する。ＭＣＳポータルＶＭ６１２はまた、負荷分散部６１６を介して構築サーバファーム６１８に接続される。図６の実施形態では、ＭＣＳポータルＶＭ６１２は、パブリックＯＨＳ６０６への／からの、負荷分散部６１６への、および、サーバファーム６１８における個々のサーバからのｈｔｔｐ通信のために、開ポート８０（または同等物）を使用する。
【０１４５】
スキーマサービス６１４はＭＣＳポータルＶＭ６１２と対話して、アプリケーションデータ、エンタープライズ署名証明書、および、テナントについてのプロビジョニングプロファイルを格納する。負荷分散部６１６は、ファームタスクをサーバファーム６１８におけるサーバへルーティングする。ルーティングは最初に総当たり方式で行なわれてもよい。図６の実施形態では、負荷分散部６１６は、開ポート８０（または同等物）を使用して冗長性を提供する、Ｆ５社（F5 Corp.）からのＢＩＧ−ＩＰ機器である。サーバファーム６１８は、構築ジョブを取扱う多くのサーバ（たとえば２０個のサーバ）を含む。それは、アプリケーションバイナリ（たとえば５ＴＢ）を格納するためのファイラ（図示せず）に接続される。一実施形態では、サーバファーム６１８の接続は、サーバ上でローカルに実行されるローカルのTomcatインスタンスによって取扱われ、構築ツールおよびプロセスは、固有のＯＳＸ呼出しによって取扱われる。
【０１４６】
アプリケーションの構築
一実施形態では、第１のデバイス６０２のユーザがいったんアプリケーションを作成し、固有のバイナリを生成することを所望している場合、ユーザは、第１のデバイス６０２のＵＩを介して、ＭＣＳウェブサイトで（たとえば「https://mcs-tenant-a.cloud.oracle.com/max/build」で）構築ＰＯＳＴ要求を開始する。ＰＯＳＴとは、ウェブサーバに要求メッセージの本体に入れられたデータを受け入れて格納するよう要求するための、ＨＴＴＰプロトコルによってサポートされる要求方法である。構築ＰＯＳＴ要求のペイロードは、アプリケーションのためのアプリケーション識別子（ｉｄ）を含む。パブリックＯＨＳ６０６は要求を受信し、ＳＳＬを終了させ、（ユーザがログインすると仮定して）ＯＡＭに対してユーザを認証および認可し、ユーザアイデンティティを要求のＨＴＴＰヘッダに配置し、要求を、ファイアウォール６０８を通過させてＭＣＳポータルＶＭ６１２のＷＬＳサーバ（たとえば、「http://mcs-tenant-a.internal/max/build」で実行されるＷＬＳサーバ）へ発送する。
【０１４７】
ＭＣＳポータルＶＭ６１２は要求を受信し、要求されたアプリケーションに対する特権についてユーザを認可し、アプリケーションデータ、テナントエンタープライズ証明書、暗号化された証明書パスワード、およびテナントプロビジョニングプロファイルについてテナントスキーマサービス６１４へクエリを送信する。スキーマサービス６１４が要求されたアイテムをいったん返すと、ＭＣＳポータルＶＭ６１２は、（スキーマサービス６１４に格納された）構築ジョブのテーブルにおいて新しいエントリを作成して、構築の試みを記録し、対応する新しい構築記録の主キーを取込む。ＭＣＳポータルＶＭ６１２はまた、（たとえば「http://max-mini-farm.internal/build/initiate」にある）負荷分散部６１６の背後の構築サーバファーム６１８に対して新しいＰＯＳＴ要求を作成して、対応するパラメータ（アプリケーションデータ、署名証明書およびパスワード、ならびにプロビジョニングプロファイル）を、要求の本文へ、およびジョブ完了のためのコールバックＵＲＬへ渡し、コールバックＵＲＬは、構築ジョブのテーブルにおいて対応する構築記録の主キーをコード化する。以下の機能性は、対応するパラメータを含む構築ＰＯＳＴ要求ペイロードの一例を提供する。
【０１４８】
【数１】
0006679711.tif 000002
【０１４９】
この例では、証明書およびパスワードは、この実施形態に従ってモバイルアプリケーションを構築するためだけに、第１のデバイス６０２のユーザによって作成され（すなわち、証明書およびパスワードは、この実施形態に従ったモバイルアプリケーションの構築以外のサービスと共有されない）、ポート３０００は公的にアクセス可能ではない。
【０１５０】
負荷分散部６１６は、サーバファーム６１８における健全なサーバのリストを維持する。一実施形態では、これは、ある時間間隔で（たとえば、数分ごとに）サニティチェックを行なう健全性チェックを介して行なわれる。構築ジョブ要求を受信すると、負荷分散部６１６は、リストにおける健全なサーバプールからあるサーバを選択し、構築ジョブ要求をそのサーバへルーティングする（たとえば、ジョブを「http://mac-mini1.internal/build/initiate」へルーティングする）。一実施形態では、ジョブを選択することは、等しい複雑性の構築ジョブのための総当たりプロセスに従う。
【０１５１】
一実施形態では、サーバファーム６１８における選択されたサーバ上で、Tomcatウェブサーバが実行されている。Tomcatウェブサーバは構築ジョブ要求を受信して、入力／出力が要求スレッドプールをブロックするのを防ぐために非同期サーブレット上で実行される外部プロセスを開始させる。プロセスが完了すると、Tomcatウェブサーバは、要求ペイロードにおいてコールバックＵＲＬへのＰＯＳＴ要求を作成する。以下の機能性は、この新しい要求のための例示的なペイロードを提供する。
【０１５２】
【数２】
0006679711.tif 000003
【０１５３】
ＭＣＳポータルＶＭ６１２は新しい要求を受信し、イベントが成功した場合には、構築ジョブのテーブルにおける対応する記録を、ペイロードからのバイナリキーで更新する。それはまた、（たとえば、オラクル・ビジネス・インテリジェンス・エンタープライズ・エディション（Oracle Business Intelligence Enterprise Edition：ＯＢＩＥＥ）１２ｃが計画された、ＯＢＩＥＥ１１ｇプッシュまたは非同期サーブレット上でのポーリングを介して）構築ジョブが完了したことをクライアント（すなわち第１のデバイス６０２）に通知し、アプリケーションをダウンロードするためのコード化されたリンクを有するＱＲコードを生成する（たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/(binaryKey)」）。
【０１５４】
アプリケーションのインストール
一実施形態では、第２のデバイス６０４のユーザがいったん第２のデバイス６０４上のＱＲコードをスキャンすると、「無線」インストールが開始される。ＱＲコードのスキャンにより、ＱＲコードにおいてコード化されたＵＲＬが開かれる（たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/(binaryKey)」）。パブリックＯＨＳ６０６は要求を受信し、ＳＳＬを終了させ、（ユーザがログインすると仮定して）ＯＡＭに対してユーザを認証および認可し、ユーザアイデンティティを要求のＨＴＴＰヘッダに配置し、要求を、ファイアウォール６０８を通過させてＭＣＳポータルＶＭ６１２のＷＬＳサーバ（たとえば、「http://mcs-tenant-a.internal/max/build」で実行されるＷＬＳサーバ）へ発送する。
【０１５５】
ＭＣＳポータルＶＭ６１２は要求を受信し、要求されたアプリケーションに対する特権についてユーザを認可し、要求元デバイス（第２のデバイス６０４）のユーザエージェント（このコンテキストでは、デバイスのＯＳフレームワーク、たとえばｉＯＳ対アンドロイド）を判断し、第２のデバイス６０４のプラットフォーム（たとえばｉＯＳ）を識別し、要求を、パブリックＯＨＳ６０６に向けることによって、対応するＵＲＬ（たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/plist/(binaryKey)」）へ発送する。パブリックＯＨＳ６０６は次に、（ユーザがアプリケーションをダウンロードすることを許可されることを保証するために、ここに説明される構築プロセス中に行なわれるように）認可するために、要求をＭＣＳポータルＶＭ６１２へ発送するであろう。ＭＣＳポータルＶＭ６１２は発送された要求を受信し、プロパティリストファイル（たとえばｉＯＳ「ｐ−ｌｉｓｔ」ファイル）を生成する。当該ファイルは、対応するプラットフォーム（たとえばｉＰｈｏｎｅ）についてのアプリケーション情報と、バイナリへのリンク（たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/ios/(binaryKey)」）とを含む。
【０１５６】
第２のデバイス６０４は次に、アプリケーションをインストールしたいかどうか、ユーザを促す。インストールしたいと仮定して、第２のデバイス６０４は、パブリックＯＨＳ６０６に向けることによって、バイナリへのリンク（たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/ios/(binaryKey)」）に従い、パブリックＯＨＳ６０６は次に、（ユーザがアプリケーションをダウンロードすることを許可されることを保証するために、ここに説明される構築プロセス中に行なわれるように）認可するために、要望をＭＣＳポータルＶＭ６１２へ発送するであろう。ＭＣＳポータルＶＭ６１２は要求を受信し、負荷分散部６１６の背後の（たとえば「http://max-mini-farm.internal/download/ios/(binaryKey)」にある）構築サーバファーム６１８への新しい構築ジョブ要求を生成する。負荷分散部６１６は、健全なサーバプールから（たとえば総当たりプロセスを介して）構築サーバファーム６１８におけるあるサーバを選択し、構築ジョブ要求をそのサーバへ（たとえば「http://mac-mini1.internal/download/ios/(binaryKey)」へ）ルーティングする。選択されたサーバ上のアプリケーションサーバ（たとえば、Tomcat）が要求を受信し、対応するコンテンツが存在するかどうかを判断し、ネットワークから（たとえば、「Filer:/filer_mnt/generated_binaries/(binaryKey)/result.ipa」から）バイナリをストリーミングする。負荷分散部６１６は、ストリーミングされた応答をＭＣＳポータルＶＭ６１２へ返し、ＭＣＳポータルＶＭ６１２は応答を受信し、それを第２のデバイス６０４へのその要求の出力ストリームにコピーする。最後に、第２のデバイス６０４はバイナリを受信してインストールを行なう。
【０１５７】
図７は、ＯＭＳＳなどのモバイルセキュリティスイート７００によって提供されるセキュリティサービスを使用する一実施形態におけるモバイルセキュリティスイートコンポーネントのブロック図である。ＯＭＳＳコンポーネントは、企業ＤＭＺ７４０およびエンタープライズイントラネット（または企業ネットワーク７５０）にわたって分散される。ＯＭＳＳの下で、オラクル社からの「オラクル・モバイル・セキュリティ・コンテナ」などのセキュリティコンテナ７０６が、モバイルデバイス７０２にインストールされ、「コンテナ化された」アプリケーション７０８、たとえば、それらの特定のコンテナにセキュアにリンクされたアプリケーションを保持するように構成される。モバイルデバイス７０２はまた、セキュリティコンテナ７０６の外部で保持された他のパーソナルアプリケーション７０４を含んでいてもよい。
【０１５８】
セキュリティコンテナ７０６は、セキュアウェブブラウザ７１２と、ファイルマネージャ（図示せず）と、文書エディタ（図示せず）と、オプションのセキュアモバイルメールマネージャ７１０とを含む。セキュアモバイルメールマネージャ７１０は、「マイクロソフト・エクスチェンジ・アクティブシンク」（Microsoft Exchange ActiveSync：ＥＡＳ）プロトコルを介して企業メールサーバと同期するメールクライアント、カレンダ、連絡先、タスク、およびメモなどの個人情報管理（personal information management：ＰＩＭ）アプリケーションを含む。「オラクル・ビジネス・インテリジェンス」（Business Intelligence：ＢＩ）、「オラクル・フュージョン・タップ」、「オラクル・ソーシャル・ネットワーク」、「オラクル・エンタープライズ・マネージャ・クラウド制御」、「オラクル・ウェブセンター・スペース」などの多くのアプリケーション、および広範囲の第三者エンタープライズアプリケーションが、セキュリティコンテナ７０６でコンテナ化され得る。モバイルデバイス７０２上のコンテナ化されたアプリケーション７０８の内部にあるすべてのデータが暗号化される。暗号化されたデータストレージは、データベース、ファイルストア、キャッシュ、およびユーザの好みを含む。セキュリティコンテナ７０６は、企業ＤＭＺ７４０の背後の企業ネットワーク７５０と通信するために、（その開示全体がここに援用される米国特許第８，３３２，４６４号に記載されているような）「AppTunnel」７１４などのセキュアチャネルを使用する。一実施形態では、AppTunnel７１４を通して移行されるデータは、連邦情報処理規格（Federal Information Processing Standard：ＦＩＰＳ）が承認したアルゴリズムでＴＬＳ／ＳＳＬを使用して暗号化される。
【０１５９】
一実施形態では、ウェブブラウザまたは他のクライアントプログラムがオラクル社からの「オラクル・モバイル・セキュリティ・アクセス・サーバ」（Oracle Mobile Security Access Server：ＭＳＡＳ）などのセキュリティアクセスサーバに未認証の要求を行なうと、セキュリティアクセスサーバは、適切なセキュリティコンテナへの転送で応答する。セキュリティコンテナは、データを保護するためにキー階層を使用する。すべてのキーは、格納されていないユーザクレデンシャルから導き出される。キー階層は、データのさまざまな感度をサポートするための複数のキーを必要とする。たとえば、ある固有キーは、極めて短期間だけ開くことが許可されるユーザの認証証明書のために使用される。別のキーは、セッション全体について復号化されたままでなければならないブラウザキャッシュのために使用される。主セキュリティコンテナは、ユーザのセキュアなエンタープライズワークスペースにおける完全な一組のアプリのためのキーを分散させ、管理する。
【０１６０】
セキュアコンテナ７０６は、従来のモバイル仮想プライベートネットワーク（virtual private network：ＶＰＮ）ソリューションに勝る少なくとも３つの独特の利点、すなわち、デバイストラスト対ゲートウェイ、セキュアコンテナパスワード対デバイスパスワード、および、セキュアコンテナAppTunnel対デバイスレベルＶＰＮを有する。ＯＭＳＳは、ネットワークのケルベロス認証トラストを、ＤＭＺに搭載されているゲートウェイサーバで止めるのではなく、ユーザのデバイスまで直接延長する。ＯＭＳＳは、ＶＰＮプロバイダによって提供される「制約付き委任」を実現する場合に比べ、著しくより効率的でより安全である。制約付き委任ソリューションは、安全性がより低いだけでなく、設定して維持するのがより面倒である。また、消費者デバイスおよびＢＹＯＤプログラムを扱う際に、有用性とセキュリティとの間のトレードオフが大きくなる。企業ＩＴは、ＢＹＯＤデバイス上の企業データを保護するために強力なパスワードを要求する。逆に、ユーザは、ソーシャルネットワークおよび他の消費者アプリケーションに容易にアクセスできるように、単純なパスワードを所望するか、または、好ましくはデバイスパスワードが全くないことを所望する。デバイスパスワードを要求することは、ユーザにとっては苛立たしい。なぜなら、ユーザは常に、エンタープライズ認証を必要としない非エンタープライズ目的のためにデバイスを使用しているためである。実施形態は、企業アプリケーションにアクセスするためだけにパスワードを要求することにより、ＢＹＯＤプログラムを扱う際のセキュリティと有用性との間の必要なバランスを提供する。
【０１６１】
さらに、デバイスレベルＶＰＮは、ユーザのデバイスとエンタープライズのネットワークとの間に信頼できるセキュアなトンネルを提供する。しかしながら、デバイスレベルＶＰＮソリューションは、消費者モバイルデバイスよりも、ラップトップなどの企業所有のセキュアなエンドポイントデバイスにとって、より適切である。モバイルデバイスＶＰＮトンネルがネットワークまでいったん開通すると、デバイス上のどのアプリケーションもこのセキュアなトンネルへのアクセスを有し、著しいセキュリティ脆弱性をもたらす。しかしながら、実施形態によれば、モバイルデバイス７０２からエンタープライズイントラネット７５０への接続は、セキュアコンテナ７０６とエンタープライズサーバとの間にのみ存在する。
【０１６２】
モバイルセキュリティスイート７００では、ＭＳＡＳ７１６が典型的には企業ＤＭＺ７４０にデプロイメントされており、複数のサーバインスタンスが、高い可用性およびスケーラビリティのために負荷分散部の背後にデプロイメントされ得る。ＭＳＡＳ７１６は、サーバとコンテナ化されたアプリ７０８との間にトンネル接続を提供する。ＭＳＡＳ７１６は認証を仲介し（強力な認証が、「オラクル・アクセス・マネージャ」（Oracle Access Manager：ＯＡＭ）７２２へのＨＴＴＰＳ接続、またはケルベロスドメインコントローラ７１８へのケルベロス接続を利用する）、それらの宛先（ウェブアプリケーションおよびウェブサービス７２４といった、企業イントラネット７５０におけるリソース）のためのＳＳＯを認可し、監査し、有効にするとともに、当該宛先への要求をプロキシする。ＭＳＡＳ７１６は、セキュリティコンテナ７０６およびコンテナ化されたアプリケーション７０８によって開始されたトンネル型接続の終端エンドポイントとして機能する。
【０１６３】
ＭＳＡＳ７１６は、セキュリティ、脅威からの保護、およびスロットリングポリシーを組織のＲＥＳＴ  ＡＰＩインフラストラクチャに追加するために、オラクル社からの「オラクルＡＰＩゲートウェイ」（Oracle API Gateway：ＯＡＧ）およびオラクル社からのＯＷＳＭをサポートする。ＳＳＯは、ＯＡｕｔｈ、ＯＡＭトークン、ケルベロス、およびＮＴ  ＬＡＮマネージャ（NT LAN Manager：ＮＴＬＭ）を通してサポートされる。ＳＡＭＬは、オラクル（カリフォルニア州）またはピン・アイデンティティ（Ping Identity）などのＳＡＭＬアイデンティティプロバイダとのＯＡＭ７２２またはケルベロス統合を通してサポートされる。ＭＳＡＳ７１６は、ＯＡＭプラットフォームと統合され、ＯＡＭ、ＯＡＧ、およびＯＷＳＭによって保護されたバックエンドリソースへのＳＳＯのためのＯＡＭおよびＯＡｕｔｈのトークンの検索をサポートする。ＭＳＡＳ７１６はまた、ＰＩＮによって保護されたマイクロソフト・アクティブ・ディレクトリへのパブリックキーインフラストラクチャ（public key infrastructure：ＰＫＩ）認証を行なうことにより、「仮想スマートカード」認証をサポートする。デジタル証明書はセキュリティコンテナアプリ内にプロビジョニングされ、ＰＩＮ検証が成功した後にのみアクセスされる。ＯＡＭとのＭＳＡＳ統合は、コンテキスト認識型でリスクベースのステップアップ認証を可能にする。
【０１６４】
モバイルセキュリティスイート７００はまた、ＳＯＡスイートのコンポーネントであってウェブサービスベースのＳＯＡセキュリティおよび管理に対処する、ＯＷＳＭを実装する。ＳＯＡインフラストラクチャの目的は、消費者が、プロバイダによって公開されたサービスを呼出すことを可能にすることである。ＯＷＳＭは、そのようなサービスインフラストラクチャのポリシー管理およびセキュリティのためのソリューションを提供する。それは、オラクル社からの「オラクル・エンタープライズ・マネージャ」によって提供される集中型管理インターフェイスを通して、ポリシーの可視性および制御を提供する。ＯＷＳＭは、会社が、（１）ＳＯＡインフラストラクチャを構成する複数のウェブサービスに適用された宣言的ポリシーを集中的に定義して格納すること、（２）構成可能エージェントを通してセキュリティおよび管理ポリシーをローカルに実施すること、および、（３）失敗した認証または認可などの実行時セキュリティイベントを監視すること、を可能にする。それはまた、実行中のビジネスプロセスを中断する必要なく、ポリシー変更がリアルタイムで実施されるようにすることによって、セキュリティ脅威およびセキュリティ違反に対応するためのビジネスアジリティ（business agility）を提供する。
【０１６５】
モバイルセキュリティスイート７００はまた、企業ネットワーク７５０内に「オラクル・モバイル・セキュリティ・マネージャ」（Oracle Mobile Security Manager：ＭＳＭ）を実装する。ＭＳＭ７２０は、オラクルＬｉｎｕｘまたはレッド・ハット・エンタープライズ（Red Hat Enterprise）Ｌｉｎｕｘ上で実行される「WebLogic」管理型サーバである。ＭＳＭ７２０は、企業ネットワーク７５０におけるマイクロソフトエクスチェンジサーバ７２８と統合して、企業電子メールサービスへのアクセスを提供する。ＭＳＭ７２０はまた、ＬＤＡＰサーバ７３２と統合して、ユーザをプロビジョニングし、モバイルデバイス管理のためのおよびセキュリティコンテナ７０６にアクセスするためのポリシーを割当てて管理し、アプリカタログを管理し、デバイスのリモートロックまたはワイプを制御してワークスペースアプリをセキュアにし（セキュリティコンテナ７０６をワイプすることは、ワークスペースアプリについてのデータおよび構成をすべて削除する）、セキュリティコンテナのためのアクセス制御ポリシーを設定する。ポリシーは、ポリシーテンプレートをユーザおよびユーザグループに関連付けることによって、ユーザに割当てられる。利用可能なポリシー制御は、デバイス制限、認証（認証頻度、失敗した試みのしきい値、ＰＫＩのためのＰＩＮ強度）、カタログ（アプリ、ＵＲＬ、ファイル共有）、コンテナ／アプリ（損なわれたプラットフォーム、位置サービス、オフラインステータス、非活動期間、データリーク防止（data leak prevention：ＤＬＰ））、時間アクセス（時間窓外の場合にロックする）、地理的アクセス（Geo Access）（地理的フェンス（市、州、国）外の場合にロックする）、デバイス（特定のデバイスモデルをホワイトリストに載せる、最小ＯＳレベルを特定する）、ブラウザ（アドレスバーを無効にする、ダウンロードを無効にする）、ファイルブラウザ（ダウンロードを許可／却下、無効にする、ファイルサーバＵＲＬを指定する）、個人情報マネージャ（personal information manager：ＰＩＭ、メールサーバＵＲＬ）、プロビジョニング（テンプレート、ＰＫＩ詳細を勧める）などを含む。ユーザが複数のグループにいて複数のポリシーを有する場合、ポリシーの組合せは特定のルールに従って解決される。
【０１６６】
ＭＳＭ７２０はＥＭＭポリシーを維持し、それらは次に、ディレクトリにおける１つ以上のユーザグループに関連付けられる。ＭＳＭ７２０は、ユーザ管理またはグループ管理を行なわないが、これらのアイデンティティおよびグループをディレクトリストアから直接（同期なしで）利用する。ＭＳＭ７２０は、ＨＴＴＰＳに対してＡＰＮＳおよびＣＧＮを使用して、デバイスへ通知を送信する。ＭＳＭ７２０はまた、内部のＣＩＦＳ／ＳＭＢ対応ファイルシステム７３０または「マイクロソフト・シェアポイント（SharePoint）サーバ」にＷｅｂＤＡＶフロントエンドを公開して、クライアントからのイントラネットファイル共有をブラウジングすることを可能にする。
【０１６７】
ソーシャルネットワーク上にますます多くの組織が存在を確立すると、ＩＴ部門は、ソーシャルアイデンティティのためのサポートを必要とする。ソーシャルアイデンティティは、エンタープライズアイデンティティよりも軽量のセキュリティ基準に依拠するものの、ソーシャルネットワークの要件により良好に適合されている。たとえば、いくつかのウェブサイトは、ユーザが、それらのサービスに認証されるために、フェースブックまたはグーグルから取得されたアクセストークンを提供することを要求する場合がある。したがって、モバイルセキュリティスイート７００はまた、既存のバックエンドアイデンティティ管理インフラストラクチャとインターフェイス接続するサーバを含むＯＡＭＭＳを実装する。サーバは、サポートされたモバイルクライアントアプリとバックエンドアイデンティティサービスとの間の仲介主体として作用する。これにより、クライアントアプリはバックエンドインフラストラクチャから分離され、そのため、モバイルクライアントプログラムを更新する必要なく、バックエンドインフラストラクチャを修正することができる。ＯＡＭＭＳは、以下の機能性を含む：
・ＯＡｕｔｈ規格を利用する委任された認可；
・エンタープライズアイデンティティ管理インフラストラクチャ、典型的には「オラクルアクセス管理プラットフォーム」に、ブラウザベース（ＨＴＭＬ５）および固有のモバイルアプリを接続するモバイルサービス；
・グーグル、Ｙａｈｏｏ、フェースブック、ツイッター、またはLinkedInといった、人気のあるクラウドベースのアイデンティティ認証および認可サービスと対話する際に、ＯＡＭＭＳを信頼できる当事者として使用させるインターネットアイデンティティサービス。ＯＡＭＭＳをデプロイメントすることにより、ユーザには、アイデンティティプロバイダごとにアクセス機能を個々に実現する必要なく、複数のログインオプションが提供される。ＬＤＡＰ  ＣＲＵＤ動作のためのＲＥＳＴインターフェイスを提供するユーザプロファイルサービス（顧客は、アプリ用のグラフィカルＵＩを構築するために同じＲＥＳＴインターフェイスを使用する）；自己登録、プロファイルメンテナンス、パスワード管理、およびアカウント削除などのユーザのセルフサービス機能。ユーザプロファイルサービスは、ＯＡｕｔｈリソースとしても利用可能である；
・エージェントＳＤＫによって提供される実行時ＲＥＳＴインターフェイスを通してＯＡＭ７２２を利用するためのアクセス管理統合サービス。
【０１６８】
図８は、本発明の実施形態に従ったモバイルアプリケーション開発のためのフロー図である。一実施形態では、図８（および以下に説明される図１０）のフロー図の機能性は、メモリもしくは他のコンピュータ読取可能媒体または有形媒体に格納され、プロセッサによって実行される、ソフトウェアによって実現される。他の実施形態では、機能性は、ハードウェアによって（たとえば、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）、プログラマブルゲートアレイ（programmable gate array：ＰＧＡ）、フィールドプログラマブルゲートアレイ（field programmable gate array：ＦＰＧＡ）などの使用を通して）、またはハードウェアとソフトウェアとの任意の組合せによって、行なわれてもよい。クラウドベースのモバイルアプリケーション開発の一例が、「モバイル実行時のための解釈されたアーチファクトの生成のためのクラウドベースのエディタ」（CLOUD BASED EDITOR FOR GENERATION OF INTERPRETED ARTIFACTS FOR MOBILE RUNTIME）と題された、２０１５年６月２９日に出願された米国仮出願第６２／１８６，０８０号（代理人明細書Ｎｏ．：８８３２５−９２４７２１（１６５７０１ＵＳ）、クライアント参照Ｎｏ．：ＯＲＡ１５０６００−ＵＳ−ＰＳＰ）に提供されており、当該仮出願の開示はここに引用により援用される。
【０１６９】
８１０で、アプリケーション定義ウィザードが生成される。ここに使用されるようなアプリケーション定義ウィザードは、１つ以上の予め定義されたクラウドアクセス可能なサービスを利用するモバイルアプリケーションの定義プロセス中にユーザを誘導する一組の１つ以上のＵＩを表わす。アプリケーション定義ウィザードは、アプリケーション定義プロセスの一部に各々関連付けられた、１つ以上のワークフローを実現することができる。一実施形態では、アプリケーション定義ウィザードは、アプリケーション識別子プレフィックス、デフォルトアイコン、スプラッシュスクリーン、デフォルトアプリケーション／特徴テンプレート、設定エンタープライズプロビジョニングプロファイル／キーストアなどのアプリケーションデフォルトを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。
【０１７０】
ある実施形態では、アプリケーション定義ウィザードは、アプリケーション名、フォームファクタ（電話またはタブレットデバイスなど）、ナビゲーションタイプ（たとえば、スプリングボード、ナビゲーションバー（navigation bar：ＮａｖＢａｒ）、スプリング／Ｎａｖコンボなどとして、単一の特徴またはＵＩを意味しないもの）、および任意のアプリケーションの好みを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。
【０１７１】
８２０で、アプリケーション定義が受信される。ここに説明されるように、アプリケーション定義は、少なくとも最小限機能的なモバイルアプリケーションを作成するために必要とされるあらゆる情報を含み得る。８３０で、アプリケーション定義に基づいてモバイルアプリケーションが生成される。一実施形態では、モバイルアプリケーションは、ターゲットデバイスのシミュレータにおいて表わされ、解釈時にコンパイルされたモバイルアプリケーションとして機能する一組の定義を含み得る。
【０１７２】
８４０で、特徴選択ウィザードが生成される。ここに使用されるような特徴選択ウィザードは、１つ以上の予め定義されたクラウドアクセス可能なサービスを利用するモバイルアプリケーションの開発プロセス中にユーザを誘導する一組の１つ以上のＵＩを表わす。特徴選択ウィザードは、アプリケーション開発プロセスの一部に各々関連付けられた、１つ以上のワークフローを実現することができる。一実施形態では、特徴選択ウィザードは、モバイルアプリケーションとともに使用可能な特徴、ＵＩモジュール、ビジネスオブジェクトなどを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。
【０１７３】
ある実施形態では、特徴選択ウィザードは、モバイルアプリケーションの第１の画面のコンポーネントを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。コンポーネントは、コンポーネントのカタログから選択され得る。
【０１７４】
ある実施形態では、特徴選択ウィザードは、モバイルアプリケーションの他の画面のコンポーネントを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。これらの他の画面は、１つ以上のＵＩモジュールの一部を形成することができる。ある実施形態では、特徴選択ウィザードは、モバイルアプリケーションの１つ以上のＵＩモジュールを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。ＵＩモジュールは、モバイルアプリケーションに対して行なわれ得るプロセッサ、タスク、またはフローを表わす。ＵＩモジュールは、ＵＩ要素およびページフローの結束した集合を提供する一組のテンプレートまたはＵＩモジュールのカタログから選択され得る。ＵＩモジュールのいくつかの例は、承認ワークフロー、ワーカータスク、データ入力タスク、レポートビルダなどである。テンプレートは、一組のＵＩ要素からなる予め設定された配置／バインディングを提供するため、ユーザは、個々のＵＩ要素を配置およびバインドする必要なく、それらのＵＩ要素を構成してテンプレートをバインドするだけでよい。一実施形態では、ユーザは、自分のテンプレートを、別のユーザにとって利用可能なテンプレートのセットに与えてもよい。ユーザは、ＵＩモジュールを表わす一連のページを構成するかまたは他の態様で指定することができる。ページごとに、従来と同様に一組のレイアウトテンプレートをユーザに提示することができる。各レイアウトテンプレートは、二次的テンプレートを選択するなどのいくつかの局面を有していてもよい。
【０１７５】
いくつかの実施形態では、特徴選択ウィザードは、予め定義されたビジネスオブジェクトといった、モバイルアプリケーションの追加特徴を指定するよう、ユーザを促すかまたは他の態様で誘導することができる。ユーザは、バックエンドサービス、ＡＰＩ、またはコネクタのうちのどのリソースが、使用されるべきか、または、各コンポーネント、画面、ＵＩモジュールなどのＵＩ要素に他の態様で関連付けられるべきかを指定することができる。
【０１７６】
８５０で、特徴定義が受信され、８６０で、データバインディングウィザードが生成される。ここに使用されるようなデータバインディングウィザードは、１つ以上の予め定義されたクラウドアクセス可能なサービスを利用するモバイルアプリケーションのデータバインディングプロセス中にユーザを誘導する一組の１つ以上のＵＩ、または既存のＵＩのＵＩ要素を表わす。データバインディングウィザードは、アプリケーション開発プロセスの一部に各々関連付けられた、１つ以上のワークフローを実現することができる。一実施形態では、データバインディングウィザードは、特徴、画面、ＵＩモジュールなどが、モバイルアプリケーションとともに使用可能なビジネスオブジェクト、サービス、ＡＰＩなどにどのようにバインドされるかを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。ある実施形態では、データバインディングウィザードは、モバイルアプリケーションのビジネスオブジェクトを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。ビジネスオブジェクトは、モバイルアプリケーションにとって利用可能なサービス、ＡＰＩなどのカタログまたはセットから選択され得る。
【０１７７】
８７０で、データバインディング定義が受信される。さまざまな実施形態では、ステップ８４０〜８７０は、連続して、または並行に行なわれ得る。８４０〜８７０における個々のステップは、モバイルアプリケーションの個々の要素に対して、または要素のグループに行なわれ得る。図示されるように、ユーザは、モバイルアプリケーションを作成するために特徴定義およびデータバインディングのプロセスを繰返すことができる。
【０１７８】
８８０で、モバイルアプリケーションがデプロイメントされる。ユーザは、ターゲットデバイス上にデプロイメントされたテスト用アプリケーションを使用して、またはターゲットデバイス上にデプロイメントされた固有アプリケーションとして、アプリケーションをテストすることができる。
【０１７９】
トランザクション自動保存
現在、ほとんどのウェブアプリケーションでは、ユーザによって行なわれる明示的な保存アクションはない。代わりに、アプリケーションがそのコンテンツをユーザに代わって自動保存する。したがって、アプリケーションは、ある保存境界がいつ生じるかを判断し、次に、それに応じて自動保存を行なう必要がある。保存境界とは、アプリケーションの自動保存をトリガするように構成された条件（たとえば、時間インスタンス／間隔、ユーザアクション、アプリケーション変数値、アプリケーション／システムイベントなど）である。
【０１８０】
いくつかの公知のシステムは、単純な時間ベースの制御機能性に基づいて自動保存を行なう（たとえば、ある設定時間の後で自動保存する）が、より論理的な保存境界を必要とするアンドゥ／リドゥアクションの場合には理想的ではない。いくつかの公知のシステムは、ユーザがアクションを行なうと自動保存がトリガされる、アクションベースの境界を使用する。これらのシステムは、アンドゥ／リドゥアクションに応答して自動保存機能性を提供できるが、自動保存をいつ行なうか、および、同じユーザアクションに結び付けられるモデル変更をどのように調整するかを判断することについて複雑性の増加をもたらし得る。たとえば、ユーザが画面上の何らかのテキストをバックエンドサービスにバインドする場合、ＵＩ定義ファイルおよびバインディング定義ファイルにそれぞれの変更が行なわれ、これらのファイルの各々は、それらのそれぞれのモデルによって修正される。したがって、アンドゥ／リドゥアクションによってトリガされる自動保存を提供することは、これらのモデル変更の調整を必要とし、それは複雑性の増加をもたらす。モデルとは、画面上のＵＩコンポーネントを記述する宣言的構文を含むページスキーマなどの、実データに対する抽象化である「信頼できる情報源（source of truth）」である。
【０１８１】
さらに、性能およびデータの完全性に関し、クライアントは、保存アクションが無事行なわれたかどうかをサーバに確認する必要があり、そのため、クライアントは、それが保存アクションを再試行する必要があるかどうかを知っている。いくつかの公知のシステムは、サーバ応答を待ってから、さらなるユーザ入力を可能にする。しかしながら、この待機はユーザへのＵＩをブロックし、サーバへの接続が遅い場合には性能を著しく損なう。いくつかの公知のシステムはサーバを待たず、クライアントＵＩをブロックしない。しかしながら、サーバが故障した場合、サーバとクライアントとの間の状態がもはや整合しないため、クライアントは回復できないことが多い。
【０１８２】
対照的に、実施形態は、ユーザアクションをクライアント上の特定のモデル変更と相関させ、対応するアクションベースの保存境界を提供しつつ、データ完全性を保証する、トランザクションシステムを実現する。加えて、実施形態は、保存アクションのためにサーバ応答を待つ必要がない（そのため、クライアントＵＩをブロックしない）。その上、保存アクションを試みる間にサーバエラーが起こった場合には自己回復を可能にする。
【０１８３】
一実施形態は、クライアント側モデルに影響を与えるユーザアクションによってトリガされるクライアント側トランザクションを定義する。トランザクションとは、単一のユーザアクションによって生じる一連の関連する変更である。たとえば、ＵＩ定義ファイルおよびバインディング定義ファイルに変更が行なわれることを要求する、画面上の何らかのテキストをバックエンドサービスにバインドするユーザアクションについて、これらのファイルの各々についてそれぞれのモデル変更を適用する代わりに、一実施形態は、これらのモデル双方への変更を含むトランザクションを取込み、当該トランザクションを使用して自動保存機能性をサポートする。
【０１８４】
一実施形態では、モデルが修正されると、変更記録が現在のトランザクションに追加される。ユーザアクションの完了後、トランザクションはコミットされ、修正は変更記録に記録される。モデルの一例は、現在の画面上のＵＩコンポーネントを記述する宣言的構文であるページスキーマである。このモデルは、画面を定義する拡張可能マークアップ言語（extensible markup language：ＸＭＬ）コードを操作するアプリケーションプログラミングインターフェイス（ＡＰＩ）として実現されてもよい。このモデルについての例示的なモデル変更は、以下のとおりである：
【０１８５】
【数３】
0006679711.tif 000004
【０１８６】
ここで、「some_component」はページモデルにおけるＵＩコンポーネントであり、変更は、スタイル属性をレッドにするよう修正することである。このモデルについての例示的なトランザクションは、ユーザがボタンをクリックすることによって生じ得る一連のモデル変更（たとえば、ページスキーマおよび対応するバインディングへの前述の変更）である。このモデルについて自動保存アクションをトリガするように構成され得るユーザアクションの例は、ボタンを押下すること、何らかのテキストを入力すること、ＵＩの何らかのピースをドラッグ・アンド・ドロップすること、などといったユーザジェスチャーである。たとえば、あるアプリケーションを開発するために「新規アプリケーションウィザード」を完了させると、ユーザは当該アプリケーションおよびその画面モデルを修正してもよく、ユーザが当該アプリケーションの開発を終了するために「終了」ボタンを押すと、自動保存がトリガされ得る。
【０１８７】
一実施形態は、ローカルコンテンツをサーバのリモート持続ストアに自動保存するための保存境界を定義する。持続ストアとは、データを長期間格納するストレージ（たとえば、ファイルシステム、データベースなど）である。この実施形態は、２つの別個のキュー上に２つの別個のライフサイクルを実現する。変更記録はまず、変更をローカルモデルにコミットするために、ローカルキュー上のローカルライフサイクルに適用される。このライフサイクルは非常に速く起こり、クライアントＵＩがこれらの変更をほぼ瞬間的に反映することを可能にする。変更記録は、それらがサーバへ送信されるためにリモートキューに入れられているリモートライフサイクルの下でも実行される。リモートキューとは、サーバのリモート持続ストアに格納されるものを管理する持続キューである。リモートキュー上に入れられた変更記録は、それらが作成された順序でサーバへ「同期して」送信される。すなわち、一実施形態では、リモートキュー上の変更記録は一度に１つずつ処理され、各変更記録は、前の変更記録がサーバ上に無事記録された場合のみ、サーバへ送信される。これは、変更の順序がサーバで維持されることを保証する。
【０１８８】
サーバへの変更を保存する保存要求が失敗すると、実施形態は、それらがキューに入れられた保存要求をそこから再送する必要がある、リモートキューのポイントを認識する。したがって、実施形態は、リモートキューにおける失敗した記録を再試行し、それから、次の記録を続ける。サーバ不良が続く場合、実施形態はオフラインモードへ移行して、リモートライフサイクル上に変更記録を記録し続ける。これらの記録は次に、サーバとの接続が復元された場合、またはサーバの不安定性が補正された場合に、正しい順序でサーバに保存される。
【０１８９】
ほぼ瞬間的なＵＩ更新を可能にすることにより、実施形態は、データ完全性を犠牲にすることなく、クライアントＵＩ性能を向上させる。たとえば、ユーザによって行なわれるアクション（複合アーチファクトを作成するといった、複雑なアクションを含む）が、ユーザのために直ちに完了される。また、サーバ保存は同期しているため、実施形態はサーバ停止を取扱うことができ、データが失われず、コンテンツがサーバとの最終的な整合性を有するであろうということを保証できる。
【０１９０】
一実施形態では、ユーザアクションがトリガされると、トランザクションが作成され、アクションが完了すると、コミットされるかまたはロールバックされる。アクションは、システムがそのアクションの結果を処理し終えたときに完了する。これらの２つのイベント（ユーザアクション、およびユーザアクションの完了）の合間に、モデル変更が、ユーザアクションに応答して起こり得る。たとえば、ユーザアクションがボタンを押下することである場合、システムはそのような押下に応答し、アクションは、システムが押下の処理を完了したときに完了する。たとえば、ページのある部分に新しい属性を追加するためにボタンが押下されたものの、その属性を追加することは違法であると考えられる場合、トランザクションはキャンセルされる。一方、属性が実際に合法である場合には、トランザクションはコミットされる。
【０１９１】
別の例として、ユーザが「ドラッグ・アンド・ドロップ」機能性によって画面へのボタンの追加を試みた場合、ユーザがボタンを画面に無事ドロップできれば、トランザクションは完了する。しかしながら、ユーザが、あるボタンを別のボタン内に追加するといった、受け入れがたいアクションを行なおうとした場合、ページモデルは、このアクションが受け入れがたいことを検出し、システムに通知する。これはトランザクションを失敗させ、トランザクションのすべての関連活動（すべてのモデル変更）がロールバックされる（逆戻りされる）。いくつかの実施形態では、ユーザジェスチャーによって開始された単一のモデル変更に応答して、追加のモデル変更が行なわれてもよい。たとえば、ユーザが受け入れ可能な位置でボタンをドロップした場合、システムは、別個の／追加のモデル変更としてテキストをボタンに（たとえばデフォルトで）自動的に追加してもよい。
【０１９２】
一実施形態は、トランザクションデータベースにおいて提供されるようなトランザクション機能性を実現する。トランザクションデータベースとは、データベース上の書込みトランザクションが（たとえば、電力または接続性の損失により）適切に完了されていない場合に、それらをロールバックすることができる、データベース管理システム（database management system：ＤＢＭＳ）である。いくつかのリレーショナルＤＢＭＳは、データベースにおける情報を各々読出し、および／または書込む１つ以上のデータ操作文およびクエリを含むトランザクションをサポートする。トランザクションはまた、新しいトランザクション（すなわち、サブトランザクション）を開始する文を内部に含む入れ子式トランザクションとして実現されてもよい。トランザクションは、その実行中にエラーが生じない場合にコミットされる。トランザクションコミット動作は、トランザクション内のすべてデータ操作に当てはまり、結果を対応するモデルまで持続させる。トランザクション中にエラーが生じた場合、またはユーザがロールバック動作を指定した場合、トランザクション内のデータ操作はモデルまで持続されない。部分的なトランザクションをモデルにコミットすることはできない。なぜなら、それはモデルを一貫性のない状態に置くためである。
【０１９３】
一実施形態では、各モデルは、変更を行ない、その変更をアンドゥするための最小の一組の命令を含む、トランザクションへのその変更を記録するように構成される。そのような最小の一組の命令は、アンドゥ／リドゥアクションを実現するために使用され得る。たとえば、ＸＭＬによって支援されるページモデルについては、「some_component.setAttribute(…)」を呼出すことはＸＭＬを直ちに修正し、「[set attribute “foo” on element “X”]」は、アンドゥ／リドゥアクションを実現するために使用され得る特異な命令であり得る。
【０１９４】
一実施形態では、トランザクションがコミットされると、それは、トランザクションがそれらが完了された順序で記録されているローカルライフサイクルへ送信される。トランザクションは、その変更が対応するクライアント側モデルに適用され、あらゆる必要なＵＩが変更を反映するように更新されたときに、「記録された」と考えられる。トランザクションがいったんローカルに記録されると、その変更記録は、リモートライフサイクルのリモート持続キューに追加される。リモートライフサイクルとは、サーバに保存される必要があるトランザクション変更記録のキューである。これらの記録は一度に１つずつ処理され、コンテンツがサーバ上にどのように持続されているかを示す。サーバへの変更記録の持続が完了した場合、変更記録はリモート持続キューから除去される。しかしながら、サーバ保存が失敗した場合、または、ある期間後（たとえば、持続動作を試みてから２０秒後）に応答が受信されない場合、持続動作は失敗したと判断される。この場合、一実施形態は、指数バックオフアルゴリズムを使用して保存アクションを再試行する。たとえば、一実施形態は、１秒後に保存アクションの第１の再試行を試み、第１の再試行が失敗した場合、２秒待って第２の再試行を試み、第２の再試行が失敗した場合、４秒待って第３の再試行を試みる、などとなっている。失敗が続く場合、一実施形態はオフラインモードへ移行し、サーバ接続が復元されたかどうかを判断するためにより長い時間間隔で（たとえば毎分）チェックする。これは、持続キューのヘッドでトランザクションの保存を再試行することによって行なわれてもよい。
【０１９５】
実施形態は、クラウド環境におけるものといった、あらゆるウェブベースのアプリケーションに適用可能である。たとえば、クラウドベースのＩＤＥにおけるウェブベースのアプリケーションのユーザが、ＵＩにおける設計キャンバス上にオブジェクトをドラッグ・アンド・ドロップした場合、別個ではあるものの論理的に関連する多くのファイルが更新され、これらのファイルへの変更は単一の論理トランザクションとして取扱われて、単一のアトミックトランザクションとしての組合されたアクションのアンドゥ／リドゥを可能にする。ＩＤＥを提供する分散型システムでは、特定のトランザクションの一部であるオブジェクトのうちのいくつかは、ユーザにとってリモートであってもよい。したがって、実施形態は、これらのリモート更新の調整がユーザ観点からブロックしていないこと、および、失敗したトランザクションが再実行されないよう、リモートシステムへ送信された変更が順序に関して調整されることを保証する。
【０１９６】
一実施形態は、アンドゥまたはリドゥされ得るコミットされたトランザクションの履歴を含むアンドゥ履歴リストを管理する「TransactionManager」ＪａｖａＳｃｒｉｐｔモジュールを実現する。TransactionManagerはシングルトンであり（すなわち、このＪａｖａＳｃｒｉｐｔモジュールの１つだけのインスタンスが作成される）、呼出し側が変更の記録を開始できるように、呼出し側に「startTransaction」ＪａｖａＳｃｒｉｐｔ方法を提供する。呼出し側はいつでも、「getCurrentTransaction()」ＪａｖａＳｃｒｉｐｔ方法を使用して現在のトランザクションを検索することができる。いったんすべての変更が行なわれると、「TransactionManager」は、変更記録をアンドゥ履歴に保存するために、「commitTransaction()」ＪａｖａＳｃｒｉｐｔ方法を呼出す。何らかの理由でトランザクションの寿命中にエラーがある場合、またはコミット動作が失敗した場合には、「TransactionManager」は、記録された変更を除去する「rollbackTransaction()」ＪａｖａＳｃｒｉｐｔ方法を呼出す。最新のトランザクションをアンドゥするために、「（undo()」ＪａｖａＳｃｒｉｐｔ方法を呼出すことができる。「undo()」を繰り返し呼出すことは、各トランザクションをアンドゥすることによってトランザクションの履歴を逆探知する。どの時点でも、最も最近のアンドゥトランザクションをリドゥするために、「redo」ＪａｖａＳｃｒｉｐｔ方法を呼出すことができる。「redo」は、「undo」が呼出されたのと同じくらい多く呼出され得る。各「undo」／「redo」は、アンドゥ／リドゥタイプの「TransactionEvent」ＪａｖａＳｃｒｉｐｔ方法をトリガする。「undo」および「redo」ＪａｖａＳｃｒｉｐｔ方法は、トランザクション内で呼出されるべきでない。
【０１９７】
一実施形態は、トランザクションの一部を構成する変更記録のためのベースＪａｖａＳｃｒｉｐｔモジュールとして、「ChangeRecord」ＪａｖａＳｃｒｉｐｔモジュールを実現する。各トランザクションは１つ以上の変更記録を含むことができ、すべての記録はアトミックにトランザクションされる（すなわち、すべてが生じるか、またはどれも生じない）。１つの変更記録をロールバックすべき場合、その同じトランザクションにおけるすべての変更記録がその後ロールバックされる。変更記録は、ローカルおよびリモートという２つのライフサイクルを有する。
【０１９８】
ローカルライフサイクルは、ローカルクライアント上で起こる非ブロッキング動作を含む。非ブロッキング動作とは、サーバ応答が続くのを待たないといった、処理が生じている間にＵＩを停止させない動作である。クライアント上で起こるライフサイクルＪａｖａＳｃｒｉｐｔ方法は、「localCommit」、「localRevert」、および「localReplay」の３つがある。「localCommit」は、変更記録が最初にコミットされるときに１回だけ呼出される。「localRevert」は、記録が逆戻りされるとき（たとえば、アンドゥ動作またはロールバック動作時）はいつでも呼出される。「localReplay」は、記録が再実行されるよう求められるとき（たとえば、リドゥ動作時）はいつでも呼出される。
【０１９９】
リモートライフサイクルはローカルライフサイクルと並行して起こるが、リモートライフサイクルＪａｖａＳｃｒｉｐｔ方法は非同期に（すなわち、同時にまたは並行して）行なわれるため、それらは、ローカルライフサイクルＪａｖａＳｃｒｉｐｔ方法に比べ、遅延されるかもしれない。リモート動作のためのＪａｖａＳｃｒｉｐｔ方法は、「remotePersist」および「remoteRestore」の２つがある。「remotePersist」は、変更の結果をリモートサーバまで持続させる（すなわち、変更をデータベースへ保存する）。一方、「remoteRestore」は、元の状態（すなわち変更前の状態）をリモートサーバに復元する。
【０２００】
一実施形態では、変更記録は、システムにおける単一のリソースを表わす固有のタイプによって識別される。リソースは、画面、画面に関連するバインディング、アプリケーションのナビゲーションフロー、アプリケーションメタデータなどといったモデルであってもよい。タイプはまた、動作のＪａｖａＳｃｒｉｐｔ方法を識別する。一実施形態では、変更記録およびリスナが動作の契約を定義することを可能にするために、タイプは非特異的なままである。タイプとは、変更の動作およびリソースのＩＤを含むタプルである。動作はまた、どのタイプのリソースが修正されているかを一意的に識別してもよい。たとえば、以下の機能性では、「resourceType」は、どのタイプのモデルが影響されるか（すなわち、データベースにおけるあるテーブルに相関するか）を示し、「id」は、そのリソースの特定のインスタンス（すなわち、そのテーブルにおけるある行）を識別する。
【０２０１】
【数４】
0006679711.tif 000005
【０２０２】
あるタイプについては、持続動作は、複数の変更記録のリモートライフサイクルを組合わせてもよい。たとえば、同じタイプについて２つの持続動作が起こる場合、第２の動作が第１の動作のデータをオーバーライドするであろうと仮定して、第１の動作がスキップされてもよい。一実施形態では、単一の変更記録は単一のリソースに影響を与え、同じトランザクションで複数のリソースが修正される場合には複数の変更記録が使用される。たとえば、画面上の何らかのテキストをバックエンドサービスにバインドするユーザアクションが、ＵＩ定義ファイルおよびバインディング定義ファイルに変更が行なわれることを必要とする場合、一実施形態は、これらのモデル双方への変更を含むトランザクションを取込み、各モデルへの変更についてのそれぞれの変更記録を追加する。
【０２０３】
一実施形態はまた、ＵＩ専用変更記録がローカルライフサイクルにおいて追加されることを可能にするＪａｖａＳｃｒｉｐｔ方法を提供する。そのような変更記録は、ＵＩ変更にローカルに影響を与えるために、ローカルライフサイクルにおいてのみ使用される。ＵＩ専用変更記録のみを必要とする変更の一例は、画面上のタブを変更することである。この変更はデータ変更を必要としないため、サーバに何も同期させる必要はない。偶発的なＵＩ取扱い（たとえば、トランザクションの前／後にＵＩ状態を取込むこと）については、ローカルライフサイクルイベント化中に利用可能なトランザクションメタデータが使用される。たとえば、ユーザが画面上のタブを切替える場合、実施形態は、ユーザがアンドゥを行なった場合にタブを元に戻すよう切替える必要がある。ＵＩ専用トランザクションに記録されたメタデータは、どのタブがアクティブであったかを取込むであろう。そのため、それはアンドゥ中に復元され得る。このメタデータは、トランザクションメタデータ（たとえば、「the_current_transaciton.setMetadata(CurrentTab, "some tab")」）を介して格納される。
【０２０４】
「ChangeRecord::localCommit」ＪａｖａＳｃｒｉｐｔ方法は、トランザクションをローカルにコミットする。いくつかのモデルは動作をコマンドで直ちに行ない、このため、コミットするものは何もない。これらの場合、このＪａｖａＳｃｒｉｐｔ方法は、コミットが完了した場合にモデルに通知するよう機能することができる。このＪａｖａＳｃｒｉｐｔ方法はオプションで、ブーリアンを返すことができる。いくつかのモデルでは、動作は一時的に行なわれ、コミットされる実際の変更はないかもしれない。それらの場合、このＪａｖａＳｃｒｉｐｔ方法は、根底的なモデルに変更が行なわれなかったことを示すために、「偽」を返す。このＪａｖａＳｃｒｉｐｔ方法が「偽」を返した場合、トランザクションは打ち切られないが、この特定の変更はトランザクションによって無視される。このＪａｖａＳｃｒｉｐｔ方法のためにその記録のすべてに「偽」を返させるトランザクションは静かに処分され、ロールバックされない。ＵＩ専用変更記録は、このＪａｖａＳｃｒｉｐｔ方法によって返されるものによって影響されない。
【０２０５】
呼出し側がモデル上のプロパティを修正すると直ちにその変更を行なうモデルの一例は、ＸＭＬによって支援されるページモデルである。このモデルについては、「some_component.setAttribute(…)」を呼出すことはＸＭＬを直ちに修正する。モデルはトランザクションが完了する前に修正されるため、トランザクションが完了すると、コミット動作中に行なわれる作業はない。
【０２０６】
いくつかのモデルは、それらの根底的なソースを直ちに修正しない。いくつかのモデルは、テンポラリーストレージにおいてそのモデルに行なわれた変更を取込み、コミット動作中にトランザクションが完了すると、それらの変更はそのテンポラリーストレージから読み出され、モデルに書込まれる。変更が必要でないモデルの一例は、ユーザがボタンのテキストを「ａ」から「ｂ」に変更し、次に同じトランザクションでそれを「ｂ」から「ａ」に戻す場合である。「ａ」という値はトランザクションの開始からトランザクションがコミットされるときまで変更されなかったため、モデルは、何もしないことを選択することができる。なぜなら、その動作のアンドゥはモデルに何の影響も与えないためである。
【０２０７】
「ChangeRecord::remoteCommit」ＪａｖａＳｃｒｉｐｔ方法は、変更をリモートサーバまで持続させる。持続動作が完了すると、このライフサイクルＪａｖａＳｃｒｉｐｔ方法は、それが完了したことを示す。持続動作が拒否されると、このライフサイクルＪａｖａＳｃｒｉｐｔ方法は、エラーが生じたことを示し、持続動作が将来再試行されるようスケジュールする。
【０２０８】
図９は、一実施形態におけるウェブアプリケーション開発のためのシステム９００のブロック図である。ユーザは、アプリケーション開発サーバ９０４に対応するアプリケーション開発ウェブサイト９１０を実行するウェブブラウザ９０２を使用することにより、アプリケーションを開発する。ユーザによって行なわれるアクションは、要求／応答メカニズムを通してアプリケーション開発サーバ９０４で反映され、要求／応答メカニズムでは、各変更がアプリケーション開発サーバ９０４へ送信され、アプリケーション開発サーバ９０４が次に、変更がアプリケーション開発サーバ９０４で持続されたかどうかを示す対応する応答を送り返す。
【０２０９】
いくつかの公知のシステムでは、最後に行なわれた変更がアプリケーション開発サーバ９０４で持続されていることを示す返答がアプリケーション開発サーバ９０４から受信されない限り、ユーザは、アプリケーション開発ウェブサイト９１０と対話してさらに変更を行なうことを継続することを許可されない。しかしながら、これは、たとえば、アプリケーション開発サーバ９０４がロードされること、アプリケーション開発サーバ９０４への接続が遅いこと、セルラー／無線シナリオにおけるアプリケーション開発サーバ９０４との接続の不良などに起因して返答の受信に遅延がある場合に、ユーザ体験および全体性能の劣化をもたらし得る。実際、いくつかの公知のシステムでは、ユーザは、各変更後、継続できるようになるまで２〜３秒待つ必要があるかもしれない。この問題は、一連のアクションがユーザによって行なわれ、ユーザが次にそれらのアクションをすべてアンドゥするつもりである場合に、増幅される。なぜなら、ユーザは、結局変更はないのに、各アクションを行なうために２〜３秒待たなければならず、次に各アクションをアンドゥするためにさらに２〜３秒待たなければならないためである。
【０２１０】
対照的に、システム９００は、ローカルキュー９０６およびリモートキュー９０８を実現することにより、クライアント側（すなわち、ウェブブラウザ９０２）でトランザクションシステムを維持する。たとえば、アプリケーション開発ウェブサイト９１０において変更「Ａ」がユーザによって行なわれると、この変更は、トランザクション（すなわち、明らかな始点および終点を有する作業の単位／ブロック）の観点から見られる。たとえば、「Ａ」は、アプリケーション開発ウェブサイト９１０上の画面へのフォームの追加であってもよい。したがって、すべての個別動作は、それ自体のトランザクションである。トランザクションがコミットされる（すなわち、トランザクションがシステムに入り、ユーザが対応するアクションを行なうと決める）と、「Ａ」はローカルキュー９０６に配置される。アプリケーション開発ウェブサイト９１０は、ローカルキュー９０６のコンテンツを一度に１つずつ処理し、対応する変更を行なう。たとえば、「Ａ」がローカルキュー９０６において最も古い未処理のアイテムである場合、アプリケーション開発ウェブサイト９１０はローカルキュー９０６から「Ａ」を取り出し、ウェブブラウザ９０２の画面上にその影響を示す。
【０２１１】
トランザクションは、ローカルキュー９０６から独立して、リモートキュー９０８にも入れられる。リモートキュー９０８も順序付けられ、そのコンテンツは一度に１つずつ処理される。たとえば、ウェブブラウザ９０２の画面にフォームを追加するための変更「Ａ」について、「Ａ」がアプリケーション開発サーバ９０４と通信されるためにリモートキュー９０８で依然として待っているかもしれない間に、ユーザは結果を直ちに見る。アプリケーション開発サーバ９０４が遅い場合（たとえば、アプリケーション開発サーバ９０４へ変更をアップロードするのに５秒かかる場合）、「Ａ」がアプリケーション開発サーバ９０４へ無事送信されるのを待つ代わりに、ユーザは前進して、他の変更「Ｂ」、「Ｃ」および「Ｄ」をローカルに行なうことができる。クライアント側では、サーバが遅いにもかかわらず、変更「Ａ」〜「Ｄ」が即座に起こり、記録される。したがって、ローカルキュー９０６は非常に速く処理される。
【０２１２】
重篤なイベント（たとえば、サーバがダウンすること）がアプリケーション開発サーバ９０４で起こった場合、システム９００はオフラインモードへ移行し、アプリケーション開発サーバ９０４でまだ反映されていない変更は、再開時にアプリケーション開発サーバ９０４と通信され得るように、リモートキュー９０８にとどまる。ウェブブラウザ９０２が終了されても、リモートキュー９０８はそのような変更を保持する。アプリケーション開発サーバ９０４が再び利用可能になった後でリモートキュー９０８を参照することにより、システム９００は、どの変更が、アプリケーション開発サーバ９０４と通信すべき次の変更かを識別する。リモートキュー９０８におけるアイテムは、当該アイテムがアプリケーション開発サーバ９０４で無事格納されたことを示す対応する応答をアプリケーション開発サーバ９０４から受信した後にのみ削除される。アイテムは一度に１つずつアプリケーション開発サーバ９０４と通信されるため、いかなる場合も、システム９００は、どのアイテムがアプリケーション開発サーバ９０４と無事通信されたかを知っている。
【０２１３】
一実施形態では、最も最近の変更がリソース全体を保存する場合、そのリソースへの前の変更は、ローカルキュー９０６および／またはリモートキュー９０８から削除され得る。たとえば、一連の変更「Ａ」〜「Ｄ」において、「Ｂ」および「Ｄ」が同じリソースを修正し、「Ｃ」および「Ｄ」が独立している場合、「Ｂ」がキューから削除され得る。そのようなリソースの一例はウェブブラウザ９０２上のＵＩであり、１つのフォームフィールドを別のフォームフィールドへ移動させることは、同じリソースを修正する。
【０２１４】
一実施形態では、ローカルキュー９０６および／またはリモートキュー９０８を処理する場合、トランザクション自体を移動させる代わりに、それぞれのポインタを移動させる。一実施形態では、他のトランザクションと全く同様に、アンドゥ動作がリモートキュー９０８でスケジュールされる。しかしながら、対応する元のトランザクションがリモートキュー９０８において依然として待っている間に、アンドゥトランザクションがリモートキュー９０８に追加された場合、双方のトランザクションはリモートキュー９０８においてキャンセルされてもよい。
【０２１５】
一実施形態では、開始時間（たとえば、アプリケーション開発ウェブサイト９１０に初めて到達した時間）から、アンドゥ履歴がローカルキュー９０６において維持される。この実施形態では、ローカルキュー９０６は持続的なオブジェクトである。
【０２１６】
図１０は、本発明の実施形態に従った自動保存機能性のフロー図である。
１０１０で、クライアントデバイスのウェブブラウザが、サーバに対応するウェブサイトと対話するユーザによって行なわれたユーザアクションを受信する。ウェブサイトはアプリケーション開発ウェブサイトであってもよく、サーバはアプリケーション開発サーバであってもよい。
【０２１７】
１０２０で、ユーザアクションに対応する変更記録が判断され、１０３０で、変更記録は、ローカルモデルへの対応する変更をコミットするために、第１のキューに入れられる。一実施形態では、第１のキューは、ウェブサイトと対話する際にアンドゥ動作およびリドゥ動作を行なうために変更記録の履歴を維持する、順序付けられた持続キューである。
【０２１８】
１０４０で、変更記録は、変更記録をサーバで持続させるために、サーバと通信する第２のキューに入れられる。一実施形態では、第２のキューは、変更記録が一度に１つずつ処理され、各変更記録は、第２のキューにおける前の変更記録がサーバ上に無事記録された場合のみ、サーバへ送信される、順序付けられたキューである。変更記録は、サーバと無事通信された後に第２のキューから除去される。第２のキューは要求／応答メカニズムを通してサーバと通信し、要求／応答メカニズムでは、第２のキューにおける各変更記録はサーバへ送信され、サーバは次に、変更記録がサーバで持続されたかどうかを示す対応する応答を送り返す。
【０２１９】
一実施形態では、変更記録は、ウェブサイトにおけるユーザアクションによって生じたモデル変更を反映しており、関連するモデル変更を構成するトランザクションにおいて追加される。トランザクションがコミットされると、トランザクションにおける変更記録が第１のキューに配置される。トランザクションは、その実行中にエラーが生じない場合にコミットされる。ウェブサイトは、第１のキューのコンテンツを一度に１つずつ処理し、対応する変更を行なう。トランザクションが記録されると、トランザクションにおける変更記録が第２のキューに配置される。トランザクションは、その変更が対応するクライアント側モデルに適用され、あらゆる必要なユーザインターフェイスが対応する変更を反映するように更新されたときに記録される。
【０２２０】
一実施形態は、要求への応答が時間しきい値の満了後にサーバから受信されていないと判断して、第２のキューのコンテンツを保護し、引き続き第２のキューに新しい変更記録を入れながら、オフラインモードへ移行する。実施形態は次に、サーバとの通信が復元されていると判断して、オンラインモードへ戻るよう移行し、第２のキューのコンテンツをサーバで持続させることを再開する。ウェブブラウザが終了されても、第２のキューはそのコンテンツを保持する。
【０２２１】
一実施形態は、変更記録がリソース全体を保存していると判断して、リソースへの前の変更記録を第１のキューおよび第２のキューから除去する。
【０２２２】
一実施形態では、対応する元のトランザクションが第２のキューにおいて依然として待っている間に、アンドゥトランザクションが第２のキューに追加された場合、アンドゥトランザクションおよび対応する元のトランザクションは双方とも、第２のキューからキャンセルされる。
【０２２３】
開示されたように、実施形態は、サーバ接続問題、またはクライアントで行なわれるアンドゥ／リドゥアクションが生じた場合でも、データを失うことなく、またはクライアントとサーバとの間に不整合を引き起こすことなく、クライアント側変更がほぼ瞬間的であり、かつ、それらの変更がリモートサーバで持続されることを可能にする、トランザクション自動保存システムを提供する。したがって、ユーザ変更をリモートサーバで持続させつつ、ユーザをブロックする必要性がないため、実施形態は非常に性能を高め、ユーザ体験を向上させる。
【０２２４】
ＵＩ状態の復元
現在、いくつかのトランザクショナルシステムは、モデル変更を逆戻りさせるために、または再度適用するために、アンドゥおよびリドゥ機能性を提供している。しかしながら、ＵＩ状態（すなわち、ユーザがどんなＵＩを見ているか）を復元することも望ましいものの、ＵＩ状態情報はモデルデータの一部ではないかもしれず、したがって、モデルを復元することはＵＩ状態を自動的に復元しないかもしれない。たとえば、ユーザは、システムにおいてページ「Ｘ」上にいて、ページ「Ｘ」にモデル変更を行ない、次に、ページ「Ｙ」に切替える／ナビゲートするかもしれない。ユーザがページ「Ｘ」へのモデル変更に対してアンドゥを行なう場合、ビューをページ「Ｘ」に戻すよう切替えることが非常に望ましいであろう。なぜなら、そこは、ユーザがそのモデル変更を行なった場所であるためである。しかしながら、ページ「Ｘ」へのモデル変更をアンドゥするだけでは、ユーザを自動的にページ「Ｙ」からページ「Ｘ」に連れてくることにはならない。システムがより複雑になるにつれ、好ましくは復元を必要とするＵＩ状態の量も増加する。
【０２２５】
いくつかの公知のシステムは、問題に全く対処しない（すなわち、ＵＩはアンドゥ／リドゥに対して変更されない）か、または、ＵＩ状態をある程度だけ復元する。たとえば、いくつかの公知のシステムでは、アンドゥまたはリドゥアクションが受信されると、ユーザは、アンドゥ／リドゥアクションに特有の詳細なＵＩにではなく、何らかのメイン／デフォルトＵＩに連れ戻される。
【０２２６】
いくつかの公知のシステムは、ユーザにどのＵＩを見せるかを判断するために、変更を検査することを試みる。しかしながら、この機能性を実現することはシステムを複雑にし、また、維持することが難しい。
【０２２７】
公知のシステムとは対照的に、実施形態は、トランザクションがロールバックされる場合、またはそれがその後再びコミットされる場合（すなわち、アンドゥ／リドゥ機能性において典型的な動作）にＵＩ状態が復元され得る、トランザクションシステムを提供する。一実施形態は、トランザクションをコミットする前および後の双方でＵＩ状態およびモデル状態を格納して、アンドゥまたはリドゥ動作がトランザクションに対して行なわれると、格納された状態を使用して適切なＵＩ状態およびモデル状態を復元する。したがって、実施形態は、相当な量のＵＩ状態が復元を必要とする複雑なシステムについても、ＵＩ復元を、トランザクション環境内で管理可能にし、自動的にする。
【０２２８】
一実施形態では、あるアクションをアンドゥすると、ユーザは、そのアクションを行なう前に自分が見ていたのと同じＵＩを見る。一実施形態は、リドゥについて同様の機能性を提供する。すなわち、アンドゥされたアクションをリドゥすると、ユーザは、そのアクションを行なった後に自分が見ていたのと同じＵＩを見る。したがって、実施形態は、ユーザがＵＩ内のコンテキストを失わないようにすることにより、ユーザ体験を著しく向上させる。
【０２２９】
実施形態は、ＵＩの任意のピースが復元機能性に関与することを可能にするように拡張可能であり、また、トランザクションシステムの意味論を理解することをＵＩを要求しない。すなわち、ＵＩは、どのモデル変更がトランザクションによって実際に行なわれるか、そのトランザクションがシステムにとって何を意味するか、または、トランザクションは一般にどのように作用するか（たとえば、コミット動作、ロールバック動作などがどのように作用するか）を理解する必要がない。
【０２３０】
一実施形態では、ウェブページがブラウザ上でレンダリングされると、そのウェブページのコンポーネントが初期化される。すなわち、ウェブページがレンダリングされると、ＵＩ要素／アクターが、まずブラウザにダウンロードされ、次に実行される。この実施形態では、システムにおけるＵＩアクターは、初期化時にトランザクションフレームワークに登録可能である。登録はまた、作業セッション中に作成されるＵＩがトランザクションフレームワークに登録され、そのＵＩが除去されると登録解除され得るように、動的であり得る。
【０２３１】
一実施形態では、トランザクションが開始されると、トランザクションフレームワークは登録されたＵＩをクエリし、それらの現在のＵＩ状態のスナップショットを検索する。一実施形態では、ＵＩ状態は、トランザクションから生じる変更の意味論上の意味を含む。トランザクションに関与するＵＩアクターは、そのようなＵＩ状態をどのように復元するかを知っている。なぜなら、これらのアクターが、最初にＵＩ状態を作成したためである。以下は、ボタンの現在の色がブルーであることを記録するためにＵＩ状態に含まれ得る例示的な機能性である。
【０２３２】
【数５】
0006679711.tif 000006
【０２３３】
トランザクションは次に、システムにおける対応するモデルをコミットし、更新する。これらの変更がＵＩにおいていったん反映されると、登録されたＵＩは再びクエリされ、それらの現在のＵＩ状態の別のスナップショットが撮られる。一実施形態では、スナップショットは、それらがトランザクション内でどのライフサイクルにいるか（たとえば、トランザクションのライフサイクル状態がコミットか、アンドゥか、リドゥかなど）を示さない。たとえば、ＵＩは、ユーザがアクション、アンドゥ動作、リドゥ動作などを行なったかどうかにかかわらず、単にその現在のスナップショットを撮る。一実施形態では、ＵＩ状態の「トランザクション前」および「トランザクション後」スナップショットが、対応するトランザクション変更記録とともに格納される。
【０２３４】
一実施形態では、変更記録は、対応するモデル状態から独立して格納され、そのモデル状態を修正するための命令を格納する。モデル状態は、任意の時点で正しい（たとえば、任意の時点でユーザに提供されているＵＩと整合する）と仮定される。一実施形態では、変更記録は「アンドゥ」スタックに格納される。各変更記録は、対応するアクションを行なうこと、またはそれをアンドゥすることができる一組の命令を含む。したがって、ユーザがアクションをアンドゥすると、最後の変更記録がアンドゥスタックから検索され、対応するアンドゥ命令を行なうために呼出される。
【０２３５】
一実施形態では、（たとえばアンドゥ動作を行なうことによって）その後ロールバックされるトランザクションにおいてモデル変更が適用されると、登録されたＵＩには、トランザクションが開始したときに撮られたそれらの対応するＵＩスナップショットが提供され、ＵＩは、それらの対応するＵＩスナップショットを復元するよう促される。同様に、（たとえばリドゥ動作を行なうことによって）その後再実行されるロールバックされたトランザクションにおいてモデル変更が復元されると、登録されたＵＩは、トランザクションがコミットされたときに撮られたそれらの対応するＵＩスナップショットに復元される。
【０２３６】
一実施形態では、ＵＩの１ピースのスナップショットを復元することは、ＵＩの他のピースに影響を与えない。たとえば、スナップショットが復元される場合、１つのＵＩピースは、別のＵＩピースに対してイベント化しない。なぜなら、他のＵＩピースをそれ自体のライフサイクル外で更新することは、予測不能の挙動を招くかもしれないためである。したがって、一実施形態では、このプロセス中、影響されたＵＩの各ピースは、そのＵＩ状態を、他のＵＩピースから独立して登録して管理し、他のＵＩピースのイベントに反応せず、また、他のＵＩピースへイベントを送信しない。
【０２３７】
実施形態は、アンドゥ／リドゥ機能性をサポートする任意のシステムまたはウェブアプリケーションに適用可能である、
図１１は、一実施形態に従った例示的なＵＩ１１００を示す。ＵＩ１１００は、たとえば、モバイルアプリケーションまたは別のタイプのアプリケーションを構成／設計するために使用されてもよい。ＵＩ１１００は、テンプレート選択ピース１１０２、テンプレートピース１１０４、およびコンポーネント選択ピース１１０６という３つのＵＩピースを含む。一例では、テンプレート選択ピース１１０２は、テンプレートＡ  １１１０、テンプレートＢ  １１１２、またはテンプレートＣ  １１１４を選択するオプションを提供してもよい。テンプレート選択ピース１１０２においてあるテンプレートオプションを選択すると、選択されたテンプレートは、テンプレートピース１１０４に示される。一実施形態では、テンプレートピース１１０４における選択されたテンプレートに対応する、テンプレート選択ピース１１０２におけるＵＩコンポーネントは、テンプレート選択ピース１１０２において強調表示されてもよい。
【０２３８】
テンプレートピース１１０４はさらに、コンポーネント選択ピース１１０６において提供されるコンポーネントによって定義および／または修正されてもよい。コンポーネント選択ピース１１０６において提供されるオプションは、テンプレートピース１１０４に示されているテンプレートの選択と関連していてもよい。たとえば、コンポーネント選択ピース１１０６は、ボタンＤ  １１１６、ボタンＥ  １１１８、またはボタンＦ  １１２０をテンプレートピース１１０４に追加するためのオプションを提供してもよい。一例では、ボタン１１０８が、コンポーネント選択ピース１１０６における対応するオプションが選択されると、テンプレート１１０４に示されてもよい。一実施形態では、テンプレートピース１１０４において追加されたボタンに対応する、コンポーネント選択ピース１１０６におけるＵＩコンポーネントは、コンポーネント選択ピース１００６において強調表示されてもよい。
【０２３９】
一実施形態では、ＵＩ１１００におけるＵＩピースは互いに関連しているが、各ＵＩピースのＵＩ状態は他のＵＩピースから独立して格納され、各ＵＩピースの復元は他のＵＩピースの復元に影響を与えず、または他のＵＩピースの復元をイベント化しない。したがって、各ＵＩピースは独立して復元されてもよく、ＵＩピースは他のＵＩピースからイベントを受信せず、または他のＵＩピースへイベントを送信しない。たとえば、テンプレート選択ピース１１０２における強調表示されたＵＩコンポーネントが、テンプレートピース１１０４における選択されたテンプレートに対応する場合、テンプレート選択ピース１１０２のＵＩ状態はそのような強調情報を含むものの、その復元は、対応するテンプレートを示すためにテンプレートピース１１０４をイベント化しない。このシナリオでは、テンプレートピース１１０４のＵＩ状態は、適切なテンプレートを示すために独立して保存され、復元されて、それにより、２つの関連するＵＩピース間の相互に関連するイベント化の必要性をなくす。同様の独立した復元機能性が、相互に関連する情報を保持するものの、復元時に互いをイベント化しない、テンプレートピース１１０４およびコンポーネント選択ピース１１０６のために実現される。したがって、ＵＩ１１００のすべてのＵＩピースは、それ自体の状態を、他のＵＩピースから独立して格納するため、どのＵＩピースも復元のために別のＵＩピースを待つ必要がない。
【０２４０】
一実施形態では、ＵＩのすべてのピースはそれぞれの状態を保存できるが、アクションの影響を受けたＵＩのピースだけが保存／復元される必要がある。一実施形態では、いくつかのＵＩピースは、アクションが何を行なっているか（すなわち、アクションの影響が何であるか）知らないかもしれず、したがって、それらがアクションの影響を受けていなくても、目に見える各ＵＩピースはその状態を保存／復元させる。一実施形態では、アクションが行なわれるとＵＩピースが見えなくなる場合、そのようなＵＩピースは、それがアクションが行なわれた時点で表示されてさえいなかったため、それはアクションの影響を受けていない、ということを知っている。したがって、アクション中に見えないＵＩピースの状態は、保存／復元されなくてもよいかもしれない。
【０２４１】
以下は、メインコンテンツエリアとサイドバーとを有するページのためにＵＩを保存し復元する一例を提供しており、サイドバーは、メインコンテンツエリアよりも若干暗い背景色を有するべきである。ページは、主コンテンツエリアが「グレー」、およびサイドバーが「ダークグレー」で始まってもよい。メインコンテンツエリアの背景色は、以下のように「レッド」に変更されてもよい：
・ユーザは、メインコンテンツエリアの背景色を変更するためのジェスチャーを行ない、対応するトランザクションが開始される；
・フレームワークはまず、ＵＩ状態をすべて記録する。メインコンテンツエリア用のカラーピッカーとサイドバー用のカラーピッカーとを含む２つのＵＩのみがあると仮定して、各カラーピッカーはその現在の状態を以下の機能性に従って記録する：
【０２４２】
【数６】
0006679711.tif 000007
【０２４３】
・メインコンテンツカラーピッカーは、その色が変わると、サイドバーカラーピッカーも、メインコンテンツカラーピッカーの新しい色のより暗いバージョンに自動的に変化すべきであるということを知っているコードを含む。したがって、メインコンテンツカラーピッカーはサイドバーカラーピッカーに、その色を「ダークレッド」にするよう命じる。
【０２４４】
・トランザクションがコミットされ、モデル状態は以下のようになる：
【０２４５】
【数７】
0006679711.tif 000008
【０２４６】
ユーザがその後、このトランザクションをアンドゥした場合：
・モデル状態は以下の状態に逆戻りされる：
【０２４７】
【数８】
0006679711.tif 000009
【０２４８】
この時点で、モデルは正しく、アンドゥアクションを反映しているが、カラーピッカーは依然として、間違った色である「レッド」を示している。
【０２４９】
・ＵＩのピース（すなわちカラーピッカー）は、それらの状態を、トランザクション前の状態に復元するよう命じられる。すなわち、以下の通りである：
【０２５０】
【数９】
0006679711.tif 000010
【０２５１】
メインコンテンツカラーピッカーは次に、その状態を「グレー」に復元し、サイドバーカラーピッカーは、その状態を「ダークグレー」に復元する。これらの状態を復元する際、メインカラーピッカーを変更することはもはや、自動的にサイドバーカラーピッカーに、メインコンテンツカラーピッカーの復元された色のより暗いバージョンになるよう命じない。すなわち、通常のＵＩ変更と同様の「イベント化」はなく、各ＵＩピースはその状態をそれ自体で管理する。この実施形態では、ＵＩピースは、それらの状態が何かを知るために、それらの対応するモデルを読出してもよい。しかしながら、ＵＩピースのＵＩ状態を追跡することは、カラーピッカーが目に見えるべきか否かといった、対応するモデルに記録されていないかもしれないＵＩ変更も追跡／格納する。
【０２５２】
図１２は、いくつかの実施形態に従った、例示的なコミットフロー１２０２、例示的なアンドゥフロー１２０４、および例示的なリドゥフロー１２０６を示す。
【０２５３】
コミットフロー１２０２では、トランザクションが起こると、トランザクションが始まる前の１２０８で（すなわち「ＩＮＩＴ」状態で）、対応するモデル状態およびＵＩ状態が記録される。図１２では、そのようなモデル状態およびＵＩ状態は、それぞれ「ＩＮＩＴ  ＭＯＤＥＬ」および「ＩＮＩＴ  ＵＩ」として示される。次に、１２１０でのコミット前状態は、外部リスナに、コミット状態の前にアクションを行なう機会を提供する。１２１２で、トランザクションは終了し（すなわち、トランザクションは「ＣＯＭＭＩＴ」状態でコミットされ）、対応するモデル状態およびＵＩ状態が再び記録される。図１２では、そのようなモデル状態およびＵＩ状態は、それぞれ「ＣＯＭＭＩＴ  ＭＯＤＥＬ」および「ＣＯＭＭＩＴ  ＵＩ」として示される。
【０２５４】
アンドゥフロー１２０４では、アンドゥ（逆戻り）動作が、トランザクション前のＵＩ状態およびモデル状態（すなわち、１２０８で取込まれた「ＩＮＩＴ  ＭＯＤＥＬ」状態および「ＩＮＩＴ  ＵＩ」状態）を復元しようと試みる。そうするために、１２１４で、「ＩＮＩＴ  ＭＯＤＥＬ」状態が、逆戻り動作の前に、逆戻り前状態で復元される。１２１６で、逆戻り動作が行なわれる。逆戻り動作は、アンドゥアクションを行なうことを含む。たとえば、テキストが「Ａ」から「Ｂ」に変更され、次にアンドゥアクションが示された場合、逆戻り動作は「Ｂ」を「Ａ」に戻す。逆戻り動作の完了後、１２１８で、「ＩＮＩＴ  ＵＩ」状態が逆戻り後状態で復元される。
【０２５５】
リドゥフロー１２０６では、リドゥ（再実行）動作が、トランザクションがコミットされた後のＵＩ状態およびモデル状態（すなわち、１２１２で取込まれた「ＣＯＭＭＩＴ  ＭＯＤＥＬ」状態および「ＣＯＭＭＩＴ  ＵＩ」状態）を復元しようと試みる。そうするために、１２２０で、「ＣＯＭＭＩＴ  ＭＯＤＥＬ」状態が、リドゥ動作の前に、リドゥ前状態で復元される。１２２２で、再実行動作が行なわれる。再実行動作は、リドゥアクションを行なうことを含む。たとえば、テキストが「Ａ」から「Ｂ」に変更され、次にアンドゥアクションが「Ｂ」を「Ａ」に戻した場合、リドゥアクションは再び「Ａ」を「Ｂ」に戻す。再実行動作の完了後、１２２４で、「ＣＯＭＭＩＴ  ＵＩ」状態が再実行後状態で復元される。
【０２５６】
図１３は、本発明の実施形態に従ったＵＩ復元機能性のフロー図である。
１３１０で、ＵＩと対話するユーザによって行なわれたアクションが受信される。ユーザアクションの例は、ボタンを押下すること、何らかのテキストを入力すること、ＵＩの何らかのピースをドラッグ・アンド・ドロップすること、などといったユーザジェスチャーである。一実施形態では、アクションは、ユーザのクライアントデバイスのウェブブラウザによって受信され、ユーザは、ＵＩをホストするサーバに対応するウェブサイトと対話する。一実施形態では、ウェブサイトはアプリケーション開発ウェブサイトであり、サーバはアプリケーション開発サーバである。
【０２５７】
１３１２で、アクションに基づいてトランザクションが判断され、トランザクションは、ＵＩに対応するモデルを修正するように構成される。一実施形態では、トランザクションは、多くの関連するモデル変更を構成する。
【０２５８】
モデルの一例は、現在の画面上のＵＩコンポーネントを記述する宣言的構文であるページスキーマである。このモデルは、画面を定義するＸＭＬコードを操作するＡＰＩとして実現されてもよい。このモデルについての例示的なモデル変更は、以下のとおりである：
【０２５９】
【数１０】
0006679711.tif 000011
【０２６０】
ここで、「some_component」はページモデルにおけるＵＩコンポーネントであり、変更は、スタイル属性をレッドにするよう修正することである。このモデルについての例示的なトランザクションは、ユーザがボタンをクリックすることによって生じ得る一連のモデル変更（たとえば、ページスキーマおよび対応するバインディングへの前述の変更）である。
【０２６１】
１３１４で、ＵＩの第１のＵＩ状態およびモデルの第１のモデル状態が格納される。
１３１６で、トランザクションがコミットされる。一実施形態では、トランザクションは、その実行中にエラーが生じない場合にコミットされる。
【０２６２】
１３１８で、第１のユーザ対話に基づいて、トランザクションをアンドゥすることが判断される。
【０２６３】
１３２０で、ＵＩは第１のＵＩ状態に復元され、モデルは第１のモデル状態に復元される。一実施形態では、第１のモデル状態はトランザクションをアンドゥする前に復元され、第１のＵＩ状態はトランザクションをアンドゥした後に復元される。一実施形態では、ＵＩは２つ以上のＵＩピースを含み、第１のＵＩ状態は、ＵＩの各ピースについてのＵＩ状態を含む。一実施形態では、ＵＩの各ＵＩピースのＵＩ状態は、ＵＩの他のＵＩピースから独立して格納され、復元される。
【０２６４】
一実施形態では、トランザクションがコミットされた後、および第１のユーザ対話の前に、ＵＩの第２のＵＩ状態およびモデルの第２のモデル状態が格納される。
【０２６５】
一実施形態では、第２のユーザ対話に基づいて、トランザクションをリドゥすることが判断され、次に、ＵＩは第２のＵＩ状態に復元され、モデルは第２のモデル状態に復元される。一実施形態では、第２のモデル状態はトランザクションをリドゥする前に復元され、第２のＵＩ状態はトランザクションをリドゥした後に復元される。
【０２６６】
開示されたように、実施形態は、トランザクションをコミットする前／後にＵＩ状態およびモデル状態の格納されたスナップショットを使用し、アンドゥ／リドゥ動作が行なわれると適切なＵＩおよびモデル状態を復元する、トランザクションシステムを提供する。一実施形態では、あるアクションをアンドゥすると、ユーザには、そのアクションを行なう前に自分が見ていたのと同じＵＩが提供される。一実施形態では、あるアクションをリドゥすると、ユーザには、そのアクションを行なった後に自分が見ていたのと同じＵＩが提供される。したがって、実施形態は著しくユーザ体験を向上させ、ＵＩ設計プロセスの効率を向上させる。
【０２６７】
いくつかの実施形態がここに具体的に例示および／または説明されている。しかしながら、開示された実施形態の変更および変形は、発明の精神および意図された範囲から逸脱することなく、上述の教示によって網羅され、添付された請求項の範囲内にある。
【図１】
0006679711.tif 000012
【図２】
0006679711.tif 000013
【図３】
0006679711.tif 000014
【図３Ａ】
0006679711.tif 000015
【図３Ｂ】
0006679711.tif 000016
【図４】
0006679711.tif 000017
【図５】
0006679711.tif 000018
【図６】
0006679711.tif 000019
【図７】
0006679711.tif 000020
【図８】
0006679711.tif 000021
【図９】
0006679711.tif 000022
【図１０】
0006679711.tif 000023
【図１１】
0006679711.tif 000024
【図１２】
0006679711.tif 000025
【図１３】
0006679711.tif 000026