(58)【調査した分野】(Int.Cl.,DB名)
前記第2のキューは要求/応答メカニズムを通して前記サーバと通信し、前記要求/応答メカニズムでは、前記第2のキューにおける各変更記録は前記サーバへ送信され、前記サーバは次に、前記変更記録が前記サーバで持続されたかどうかを示す対応する応答を送り返す、請求項1〜14のいずれか1項に記載の方法。
【発明を実施するための形態】
【0006】
詳細な説明
アプリケーションとはソフトウェアプログラムを指し、それは実行時、特定の所望のタスクを行なう。一般に、いくつかのアプリケーションは、1つ以上のオペレーティングシステム(operating system:OS)、(たとえばJava(登録商標)プログラミング言語をサポートする)仮想マシン、デバイスドライバなどを含む実行時環境において実行される。開発者はしばしば、所望のアプリケーションを実現/開発するためのアプリケーション開発フレームワーク(Application Development Framework:ADF)(それら自体がアプリケーションである)を使用する。ADFは、アプリケーションの開発において直接的/間接的に使用され得る1組の予め定義されたコード/データモジュールを提供する。ADFはまた、統合開発環境(integrated development environment:IDE)、コード生成部、デバッガなどのツールを提供してもよい。一般に、ADFは、再使用可能なコンポーネントを提供することによって、アプリケーション開発を単純化する。再使用可能なコンポーネントは、たとえば、所望のタスクを行なうためのコンポーネントを選択し、選択されたコンポーネントの外観、挙動、および対話を定義することにより、ユーザインターフェイス(UI)およびアプリケーションロジックを定義するために、アプリケーション開発者によって使用され得る。オラクル社(Oracle Corp.)からの「オラクルADF」(Oracle ADF)といったいくつかのADFは、緩い結合とより容易なアプリケーション開発および保守とを促進するモデル・ビュー・コントローラ(model-view-controller:MVC)設計パターンに基づいている。
【0007】
一般に、多くの会社は、出張中の従業員がエンタープライズコンピュータシステム上に格納された情報にアクセスできるように、従業員がモバイルデバイスを用いて社外の場所からセキュアなエンタープライズアプリケーションにアクセスできるようにする必要性を表明してきた。そのような能力があれば、たとえば、営業担当者は出先から仕事してもよく、サービス技術者は顧客サイトにいる間に部品を調べてもよく、従業員は自宅から仕事してもよい。いくつかの会社はまた、最終顧客がエンタープライズコンピュータシステムに存在するデータにアクセスできるようにすることを望んでいる。そのようなアクセスは、顧客体験を向上させ、コストを下げることにより、ある会社を競合他社から差別化し得る。たとえば、そのようなアクセスを実現することにより、ある店舗は、顧客がいつでも都合のよい時にあるアイテムについて店舗在庫をリモートでサーチして買い物できるようにしてもよく、それにより、顧客体験を向上させ、営業担当者、オペレータ、および他のスタッフの必要性を低下させる。
【0008】
さまざまなエンタープライズアプリケーションベンダーは従来より、会社所有のセキュアなモバイルデバイスまたはカスタムモバイルアプリケーションと組合された特殊なポータルを提供することにより、この必要性を満たしてきた。しかしながら、利用可能なさまざまなパーソナルモバイルデバイスの現在の爆発的増加により、これらの従来のソリューションはすぐに時代遅れになる。なぜなら、ベンダーが単に、利用可能になるすべての最新のOSおよびハードウェアに遅れずについていくことができないためである。
【0009】
また、アプリケーションは、アプリケーションタイプおよび/またはアプリケーションによって使用されるデータのタイプに依存して、さまざまなエンタープライズコンピュータシステムと接続して同期する必要があるかもしれない。これらのエンタープライズコンピュータシステムは、同様にアプリケーションタイプおよびデータタイプに基づいて変わり得るさまざまなバックエンドコンピュータシステムによってサポートされるかもしれない。しかしながら、さまざまなバックエンドエンタープライズシステムは、デバイスへデータを通信するためにさまざまな通信プロトコルおよびメカニズムを使用するかもしれず、それにより、さまざまなアプリケーションを実行するモバイルコンピューティングデバイスは、エンタープライズコンピュータシステムをサポートするさまざまなバックエンドコンピュータシステムと通信するための課題に直面するようになる。
【0010】
さらに、セキュリティは、エンタープライズの内部コンピュータシステムへのアクセスを許可する際に懸念となり得る。モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間でのサポートされる通信プロトコルの違いは、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通信のためのセキュリティアクセス管理をさらに複雑にし得る。たとえば、専用セキュリティプロトコルを有する特定のエンタープライズコンピュータシステムにアクセスするためのアプリケーションの認証を保証するために、さまざまなメカニズムが実現され得る。いくつかの公知のシステムは、既製の消費者モバイルデバイスを会社のバックエンドエンタープライズシステムと接続することにより、この問題に対処しようと試みてきた。これらのデバイスは、エンタープライズバックエンドコンピュータシステムとの通信専用の特殊なポータルを通してエンタープライズネットワークに接続するアプリケーションまたはOSを用いて構成されてもよい。しかしながら、モバイルデバイスの製造業者、アプリケーション開発者、およびエンタープライズは、アプリケーションを開発し、モバイルデバイスをエンタープライズバックエンドコンピュータシステムに接続するためのより柔軟で頑強な手法から利益を得てもよい。
【0011】
公知のシステムとは対照的に、本発明の実施形態は、「クラウド」サービスにおける迅速でビジネスユーザフレンドリなモバイルアプリケーション構成のための宣言的なブラウザベースのクライアントアプリケーション開発ツールを提供する。一実施形態では、クラウドサービスは、オラクル社からの「モバイル・クラウド・サービス」(Mobile Cloud Service:MCS)である。実施形態は、バックエンドサービスのためにクラウドサービスを使用する予め定義されたテンプレートを使用してモバイルアプリケーションを構築することを可能にし、そのため、アプリケーション開発中に開発者にサービス定義を提示することができ、UI設計とバックエンドサービスとの間の迅速な接続を可能にする。
【0012】
MCS
MCSを使用する実施形態では、MCSは、クラウドコンピュータシステムを介した、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通信を容易にする。MCSは、モバイルデバイスと会社のエンタープライズネットワークとの間の第三者クラウドベースのインターフェイスを使用する。クラウドベースのインターフェイスは、さまざまなエンタープライズコンピュータシステム用のセキュアなアダプタを集中化して、さまざまなプロトコルを、標準化されたレプレゼンテーショナル・ステート・トランスファ(Representational State Transfer:REST)アーキテクチャに翻訳する。会社は、本発明の実施形態を使用して、それら自体のカスタムモバイルアプリケーションを、MCS上で利用可能なツールを使用して作成することができ、そのようなアプリケーションは、固有のフォームでモバイルユーザデバイス上にダウンロードされ得る。アプリケーションがいったんインストールされると、それは、MCSのクラウドベースのインターフェイスにアクセスして、MCSによって提供されるセキュアなアダプタを通してさまざまなエンタープライズコンピュータシステムに到達することができる。
【0013】
MCSを使用する実施形態におけるアプリケーション開発のために、MCSは、モバイル・バックエンド・アズ・ア・サービス(Mobile Backend as a Service:MBaaS;BaaSとも呼ばれる)モデルの下でバックエンドサービスを提供する。MBaaSは、ウェブおよびモバイルアプリケーション開発者が、自分のアプリケーションを、バックエンドアプリケーションによって公開されたバックエンドクラウドストレージおよびAPIにリンクすることを可能にするとともに、ユーザ管理、プッシュ通知、ソーシャルネットワーキングサービスとの統合なども提供する。MBaaSモデルの下でMCSにおいて提供されるバックエンドサービスを使用することにより、実施形態は、コード化に精通していない専門外のユーザによるモバイルアプリケーション開発のために構成された宣言的なウェブベースのUIを提供する。
【0014】
一実施形態では、ユーザが新しいアプリケーションの開発を開始すると、ウィザードが開始され、ユーザは、新しいアプリケーションについて名前および記述を与えるよう求められる。次に、ユーザは、アプリケーションの第1のページについてUIをプレシード(pre-seed)できる一組の予め定義されたテンプレート(たとえば、タブ、底部タブ、ページネーションなど)から選択することにより、第1のページを設計するよう求められる。UIは次に、変更を示すようにプレビューが自動的に更新される間に、テンプレートにおいて詳細を指定することによって完成される。UI設計が完成すると、ユーザはパレットを使用して、モバイルアプリケーションがMCSを通して利用可能である、利用可能なサービスおよびデータソースのカタログ(たとえばサービスカタログ)をブラウズすることができる。UIに追加されるカタログの各アイテムについて、ユーザには属性のリストが提示され、1つ以上のジェスチャ(たとえばドラッグ・アンド・ドロップなど)を使用して、ユーザは属性をUI要素にバインドすることができる。ユーザは、モバイルアプリケーションを作成するために、特徴定義およびデータバインディングのプロセスを繰返すことができる。マップ、グラフといった他のUIコンポーネントも、UIに追加され得る。アプリケーションをテストする準備ができると、ユーザは、(iOS、アンドロイド(登録商標)、または任意の他のモバイルデバイスOS用の固有の実行ファイルを構築して)対応するバイナリが作成されるようにアプリケーションを発行してもよく、その後、クイックレスポンス(Quick Response:QR)コード(登録商標)が生成されてユーザに提供される。ユーザがモバイルデバイスによってQRコードをスキャンする場合、アプリケーションは無線でモバイルデバイス上にインストールされる。
【0015】
実施形態は、ADFにおいて予め構築されたコンポーネントを使用する。コンポーネントは、データ対話、データ視覚化、およびカプセル化されたブラウザ側動作を提供し、リッチクライアントプリケーション開発を単純化する。ADFはまた、カメラ、全地球測位システム(Global Positioning System:GPS)、連絡先などといったデバイス特徴にアクセスするために、アパッチ・コルドバ(Apache Cordova)プラグインなどのプラグインを実現してもよい。
【0016】
一実施形態では、ADFがモバイルデバイス用のアプリケーションを構築する要求を受信すると、それは、すでに開発された1つ以上のアプリケーションのうち、ツールキットを使用してプリコンパイルされた部分を判断し、それらの既存のアプリケーションに関連付けられた宣言的情報を修正する。この実施形態は次に、修正された宣言的情報と既存のアプリケーションの1つ以上のバイナリアーティファクトとに基づいて、要求されたアプリケーションを構築する。これは、所望のオペレーティングシステム(iOS、アンドロイドなどの「OS」)のために要求されたアプリケーションを表わす当該バイナリアーティファクトをパッケージングすることによる。ADFは次に、要求されたアプリケーションをコンパイルして、1つ以上のバイナリアーティファクトおよび一組の定義ファイルを生成する。エンドユーザ開発では、アーティファクトとは、プログラミング言語を知る必要なくエンドユーザによって作成されるアプリケーションまたは複合データオブジェクトである。
【0017】
モバイルセキュリティ
いくつかの実施形態は、オラクル社からの「オラクル・モバイル・セキュリティ・スイート」(Oracle Mobile Security Suite:OMSS)などのモバイルセキュリティスイートによって提供されるセキュリティサービスを使用する。OMSSは、従業員中心の包括的なエンタープライズモビリティ管理(Enterprise Mobility Management:EMM)ソリューションと、消費者中心のモバイルおよびソーシャルサービスとを提供する、モバイルデバイスおよびモバイルアプリケーションセキュリティソリューションである。EMMは、既存のユーザアイデンティティにシームレスに繋がって、モバイルアクセスのためのエンタープライズバックエンドアイデンティティ管理インフラストラクチャの高度な特徴を利用することにより、モバイルデバイス管理(mobile device management:MDM)、モバイルアプリケーション管理(mobile application management:MAM)、モバイルコンテンツ管理(mobile content management:MCM)、およびモバイルアイデンティティポリシーを提供する。企業ニーズに準拠するセキュリティポリシーは、(典型的には企業所有のデバイスについて)完全なデバイスロックダウンを実施するように、および/または、(個人所有のデバイスの持ち込み(bring your own device:BYOD)について)セキュアな「コンテナ化された」企業アプリケーションおよびデータからパーソナルアプリケーションを分離するように、定義され得る。モバイルおよびソーシャルサービスはソフトウェア開発キット(software development kit:SDK)を提供して、企業の開発者がiOSおよびアンドロイドデバイス用のカスタムエンタープライズアプリケーションをセキュアにすることを可能にし、モバイルデバイス、ソーシャルネットワーク、およびエンタープライズバックエンドアイデンティティ管理インフラストラクチャ間の隙間を埋める。
【0018】
OMSSは、アプリケーションおよびコンテンツのセキュリティのためにセキュアコンテナをモバイルデバイスに提供して、企業のアプリケーションおよびデータを分離、保護、およびワイプする。モバイルデバイスとエンタープライズイントラネットリソースとの間の通信はすべて、モバイルデバイスの吟味された(または「コンテナ化された」)アプリケーションによってのみ使用され得る、認証されたトランスポート層セキュリティ(transport layer security :TLS)/セキュアソケット層(secure socket layer:SSL)トンネル(AppTunnel)を通過する。AppTunnelは、企業の非武装ゾーン(demilitarized zone:DMZ)に位置するモバイルセキュリティアクセスサーバで終端される。このサーバは、モバイルデバイスへのセキュアなイントラネットアクセスを提供し、セキュアコンテナからのAppTunnelのみを終端させ、それにより、不正アプリケーションのリスクとデバイスレベルVPNについての必要性とを減少させる。
【0019】
ADFによって提供されるものを利用して、実施形態は、コード化を必要とせず、ビジネスサービスに容易にマッピングされる、ブラウザベースのアプリケーション開発を提供する。実施形態はまた、(たとえばアプリケーションの開発中に)アプリケーションをインラインでプレビューすること、ならびに、アプリケーションを編集し、テストし、ブラウザから発行することを可能にする。したがって、実施形態は、プロの開発者によって使用されるように構成されるオラクル社からの「Jdeveloper」などのIDEではなく、ビジネスユーザ(たとえば専門外のユーザ)によって使用されるように構成される。
【0020】
サービスカタログ
MCSを使用する本発明の実施形態をサポートするために、MCSは、オラクル社からの「オラクルAPIカタログ」(Oracle API Catalog:OAC)などのAPIカタログへのアクセスを提供する。OACは、ある組織における利用可能なAPIへの可視性を提供して、それらのAPIがアプリケーション開発のために再使用され得るようにする。OACは、APIアセットのための単純なメタモデル、OACにAPIをポピュレートするための自動化、および、ユーザがAPIについてOACをサーチし、APIの詳細を理解して、それらのアプリケーションにおけるそれらの適合性を評価するための能力を含む。OACは、OACにおいてAPIアセットを作成するハーベスタを含む。いくつかの実施形態では、プロジェクトの構築時間にハーベスティングが行なわれる。ハーベスタは、デプロイメントされたサービスをイントロスぺクション(introspection)して、プロジェクトにおいて発見されたサービスを表わすAPIアセットを作成する。これらのサービスには、サービス指向アーキテクチャ(service oriented architecture:SOA)サービスおよびサービスバスプロキシ、ウェブサービス記述言語(Web Services Description Language:WSDL)ベースのウェブサービス、ならびに、ウェブアプリケーション記述言語(Web Application Description Language:WADL)ベースのRESTサービスなどがある。作成されたアセットは、OACにおいて収集される。
【0021】
APIアセットがハーベスタによって作成された後に、キュレータが、単純なエディタを使用してAPIアセットを編集して、APIの発見および理解を容易にするための追加のメタデータを提供する。キュレータは、名前を変更し、記述を追加し、キーワードをタグ付けし、またはOACにおけるAPIアセットに文書リファレンスを追加することができる。このメタデータは、ユーザによる各APIアセットの発見および理解を単純化する。APIメタデータが編集された後に、キュレータは、OACにおいてAPIをユーザに見えるようにすることによって、APIを発行する。発行されたアセットは、OACコンソールにおいて、オラクルJDeveloperオラクル・エンタープライズ・リポジトリ(Oracle Enterprise Repository)プラグインを介して利用可能である。ユーザは、OACをサーチしてAPIを発見し、キュレータによって提供されるメタデータを調査して、APIについてさらに学習することができる。
【0022】
各OACユーザには、各ユーザにとってどのOAC特徴およびコンテンツが利用可能であるかを判断する役割が割当てられている。OACには、開発者、キュレータ、および管理者を含む、予め定義された役割がある。開発者の役割を有するユーザは、発行されたAPIについてOACをサーチし、APIをよりよく理解するためにAPIメタデータを調べ、APIへの関心を宣言し、APIについての格付けおよびレビューを提示する能力を有する。開発者の役割に利用可能な能力に加えて、キュレータの役割を有するユーザは、ハーベスタを実行して、OACにおいて新しいAPIアセットを作成し、APIを編集してそれらのメタデータを更新し、それらを発行することができる。キュレータおよび開発者に利用可能な能力に加えて、管理者の役割を有するユーザは、OACにおける管理ページへのアクセスを有しており、システム設定を編集し、新しいユーザを作成し、新しい部門を作成し、セッションを管理し、インポート/エクスポートツールを使用することによって、OACのインフラストラクチャを管理する。管理者はまた、OACに含まれるセキュリティ特徴を構成することができる。
【0023】
いくつかの実施形態では、アプリケーションが、固有アプリケーションまたはホスト型アプリケーションとして開発され、モバイルデバイスにデプロイメントされてもよい。固有アプリケーションのデプロイメントについては、完全なアプリケーションがデバイス上にインストールされる。ホスト型アプリケーションの開発については、ユーザは「アップストア」(app store)からホスティングアプリケーションをダウンロードする必要があり、そのようなホスティングアプリケーションは、ホスティングアプリケーション上に「特徴」としてインストールされるであろうホスト型アプリケーションを「ホストする」。この実施形態は、宣言的メタデータがデバイスへ送信され、既存のアプリケーションの上に重ねられて、当該アプリケーションを、この新しいメタデータに対して実行するように更新することができるように、サーバからの実行中のホスティングアプリケーションを更新することを可能にしてもよい。
【0024】
図1は、MCS122をバックエンドサービスとして使用することを可能にする予め定義されたテンプレートを使用することによってアプリケーションを開発するためのシステム環境100のブロック図である。アプリケーション開発中にユーザにサービス定義を提示することができ、UI設計とバックエンドサービスとの間の迅速な接続を可能にする。
【0025】
図示された実施形態では、システム環境100は、1つ以上のクライアントコンピューティングデバイス104、106、および108にクラウドサービスを提供するクラウドインフラストラクチャシステム102を含む。クライアントコンピューティングデバイス104、106、および108は、クラウドインフラストラクチャシステム102と対話するためにユーザによって使用されてもよい。クライアントコンピューティングデバイス104、106、および108は、クラウドインフラストラクチャシステム102によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム102と対話するためにクライアントコンピューティングデバイスのユーザによって使用され得る、ウェブブラウザ、専用クライアントアプリケーション(たとえば、オラクル・フォームズ(Oracle Forms))、または何らかの他のアプリケーションといったクライアントアプリケーションを動作させるように構成されてもよい。
【0026】
クラウドインフラストラクチャシステム102は、図示されたもの以外のコンポーネントを有していてもよい。また、
図1に示す実施形態は、この発明の一実施形態を取入れ得るクラウドインフラストラクチャシステムの単なる一例である。いくつかの他の実施形態では、クラウドインフラストラクチャシステム102は、
図1に示すものよりも多い、または少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組合せてもよく、もしくは、異なる構成または配置のコンポーネントを有していてもよい。
【0027】
クライアントコンピューティングデバイス104、106、および108は、携帯型ハンドヘルドデバイス(たとえば、iPhone(登録商標)、携帯電話、iPad(登録商標)、コンピューティングタブレット、携帯情報端末(personal digital assistant:PDA))、またはウェアラブルデバイス(たとえば、グーグル・グラス(Google Glass)(登録商標)頭部装着型ディスプレイ)であってもよく、マイクロソフト・ウィンドウズ・モバイル(Microsoft Windows Mobile)(登録商標)などのソフトウェア、および/または、iOS、ウィンドウズ(登録商標)フォン、アンドロイド、ブラックベリー(登録商標)10、パームOSなどのさまざまなモバイルOSを実行し、インターネット、電子メール、ショートメッセージサービス(short message service:SMS)、ブラックベリー(登録商標)、または他の通信プロトコルに対応している。クライアントコンピューティングデバイス104、106、および108は、マイクロソフト・ウィンドウズ(登録商標)、アップル・マッキントッシュ(登録商標)、および/またはLinux(登録商標)OSのさまざまなバージョンを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを例として含む、汎用パーソナルコンピュータであり得る。クライアントコンピューティングデバイス104、106、および108は、たとえばグーグル・クロームOSなどのさまざまなGNU/LinuxOSを何ら限定されることなく含む、商業的に入手可能なさまざまなUNIX(登録商標)またはUNIX様OSのうちのいずれかを実行するワークステーションコンピュータであり得る。それに代えて、またはそれに加えて、クライアントコンピューティングデバイス104、106、および108は、ネットワーク110を通して通信可能である、シンクライアントコンピュータ、インターネット対応ゲーミングシステム(たとえば、Kinect(登録商標)ジェスチャー入力デバイスを有する、または有さない、マイクロソフトXboxゲーミングコンソール)、および/またはパーソナルメッセージングデバイスといった、任意の他の電子デバイスであってもよい。
【0028】
例示的なシステム環境100は3つのクライアントコンピューティングデバイスを有して図示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを有するデバイスなどの他のデバイスが、クラウドインフラストラクチャシステム102と対話してもよい。
【0029】
ネットワーク110は、クライアント104、106、および108とクラウドインフラストラクチャシステム102との間のデータの通信および交換を容易にしてもよい。ネットワーク110は、伝送制御プロトコル/インターネットプロトコル(transmission control protocol/Internet protocol:TCP/IP)、システムネットワークアーキテクチャ(systems network architecture:SNA)、インターネットパケット交換(Internet packet exchange:IPX)、アップル・トーク(Apple Talk)などを何ら限定されることなく含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。単なる例として、ネットワーク110は、イーサネット(登録商標)、トークンリング(Token-Ring)などに基づくものといった、ローカルエリアネットワーク(local area network:LAN)であり得る。ネットワーク110は、ワイドエリアネットワークおよびインターネットであり得る。それは、仮想プライベートネットワーク(virtual private network:VPN)を何ら限定されることなく含む仮想ネットワーク、イントラネット、エクストラネット、公衆交換電話網(public switched telephone network:PSTN)、赤外線ネットワーク、無線ネットワーク(たとえば、電気電子技術者協会(the Institute of Electrical and Electronics:IEEE)802.11プロトコルスイート、Bluetooth(登録商標)、および/または任意の他の無線プロトコルのうちのいずれかの下で動作するネットワーク)、ならびに/もしくは、これらのおよび/または他のネットワークの任意の組合せを含み得る。
【0030】
クラウドインフラストラクチャシステム102は、1つ以上のコンピュータおよび/またはサーバを含んでいてもよい。これらのコンピュータシステムまたはサーバは、1つ以上の汎用コンピュータ、専用サーバコンピュータ(パーソナルコンピュータ(PC)サーバ、UNIX(登録商標)サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを例として含む)、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および/または組合せで構成されてもよい。さまざまな実施形態では、クラウドインフラストラクチャシステム102に関連付けられた1つ以上のコンピュータシステムまたはサーバは、前述の開示で説明された1つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、クラウドインフラストラクチャシステム102に関連付けられた1つ以上のコンピュータシステムまたはサーバは、この開示の一実施形態に従った、ここに記載された処理を行なうためのサーバに対応していてもよい。
【0031】
クラウドインフラストラクチャシステム102に関連付けられた1つ以上のコンピュータシステムまたはサーバは、上述のもののうちのいずれかを含むOS、および商業的に入手可能な任意のサーバOSを実行してもよい。クラウドインフラストラクチャシステム102に関連付けられた1つ以上のコンピュータシステムまたはサーバはまた、ハイパーテキスト伝送プロトコル(hypertext transport protocol:HTTP)サーバ、ファイル転送プロトコル(file transfer protocol:FTP)サーバ、コモンゲートウェイインターフェイス(common gateway interface:CGI)サーバ、JAVA(登録商標)サーバ、データベースサーバなどを含む、さまざまな追加のサーバアプリケーションおよび/または中間層アプリケーションのうちのいずれかを実行してもよい。
【0032】
ある実施形態では、クラウドインフラストラクチャシステム102によって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどといった、クラウドインフラストラクチャシステム102のユーザにとってオンデマンドで利用可能にされる多数のサービスを含んでいてもよい。クラウドインフラストラクチャシステム102によって提供されるサービスは、そのユーザの必要性を満たすために動的にスケール変更され得る。クラウドインフラストラクチャシステム102によって提供されるサービスの特定のインスタンス化は、ここに「サービスインスタンス」と呼ばれる。一般に、クラウドサービスプロバイダのシステムから、インターネットなどの通信ネットワークを介してユーザに利用可能とされる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを作り上げるサーバおよびシステムは、顧客自身の構内サーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドでアプリケーションをオーダーし、使用してもよい。
【0033】
いくつかの例では、クラウドインフラストラクチャ102によってインスタンス化されたサービスインスタンスは、クラウドベンダーによってユーザに提供されるかまたは当該技術分野において他の態様で公知であるようなストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、もしくは他のサービスへの、保護されたコンピュータネットワークアクセスを含んでいてもよい。たとえば、クラウドインフラストラクチャ102によってインスタンス化されたサービスインスタンスは、インターネットを通した、クラウド上のリモートストレージへの、パスワードで保護されたアクセスを含み得る。別の例として、クラウドインフラストラクチャ102によってインスタンス化されたサービスインスタンスは、ネットワーク化された開発者による私的使用のための、ウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、クラウドインフラストラクチャ102によってインスタンス化されたサービスインスタンスは、クラウドベンダーのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含み得る。
【0034】
ある実施形態では、クラウドインフラストラクチャシステム102は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼でき、高可用性で、かつセキュアな態様で顧客に提供される、アプリケーション、ミドルウェア、開発サービス、およびデータベースサービス提供物一式を含んでいてもよい。クラウドインフラストラクチャサービス102において具現化されたような、そのようなクラウドインフラストラクチャシステムの一例は、オラクル社からの「オラクル・パブリック・クラウド」(Oracle Public Cloud)である。
【0035】
クラウドインフラストラクチャシステム102は、さまざまなデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム102がクラウドサービスを販売する組織によって所有され(たとえば、オラクル社によって所有され)、サービスが一般大衆またはさまざまな産業企業にとって利用可能とされる、パブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム102が単一の組織のためにのみ動作され、その組織内の1つ以上のエンティティのためのサービスを提供し得る、プライベートクラウドモデルの下で提供されてもよい。クラウドサービスはまた、クラウドインフラストラクチャシステム102、およびクラウドインフラストラクチャシステム102によって提供されるサービスが、関連するコミュニティにおけるいくつかの組織によって共有される、コミュニティクラウドモデルの下で提供されてもよい。クラウドサービスはまた、2つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルの下で提供されてもよい。
【0036】
いくつかの実施形態では、クラウドインフラストラクチャシステム102によって提供されるサービスは、ソフトウェア・アズ・ア・サービス(Software as a Service:SaaS)カテゴリー、プラットフォーム・アズ・ア・サービス(Platform as a Service:PaaS)カテゴリー、インフラストラクチャ・アズ・ア・サービス(Infrastructure as a Service:IaaS)カテゴリー、MBaaSカテゴリー、または、ハイブリッドサービスを含むサービスの他のカテゴリーの下で提供される、1つ以上のサービスを含んでいてもよい。いくつかの実施形態では、クラウドインフラストラクチャシステム102によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、インフラストラクチャサービス、バックエンドサービスなどを、何ら限定されることなく含んでいてもよい。いくつかの例では、アプリケーションサービスは、SaaSプラットフォームを介して、クラウドインフラストラクチャシステム102によって提供されてもよい。SaaSプラットフォームは、SaaSカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。たとえば、SaaSプラットフォームは、統合された開発およびデプロイメントプラットフォーム上にオンデマンドアプリケーション一式を構築し、配信するための能力を提供してもよい。SaaSプラットフォームは、SaaSサービスを提供するための根底的なソフトウェアおよびインフラストラクチャを管理し、制御してもよい。SaaSプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得できる。さまざまな異なるSaaSサービスが提供されてもよい。例は、大型組織のための販売実績管理、企業統合、およびビジネス柔軟性についてのソリューションを提供するサービスを、何ら限定されることなく含む。
【0037】
いくつかの実施形態では、プラットフォームサービスは、PaaSプラットフォームを介して、クラウドインフラストラクチャシステム102によって提供されてもよい。PaaSプラットフォームは、PaaSカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例は、(オラクルなどの)組織が共有の共通アーキテクチャ上で既存のアプリケーションを統合できるようにするサービスと、プラットフォームによって提供される共有のサービスを活用する新しいアプリケーションを構築するための能力とを、何ら限定されることなく含んでいてもよい。PaaSプラットフォームは、PaaSサービスを提供するための根底的なソフトウェアおよびインフラストラクチャを管理し、制御してもよい。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステム102によって提供されるPaaSサービスを取得できる。プラットフォームサービスの例は、オラクル社からの「オラクルJavaクラウド・サービス」(Java Cloud Service:JCS)、オラクル社からの「オラクル・データベース・クラウド・サービス」(Database Cloud Service:DBCS)などを、何ら限定されることなく含む。
【0038】
PaaSプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム102によってサポートされるプログラミング言語およびツールを採用するとともに、デプロイメントされたサービスを制御することができる。いくつかの実施形態では、クラウドインフラストラクチャシステム102によって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス(たとえば、オラクル・フュージョン・ミドルウェア(Oracle Fusion Middleware)サービス)、およびJavaクラウドサービスを含んでいてもよい。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形をしたデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発してデプロイメントするためのプラットフォームを提供してもよく、Javaクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてJavaアプリケーションをデプロイメントするためのプラットフォームを提供してもよい。
【0039】
クラウドインフラストラクチャシステム102において、さまざまな異なるインフラストラクチャサービスが、IaaSプラットフォームによって提供されてもよい。これらのインフラストラクチャサービスは、SaaSプラットフォームおよびPaaSプラットフォームによって提供されるサービスを利用する顧客のための、ストレージ、ネットワーク、ならびに他の基礎的コンピューティングリソースなどの根底的なコンピューティングリソースの管理および制御を容易にする。
【0040】
ある実施形態では、クラウドインフラストラクチャシステム102は、クラウドインフラストラクチャシステムにおけるクラウドサービス(たとえば、SaaS、PaaS、IaaS、およびMBaaSサービス)の包括的管理を提供してもよい。一実施形態では、クラウド管理機能性は、クラウドインフラストラクチャシステム102によって受信された顧客のサブスクリプションをプロビジョニングし、管理し、追跡するための能力などを含んでいてもよい。さまざまな実施形態では、クラウドインフラストラクチャシステム102は、クラウドインフラストラクチャシステム102によって提供されるサービスへの顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するように適合されてもよい。顧客は、クラウドインフラストラクチャシステム102によって提供される1つ以上のサービスを、サブスクリプションオーダーを介してオーダーしてもよい。クラウドインフラストラクチャシステム102は次に、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を行なう。
【0041】
一実施形態では、クラウド管理機能性は、オーダー管理および監視モジュール114などの1つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および/または組合せであり得る、1つ以上のコンピュータおよび/またはサーバを含んでいてもよく、もしくはそれらを使用して提供されてもよい。
【0042】
例示的な動作では、クライアントコンピューティングデバイス104、106または108を使用する顧客は、クラウドインフラストラクチャシステム102によって提供される1つ以上のサービスを要求することにより、クラウドインフラストラクチャシステム102と対話してもよい。顧客は、さまざまな手段を使用して、サービス要求134をクラウドインフラストラクチャシステム102に発行してもよい。サービス要求134は、クラウドインフラストラクチャシステム102によって提供される1つ以上のサービスについてサブスクリプションオーダーを出すこと、クラウドインフラストラクチャシステム102によって提供される1つ以上のサービスにアクセスすること、などを含んでいてもよい。ある実施形態では、顧客は、クラウドUI132、134、138にアクセスし、これらのUIを介してサブスクリプションオーダーを出してもよい。顧客がオーダーを出したことに応答してクラウドインフラストラクチャシステム102が受信したオーダー情報は、顧客を識別する情報と、顧客が申し込むつもりである、クラウドインフラストラクチャシステム102によって提供される1つ以上のサービスを識別する情報とを含んでいてもよい。顧客によってオーダーが出された後で、オーダー情報がクラウドUI132、134、および/または138を介して受信される。
【0043】
この例では、オーダー管理および監視モジュール112が、顧客から受信した情報をオーダーデータベースへ送信して、顧客によって出されたオーダーを格納させる。オーダーデータベースは、クラウドインフラストラクチャシステム102によって動作され、他のシステム要素とともに動作される、いくつかのデータベースのうちの1つであり得る。オーダー管理および監視モジュール112は、オーダーデータベースに格納されたオーダー情報のすべてまたは一部を含む情報をオーダー管理モジュールへ発送してもよい。場合によっては、オーダー管理モジュールは、オーダーを検証し、検証後にオーダーを予約するといった、オーダーに関連する請求および課金機能を行なうように構成されてもよい。
【0044】
ある実施形態では、クラウドインフラストラクチャシステム100は、アイデンティティ管理モジュール114を含んでいてもよい。アイデンティティ管理モジュール114は、クラウドインフラストラクチャシステム102においてアクセス管理および認証サービスなどのアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態では、アイデンティティ管理モジュール114は、クラウドインフラストラクチャシステム102によって提供されるサービスを利用したい顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース(たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど)に対してそれらの顧客がどのアクションを行なうことが認可されているかを記述する情報とを含み得る。アイデンティティ管理モジュール114はまた、各顧客についての記述的情報と、その記述的情報が誰によってどのようにアクセスされ、修正され得るかについての記述的情報との管理を含んでいてもよい。
【0045】
ある実施形態では、クラウドインフラストラクチャシステム102はまた、クラウドインフラストラクチャシステム102の顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース116を含んでいてもよい。一実施形態では、インフラストラクチャリソース116は、PaaSプラットフォームおよびSaaSプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージ、およびネットワーキングリソースといったハードウェアの予め統合され最適化された組合せを含んでいてもよい。
【0046】
いくつかの実施形態では、クラウドインフラストラクチャシステム102におけるリソースは、複数のユーザによって共有され、要望ごとに動的に再割当てされてもよい。加えて、リソースは、異なる時間帯におけるユーザに割当てられてもよい。たとえば、クラウドインフラストラクチャシステム102は、第1の時間帯における第1の一組のユーザが、特定数の時間、クラウドインフラストラクチャシステムのリソースを利用することを可能にし、次に、異なる時間帯に位置する別の一組のユーザへの同じリソースの再割当てを可能にして、それによりリソースの利用を最大化してもよい。
【0047】
ある実施形態では、クラウドインフラストラクチャシステム102の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム102が提供するサービスによって共有される、多くの内部共有サービス118が提供されてもよい。これらの内部共有サービス118は、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウィルススキャニングおよびホワイトリストサービス、高可用性、バックアップおよび復元サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを、何ら限定されることなく含んでいてもよい。
【0048】
ある実施形態では、クラウドインフラストラクチャシステム102の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム102が提供するサービスによって共有される、多くの外部共有サービス120が提供されてもよい。これらの外部共有サービス120は、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウィルススキャニングおよびホワイトリストサービス、高可用性、バックアップおよび復元サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを、何ら限定されることなく含んでいてもよい。
【0049】
さまざまな実施形態では、外部共有サービス120は、アクセス、データ変換、自動化などをエンタープライズコンピュータシステム126に提供する1つ以上のコンポーネントを含んでいてもよい。エンタープライズコンピュータシステム126へのアクセスは、クラウドインフラストラクチャシステム102の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム102が提供するサービスによって、共有されてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム126へのアクセスは、1人以上のサブスクライバに制限される、クラウドインフラストラクチャシステム102が提供するサービスインスタンスによって、共有されてもよい。
【0050】
さらなる実施形態では、外部共有サービス120は、クラウドインフラストラクチャシステム102の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム102が提供するサービスによって共有される、外部アプリケーションプログラミングインターフェイス(application programming interface:API)サービス128を含んでいてもよい。これらの外部APIサービス128は、他の第三者サービスまたはエンティティによって提供されるAPIを、何ら限定されることなく含んでいてもよい。
【0051】
クラウドインフラストラクチャシステム102では、MCS122によって、さまざまな異なるモバイルクラウドサービスが提供されてもよい。本発明のいくつかの実施形態によれば、MCS122は、モバイルコンピューティングデバイスとエンタープライズコンピュータシステム(たとえば、エンタープライズコンピュータシステム124および126)との間の通信を容易にする。MCS122は、エンタープライズデータおよび認証情報を格納するために使用される1つ以上のメモリ記憶装置(ローカルストレージ)を含んでいてもよい。エンタープライズデータは、エンタープライズコンピュータシステム126から、あるいはクライアントコンピューティングデバイス104、106、または108から受信されてもよく、もしくは、クラウドインフラストラクチャシステム102によって変換されたエンタープライズデータを含んでいてもよく、もしくはそれらの組合せであってもよい。認証情報は、アイデンティティ管理システム116から受信されてもよく、および/または、クラウドインフラストラクチャシステム102によって生成されてもよい。いくつかの実施形態では、認証情報は、サービスについての要求に関するユーザのセキュリティ認証を示す情報を含んでいてもよい。
【0052】
エンタープライズコンピュータシステム126などのエンタープライズコンピュータシステムは、クラウドインフラストラクチャシステム102のファイアウォールを越えて、クラウドインフラストラクチャシステム102とは異なる地理的場所(たとえば、リモートの地理的場所)に物理的に位置していてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム126は、1つ以上の異なるコンピュータまたはサーバを含んでいてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム126は、単一のコンピュータシステムの一部であってもよい。
【0053】
ある実施形態では、エンタープライズコンピュータシステム126は、1つ以上の異なるプロトコルを使用して、クラウドインフラストラクチャシステム102と通信してもよい。エンタープライズコンピュータシステム126の各々は、異なる通信プロトコルを使用して、クラウドインフラストラクチャシステム102と通信してもよい。エンタープライズコンピュータシステム126は、同じまたは異なるセキュリティプロトコルをサポートしてもよい。いくつかの実施形態では、MCS122は、エンタープライズコンピュータシステム126との通信を取扱うためのエージェントシステムを含んでいてもよい。
【0054】
プロトコルは、SPeeDY(SPDY)などの通信プロトコルを含んでいてもよい。プロトコルは、HTTPベースのプロトコルなどのアプリケーションプロトコルを含んでいてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム126は、RESTまたはシンプル・オブジェクト・アクセス・プロトコル(Simple Object Access Protocol:SOAP)などの通信プロトコルを使用して、クラウドインフラストラクチャシステム102と通信してもよい。たとえば、RESTプロトコルは、ユニフォームリソース識別子(uniform resource identifier:URI)またはユニフォームリソースロケータ(uniform resource locator:URL)を含むフォーマットをサポートしてもよい。RESTプロトコルを使用する通信のためにフォーマット化されたエンタープライズデータは、JavaScript(登録商標)オブジェクト表記法(JavaScript Object Notation:JSON)、コンマ区切り形式(comma-separated values:CSV)、およびリアリー・シンプル・シンジケーション(really simple syndication:RSS)などのデータフォーマットに容易に変換されてもよい。エンタープライズコンピュータシステム126とクラウドインフラストラクチャシステム102とは、リモート・プロシージャ・コール(remote procedure call:RPC)(たとえば、拡張マークアップ言語(extended markup language:XML)RPC)などの他のプロトコルを使用して通信してもよい。
【0055】
いくつかの実施形態では、MCS122は、クラウドインフラストラクチャサービス102によって提供される1つ以上のサービスとの通信をサポートするように構成されたアダプタインターフェイスを含んでいてもよく、それらのサービスのうちのいくつかは、通信用の異なるプロトコルまたは手法をサポートしてもよい。いくつかの実施形態では、MCS122は、エンタープライズコンピュータシステム126との通信をサポートするように構成されたアダプタインターフェイスを含んでいてもよく、エンタープライズコンピュータシステム126のうちのいくつかは、通信用の異なるプロトコルまたは手法をサポートしてもよい。MCS122は、通信プロトコル、エンタープライズコンピュータシステムのタイプ、アプリケーションのタイプ、サービスのタイプ、またはそれらの組合せに従って通信するように各々構成され得る1つ以上のアダプタを含んでいてもよい。アダプタによってサポートされる通信プロトコルは、サービスに、またはエンタープライズコンピュータシステム126のうちの1つ以上に特有のものであってもよい。
【0056】
ある実施形態では、クライアントコンピューティングデバイス104、106、および108は各々、MCS122と通信するための特定のUIを提供できるアプリケーションを実装してもよい。特定のUIは、特定の通信プロトコルを使用して通信するように構成されてもよい。いくつかの実施形態では、特定のUIは、MCS122と通信するために呼出され得る、呼出し可能インターフェイス、機能、ルーチン、方法、および/または動作を含んでいてもよい。特定のUIは、エンタープライズデータのために、および/またはサービスを要求するために、クラウドインフラストラクチャサービス102によって提供されるサービスと通信するためのパラメータ、またはエンタープライズコンピュータシステム126と通信するためのパラメータを、入力として受け入れてもよい。いくつかの実施形態では、MCS122を通した通信は、カスタム通信プロトコルを使用する通信のために変換されてもよい。いくつかの実施形態では、特定のUIは、アプリケーションにおいてカスタムクライアントに対応していてもよい。
【0057】
MCS122は、1つ以上の呼出し可能インターフェイス、たとえばAPIを含んでいてもよい。MCS122に関連付けられた呼出し可能インターフェイスは、モバイルコンピューティングデバイス上のアプリケーションがMCS122に要求を通信することを可能にしてもよい。MCS122に関連付けられた呼出し可能インターフェイスは共通または標準インターフェイスをサポートしてもよく、それは、パラメータを含む要求が、標準化プロトコル、アーキテクチャスタイル、および/またはフォーマット(たとえばRESTプロトコル)に従って、アプリから受信されることを可能にしてもよい。MCS122に関連付けられた呼出し可能インターフェイスは、コンピューティングデバイス104、106、または108のうちのいずれか1つのユーザによって構成可能であってもよい。MCS122に関連付けられた呼出し可能インターフェイスは、通信プロトコルに従って、サービスについての要求を受信してもよい。デバイスアプリケーション開発者は、自分のカスタムアプリケーションのためにMCS122に接続することができる。いくつかの実施形態では、MCS122に関連付けられた呼出し可能インターフェイスは、アプリを開発したのと同じ人によって構成され、その人が、MCS122と通信するためのカスタムアプリケーションを実現できるようになっていてもよい。
【0058】
MCS122に関連付けられた呼出し可能インターフェイスはさらに、エンタープライズコンピュータシステム126が、標準化プロトコルまたはフォーマットに従ってMCS122と通信することを可能にしてもよい。アプリケーション開発者と同様に、エンタープライズコンピュータシステムを管理する人は、1つ以上の呼出し可能インターフェイスを介してMCS122と通信するように構成されたコード(たとえばエージェントシステム)を実現することができる。MCS122に関連付けられた呼出し可能インターフェイスは、コンピューティングデバイスのタイプ、エンタープライズコンピュータシステムのタイプ、アプリ、エージェントシステム、サービス、プロトコル、または他の基準に基づいて実現されてもよい。いくつかの実施形態では、MCS122に関連付けられた呼出し可能インターフェイスは、認証、圧縮、暗号化、カーソルを用いたページネーション、クライアントベースのスロットリング、否認不可、ロギング、およびメトリック収集を含むサービスについての要求をサポートしてもよい。いくつかの実施形態では、MCS122に関連付けられた呼出し可能インターフェイスは、認証、ポリシー実施、応答のキャッシング、MCS122への呼出しのスロットリング、非同期パターンと同期パターンとの間の翻訳、根底的なサービスへの呼出しのロギング、またはそれらの組合せ、といったカスタムビジネス関連サービスのために実現されてもよい。いくつかの実施形態では、MCS122に関連付けられた呼出し可能インターフェイスは、ユーザが、クラウドインフラストラクチャシステム102による実現のためにカスタムコードをロードすることを可能にしてもよい。カスタムコードは、クラウドインフラストラクチャシステム102のために、MCS122に関連付けられた1つ以上の呼出し可能インターフェイスを実現してもよく、それは、ユーザがカスタムサービスまたは他のエンタープライズコンピュータシステムにアクセスすることを可能にできる。
【0059】
MCS122に関連付けられたプロトコルトランスレータは、メッセージを処理して、メッセージ用の通信プロトコルを判断し、および/またはメッセージを宛先用の通信プロトコルに変換してもよい。MCS122に関連付けられたプロトコルトランスレータは、クライアントコンピューティングデバイス104、106、または108から受信された要求を変換してもよい。要求は、クライアントコンピューティングデバイス104、106、または108によってサポートされる通信プロトコルのフォーマットから、クラウドインフラストラクチャサービス102またはエンタープライズコンピュータシステム126によって提供されるサービスによってサポートされる通信プロトコルのフォーマットに変換されてもよい。MCS122に関連付けられたプロトコルトランスレータは、クラウドインフラストラクチャサービス102またはエンタープライズコンピュータシステム126によって提供されるサービスから受信された応答を変換してもよい。応答は、クラウドインフラストラクチャサービス102またはエンタープライズコンピュータシステム126によって提供されるサービスによってサポートされる通信プロトコルのフォーマットから、クライアントコンピューティングデバイス104、106、または108によってサポートされる通信プロトコルのフォーマットに変換されてもよい。
【0060】
MCS122に関連付けられたセキュリティサービスは、クライアントコンピューティングデバイス104、106、または108のうちのいずれかから受信された要求についてのセキュリティ認証を管理してもよい。MCS122に関連付けられたセキュリティサービスは、顧客プロセスおよびエンタープライズデータの完全性を保護してもよい。システムまたはデータが損なわれないようにするために、クライアントコンピューティングデバイス104、106、または108から要求が受信されると、セキュリティ認証が起こってもよい。セキュリティ認証は、クラウドインフラストラクチャシステム102による処理のために要求が発送される前に行なわれてもよい。あるユーザについて判断されたセキュリティ認証は、モバイルコンピューティングデバイスに関連付けられたユーザが、MCS122を介してサービスを要求するための認証を有することを可能にしてもよい。セキュリティ認証は、ユーザが、MCS122を介して要求された異なる要求および/またはサービスについて認証するための労力を減少させてもよい。MCS122に関連付けられたセキュリティサービスは、要求のセキュリティを認証するさまざまな動作を行なうように構成された1つ以上の機能ブロックまたはモジュールとして実現されてもよい。
【0061】
MCS122に関連付けられた認証サービスは、クライアントコンピューティングデバイス104、106、または108から受信された要求についてのセキュリティ認証を管理してもよい。MCS122に関連付けられた認証サービスは、MCS122に要求を送信するコンピューティングデバイスに関連付けられたユーザについてセキュリティ認証を判断してもよい。セキュリティ認証は期間に基づいて判断されてもよく、期間は、アプリケーションの動作(たとえば、アプリケーションの起動)、要求、コンピューティングデバイス、エンタープライズコンピュータシステム、要求に関連する他の基準、またはそれらの組合せに結び付けられてもよい。セキュリティ認証は、個々の要求、1つ以上のエンタープライズコンピュータシステム、特定のサービス、サービスのタイプ、ユーザ、コンピューティングデバイス、セキュリティ認証を判断するための他の基準、またはそれらの組合せ、などのうちのいずれか1つについて、検証され付与されてもよい。いくつかの実施形態では、クラウドインフラストラクチャシステム102は、エンタープライズコンピュータシステム、またはエンタープライズコンピュータシステムをサポートする認証システムから受信されたユーザの認証情報を格納してもよい。クラウドインフラストラクチャシステム102は、要求に関連付けられたユーザのアイデンティティがそのような要求を行なう認可を有するかどうかを判断するためにルックアップ機能を行なうことによって、認証を判断してもよい。格納された認証情報は、ユーザがアクセスすることを認可され得る、要求、機能、エンタープライズコンピュータシステム、エンタープライズデータなどのタイプといった情報を含んでいてもよい。いくつかの実施形態では、インフラストラクチャシステム102は、認証を判断するために、要求元コンピューティングデバイスとの通信を起動してもよい。
【0062】
いくつかの実施形態では、セキュリティ認証は、サービスを要求するユーザに関連付けられた役割に基づいて判断されてもよい。役割は、MCS122へのアクセスを要求するユーザに関連付けられてもよい。いくつかの実施形態では、ユーザは、MCS122によって提供されるリソースおよび/またはサービスへのアクセスを付与され得るMCS122のサブスクライバまたはテナントとして、サービスを要求してもよい。認証は、ユーザがサブスクライバとしてMCS122を介してサービスを要求することが認可され得るように、MCS122へのユーザのサブスクリプションに対応していてもよい。いくつかの実施形態では、サブスクリプションは、MCS122によって提供される特定の一組のリソースに限定されてもよい。セキュリティ認証は、MCS122のユーザがアクセス可能なリソースおよび/またはサービスに基づいていてもよい。いくつかの実施形態では、「実行時環境」と呼ばれる実行中に、要求にテンプレートがプロビジョニングされてもよい。実行時環境は、要求、ユーザ、またはデバイスに割当てられるリソースに関連付けられてもよい。
【0063】
いくつかの実施形態では、MCS122に関連付けられた認証サービスは、アイデンティティ管理システムに、ユーザについてセキュリティ認証を判断するよう要求してもよい。アイデンティティ管理システムは、クラウドインフラストラクチャシステム102によって(たとえばアイデンティティ管理114として)実現されてもよく、または、クラウドインフラストラクチャシステム102の外部の別のコンピュータシステムによって実現されてもよい。アイデンティティ管理116は、MCS122にアクセスするためのユーザの役割またはサブスクリプションに基づいて、ユーザのセキュリティ認証を判断してもよい。役割またはサブスクリプションには、エンタープライズコンピュータシステム、エンタープライズコンピュータシステムによって提供されるサービス、エンタープライズコンピュータシステムの機能または特徴、エンタープライズコンピュータシステムへのアクセスを制御するための他の基準、またはそれらの組合せに対する特権および/または権利が割当てられてもよい。
【0064】
ADF
クラウドインフラストラクチャシステム102では、さまざまな異なるADF124が提供されてもよい。ADF124は、アジャイルなSOAベースのアプリケーションを実装するためにインフラストラクチャコードを提供する。ADF124はさらに、1つ以上の開発ツール(たとえば、「オラクルJDeveloper 11g」開発ツール)を通して、開発への視覚的および宣言的アプローチを提供する。ADF124によって提供される1つ以上のフレームワークは、MVC設計パターンを実装してもよい。そのようなフレームワークは、MVCアーキテクチャのすべての層を、オブジェクト/リレーショナルマッピング、データ持続、再使用可能なコントローラ層、リッチなウェブUIフレームワーク、UIへのデータバインディング、セキュリティおよびカスタム化などのエリアに対するソリューションでカバーする、統合的ソリューションを提供する。コアウェブベースのMVCアプローチを超えて、そのようなフレームワークはまた、オラクルSOAおよびウェブセンターポータル(WebCenter Portal)フレームワークと統合して、完全な複合アプリケーションの作成を単純化する。
【0065】
ある実施形態では、ADF124は、クラウドインフラストラクチャシステム102によって提供されるビルトインビジネスサービスにサービスインターフェイスを結合することによって、サービスとしてデータを公開するアジャイルなアプリケーションを開発することを容易にする。ビジネスサービス実装詳細のこの分離は、ADF124においてメタデータを介して行なわれる。このメタデータ駆動型アーキテクチャの使用により、アプリケーション開発者は、サービスがどのようにアクセスされるかの詳細にではなく、ビジネスロジックおよびユーザ体験に集中できるようになる。ある実施形態では、ADF124は、サービスの実装詳細を、モデル層におけるメタデータに格納する。これにより、開発者は、UIを修正することなくサービスを交換できるようになり、アプリケーションが非常にアジャイルになる。加えて、UIを作成する開発者は、ビジネスサービスアクセス詳細に悩まされる必要がない。代わりに、開発者は、アプリケーションインターフェイスおよび対話ロジックの開発に集中することができる。ユーザ体験を作り出すことは、ビジュアルページデザイナ上に所望のビジネスサービスをドラッグ・アンド・ドロップし、どのタイプのコンポーネントがそのデータを表わすべきかを示すのと同じくらい単純であり得る。
【0066】
さまざまな実施形態では、開発者はADF124と対話して、エンタープライズアプリケーションを形成するモジュールを作成する。エンタープライズアプリケーションは、クラウドインフラストラクチャシステム102のコンテキスト内で実行され得る。さまざまな実施形態では、開発者はADF124と対話して、モバイルアプリケーションを形成するモジュールを作成する。モバイルアプリケーションは、クラウドインフラストラクチャシステム102のコンテキスト内で実行され得る。以下に説明されるこの発明の特徴は、ここに提供される開示を読むことによって当業者には明らかであるように、プログラミング言語とアプリケーション開発フレームワークとの任意の所望の組合せを使用して実現されてもよい。
【0067】
ADF124によって提供される1つ以上のフレームワークは、一例ではオラクルADFとして具現化され得る。したがって、ADF124におけるフレームワークは、MVC設計パターンに基づき得る。MVCアプリケーションは、1)データソースとの対話を取扱い、ビジネスロジックを実行するモデル層と、2)アプリケーションUIを取扱うビュー層と、3)アプリケーションフローを管理し、モデル層とビュー層との間のインターフェイスとして作用するコントローラとに分離される。これら3つの層にアプリケーションを分離することは、アプリケーション間にわたるコンポーネントの保守および再使用を単純化する。各層の他の層からの独立は、緩く結合されたSOAをもたらす。
【0068】
さまざまな実施形態では、ADF124は、開発者がアプリケーションを多層の形で作成することを可能にするツールおよびリソースを提供し、各層は、予め定義された仕様に従って所望のロジックを実現するコードモジュール/ファイルを含む。このため、一実施形態では、ADF124は、アプリケーションが、アプリケーションのUIを提供するコードモジュール/ファイルを含むビュー層と、アプリケーションのフローを制御するコードモジュールを含むコントローラ層と、根底的なデータのための抽象化層を提供するデータ/コードモジュールを含むモデル層と、さまざまなソースからのデータへのアクセスを提供し、ビジネスロジックを取扱うコードモジュールを含むビジネスサービス層という4つの層として開発されることを可能にする。
【0069】
ある実施形態では、ADF124は、開発者に、層の各々を実装する際に自分が使用したい技術を選択させる。エンタープライズJavaBean(Enterprise JavaBean:EJB)(登録商標)、ウェブサービス(Web Services)、JavaBeans、JPA/エクリプスリンク(EclipseLink)/トップリンク(TopLink)オブジェクト、および他の多くがすべて、ADF124のためのビジネスサービスとして使用可能である。ビュー層は、Javaサーバ・フェイス(Java Server Faces:JSF)、デスクトップ・スイング(Desktop Swing)アプリケーション、およびマイクロソフト・オフィス・フロントエンドを用いて実現されるウェブベースのインターフェイスと、モバイル装置用のインターフェイスとを含み得る。
【0070】
一局面では、ビュー層は、開発中のアプリケーションのUIを表わす。ビュー層は、デスクトップビュー、モバイルビュー、およびブラウザベースのビューを含んでいてもよく、それらの各々はUIのすべてまたは一部を提供するとともに、ビュータイプに対応するさまざまな態様でアクセス可能である。たとえば、ウェブページが、対応するURLを含むクライアント要求を受信することに応答して、アプリケーションによって送信されてもよい。ウェブページは次に、要求元クライアントシステムに関連付けられた表示部(図示せず)上にブラウザによって表示されてもよく、それにより、要求元クライアントシステムのユーザがエンタープライズアプリケーションと対話することを可能にする。ADF124は、ビジネスサービスの再使用を可能にするビジネスサービスへのマルチチャネルアクセスと、ウェブクライアント、クライアント・サーバ・スイング・デスクトップベース・アプリケーション(client-server swing desktop-based application)、マイクロソフト・エクセル・スプレッドシート、スマートフォンなどのモバイルデバイス、などからのアクセスとをサポートする。
【0071】
(ウェブページなどの)ビュー層を形成するコードファイル/モジュールは、ハイパーテキストマークアップ言語(hypertext markup language:HTML)、Javaサーバ・ページ(Java server page:JSP)、およびJSFのうちの1つ以上を使用して実現されてもよい。それに代えて、UIは、スイング(Swing)などのJavaコンポーネント、および/またはXMLを使用して実現されてもよい。さらに述べられるように、UIは、マイクロソフトによるワードおよびエクセルなどのデスクトップアプリケーションについてのユーザの体験および習熟を活用してもよい。
【0072】
上述のように、ユーザが開発した関連するコード/データモジュールが、層の各々において提供される。しかしながら、各層は典型的には、ADF124によって提供される他の予め定義されたコード/データモジュールを含む。予め定義されたモジュールのうちのいくつかは、たとえば、ウェブページを開発するためのテンプレート、開発されたコードに所望の機能性を含めるためのテンプレートなどとして、開発中に使用されてもよい。(URL書換モジュールなどの)他の予め定義されたモジュールが、開発されたアプリケーションとともにデプロイメントされてもよく、エンタープライズアプリケーションの実行中に追加の機能性(要求されたURLの、内部名へのマッピング)をユーザに提供してもよい。
【0073】
コントローラ層は、アプリケーションのフローを制御するコードモジュール/ファイルを含む。各コントローラオブジェクトは、ビュー層において情報を提示する所望の態様に従って実現されたソフトウェア命令および/またはデータを含む。所望の態様は、別のウェブページにおけるリンクがユーザによってクリック/選択されると表示される特定のウェブページ、実行中にエラーが起こると表示される、格納/検索すべき特定のデータを示すページなどを含んでいてもよい。
【0074】
一局面では、コントローラ層はアプリケーションのフローを管理し、ユーザ入力を取扱う。たとえば、ページ上でサーチボタンがクリックされると、コントローラは、どのアクションを行なうべきか(サーチを行なう)と、どこにナビゲートすべきか(結果ページ)とを判断する。JDeveloperでは、ウェブベースのアプリケーションについて、標準のJSFコントローラ、またはJSFコントローラ機能性を拡張するADFコントローラという2つのコントローラオプションがある。どちらのコントローラが使用されても、アプリケーションフローは典型的には、ページおよびナビゲーションルールをダイアグラム上にレイアウトすることによって設計される。アプリケーションのフローは、より小さい再使用可能タスクフローに分割可能であり、方法呼出しおよび判定ポイントなどの非視覚的コンポーネントをフローに含めることでき、単一の含有ページの領域内で実行される「ページフラグメント」フローを作成することができる。
【0075】
コントローラ層を形成するコードモジュール/ファイルはしばしば、クライアント要求を受信するととともに対応する応答として所望のウェブページを送信するJavaサーブレットとして実現される。コントローラオブジェクトはまた、たとえば、アパッチ・ジャカルタ・ストラット(Apache Jakarta Struts)コントローラとして、またはJSF規格に従って実現されてもよい。
【0076】
モデル層は、さまざまなビジネスサービスを、それらを他の層で使用するオブジェクトに、たとえば上述のコントローラオブジェクトに、または直接デスクトップアプリケーションに接続する、データ/コードモジュールを含む。モデル層の各抽象データオブジェクトは、任意のタイプのビジネスサービスにアクセスするために使用され得る対応するインターフェイスを提供し、根底的なビジネスサービス層で実行される。データオブジェクトは、クライアントからのサービスのビジネスサービス実装詳細を抽象化し、および/または、データ制御方法/属性をビューコンポーネントに公開してもよく、このため、ビュー層とデータ層との分離を提供する。
【0077】
一局面では、モデル層は、データ制御およびデータバインディングという2つのコンポーネントからなり、それらは、インターフェイスを定義するためにメタデータファイルを利用する。データ制御は、クライアントからのビジネスサービス実装詳細を抽象化する。データバインディングは、データ制御方法および属性をUIコンポーネントに公開し、ビューとモデルとのクリーンな分離を提供する。モデル層のメタデータアーキテクチャにより、開発者は、任意のタイプのビジネスサービス層実装をビュー層およびコントローラ層にバインドする際に、同じ開発体験を得る。
【0078】
ある実施形態では、ADF124は、開発プロセス全体にわたって宣言的プログラミングパラダイムの使用を強調して、ユーザが、実現詳細に手をつける必要なく、アプリケーション作成のロジックに集中できるようにする。高レベルでは、フュージョン・ウェブ(Fusion Web)アプリケーションのための開発プロセスは通常、アプリケーションワークスペースを作成することを伴う。ウィザードを使用して、開発者が選択した技術にとって必要なライブラリおよび構成が自動的に追加され、アプリケーションが、パッケージおよびディレクトリを有するプロジェクトへと構造化される。
【0079】
データベースオブジェクトをモデル化することにより、オンラインデータベースまたは任意のデータベースのオフラインレプリカが作成可能であり、定義が編集可能であり、スキーマが更新可能である。統一モデリング言語(unified modeling language:UML)モデラーを使用して、使用事例が次に、アプリケーションのために作成可能である。アプリケーション制御およびナビゲーションも設計可能である。アプリケーション制御およびナビゲーションのフローを視覚的に判断するために、ダイアグラマ(diagrammer)が使用可能である。次に、フローを記述する根底的なXMLファイルが自動的に作成可能である。開発者が、インポートされたライブラリを、アプリケーションに単純にドラッグ・アンド・ドロップすることによって閲覧および使用することを可能にするために、リソースライブラリが使用可能である。データベーステーブルから、エンティティオブジェクトが、ウィザードまたはダイアログを使用して作成可能である。それらのエンティティオブジェクトから、ビューオブジェクトが、アプリケーションにおけるページによって使用されるように作成される。検証ルールおよび他のタイプのビジネスロジックが実現可能である。
【0080】
この例では、ビジネスサービス層は、データ持続層との対話を管理する。それは、データ持続、オブジェクト/リレーショナルマッピング、トランザクション管理、およびビジネスロジック実行などのサービスを提供する。ビジネスサービス層は、シンプルJavaクラス、EJB、ウェブサービス、JPAオブジェクト、およびオラクルADFビジネスコンポーネント(Oracle ADF Business Components)といったオプションのうちのいずれかで実装可能である。加えて、データは、ファイル(XMLまたはCSV)およびRESTから直接消費され得る。このため、各ビジネスサービスは、対応するデータ持続層との対話を管理し、また、オブジェクト/リレーショナルマッピング、トランザクション管理、ビジネスロジック実行などのサービスを提供する。ビジネスサービス層は、シンプルJavaクラス、エンタープライズJavaBeans、ウェブサービスなどのうちの1つ以上を使用して実装されてもよい。
【0081】
ビジネスコンポーネントは、データベース、ウェブサービス、レガシーシステム、アプリケーションサーバなどとの対話を提供するために、たとえばオラクル社からの「オラクルADFビジネスコンポーネント」を使用して実装されるビジネスサービスを表わす。一実施形態では、ビジネスサービス層のビジネスコンポーネントは、ビジネスサービス実装を提供するために協働するアプリケーションモジュール、ビュー/クエリオブジェクト、およびエンティティオブジェクトの混合を含む。アプリケーションモジュールは、アプリケーション/トランザクションデータと連携するためにUIクライアントが通信するトランザクションコンポーネント/コードモジュールであり得る。アプリケーションモジュールは、更新可能なデータモデルを提供してもよく、また、ユーザトランザクションに関する手順/機能(一般にサービス方法と呼ばれる)を提供してもよい。
【0082】
エンティティオブジェクトは、データベーステーブルにおける対応する行を表わしてもよく、対応する行に格納されたデータの操作(更新、削除など)を単純化してもよい。エンティティオブジェクトはしばしば、所望のビジネスルールが一貫して実施されることを保証するために、対応する行のためのビジネスロジックをカプセル化する。エンティティオブジェクトはまた、根底的なデータベースに格納された行間に存在する関係を反映するように、他のエンティティオブジェクトに関連付けられてもよい。
【0083】
図2は、本発明のいくつかの実施形態に従った、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通信を容易にするためのコンピューティング環境200のブロック図を示す。例示の目的のために、さまざまな例が、モバイルコンピューティングデバイス(たとえば、コンピューティングデバイス202)がクラウドエンタープライズコンピュータシステム240(たとえば、「serviceprovider.com」)および構内エンタープライズコンピュータシステム250などの1つ以上のエンタープライズコンピュータシステムと通信できるようにするための手法を説明するためにここに提供される。そのような通信は、エンタープライズデータを交換または転送すること、エンタープライズコンピュータシステムによって提供されるサービスを要求すること、メッセージを通信すること、もしくはそれらの組合せであってもよい。
【0084】
メッセージは、サービス呼出しメッセージ、結果メッセージ、要求メッセージ、内部で通信される他のメッセージ、コンピューティングデバイスとエンタープライズコンピュータシステムとの間で通信される他のメッセージ、またはそれらの組合せを含んでいてもよい。メッセージは、メッセージタイプ(たとえば、一組の共有タイプの定数からのタイプ値)、相関id(たとえば、このメッセージを1つ以上の他のメッセージと相関させるために使用されるid)、優先順位ベースのメッセージキューについてサポートするための優先順位情報、タイムアウト、メッセージデータ分離をサポートするための感度指標、メッセージソース(たとえば、送信側のユニフォームリソース識別子)、メッセージ宛先(たとえば、宛先を一意的に識別するユニフォームリソース識別子)、要求コンテキスト(たとえば、ディスパッチャからの要求情報)、および/または、メッセージペイロードを含んでいてもよい。ペイロードは、パラメータデータおよび結果データといった送信中のメッセージのタイプに依存して、異なる属性を有していてもよい。
【0085】
ここに説明されるようなエンタープライズデータは、エンタープライズコンピュータシステムから受信されるデータ、エンタープライズコンピュータシステムへ送信されるデータ、エンタープライズコンピュータシステムによって処理されるデータ、またはそれらの組合せを含んでいてもよい。エンタープライズデータは、消費者アプリケーションおよび/またはサービスについてのデータとは区別可能であってもよい。いくつかの実施形態では、たとえば、エンタープライズデータはエンタープライズデータの適用または使用に基づいて変化してもよく、一方、消費者アプリケーションについてのデータ(たとえば、消費者データ)は使用を通して静的なままであってもよい。ある実施形態では、エンタープライズデータは、そのエンタープライズデータを格納、使用、および/または管理するための基準を示すルールを含んでいてもよく、または当該ルールに関連付けられてもよい。たとえば、エンタープライズデータは、そのエンタープライズデータを格納、使用、および/または管理するための1つ以上のポリシーを示すポリシー情報に関連付けられてもよい。ある実施形態では、ポリシー情報は、エンタープライズデータに含まれていてもよい。ある実施形態では、エンタープライズデータは、エンタープライズコンピュータシステムにおいて実行されるアプリケーションまたはサービスによって処理、格納、使用、または通信されるデータを含んでいてもよい。たとえば、エンタープライズデータは、エンタープライズアプリケーションからのJSONフォーマット化データ、構造化データ(たとえば、キー値ペア)、非構造化データ(たとえば、アプリケーションによって処理または使用される内部データ、JSONフォーマットのデータ、ソーシャルポスト、会話ストリーム、アクティビティフィードなど)、バイナリラージオブジェクト(binary large object:BLOB)、文書、システムフォルダ(たとえば、サンドボックス環境におけるアプリケーション関連フォルダ)、REST手法を使用したデータ(ここでは「RESTfulなデータ」と呼ばれる)(たとえば、RESTエンドポイントによって利用可能にされる同期データ)、システムデータ、構成データ、同期データ、またはそれらの組合せ、といったビジネスデータ(たとえば、ビジネスオブジェクト)を含んでいてもよい。いくつかの実施形態では、エンタープライズデータは、RESTフォーマット化されたエンタープライズデータを含んでいてもよい。RESTフォーマット化されたエンタープライズデータは、RESTfulなデータを含んでいてもよい。RESTフォーマット化されたデータは、エンタープライズコンピュータシステムによって実現されるREST手法に従ってフォーマット化されたデータを含んでいてもよい。構成データまたは同期データは、バージョン、履歴、統合データなどといった、エンタープライズデータの同期のために使用されるデータを含んでいてもよい。エンタープライズデータにおける文書は、XMLファイル、ビジュアルアセット、構成ファイル、メディアアセットなどを含んでいてもよい。BLOBは、画像、マルチメディアオブジェクト、または実行可能コードといった、データベース管理システムにおける単一のエンティティとして、もしくは当該技術分野において他の態様で公知であるものとして格納された、バイナリデータの集合を含んでいてもよい。
【0086】
エンタープライズコンピュータシステムは、エンティティまたはエンタープライズのために動作するように構成されたさまざまなコンピューティングシステムを含んでいてもよい。たとえば、エンタープライズコンピュータシステムは、サービスについての要求を処理するための、エンタープライズサーバコンピュータ(たとえば、バックエンドサーバコンピュータ)といった1つ以上のコンピュータシステムを含んでいてもよい。エンタープライズコンピュータシステムは、エンタープライズデータを使用して処理および/または動作できるアプリケーションおよび/またはサービスを含んでいてもよい。たとえば、エンタープライズコンピュータシステム250は、エンタープライズを管理または動作させるための1つ以上のサービスおよび/またはアプリケーションを提供してもよい。サービスは、顧客関係管理(customer relationship management:CRM)、人的資本管理(human capital management:HCM)、人的資源(human resource:HR)管理、サプライチェーン管理、エンタープライズ通信、電子メール通信、ビジネスサービス、他のエンタープライズ管理サービスまたはアプリケーション、もしくはそれらの組合せを、制限なしで含んでいてもよい。エンタープライズコンピュータシステム250は、1つ以上のサービスを提供するための専用の1つ以上のコンピュータシステムを含んでいてもよい。いくつかの実施形態では、あるサービスを提供する異なる各コンピュータシステムが、エンタープライズの構内に位置していてもよく、またはエンタープライズからリモートに位置していてもよい。いくつかの実施形態では、異なるサービスをサポートする複数の異なるコンピュータシステムが、エンタープライズの構内といった単一の地理的場所に位置していてもよい。
図2に示す例では、構内エンタープライズコンピュータシステム250は、HRシステム254およびCRMシステム256を含んでいてもよく、それらは双方ともエンタープライズの構内に位置していてもよい。いくつかの実施形態では、エンタープライズコンピュータシステム250は、クラウドコンピュータシステム210と1つ以上のエンタープライズシステム254、256との間の通信を容易にし、または取扱うために、エージェントシステム252を含んでいてもよく、または実装してもよい。クラウドエンタープライズコンピュータシステム240および構内エンタープライズコンピュータシステム250などのエンタープライズコンピュータシステムについて、以下にさらに詳細に説明する。
【0087】
コンピュータ環境200は、コンピューティングデバイス202と1つ以上のエンタープライズコンピュータシステムとの間の通信を容易にし得るセキュアな仲介コンピューティング環境として動作するように実現されたMCS212を含んでいてもよい。なぜなら、コンピューティングデバイス202は、そのようなエンタープライズコンピュータシステムと通信するように構成されていないかもしれないためである。たとえば、いくつかのエンタープライズコンピュータシステムは、レガシーまたはバックエンドコンピュータシステムによってサポートされてもよい。そのようなシステムは、さまざまな通信および/またはセキュリティプロトコルを使用して動作するように構成されてもよい。そのようなエンタープライズコンピュータシステムによってサポートされるプロトコルは、モバイルコンピューティングデバイスによってサポートされるものとは異なっていてもよい。MCS212は、さまざまなタイプのモバイルコンピューティングデバイスとの通信をサポートしてもよい。そのため、MCS212は、エンタープライズコンピュータシステムとモバイルコンピューティングデバイスとの間の通信を容易にするための手法を実現して、それらが、フォーマットまたは通信プロトコル間の違いといった、通信におけるそれらの非互換性にもかかわらず、互いに通信できるようにしてもよい。たとえば、MCS212は、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間で通信プロトコルを翻訳してもよい。
【0088】
クラウドコンピュータシステム210は、MCS212をサポートしてもよい。クラウドコンピュータシステム210は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せを使用して実現されてもよい。たとえば、クラウドコンピュータシステム210は、サーバコンピュータなどの1つ以上のコンピューティングデバイスを含んでいてもよい。クラウドコンピュータシステム210は、1つ以上のメモリ記憶装置と、1つ以上のプロセッサとを含んでいてもよい。メモリ記憶装置は、プロセッサにアクセス可能であってもよく、そこに格納された命令を含んでいてもよく、命令は、プロセッサによって実行されると、プロセッサに、ここに開示された1つ以上の動作を実行させる。いくつかの実施形態では、メモリ記憶装置はローカルストレージ(たとえばキャッシュ)として動作してもよい。クラウドコンピュータシステム210は、さまざまな種類のオペレーティングシステムを含んでいてもよい。メモリ記憶装置は、プロセッサにアクセス可能であってもよく、そこに格納された命令を含んでいてもよく、命令は、プロセッサによって実行されると、プロセッサに、ここに開示された1つ以上の動作、方法、またはプロセスを実行させる。メモリ記憶装置はローカルストレージとして動作してもよい。ローカルストレージは、メモリ記憶装置または他のコンピュータ読取可能記憶媒体といった任意のタイプの永続的記憶装置を使用して実現されてもよい。いくつかの実施形態では、ローカルストレージは、1つ以上のデータベース(たとえば、文書データベース、リレーショナルデータベース、または他のタイプのデータベース)、1つ以上のファイルストア、1つ以上のファイルシステム、またはそれらの組合せを含んでいてもよく、もしくは実現してもよい。ローカルストレージはエンタープライズデータを格納してもよい。
【0089】
ある実施形態では、クラウドコンピュータシステム210は、メタデータリポジトリ224、診断ストア126、および解析ストア228といった、1つ以上のデータストアを含んでいてもよい。データストア224、226、228は、クラウドコンピュータシステム210におけるどのコンポーネントによってもアクセス可能であってもよい。
【0090】
メタデータリポジトリ224は、MCS212に関連付けられたメタデータをすべて格納してもよい。この情報は、利用可能性および性能に対する独自の要件を各々有する、実行時データおよび設計時データの双方で構成されてもよい。MCS212のテナントまたはサブスクライバは、任意の数のアプリケーションを有していてもよい。各アプリケーションはバージョン管理されてもよく、それらのリソースAPIが契約する、関連付けられたゼロ以上のバージョンのリソースAPIおよびゼロ以上のバージョンのサービス実装を有していてもよい。これらのエンティティは、仮想要求(mAPI)を具体的なサービス実装(サービス)にマッピングするために、実行時が使用するものである。このマッピングは、モバイル開発者が自分のアプリケーションを設計し構築する際に実際の実装サービスを知る必要がないという贅沢、および、サービスバグ修正ごとに新しいアプリケーションを再発行しなければならないとモバイル開発者に要求することもないという贅沢を、モバイル開発者に提供する。メタデータリポジトリ224は1つ以上の呼出し可能インターフェイスを格納してもよく、それらはコンピューティングデバイス(たとえばコンピューティングデバイス202)によって呼出されてもよい。呼出し可能インターフェイスは、MCS212との通信を容易にするように、アプリケーションのユーザ(たとえば開発者)によってカスタマイズ可能であってもよい。メタデータリポジトリ224は、呼出し可能インターフェイスの1つ以上の構成に対応するメタデータを格納してもよい。メタデータリポジトリ224は、呼出し可能インターフェイスを実現するためのメタデータを格納するように構成されてもよい。呼出し可能インターフェイスは、通信用の1つのフォーマット、プロトコル、またはアーキテクチャスタイルと、通信用の別のフォーマット、プロトコル、またはアーキテクチャのスタイルとの間で翻訳するように実現されてもよい。メタデータリポジトリ224は、認証されたユーザによって、外部ネットワークを介して修正可能であってもよい。
【0091】
診断ストア226は、MCS212において生じる処理についての診断情報を格納してもよい。診断ストア226は、MCS212を介して通信されるメッセージとログ情報とを格納してもよい。解析ストア228は、システムにおける処理中に取込まれたロギングおよび解析データを格納してもよい。
【0092】
MCS212のために、クラウドコンピュータシステム210は、そのコンピューティングリソースを利用して、カスタムコード216(たとえば、動作、アプリケーション、方法、機能、ルーチンなど)の実行を可能にしてもよい。コンピューティングリソースは、MCS212のサブスクライバまたはテナントとして関連付けられた特定のユーザに対して、使用のために割当てられてもよい。リソースは、ユーザ、デバイス、アプリケーション、または、サブスクライバに関連する他の基準に対して割当てられてもよい。MCS212は、エンタープライズコンピュータシステムと通信することを求めるモバイルコンピューティングデバイスの要望に依存して、スケールインまたはスケールアウトされてもよい。MCS212は、それが、モバイルコンピューティングデバイスとエンタープライズコンピュータシステムとの間の通常のトラフィックよりも大きいサージおよび一時的期間を取扱うために弾力的であるように構成され得る。いくつかの実施形態では、MCS212は、通信における要望を満足させるためにコンポーネントが追加または置換され得るようにスケーラビリティをサポートする要素を含んでいてもよい。
【0093】
コンピューティングデバイス202は、エンタープライズコンピュータシステムによって提供されるサービスを要求するためにMCS212と通信してもよい(たとえば、要求メッセージを送信してもよい)。コンピューティングデバイス202(たとえばモバイルコンピューティングデバイス)は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せを使用して実現されてもよい。コンピューティングデバイス202は、MCS212を介してエンタープライズコンピュータシステム240、250と通信してもよい。コンピューティングデバイス202は、エンドポイントデバイス、PDA、タブレットコンピュータ、ラップトップコンピュータ、モバイルコンピューティングデバイス、デスクトップコンピュータ、ウェアラブルコンピュータ、ページャなどを含んでいてもよく、または当該デバイスとして実現されてもよい。コンピューティングデバイス202は、1つ以上のメモリ記憶装置と、1つ以上のプロセッサとを含んでいてもよい。コンピューティングデバイス202は、さまざまな種類のオペレーティングシステムを含んでいてもよい。メモリ記憶装置は、プロセッサにアクセス可能であってもよく、そこに格納された命令を含んでいてもよく、命令は、プロセッサによって実行されると、プロセッサに、ここに開示された1つ以上の動作、方法、またはプロセスを実行させる。メモリ記憶装置はローカルストレージとして動作してもよい。ローカルストレージは、メモリ記憶装置または他のコンピュータ読取可能記憶媒体といった任意のタイプの永続的記憶装置を使用して実現されてもよい。いくつかの実施形態では、ローカルストレージは、1つ以上のデータベース(たとえば、文書データベース、リレーショナルデータベース、または他のタイプのデータベース)、1つ以上のファイルストア、1つ以上のファイルシステム、またはそれらの組合せを含んでいてもよく、もしくは実現してもよい。ローカルストレージはエンタープライズデータを格納してもよい。
【0094】
さまざまな実施形態では、コンピューティングデバイス202は、ウェブブラウザ、クライアントアプリケーション、専用クライアントアプリケーションといった1つ以上のアプリケーションを実行し、動作させるように構成されてもよい。アプリケーションは、エンタープライズコンピュータシステムによって提供されるエンタープライズデータおよび/またはサービスのために構成された特定のアプリケーションを含み得る。クライアントアプリケーションは、1つ以上のネットワークを介してアクセス可能であってもよく、または動作されてもよい。アプリケーションは、アプリケーションを動作させるためのグラフィカルUI(GUI)を含んでいてもよい。
【0095】
コンピューティングデバイス202は、無線通信を使用する1つ以上の通信ネットワークを介して、MCS212と通信してもよい。通信ネットワークの例は、モバイルネットワーク、無線ネットワーク、セルラーネットワーク、LAN、ワイドエリアネットワーク(wide area network:WAN)、他の無線通信ネットワーク、またはそれらの組合せを含んでいてもよい。ある実施形態では、コンピューティングデバイス202は、カスタム通信プロトコル(たとえばカスタムプロトコル)を使用して、MCS212との通信接続214を確立してもよい。接続214は、クラウドコンピュータシステム210を通してMCS212と確立されてもよい。カスタムプロトコルは、HTTPベースのプロトコルであってもよい。カスタム通信プロトコルを利用することにより、コンピューティングデバイス202は、任意のコンピューティングデバイスプラットフォーム上で動作して、クラウドコンピュータシステム210と通信してもよい。
【0096】
コンピューティングデバイス202は、1つ以上の呼出し可能インターフェイス、たとえばAPIを介して、クラウドコンピュータシステム210と通信してもよい。呼出し可能インターフェイスは、コンピューティングデバイス202上で実現されてもよい。呼出し可能インターフェイスは、カスタムアプリケーションがMCS212と通信できるようにするカスタムアプリケーションのために実現されてもよい。いくつかの実施形態では、呼出し可能インターフェイスは、MCS212のために開発されてもよい。呼出し可能インターフェイスは、アプリケーションが、プロトコル(たとえば、通信プロトコルもしくは開発プロトコル)および/またはアーキテクチャスタイルもしくはフォーマットの違いに適合する必要なく、MCS212と通信することを可能にしてもよい。
【0097】
MCS212は、要求を処理してカスタムコード216を実行するためのセキュアな環境を提供するために、1つ以上のファイアウォール204、230によって保護されてもよい。コンピューティングデバイス202とMCS212との間の通信は、外部通信ファイアウォール204によって分離されてもよい。ファイアウォール204は、MCS212へのセキュアなアクセスを容易にするために、クラウドコンピュータシステム210と接続されてもよい。ファイアウォール204は、クラウドコンピュータシステム210とコンピューティングデバイス(たとえばコンピューティングデバイス202)との間のメッセージの通信を許可してもよい。そのようなメッセージ(たとえば、HTTPメッセージまたはRESTメッセージ)は、呼出し可能インターフェイスによってサポートされ得る通信プロトコル(たとえば、HTTPまたはREST)に準拠していてもよい。別の例では、クラウドコンピュータシステム210とコンピューティングデバイス202との間のメッセージは、SPDYなどの通信プロトコルに準拠していてもよい。MCS212は、クラウドコンピュータシステム210とエンタープライズコンピュータシステム240、250との間の通信をセキュアにするために、ファイアウォール230を管理してもよい。ファイアウォール230は、クラウドコンピュータシステム210とコンピューティングデバイス(たとえばコンピューティングデバイス202)との間のメッセージの通信を許可してもよい。そのようなメッセージ(たとえば、SPDYメッセージ、HTTPメッセージ、またはRESTメッセージ)は、通信プロトコル(たとえば、SPDY、HTTP、またはREST)に準拠していてもよい。コンピューティングデバイス202とエンタープライズコンピュータシステム240、250との間の通信は、MCS212を介して双方向であってもよい。
【0098】
コンピューティングデバイス202およびエンタープライズコンピュータシステム240、250との通信は、セキュアでないパブリックネットワークを介して生じる場合があるため、ファイアウォール204、230は、MCS212へのおよびMCS212からの通信のための追加の保護層を提供する。ファイアウォール204、230は、MCS212が、その内部ネットワークと、コンピューティングデバイス202およびエンタープライズコンピュータシステム240、250を接続する外部ネットワークとを区別できるようにしてもよい。いくつかの実施形態では、ファイアウォール204、230は2つの別個のファイアウォールとして図示されているが、MCS212をカプセル化する単一のファイアウォールとして実現されてもよい。
【0099】
クラウドコンピュータシステム210はまた、一部が異なる通信プロトコルを有し得るエンタープライズコンピュータシステムと通信することによって、仲介コンピューティング環境として動作してもよい。そのような通信プロトコルは、クラウドコンピュータシステム210と通信しているアプリケーションまたはサービスに特化されたもの、または特有のものであってもよい。また、クラウドコンピュータシステム210は、エンタープライズコンピュータシステムと通信して、エンタープライズコンピュータシステムによってサポートされるフォーマットに従って、エンタープライズサービスを提供し、および/またはエンタープライズデータを交換してもよい。クラウドコンピュータシステム210は、エンタープライズデータのローカルストレージ(たとえば、ローカルキャッシュ)を維持してもよく、そのローカルストレージを使用して、モバイルコンピューティングデバイスとエンタープライズコンピュータシステム240、250との間のエンタープライズデータの同期を管理してもよい。
【0100】
コンピューティングデバイス202は、エンタープライズコンピュータシステムによって提供されるサービスを要求するために、MCS212と通信してもよい(たとえば、要求メッセージを送信してもよい)。ファイアウォール204を通って受信された要求はまず、セキュリティサービス232によって処理されてもよい。セキュリティサービス232は、要求に関連付けられたユーザについてのセキュリティ認証を管理してもよい。このため、クラウドコンピュータシステムは、顧客通信およびエンタープライズデータの完全性を保護し得る、ここに説明されるセキュリティメカニズムを提供することを含む技術的利点を提供してもよい。クラウドコンピュータシステムの技術的利点は、損なわれた通信および/またはデータが損なわれることを防止し、または低減させることを含んでいてもよく、認証が最初に起こって、要求されるクレデンシャルを有するものだけにアクセスを制限してもよい。クラウドコンピュータシステムの技術的利点は、要求が入ってくるとそれらはそれらが認可されているサービスにアクセスすることしかできないように、サービスおよびサービス呼出しフローが構造化されることを含んでいてもよい。システム処理の残りから認可を切り離すことにより、別の技術的利点は、「誰によって何が行なわれ得るか」を認可するタスクが、特定の企業顧客によっていかなる追加のカスタムセキュリティ手段が要求されてもそれをサポートするように拡張され得る専用のプロビジョニングされたセキュリティサブシステム(たとえばアイデンティティ管理システム)に委任されることを含んでいてもよい。いくつかの実施形態では、セキュリティ認証は、要求、セッション、ユーザ、デバイス、ユーザに関連する他の基準、またはそれらの組合せについて判断されてもよい。セキュリティ認証は、受信される要求ごとに行なわれてもよい。いくつかの実施形態では、セキュリティサービス232は、要求の以前の検証に基づいて認証を判断してもよい。セキュリティ認証は、異なるエンタープライズコンピュータシステム240、250への要求が単一のセキュリティ検証に基づいて認証され得るように、ユーザまたはデバイスについて判断されてもよい。
【0101】
この発明のさらなる技術的利点は、一部が異なったように実現され得るさまざまなエンタープライズコンピュータシステムとコンピューティングデバイスが通信することを、クラウドコンピュータシステムが可能にすることを含んでいてもよい。たとえば、コンピューティングデバイス202、クラウドコンピュータシステム210、およびエンタープライズコンピュータシステム250は、互いから物理的に分離された異なる地理的場所に位置していてもよい。したがって、コンピューティングデバイス202はエンタープライズコンピュータシステム250と、それらの位置にかかわらず通信することができる。技術的利点は、1つ以上の別個のセキュリティプロトコルをサポートし得るエンタープライズコンピュータシステムへコンピューティングデバイスがサービスについての要求を通信することを、クラウドコンピュータシステムが可能にすることを含んでいてもよい。場合によっては、エンタープライズコンピュータシステムは、異なるセキュリティプロトコルに容易に適合できないバックエンドシステムによってサポートされてもよい。場合によっては、アプリケーションの開発者が、そのようなセキュリティプロトコルの知識を持たずにサービスを要求できるようにアプリケーションを実現できることが、望ましいであろう。エンタープライズコンピュータシステムのユーザ(たとえば、管理者または設計者)が、異なるタイプのアプリケーション、セキュリティプロトコル、および規格に対処することなく要求を受信できることも、同等に望ましいであろう。技術的利点は、要求されているさまざまなエンタープライズコンピュータシステムのセキュリティ対策を要求が満たすことができるようにセキュリティ認証を取扱うことができる、ここに説明されるようなクラウドコンピュータシステムの実現によって、そのような要望が満たされることを可能にし得る。
【0102】
いくつかの実施形態では、セキュリティサービス232は、要求されたエンタープライズコンピュータシステムについてのセキュリティプロトコルを判断し、それに応じて、そのようなセキュリティプロトコルに従ったセキュリティトークンを生成してもよい。セキュリティトークンは、エンタープライズコンピュータシステムへ要求とともに渡されて、そのエンタープライズコンピュータシステムが生成されたセキュリティトークンに基づいて認証を検証することを可能にしてもよい。エンタープライズコンピュータシステムは、異なるセキュリティプロトコルをサポートしてもよい。セキュリティプロトコルは、セキュリティを判断するための規格であってもよい。セキュリティは、セキュリティサービス232によって生成されるセキュリティトークンに基づいて検証されてもよい。セキュリティサービス232は、要求について識別されるエンタープライズコンピュータシステム用のセキュリティプロトコルを判断してもよい。いくつかの実施形態では、エンタープライズコンピュータシステム250は、MCS212によってサポートされるカスタムのまたは特有のセキュリティプロトコルに従って構成または実現され得るエージェントシステム252を有していてもよい。そのため、MCS212は、そのようなカスタムセキュリティプロトコルに従ってセキュリティトークンを生成してもよい。
【0103】
クラウドコンピュータシステム210は、1つ以上の負荷分散システム206、208を含み、実現し、および/またはそれらと通信してもよい。セキュリティ認証を判断すると、クラウドコンピュータシステム210は、負荷分散システム206、208のうちのいずれか一方に、それが受信する要求を調べて、その要求がどのサービスに向けられているかを検出するよう、要求してもよい。MCS212は、負荷分散部206、208を用いて構成されてもよく、起動されたリソースを用いて更新されてもよく、そのため、要求が入ってくると、負荷分散部206、208は、要求される負荷を異なるリソースにわたって分散させることができる。
【0104】
クラウドコンピュータシステム210は、要求を取扱い、それらを適切なサービスへ発送し得るディスパッチャ218を含んでいてもよい。要求は、発送されると、適切なサービスへルーティングされてもよい。いくつかの実施形態では、サービス自体が、内部の要求を、MCS212またはエンタープライズコンピュータシステムにおける別の内部サービスへルーティングしてもよい。いくつかの実施形態では、ディスパッチャ218は要求を解決して、その宛先を、要求のURIおよび/またはURLにおいて識別される宛先の場所(たとえばアドレス)に基づいて判断してもよい。ディスパッチャ218は、要求およびそのヘッダを構文解析して、以下の情報、すなわち、テナント識別子、サービス識別子、アプリケーション名、アプリケーションバージョン、要求リソース、動作およびパラメータなどのうちの1つ以上を抽出してもよい。ディスパッチャ218は、構文解析された情報を使用して、メタデータリポジトリ224においてルックアップを行なうことができる。ディスパッチャ218は、対応するアプリケーションメタデータを検索してもよい。ディスパッチャ218は、要求されたリソースおよびメタデータにおけるマッピングに基づいて、ターゲットサービスを判断してもよい。メタデータは、最初は非常に基本的なマッピングであるが、より洗練された、ルールベースの発送を提供するために強化され得る。ディスパッチャ218は、ディスパッチャ特有の任意のロギング、メトリック収集などを行なってもよい。ディスパッチャ218は次に、アプリケーションメタデータに従って初期認可を行なってもよい。ディスパッチャ218は、インバウンド要求および任意の他の必要な情報をフォーマット化して、さらなる処理のためにメッセージをルーティングバス220上に配置してもよい。ディスパッチャ218は、要求をキュー上に配置して、対応する応答を待ってもよい。ディスパッチャ218は、ルーティングバス220から受信された応答を処理して、応答をコンピューティングデバイス202へ返してもよい。
【0105】
外部の要求に対する発送を取扱うことに加えて、ディスパッチャ218はまた、内部の要求を発送する役割を果たしてもよい。そのような内部の要求は、複合サービス、またはサービスへのカスタムコード呼出しの形で来る場合がある。いずれの場合も、呼出し側は、アプリケーション内で定義されるような論理サービス名を使用可能である。ディスパッチャ218は、現在の実行コンテキストを使用してアプリケーションを判断し、その論理名を使用して、呼出すべき適切なサービスを判断してもよい。
【0106】
クラウドコンピュータシステム210は、ルーティングバス220に登録された宛先へのメッセージの配信を管理するために、ルーティングバス220を含んでいてもよい。ルーティングバス220は、クラウドサービス212において通信を管理するための中央システムとして動作してもよい。ルーティングバス220を通して通信されたデータは、そのデータを取込んで格納するように処理されてもよい。ルーティングバス220は、追加の集中化サービス(追加の認可、デバッグなど)が必要に応じて容易にプラグインされ得るように、フレームワークを提供してもよい。ルーティングバス220によって取込まれたデータは、診断ストア226および/または解析ストア228に格納されてもよい。
【0107】
ルーティングバス220は、メッセージを1つ以上の宛先へルーティングしてもよい。いくつかの実施形態では、メッセージは、カスタムコード216を実行する要求を含んでいてもよい。そのような実施形態では、ルーティングバス220はカスタムコード216に、呼出されるよう要求してもよい(234)。いくつかの実施形態では、ルーティングバス220は、要求における情報によって識別される宛先エンタープライズコンピュータシステムへ、要求を渡してもよい。ルーティングバス220はアダプタインターフェイス222に、必要であれば翻訳を行なって、エンタープライズコンピュータシステム、たとえばエンタープライズコンピュータシステム240またはエンタープライズコンピュータシステム250へ要求を渡すよう、要求してもよい(236)。
【0108】
ある実施形態では、クラウドコンピュータシステム210は、メッセージを受信側エンタープライズコンピュータシステムによってサポートされるプロトコルに翻訳または変換するために、アダプタインターフェイス222を含んでいてもよく、または実装してもよい。アダプタインターフェイス222は、エンタープライズコンピュータシステム240、250の各々と、別々の通信接続を確立してもよい。クラウドコンピュータシステム210は、1つ以上のネットワーク(図示せず)を介してエンタープライズコンピュータシステム240、250と通信するように構成されてもよい。通信ネットワークの例は、インターネット、モバイルネットワーク、パブリックネットワーク、無線ネットワーク、セルラーネットワーク、LAN、WAN、他の通信ネットワーク、またはそれらの組合せを含んでいてもよい。ある実施形態では、通信接続は、高速通信トランクを使用して容易にされる高速通信接続であってもよい。エンタープライズコンピュータシステム240、250との通信は、外部ネットワークとの通信が、そのような通信を介するMCS212への不正アクセスを防止するようセキュアであることを保証する、ファイアウォール230を通過してもよい。
【0109】
いくつかの実施形態では、クラウドコンピュータシステム210は、コンピューティングデバイス202のユーザへの通知を容易にしてもよい。クラウドコンピュータシステム210は、たとえば、ユーザの好みに基づいて警告を1つ以上のチャネルを通して配信し、応答を待ち、その応答に基づいて行動するために、ユーザとのステートフルな対話をサポートする警告管理サービスを含んでいてもよい。1つのチャネル上で送信された警告への応答は、サービスが取扱うことができる必要のある別のチャネルを通して受信されてもよい。プラットフォームは、人気のある対話パターン用のビルトインの状態モデルを備えていてもよく、新しい状態モデルを用いて拡張可能であってもよい。いくつかの警告チャネルは、一方向または双方向の公知の通信リソースを含んでいてもよい。例は、SMS、ツイッター(登録商標)、プッシュ通知、およびグーグル・クラウド・メッセージング(登録商標)を含む。
【0110】
いくつかの実施形態では、クラウドコンピュータシステム210は、コンピューティングデバイスが、オブジェクトストアサービス、データベースサービス、アクセスウェブサービス、ソーシャルサービス、リソースサービス、またはそれらの組合せといった1つ以上のサービスにアクセスすること、および/または当該サービスを要求することを可能にしてもよい。
【0111】
クラウドコンピュータシステム210は、BLOB用のストレージ設備を提供し得るオブジェクトストアサービスを提供してもよい。ストレージの基本単位はテキストであってもよく、読出動作および書込動作を伴う。JSONオブジェクト用の基本クエリ設備も提供されてもよい。
【0112】
クラウドコンピュータシステム210は、クエリまたは書込を行なうためにホスト型データベースへの接続性を可能にするために、データベースサービスを提供してもよい。必要とされるパラメータ化は、データベースのための十分な接続ストリング、実行すべきSQLストリングまたは格納された手順、任意のパラメータおよびおそらくはクレデンシャルを必要とし得る。必要な情報は、実行時に提供され得るか、またはアプリケーションメタデータにおいて予め構成され得る。
【0113】
クラウドコンピュータシステム210は、SOAPウェブサービスなどのウェブサービスへのアクセスを提供してもよい。クラウドコンピュータシステム210は、任意のRESTリソースへの接続性といった、RESTサービスへのアクセスを提供してもよい。
【0114】
クラウドコンピュータシステム210は、フェースブック(登録商標)、ツイッター(登録商標)といった人気のあるソーシャルサイトの多くとの基本的統合を提供し得るソーシャルサービスへのアクセスを提供してもよい。これらのサービスは、それらのサイトからのユーザのクレデンシャルを使用した第三者認証、およびそれらのサービスへのアクセスを可能にしてもよい。例は、ツイートを送信すること、または自分のステータスを更新することを含む。
【0115】
クラウドコンピュータシステム210は、ユーザが通信を単純化し最適化することができるように、パブリッククラウドサービスを提供してもよい。たとえば、サービス開発者は、クラウドコンピュータシステム210のクラウドサービスを使用してホストされるリソースと、MCS212の包括的ウェブサービスを使用して通信してもよい。
【0116】
ここに説明されるもののようなクラウドコンピュータシステムは、コンピューティングリソースの違いにもかかわらず、モバイルコンピューティングデバイスがエンタープライズコンピュータシステムと通信することを可能にしてもよい。クラウドコンピュータシステムは、頻繁に通信してエンタープライズデータを受信するために、より多くのリソース、および、エンタープライズコンピュータシステムとのより高速で信頼性のある接続を備えていてもよい。クラウドコンピュータシステムは、エンタープライズコンピュータシステムからのサービスについての要求を管理し、調整してもよい。要求をメッセージの受信側によってサポートされるプロトコルに翻訳することにより、クラウドコンピュータシステムは、異なるタイプのバックエンドコンピュータシステムとの通信用のアプリケーションを構成するための開発者の負担を低減する。エンタープライズは、モバイルデバイス用にサポートされる通信プロトコルの進歩または変化に対処する必要なく、それらのバックエンドシステムを維持することができる。異なるエンタープライズコンピュータシステムは、処理される要求および提供されるサービスのタイプに基づいて、異なるセキュリティプロトコルをサポートしてもよい。異なるエンタープライズコンピュータシステムへのアクセスのために集中化された態様でセキュリティ認証を管理することにより、エンタープライズコンピュータシステムは、セキュリティプロトコルの違いに適合しなくてもよい。クラウドコンピュータシステムのユーザを認証することにより、要求の処理はより効率的になり得る。なぜなら、認証はすべてのインスタンスで行なわれるとは限らないためである。
【0117】
いくつかの実施形態では、アプリケーションは、当該アプリケーションへのアクセスを制御して極秘データの暗号化を保証するためのビルトインセキュリティを提供するモバイルアプリケーションフレームワーク(mobile application framework:MAF)、たとえばオラクル社からのオラクルMAF(Oracle MAF)などの下でデプロイメントされてもよい。MAFは、(ウェブビューにおいてUIをレンダリングするための)HTML5およびカスケーディング・スタイル・シート(Cascading Style Sheet:CSS)、(アプリケーションビジネスロジックのための)Java、および(GPSアクティビティおよび電子メールなどのデバイス特徴にアクセスするための)アパッチ・コルドバを使用する、ハイブリッドモバイルアーキテクチャである。MAFはこれらのクロスプラットフォーム手法を使用しているため、アンドロイドデバイスおよびiOSデバイス双方のために、プラットフォーム特有のツールを使用する必要なく、同じアプリケーションを構築することができる。アプリケーションがデバイスにデプロイメントされた後、当該アプリケーションは、オブジェクティブCまたはアンドロイドSDKなどのプラットフォーム特有のツールを使用して作成されたアプリケーションとして挙動する。また、MAFは、スマートフォンまたはタブレットのために同じアプリケーションを構築することを可能にし、それにより、同じアプリケーションにおけるビジネスロジックの再使用を可能にし、さまざまなタイプのデバイス、画面サイズ、および能力をターゲットとする。
【0118】
図3は、「重い(heavy)」アプリケーション(たとえば、アップストアから取得された通常のiPhone「アプリ」と同じ態様でモバイルデバイスに搭載されるモバイルアプリケーション)としてデプロイメントされた「WorkBetter」と呼ばれるMAFアプリケーション302を含む、モバイルアプリケーションスプリングボード300の一例を示す。MAFアプリケーションは、アプリケーション特徴として追加される1つ以上の埋込み型アプリケーションを含んでいてもよい。そのような追加されるアプリケーション特徴は、メインアプリケーションのスプリングボードまたはナビゲーションバー内のアイコンとして表わされる。アプリケーション特徴は本質的に、そのようなモバイルアプリケーションの構築ブロックである。MAFアプリケーションへ統合されている各アプリケーション特徴は、特定の一組のタスクを行なう。アプリケーション特徴は、互いの機能性を補完するためにともにグループ化され得る。たとえば、顧客連絡先を提供するアプリケーション特徴は、製品在庫についてのアプリケーション特徴と対にされてもよい。各アプリケーション特徴はそれ自体のクラスローダおよびウェブビューを有しているため、アプリケーション特徴は互いから独立しており、このため、いくつかの異なる開発チームによって作成されたアプリケーション特徴から、単一のMAFアプリケーションを組み立てることができる。アプリケーション特徴はまた、他のMAFアプリケーションにおいて再使用可能である。MAFアプリケーション自体は、別のアプリケーション用のベースとして再使用可能であり、独立系ソフトウェアベンダー(independent software vendor:ISV)が、特定の顧客によって構成可能なアプリケーションを作成することを可能にする。
【0119】
デバイス上でローカルで実行されるハイブリッドモバイルアプリケーションに加えて、アプリケーション特徴は、モバイルアプリケーションおよび利用可能なリソースの要件に依存して、以下のモバイルアプリケーションタイプのうちのいずれかとして実現されてもよい:
・サーバ上でホストされるモバイルウェブアプリケーションについては、コードはプラットフォーム間でポータブルであり得るが、これらのアプリケーションはデバイスのブラウザによって管理されるため、デバイス特徴およびローカルストレージへのアクセスは制限され得る;
・固有アプリケーションは、Xcodeで、またはアンドロイドSDKを通してオーサリングされており、そのため、双方のプラットフォームのために機能するという点で制限される。コードの再利用も同様に制限される。
【0120】
MAFは、アプリケーションにおける特徴レベルでの改良されたセキュリティのための認証およびアクセス制御をサポートし、開発者は、適切なログインサーバ、たとえば、基本的な認証を用いて「オラクルアイデンティティ管理」(Oracle Identity Management)および/または「Oracle WebLogic」を実行するサーバ、OAuthプロトコルをサポートするサーバなどを指定できる。実行時、ユーザにはログイン画面が提示され、適切なトークンが、さらなるウェブサービス呼出しのためにアクセス可能である。MAFにより、開発者は、さまざまな特権を有するユーザの必要性を満たす(たとえば、ユーザの役割または特権に基づいてコンポーネントを示す/隠す)個々のUIを構築することができる。
【0121】
MAFは、SSL/TLS(HTTPセキュア(HTTPS))を使用する通信暗号化、オフライン認証をサポートする際に検証のために使用されるべきクレデンシャルを暗号化されたキーストアに保持するためのオンデバイス暗号化、および、SQLite暗号化拡張を使用することによるSQLiteデータベース暗号化を実施する。MAFで構築されたアプリケーションのためにSQLiteデータベースを暗号化することは、当該アプリケーションが開発される際に構成オプションを介して行なわれてもよい。いくつかの実施形態では、MAFは、アプリケーションのためのオフラインおよびオンライン動作モードをサポートし、そのため、自立型のアプリケーションがモバイルデバイス上で接続モードおよび非接続モードで実行可能である。データアクセス/格納のために、そのようなアプリケーションは、ローカルの暗号化されたSQLiteデータベースを利用してもよい。当該アプリケーションは、データへの最初のアクセスがウェブサービスを通してリモートサーバから行なわれ、次にデータがオフラインアクセスのためにローカルのSQLiteデータベースに格納されるように、構築されてもよい。接続性が再び利用可能になると、データは複製されてサーバと同期され得る。MAFはまた、セキュアにされたアプリケーションへのオフライン認証/認可を可能にするように、ユーザ認証クレデンシャルのローカルストレージをサポートする。
【0122】
図3Aおよび
図3Bは、本発明の一実施形態に従ったHRモバイルアプリケーションUI304を示す。UI304は、
図3のモバイルアプリケーションスプリングボード300などのスプリングボード上でアイコンを開くと提供されてもよい。
図3Aでは、UI304は、ある従業員についてのさまざまなHR関連情報、たとえば、写真、役職、連絡先情報、ソーシャルネットワーキング情報、業績/格付け情報、報酬情報、マネージャ、スキル、位置などを含む。
図3Bは、UI304における情報が取得され得るさまざまなソース、たとえば構内またはクラウドに位置するサービスを示す。たとえば、基本的な従業員情報は、PeopleSoft、システムズ、アプリケーションおよび製品(Systems, Applications & Product:SAP)などの構内コアHRサービス306から取得されてもよく、一方、位置情報は、グーグルなどのマップサービス308から取得される。同様に、業績情報は、TALEOなどの才能管理クラウドサービス310から取得されてもよく、ソーシャルネットワーキング情報312(たとえば、ツイッター、フェースブック、LinkedInなど)はウェブから取得されてもよい。一実施形態では、これらのさまざまなソースからの情報は、MCS212(
図2参照)を通されてから、モバイルデバイス202(
図2参照)上のアプリケーションまで送信される。
【0123】
図4は、一実施例に従ったMAF実行時アーキテクチャ400のブロック図である。実行時アーキテクチャ400は、モバイルデバイス404にデプロイメントされた「薄型(thin)」のデバイス固有コンテナ402を含む。実行時アーキテクチャ400は、モデル層およびコントローラロジックからプレゼンテーションを分離するMVC開発アプローチを表わす。デバイス固有コンテナ402は、MAFアプリケーションが、ローカルのSQLiteデータベース406(SQLite408を介する)、モバイルデバイスサービス426(アパッチ・コルドバ410のコルドバAPIを介する)、ならびに、構成サーバ444、サーバ生成HTML430、プッシュサービス448、およびウェブサービス440などのサーバ側リソース412と対話することにより、さまざまなプラットフォーム(たとえばiOS、アンドロイドなど)上の固有アプリケーションとして機能することを可能にする。
【0124】
デバイスサービス426は、カメラ、GPS、電子メールなどといった、デバイス404に固有のサービスおよび特徴である。構成サーバ444は、アプリケーション構成サービスによって使用されるウェブ分散オーサリングおよびバージョン管理(Web Distributed Authoring and Versioning:WebDav)およびホスティング構成ファイルに基づいたサーバである。WebDavは、たとえば、インターネット・エンジニアリング・タスク・フォース(Internet Engineering Task Force:IETF)コメント要求(Request for Comments:RFC)4918において定義される。構成サーバ444は、リファレンス実装として提供される。Java2プラットフォーム、エンタープライス・エディション(Java 2 Platform, Enterprise Edition:J2EE)サーバ上でホストされるどの通常のWebDavサービスも、この目的のために使用可能である。サーバ生成HTML430は、リモートサーバ上でホストされ、ブラウザベースのアプリケーション特徴のために使用される、ウェブコンテンツを含む。プッシュサービス448は、たとえば、通知イベントをMAFアプリケーションへ送信する通知プロバイダである、アップルプッシュ通知サービス(Apple Push Notification Service:APN)およびグーグル・クラウド・メッセージング(Google Cloud Messaging:GCM)プッシュサービスを含んでいてもよい。Webサービス440は、たとえば、リモートでホストされるSOAPベースのウェブサービスである。
【0125】
デバイス固有コンテナ402は、モバイルデバイスのウェブエンジンを使用してウェブベースのコンテンツを表示して処理するウェブビュー416を含む。MAFアプリケーションでは、ウェブビュー416は、アプリケーションマークアップをHTML5としてレンダリングすることによってUIを提供する。UIは、以下のコンテンツタイプのうちのいずれか、すなわち、MAFアプリケーションモバイルXML(Application Mobile XML:AMX)ビュー420、コントローラ422、ローカルHTML424、またはサーバHTML428を実現することにより、モバイルアプリケーション特徴のために作成されてもよい。MAF AMXビュー420、コントローラ422、およびローカルHTML424は、HTML5およびJavaScriptプレゼンテーション418を提供する。さまざまなコンテンツタイプから実現されるアプリケーション特徴は、同じモバイルアプリケーション内で共存可能であり、かつ互いと対話することができる。
【0126】
MAF AMXビュー420として実現されるコンテンツを有するアプリケーションはデバイス404上に常駐しており、デバイスのプラットフォームに特有の言語でオーサリングされるアプリケーションと同様の、最も信頼性のあるデバイス固有のユーザ体験を提供する。MAFは、ユーザが、モバイルデバイスのフォームファクタに適合されたコンポーネントからUIを宣言的に作成することを可能にする、一組のコードエディタを提供する。これらのコンポーネントは、ページレイアウト(たとえばリストビュー)および入力コンポーネント(たとえば入力フィールド)を作成するために使用され得る。ユーザがMAF AMXビュー420を開発する際、ユーザは、ユーザがデータにバインドされたUIコンポーネントを宣言的に作成し、ウェブサービスおよびモバイルデバイスのサービス(たとえばカメラ、GPSまたは電子メール)にアクセスすることを可能にする、データ制御を利用することができる。実行時、ウェブビュー416におけるJavaScriptエンジンが、MAF AMXビュー定義をHTML5およびJavaScriptにレンダリングする。
【0127】
コントローラ422として実現されるコンテンツを有するアプリケーションについては、コントローラ422は、モバイルアプリケーションにおけるページ間のフローを管理する。コントローラ422は、ユーザがアプリケーションのフローをより小さい再使用可能タスクフローに分解し、方法呼出しおよび判定ポイントなどの非視覚的コンポーネントを含めることを可能にする。
図4の実施形態では、コントローラ422はMAF AMXビュー420に含まれており、たとえば、ページを移行させ、および/またはアクションを起動するために、MAF AMXビュー420によって呼出される。しかしながら、代替的な実施形態では、コントローラ422は、MAF AMXビュー420のピアとして実現されてもよい。
【0128】
ローカルHTML424として実現されるコンテンツを有するアプリケーションについては、HTMLページは、MAFアプリケーションの一部としてデバイス上で実行される。ローカルHTMLファイルは、アパッチ・コルドバ410およびJavaScript APIを通して、デバイス固有の特徴およびサービスにアクセスすることができる。
【0129】
サーバHTML428として実現されるコンテンツを有するアプリケーションについては、UIは、アプリケーション特徴のウェブビュー416内で開くことができるサーバ生成ウェブページ(サーバ生成HTML430)から提供される。MAFのコンテキスト内では、このコンテンツタイプはリモートURLと呼ばれる。これらのブラウザベースのアプリケーションのためのリソースは、デバイス404上に常駐していない。代わりに、UI、ページフローロジック、およびビジネスロジックは、リモートサーバから提供される。
【0130】
リモートでホストされるこれらのウェブアプリケーションのうちの1つがウェブビュー416内で開くことが許可されると、それは、コルドバJavaScript APIを使用して、カメラまたはGPS能力といった任意の指定されたデバイス固有の特徴またはサービスにアクセスすることができる。リモートのURLコンテンツを使用してアプリケーションを実現する場合、ユーザは、モバイル用途のために最適化された既存のブラウザベースのアプリケーションを利用するか、または、特定のタイプのモバイルデバイスのために具体的に書かれたアプリケーションを使用することができる。デスクトップまたはタブレット上のブラウザ内で実行可能なアプリケーションについては、ユーザは、オラクル社からの「オラクルADFフェース」(Oracle ADF Faces)によって提供されるもののようなリッチクライアントベースのコンポーネントを通して作成されたアプリケーションを使用して、リモートのURLコンテンツを実現することができる。具体的に携帯電話をターゲットとするアプリケーションについては、リモートのURLコンテンツは、MAFを使用して作成されたウェブページから提供され得る。MAFでオーサリングされたアプリケーションは、さまざまなスマートフォン上でレンダリングできるだけではなく、アパッチ・トリニダード(Apache Trinidad)JSFコンポーネントおよび動的に選択されたスタイルシートで構築されたUIを通して、フィーチャーフォン上で利用可能な低下した能力にまで優雅に質を低下させることができる。コンテンツがリモートで供給されるため、アプリケーションは、サーバ接続がアクティブなままである限りにおいてのみ、利用可能である。
【0131】
デバイス固有コンテナ402はさらに、デバイス固有の特徴およびサービスをモバイルアプリケーションに統合するJavaScript APIを提供する、アパッチ・コルドバ410を含む。ユーザは、Javaコードからプログラムによって(または、MAFモバイルアプリケーションをローカルHTML424として実現する場合には、JavaScriptを使用して)これらのAPIにアクセスすることができるが、ユーザは、MAF AMXページを作成する際にデバイス統合を宣言的に追加することができる。なぜなら、MAFはこれらのAPIをデータ制御としてパッケージングするためである。
【0132】
デバイス固有コンテナ402はさらに、Java仮想マシン(Java Virtual Machine:JVM)432を含む。Javaは、MAFアプリケーションのためのJava実行時環境を提供する。JVM432は、デバイス固有のコードで実現され、固有アプリケーションバイナリの一部としてMAFアプリケーションの各インスタンスに埋込まれる(またはコンパイルされる)。JVM432は、Javaプラットフォーム、マイクロ・エディション(Java ME)接続デバイス構成(Connected Device Configuration:CDC)仕様に基づいている。実行時アーキテクチャ400では、JVM432は、ビジネスロジック434と、モデル436と、Javaデータベース接続性(Java database connectivity:JDBC)438とを含む。Javaは、MAFアプリケーションにおいてビジネスロジック434を可能にする。管理ビーン(Managed Beans:MBeans)とは、サーバから返されたデータを処理するための追加のビジネスロジックを提供するといった、MAFの能力を拡張するために作成され得るJavaクラスである。MBeansは、埋込み型Javaサポートによって実行され、JavaME CDC仕様に準拠する。モデル436は、ビジネスロジックコンポーネントをUIと接続するバインディング層を含む。加えて、バインディング層は、リモートでホストされるSOAPベースのウェブサービスなどのウェブサービス440を呼出すために、実行ロジックを提供する。これらのサービスは、Java層(JVM432)を通してアクセスされる。MAF AMXにおいてオーサリングされるアプリケーション特徴は、データ制御を通してSOAPベースのデータサービスにアクセスする。JDBC438は、モデル層が、作成、読取り、更新、削除(Create, Read, Update and Delete:CRUD)動作を通して、暗号化されたSQLiteデータベース406におけるデータにアクセスすることを可能にするAPIである。
【0133】
デバイス固有コンテナ402はさらにアプリケーション構成442を含み、それは、ウェブサービス用のURLエンドポイントまたは構成サーバ444のリモートURL接続などのアプリケーション構成がダウンロードされてリフレッシュされることを可能にするサービスを指す。アプリケーション構成サービスは、サーバ側のWebDavベースのサービスから構成情報をダウンロードする。
【0134】
デバイス固有コンテナ402はさらに、クレデンシャル管理、シングルサインオン(Single Sign-on:SSO)、およびアクセス制御を提供するモジュール446を含む。MAFは、「オラクルアクセス管理モバイルおよびソーシャル」(Oracle Access Management Mobile and Social:OAMMS)アイデンティティマネージャ(identity manager:IDM)SDKを通して、ユーザ認証およびクレデンシャル管理を取扱う。MAFアプリケーションは、オフライン認証を行なう。これは、接続中にユーザがアプリケーションにログインすると、MAFがユーザ名およびパスワードをデバイス404上でローカルに維持し、それにより、認証サーバへの接続が利用できなくなっても、ユーザがアプリケーションに引き続きアクセスできるようにすることを意味する。MAFは、ローカルのSQLiteデータベース406に格納されたデータだけでなく、ローカルに格納されたユーザ情報も暗号化する。ログインサーバに対して認証した後、ユーザは、その接続によってセキュアにされたアプリケーション特徴のすべてにアクセスすることができる。MAFはまた、ユーザの役割および特権を適用することによってアプリケーション特徴(またはアプリケーション特徴の特定の機能)へのアクセスを制限することにより、アクセス制御の概念をサポートする。リモートで供給されるウェブコンテンツについては、MAFはホワイトリストを使用して、意図されたURIだけがアプリケーション特徴のウェブビュー416内で開くことができること(およびデバイス特徴にアクセスできること)を保証する。
【0135】
デバイス固有コンテナ402はまた、サーバ側リソース412に含まれるプッシュサービス448と通信し、MAFアプリケーションがiOSまたはアンドロイドの通知サーバなどの通知サーバからイベントを受信することを可能にするプッシュハンドラ414を介したプッシュ通知を可能にする。Java層(JVM432)は通知処理を取扱う。
【0136】
実行時アーキテクチャ400では、デバイス固有コンテナ402は暗号化SQLiteデータベース406と対話し、それは、ローカルに格納されたデータを保護し、JDBC438を使用してモデル層によって呼出される、埋込み型SQLiteデータベースである。MAFアプリケーションは、この軽量のクロスプラットフォームリレーショナルデータベース406を生成する。データベース406は暗号化されているため、デバイスが紛失または盗難された場合でも、それはデータをセキュアにする。正確なユーザ名およびパスワードを入力するユーザだけが、このデータベースにおけるデータにアクセスできる。
【0137】
図5は、本発明の実施形態に従った、モバイルクラウドインフラストラクチャにおいてモバイルアプリケーションを開発するためのシステム500のブロック図である。システム500では、ユーザは、ユーザデバイス528を使用して、ウェブベースのツールを介してクラウドインフラストラクチャ506においてアプリケーションを開発し、構築してもよい。一実施形態では、アプリケーションはモバイルデバイス526上に無線でダウンロードされてもよく、このため、アップストアの必要性をなくす。固有アプリケーションは、MCS502において作成されたバックエンド504と通信する。一実施形態では、モバイルデバイス526にアプリケーションを提供するために、
図4のMAF実行時アーキテクチャ400が使用されてもよい。一実施形態では、アプリケーションの宣言的構文がモバイルデバイス526上に無線でデプロイメントされ、その宣言的構文は、
図4のMAF実行時アーキテクチャ400によって、モバイルデバイス526上で解釈される。
【0138】
クラウドインフラストラクチャ506は、アプリケーション開発が行なわれ得る管理(admin)UI516を提供するMCS502を含む。MCS502はさらに、モバイルアプリケーションが開発され得る生産環境512と、モバイルアプリケーションがテストされ得るテスト環境514とを含む。これらの環境は、コネクタを介して対応するバックエンド504と通信することにより、生産/テスト機能性を提供する。アプリケーションはまず、テスト環境514で開発される。当該アプリケーションは、いったん発行されると、生産環境512へ移動する。
【0139】
一実施形態では、モバイルアプリケーションは、ユーザデバイス528を使用してセキュリティ層524を通してMCS管理UI516(ポータルとも呼ばれる)と通信することによって開発される。MCS管理UI516は、MCS管理UI516を介してインターフェイス接続され得るアプリケーション開発サーバ518を含む。MCS管理UI516において開発されるアプリケーションは、生産環境512および/またはテスト環境514と通信することにより、ユーザデバイス528のブラウザ上で、またはモバイルデバイス526上で実行され得る。一実施形態では、アプリケーションがモバイルデバイス526上にデプロイメントされると、モバイルデバイス526はテスト環境514と通信する。しかしながら、アプリケーションがモバイルデバイス526上で更新される場合、そのような更新はMCS管理UI516を介して行なわれる。
【0140】
システム500において開発されるアプリケーションは、軽いアプリケーションまたは重いアプリケーションとして構築されてもよい。重いアプリケーションとは、アップストアからダウンロードされるアプリなどの完全なアプリケーションである。軽いアプリケーションとは、オラクルアプリなどの、すでにデプロイメントされている完全なアプリケーション(すなわちホスティングアプリケーション)への追加特徴としてデプロイメントされるアプリケーションである。ホスティングアプリケーションは、軽いアプリケーションを保持するコンテナとして作用する。重いアプリケーションおよび軽いアプリケーションはともに、
図7を参照してここに説明されるセキュリティコンテナによってさらにコンテナ化され得る。
【0141】
図6は、本発明の実施形態に従った、モバイルアプリケーションを構築するためのシステム600におけるネットワークコンポーネントのブロック図である。システム600では、第1のデバイス602が、構築要求を開始するためにMCSウェブサイト(
図6の例示的な実施形態では「https://mcs-tenant-a.cloud.oracle.com」として示される)と対話し、第2のデバイス604が、固有アプリケーションの無線インストールを行なうために当該MCSウェブサイトと通信する。一般に、無線インストールは、アプリケーションと、対応するアプリケーションアーカイブファイル(拡張子「.ipa」を有し、アプリケーションを格納するファイル)をダウンロードするべき位置とを記述する、プロパティリストファイル(拡張子「.plist」を有する「p−リスト」ファイル)などのファイルをダウンロードすることと、次に、その位置からアプリケーションアーカイブファイルをダウンロードすることとを含む。
【0142】
第1のデバイス602および第2のデバイス604は、パブリックオラクルHTTPサーバ(Oracle HTTP Server:OHS)606を通してサーバ610のMCSポータルVM612と通信することにより、MCSウェブサイトと対話する。パブリックOHS606は、ファイアウォール608の背後に位置するMCSポータルVM612へトラフィックを向けるパブリックフェイシングオラクルHTTPサーバである。パブリックOHS606は、オラクル・アクセス・マネージャ(Oracle Access Manager:OAM)用のウェブサーバプラグインであるウェブゲート(WebGate)を実現して、HTTP要求を遮り、それらを認証および認可のために対応するアクセスサーバへ発送する。したがって、パブリックOHS606は、第1のデバイス602のユーザを認証し、ユーザクレデンシャルをMCSポータルVM612へ渡し、第1のデバイス602とのSSL接続を終了させる。
図6の例示的な実施形態では、第1のデバイス602および第2のデバイス604は、httpsのためにポート443が使用される「https://mcs-tenant-a.cloud.oracle.com」で、パブリックOHS606にアクセスする。
【0143】
MCSポータルVM612は、スキーマサービス614における単一のテナントスキーマによって支援されるデータを有する標準的なウェブロジック・サーバ(WebLogic Server:WLS)アプリケーションであり、その対応するアプリケーション開発クライアントは、オラクル・ジャンプスタート・エンタープライズ・ツールキット(Oracle Jumpstart Enterprise Toolkit:JET)フレームワークを使用して書かれる。ウェブロジック・サーバは、オラクル社によって開発されたJavaEEアプリケーションサーバである。データベーススキーマとは、オブジェクト(たとえば、テーブル、ビュー、格納された手順など)のコンテナであり、それらを論理的にグループ化する。
【0144】
MCSポータルVM612は単一のテナントであり、そのセキュリティは、(
図7を参照してここに説明されるオラクル・ウェブ・サービシーズ・マネージャ(Oracle Web Services Manager:OWSM)を介して提供される。したがって、MCSポータルVM612は、信頼されたゾーンにおいてWLSを実行させる。MCSポータルVM612は、第1のデバイス602による要求を取扱い、スキーマサービス614への接続を有する。MCSポータルVM612はまた、負荷分散部616を介して構築サーバファーム618に接続される。
図6の実施形態では、MCSポータルVM612は、パブリックOHS606への/からの、負荷分散部616への、および、サーバファーム618における個々のサーバからのhttp通信のために、開ポート80(または同等物)を使用する。
【0145】
スキーマサービス614はMCSポータルVM612と対話して、アプリケーションデータ、エンタープライズ署名証明書、および、テナントについてのプロビジョニングプロファイルを格納する。負荷分散部616は、ファームタスクをサーバファーム618におけるサーバへルーティングする。ルーティングは最初に総当たり方式で行なわれてもよい。
図6の実施形態では、負荷分散部616は、開ポート80(または同等物)を使用して冗長性を提供する、F5社(F5 Corp.)からのBIG−IP機器である。サーバファーム618は、構築ジョブを取扱う多くのサーバ(たとえば20個のサーバ)を含む。それは、アプリケーションバイナリ(たとえば5TB)を格納するためのファイラ(図示せず)に接続される。一実施形態では、サーバファーム618の接続は、サーバ上でローカルに実行されるローカルのTomcatインスタンスによって取扱われ、構築ツールおよびプロセスは、固有のOSX呼出しによって取扱われる。
【0146】
アプリケーションの構築
一実施形態では、第1のデバイス602のユーザがいったんアプリケーションを作成し、固有のバイナリを生成することを所望している場合、ユーザは、第1のデバイス602のUIを介して、MCSウェブサイトで(たとえば「https://mcs-tenant-a.cloud.oracle.com/max/build」で)構築POST要求を開始する。POSTとは、ウェブサーバに要求メッセージの本体に入れられたデータを受け入れて格納するよう要求するための、HTTPプロトコルによってサポートされる要求方法である。構築POST要求のペイロードは、アプリケーションのためのアプリケーション識別子(id)を含む。パブリックOHS606は要求を受信し、SSLを終了させ、(ユーザがログインすると仮定して)OAMに対してユーザを認証および認可し、ユーザアイデンティティを要求のHTTPヘッダに配置し、要求を、ファイアウォール608を通過させてMCSポータルVM612のWLSサーバ(たとえば、「http://mcs-tenant-a.internal/max/build」で実行されるWLSサーバ)へ発送する。
【0147】
MCSポータルVM612は要求を受信し、要求されたアプリケーションに対する特権についてユーザを認可し、アプリケーションデータ、テナントエンタープライズ証明書、暗号化された証明書パスワード、およびテナントプロビジョニングプロファイルについてテナントスキーマサービス614へクエリを送信する。スキーマサービス614が要求されたアイテムをいったん返すと、MCSポータルVM612は、(スキーマサービス614に格納された)構築ジョブのテーブルにおいて新しいエントリを作成して、構築の試みを記録し、対応する新しい構築記録の主キーを取込む。MCSポータルVM612はまた、(たとえば「http://max-mini-farm.internal/build/initiate」にある)負荷分散部616の背後の構築サーバファーム618に対して新しいPOST要求を作成して、対応するパラメータ(アプリケーションデータ、署名証明書およびパスワード、ならびにプロビジョニングプロファイル)を、要求の本文へ、およびジョブ完了のためのコールバックURLへ渡し、コールバックURLは、構築ジョブのテーブルにおいて対応する構築記録の主キーをコード化する。以下の機能性は、対応するパラメータを含む構築POST要求ペイロードの一例を提供する。
【0149】
この例では、証明書およびパスワードは、この実施形態に従ってモバイルアプリケーションを構築するためだけに、第1のデバイス602のユーザによって作成され(すなわち、証明書およびパスワードは、この実施形態に従ったモバイルアプリケーションの構築以外のサービスと共有されない)、ポート3000は公的にアクセス可能ではない。
【0150】
負荷分散部616は、サーバファーム618における健全なサーバのリストを維持する。一実施形態では、これは、ある時間間隔で(たとえば、数分ごとに)サニティチェックを行なう健全性チェックを介して行なわれる。構築ジョブ要求を受信すると、負荷分散部616は、リストにおける健全なサーバプールからあるサーバを選択し、構築ジョブ要求をそのサーバへルーティングする(たとえば、ジョブを「http://mac-mini1.internal/build/initiate」へルーティングする)。一実施形態では、ジョブを選択することは、等しい複雑性の構築ジョブのための総当たりプロセスに従う。
【0151】
一実施形態では、サーバファーム618における選択されたサーバ上で、Tomcatウェブサーバが実行されている。Tomcatウェブサーバは構築ジョブ要求を受信して、入力/出力が要求スレッドプールをブロックするのを防ぐために非同期サーブレット上で実行される外部プロセスを開始させる。プロセスが完了すると、Tomcatウェブサーバは、要求ペイロードにおいてコールバックURLへのPOST要求を作成する。以下の機能性は、この新しい要求のための例示的なペイロードを提供する。
【0153】
MCSポータルVM612は新しい要求を受信し、イベントが成功した場合には、構築ジョブのテーブルにおける対応する記録を、ペイロードからのバイナリキーで更新する。それはまた、(たとえば、オラクル・ビジネス・インテリジェンス・エンタープライズ・エディション(Oracle Business Intelligence Enterprise Edition:OBIEE)12cが計画された、OBIEE11gプッシュまたは非同期サーブレット上でのポーリングを介して)構築ジョブが完了したことをクライアント(すなわち第1のデバイス602)に通知し、アプリケーションをダウンロードするためのコード化されたリンクを有するQRコードを生成する(たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/(binaryKey)」)。
【0154】
アプリケーションのインストール
一実施形態では、第2のデバイス604のユーザがいったん第2のデバイス604上のQRコードをスキャンすると、「無線」インストールが開始される。QRコードのスキャンにより、QRコードにおいてコード化されたURLが開かれる(たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/(binaryKey)」)。パブリックOHS606は要求を受信し、SSLを終了させ、(ユーザがログインすると仮定して)OAMに対してユーザを認証および認可し、ユーザアイデンティティを要求のHTTPヘッダに配置し、要求を、ファイアウォール608を通過させてMCSポータルVM612のWLSサーバ(たとえば、「http://mcs-tenant-a.internal/max/build」で実行されるWLSサーバ)へ発送する。
【0155】
MCSポータルVM612は要求を受信し、要求されたアプリケーションに対する特権についてユーザを認可し、要求元デバイス(第2のデバイス604)のユーザエージェント(このコンテキストでは、デバイスのOSフレームワーク、たとえばiOS対アンドロイド)を判断し、第2のデバイス604のプラットフォーム(たとえばiOS)を識別し、要求を、パブリックOHS606に向けることによって、対応するURL(たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/plist/(binaryKey)」)へ発送する。パブリックOHS606は次に、(ユーザがアプリケーションをダウンロードすることを許可されることを保証するために、ここに説明される構築プロセス中に行なわれるように)認可するために、要求をMCSポータルVM612へ発送するであろう。MCSポータルVM612は発送された要求を受信し、プロパティリストファイル(たとえばiOS「p−list」ファイル)を生成する。当該ファイルは、対応するプラットフォーム(たとえばiPhone)についてのアプリケーション情報と、バイナリへのリンク(たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/ios/(binaryKey)」)とを含む。
【0156】
第2のデバイス604は次に、アプリケーションをインストールしたいかどうか、ユーザを促す。インストールしたいと仮定して、第2のデバイス604は、パブリックOHS606に向けることによって、バイナリへのリンク(たとえば、「https://mcs-tenant-a.cloud.oracle.com/max/native-application/ios/(binaryKey)」)に従い、パブリックOHS606は次に、(ユーザがアプリケーションをダウンロードすることを許可されることを保証するために、ここに説明される構築プロセス中に行なわれるように)認可するために、要望をMCSポータルVM612へ発送するであろう。MCSポータルVM612は要求を受信し、負荷分散部616の背後の(たとえば「http://max-mini-farm.internal/download/ios/(binaryKey)」にある)構築サーバファーム618への新しい構築ジョブ要求を生成する。負荷分散部616は、健全なサーバプールから(たとえば総当たりプロセスを介して)構築サーバファーム618におけるあるサーバを選択し、構築ジョブ要求をそのサーバへ(たとえば「http://mac-mini1.internal/download/ios/(binaryKey)」へ)ルーティングする。選択されたサーバ上のアプリケーションサーバ(たとえば、Tomcat)が要求を受信し、対応するコンテンツが存在するかどうかを判断し、ネットワークから(たとえば、「Filer:/filer_mnt/generated_binaries/(binaryKey)/result.ipa」から)バイナリをストリーミングする。負荷分散部616は、ストリーミングされた応答をMCSポータルVM612へ返し、MCSポータルVM612は応答を受信し、それを第2のデバイス604へのその要求の出力ストリームにコピーする。最後に、第2のデバイス604はバイナリを受信してインストールを行なう。
【0157】
図7は、OMSSなどのモバイルセキュリティスイート700によって提供されるセキュリティサービスを使用する一実施形態におけるモバイルセキュリティスイートコンポーネントのブロック図である。OMSSコンポーネントは、企業DMZ740およびエンタープライズイントラネット(または企業ネットワーク750)にわたって分散される。OMSSの下で、オラクル社からの「オラクル・モバイル・セキュリティ・コンテナ」などのセキュリティコンテナ706が、モバイルデバイス702にインストールされ、「コンテナ化された」アプリケーション708、たとえば、それらの特定のコンテナにセキュアにリンクされたアプリケーションを保持するように構成される。モバイルデバイス702はまた、セキュリティコンテナ706の外部で保持された他のパーソナルアプリケーション704を含んでいてもよい。
【0158】
セキュリティコンテナ706は、セキュアウェブブラウザ712と、ファイルマネージャ(図示せず)と、文書エディタ(図示せず)と、オプションのセキュアモバイルメールマネージャ710とを含む。セキュアモバイルメールマネージャ710は、「マイクロソフト・エクスチェンジ・アクティブシンク」(Microsoft Exchange ActiveSync:EAS)プロトコルを介して企業メールサーバと同期するメールクライアント、カレンダ、連絡先、タスク、およびメモなどの個人情報管理(personal information management:PIM)アプリケーションを含む。「オラクル・ビジネス・インテリジェンス」(Business Intelligence:BI)、「オラクル・フュージョン・タップ」、「オラクル・ソーシャル・ネットワーク」、「オラクル・エンタープライズ・マネージャ・クラウド制御」、「オラクル・ウェブセンター・スペース」などの多くのアプリケーション、および広範囲の第三者エンタープライズアプリケーションが、セキュリティコンテナ706でコンテナ化され得る。モバイルデバイス702上のコンテナ化されたアプリケーション708の内部にあるすべてのデータが暗号化される。暗号化されたデータストレージは、データベース、ファイルストア、キャッシュ、およびユーザの好みを含む。セキュリティコンテナ706は、企業DMZ740の背後の企業ネットワーク750と通信するために、(その開示全体がここに援用される米国特許第8,332,464号に記載されているような)「AppTunnel」714などのセキュアチャネルを使用する。一実施形態では、AppTunnel714を通して移行されるデータは、連邦情報処理規格(Federal Information Processing Standard:FIPS)が承認したアルゴリズムでTLS/SSLを使用して暗号化される。
【0159】
一実施形態では、ウェブブラウザまたは他のクライアントプログラムがオラクル社からの「オラクル・モバイル・セキュリティ・アクセス・サーバ」(Oracle Mobile Security Access Server:MSAS)などのセキュリティアクセスサーバに未認証の要求を行なうと、セキュリティアクセスサーバは、適切なセキュリティコンテナへの転送で応答する。セキュリティコンテナは、データを保護するためにキー階層を使用する。すべてのキーは、格納されていないユーザクレデンシャルから導き出される。キー階層は、データのさまざまな感度をサポートするための複数のキーを必要とする。たとえば、ある固有キーは、極めて短期間だけ開くことが許可されるユーザの認証証明書のために使用される。別のキーは、セッション全体について復号化されたままでなければならないブラウザキャッシュのために使用される。主セキュリティコンテナは、ユーザのセキュアなエンタープライズワークスペースにおける完全な一組のアプリのためのキーを分散させ、管理する。
【0160】
セキュアコンテナ706は、従来のモバイル仮想プライベートネットワーク(virtual private network:VPN)ソリューションに勝る少なくとも3つの独特の利点、すなわち、デバイストラスト対ゲートウェイ、セキュアコンテナパスワード対デバイスパスワード、および、セキュアコンテナAppTunnel対デバイスレベルVPNを有する。OMSSは、ネットワークのケルベロス認証トラストを、DMZに搭載されているゲートウェイサーバで止めるのではなく、ユーザのデバイスまで直接延長する。OMSSは、VPNプロバイダによって提供される「制約付き委任」を実現する場合に比べ、著しくより効率的でより安全である。制約付き委任ソリューションは、安全性がより低いだけでなく、設定して維持するのがより面倒である。また、消費者デバイスおよびBYODプログラムを扱う際に、有用性とセキュリティとの間のトレードオフが大きくなる。企業ITは、BYODデバイス上の企業データを保護するために強力なパスワードを要求する。逆に、ユーザは、ソーシャルネットワークおよび他の消費者アプリケーションに容易にアクセスできるように、単純なパスワードを所望するか、または、好ましくはデバイスパスワードが全くないことを所望する。デバイスパスワードを要求することは、ユーザにとっては苛立たしい。なぜなら、ユーザは常に、エンタープライズ認証を必要としない非エンタープライズ目的のためにデバイスを使用しているためである。実施形態は、企業アプリケーションにアクセスするためだけにパスワードを要求することにより、BYODプログラムを扱う際のセキュリティと有用性との間の必要なバランスを提供する。
【0161】
さらに、デバイスレベルVPNは、ユーザのデバイスとエンタープライズのネットワークとの間に信頼できるセキュアなトンネルを提供する。しかしながら、デバイスレベルVPNソリューションは、消費者モバイルデバイスよりも、ラップトップなどの企業所有のセキュアなエンドポイントデバイスにとって、より適切である。モバイルデバイスVPNトンネルがネットワークまでいったん開通すると、デバイス上のどのアプリケーションもこのセキュアなトンネルへのアクセスを有し、著しいセキュリティ脆弱性をもたらす。しかしながら、実施形態によれば、モバイルデバイス702からエンタープライズイントラネット750への接続は、セキュアコンテナ706とエンタープライズサーバとの間にのみ存在する。
【0162】
モバイルセキュリティスイート700では、MSAS716が典型的には企業DMZ740にデプロイメントされており、複数のサーバインスタンスが、高い可用性およびスケーラビリティのために負荷分散部の背後にデプロイメントされ得る。MSAS716は、サーバとコンテナ化されたアプリ708との間にトンネル接続を提供する。MSAS716は認証を仲介し(強力な認証が、「オラクル・アクセス・マネージャ」(Oracle Access Manager:OAM)722へのHTTPS接続、またはケルベロスドメインコントローラ718へのケルベロス接続を利用する)、それらの宛先(ウェブアプリケーションおよびウェブサービス724といった、企業イントラネット750におけるリソース)のためのSSOを認可し、監査し、有効にするとともに、当該宛先への要求をプロキシする。MSAS716は、セキュリティコンテナ706およびコンテナ化されたアプリケーション708によって開始されたトンネル型接続の終端エンドポイントとして機能する。
【0163】
MSAS716は、セキュリティ、脅威からの保護、およびスロットリングポリシーを組織のREST APIインフラストラクチャに追加するために、オラクル社からの「オラクルAPIゲートウェイ」(Oracle API Gateway:OAG)およびオラクル社からのOWSMをサポートする。SSOは、OAuth、OAMトークン、ケルベロス、およびNT LANマネージャ(NT LAN Manager:NTLM)を通してサポートされる。SAMLは、オラクル(カリフォルニア州)またはピン・アイデンティティ(Ping Identity)などのSAMLアイデンティティプロバイダとのOAM722またはケルベロス統合を通してサポートされる。MSAS716は、OAMプラットフォームと統合され、OAM、OAG、およびOWSMによって保護されたバックエンドリソースへのSSOのためのOAMおよびOAuthのトークンの検索をサポートする。MSAS716はまた、PINによって保護されたマイクロソフト・アクティブ・ディレクトリへのパブリックキーインフラストラクチャ(public key infrastructure:PKI)認証を行なうことにより、「仮想スマートカード」認証をサポートする。デジタル証明書はセキュリティコンテナアプリ内にプロビジョニングされ、PIN検証が成功した後にのみアクセスされる。OAMとのMSAS統合は、コンテキスト認識型でリスクベースのステップアップ認証を可能にする。
【0164】
モバイルセキュリティスイート700はまた、SOAスイートのコンポーネントであってウェブサービスベースのSOAセキュリティおよび管理に対処する、OWSMを実装する。SOAインフラストラクチャの目的は、消費者が、プロバイダによって公開されたサービスを呼出すことを可能にすることである。OWSMは、そのようなサービスインフラストラクチャのポリシー管理およびセキュリティのためのソリューションを提供する。それは、オラクル社からの「オラクル・エンタープライズ・マネージャ」によって提供される集中型管理インターフェイスを通して、ポリシーの可視性および制御を提供する。OWSMは、会社が、(1)SOAインフラストラクチャを構成する複数のウェブサービスに適用された宣言的ポリシーを集中的に定義して格納すること、(2)構成可能エージェントを通してセキュリティおよび管理ポリシーをローカルに実施すること、および、(3)失敗した認証または認可などの実行時セキュリティイベントを監視すること、を可能にする。それはまた、実行中のビジネスプロセスを中断する必要なく、ポリシー変更がリアルタイムで実施されるようにすることによって、セキュリティ脅威およびセキュリティ違反に対応するためのビジネスアジリティ(business agility)を提供する。
【0165】
モバイルセキュリティスイート700はまた、企業ネットワーク750内に「オラクル・モバイル・セキュリティ・マネージャ」(Oracle Mobile Security Manager:MSM)を実装する。MSM720は、オラクルLinuxまたはレッド・ハット・エンタープライズ(Red Hat Enterprise)Linux上で実行される「WebLogic」管理型サーバである。MSM720は、企業ネットワーク750におけるマイクロソフトエクスチェンジサーバ728と統合して、企業電子メールサービスへのアクセスを提供する。MSM720はまた、LDAPサーバ732と統合して、ユーザをプロビジョニングし、モバイルデバイス管理のためのおよびセキュリティコンテナ706にアクセスするためのポリシーを割当てて管理し、アプリカタログを管理し、デバイスのリモートロックまたはワイプを制御してワークスペースアプリをセキュアにし(セキュリティコンテナ706をワイプすることは、ワークスペースアプリについてのデータおよび構成をすべて削除する)、セキュリティコンテナのためのアクセス制御ポリシーを設定する。ポリシーは、ポリシーテンプレートをユーザおよびユーザグループに関連付けることによって、ユーザに割当てられる。利用可能なポリシー制御は、デバイス制限、認証(認証頻度、失敗した試みのしきい値、PKIのためのPIN強度)、カタログ(アプリ、URL、ファイル共有)、コンテナ/アプリ(損なわれたプラットフォーム、位置サービス、オフラインステータス、非活動期間、データリーク防止(data leak prevention:DLP))、時間アクセス(時間窓外の場合にロックする)、地理的アクセス(Geo Access)(地理的フェンス(市、州、国)外の場合にロックする)、デバイス(特定のデバイスモデルをホワイトリストに載せる、最小OSレベルを特定する)、ブラウザ(アドレスバーを無効にする、ダウンロードを無効にする)、ファイルブラウザ(ダウンロードを許可/却下、無効にする、ファイルサーバURLを指定する)、個人情報マネージャ(personal information manager:PIM、メールサーバURL)、プロビジョニング(テンプレート、PKI詳細を勧める)などを含む。ユーザが複数のグループにいて複数のポリシーを有する場合、ポリシーの組合せは特定のルールに従って解決される。
【0166】
MSM720はEMMポリシーを維持し、それらは次に、ディレクトリにおける1つ以上のユーザグループに関連付けられる。MSM720は、ユーザ管理またはグループ管理を行なわないが、これらのアイデンティティおよびグループをディレクトリストアから直接(同期なしで)利用する。MSM720は、HTTPSに対してAPNSおよびCGNを使用して、デバイスへ通知を送信する。MSM720はまた、内部のCIFS/SMB対応ファイルシステム730または「マイクロソフト・シェアポイント(SharePoint)サーバ」にWebDAVフロントエンドを公開して、クライアントからのイントラネットファイル共有をブラウジングすることを可能にする。
【0167】
ソーシャルネットワーク上にますます多くの組織が存在を確立すると、IT部門は、ソーシャルアイデンティティのためのサポートを必要とする。ソーシャルアイデンティティは、エンタープライズアイデンティティよりも軽量のセキュリティ基準に依拠するものの、ソーシャルネットワークの要件により良好に適合されている。たとえば、いくつかのウェブサイトは、ユーザが、それらのサービスに認証されるために、フェースブックまたはグーグルから取得されたアクセストークンを提供することを要求する場合がある。したがって、モバイルセキュリティスイート700はまた、既存のバックエンドアイデンティティ管理インフラストラクチャとインターフェイス接続するサーバを含むOAMMSを実装する。サーバは、サポートされたモバイルクライアントアプリとバックエンドアイデンティティサービスとの間の仲介主体として作用する。これにより、クライアントアプリはバックエンドインフラストラクチャから分離され、そのため、モバイルクライアントプログラムを更新する必要なく、バックエンドインフラストラクチャを修正することができる。OAMMSは、以下の機能性を含む:
・OAuth規格を利用する委任された認可;
・エンタープライズアイデンティティ管理インフラストラクチャ、典型的には「オラクルアクセス管理プラットフォーム」に、ブラウザベース(HTML5)および固有のモバイルアプリを接続するモバイルサービス;
・グーグル、Yahoo、フェースブック、ツイッター、またはLinkedInといった、人気のあるクラウドベースのアイデンティティ認証および認可サービスと対話する際に、OAMMSを信頼できる当事者として使用させるインターネットアイデンティティサービス。OAMMSをデプロイメントすることにより、ユーザには、アイデンティティプロバイダごとにアクセス機能を個々に実現する必要なく、複数のログインオプションが提供される。LDAP CRUD動作のためのRESTインターフェイスを提供するユーザプロファイルサービス(顧客は、アプリ用のグラフィカルUIを構築するために同じRESTインターフェイスを使用する);自己登録、プロファイルメンテナンス、パスワード管理、およびアカウント削除などのユーザのセルフサービス機能。ユーザプロファイルサービスは、OAuthリソースとしても利用可能である;
・エージェントSDKによって提供される実行時RESTインターフェイスを通してOAM722を利用するためのアクセス管理統合サービス。
【0168】
図8は、本発明の実施形態に従ったモバイルアプリケーション開発のためのフロー図である。一実施形態では、
図8(および以下に説明される
図10)のフロー図の機能性は、メモリもしくは他のコンピュータ読取可能媒体または有形媒体に格納され、プロセッサによって実行される、ソフトウェアによって実現される。他の実施形態では、機能性は、ハードウェアによって(たとえば、特定用途向け集積回路(application specific integrated circuit:ASIC)、プログラマブルゲートアレイ(programmable gate array:PGA)、フィールドプログラマブルゲートアレイ(field programmable gate array:FPGA)などの使用を通して)、またはハードウェアとソフトウェアとの任意の組合せによって、行なわれてもよい。クラウドベースのモバイルアプリケーション開発の一例が、「モバイル実行時のための解釈されたアーチファクトの生成のためのクラウドベースのエディタ」(CLOUD BASED EDITOR FOR GENERATION OF INTERPRETED ARTIFACTS FOR MOBILE RUNTIME)と題された、2015年6月29日に出願された米国仮出願第62/186,080号(代理人明細書No.:88325−924721(165701US)、クライアント参照No.:ORA150600−US−PSP)に提供されており、当該仮出願の開示はここに引用により援用される。
【0169】
810で、アプリケーション定義ウィザードが生成される。ここに使用されるようなアプリケーション定義ウィザードは、1つ以上の予め定義されたクラウドアクセス可能なサービスを利用するモバイルアプリケーションの定義プロセス中にユーザを誘導する一組の1つ以上のUIを表わす。アプリケーション定義ウィザードは、アプリケーション定義プロセスの一部に各々関連付けられた、1つ以上のワークフローを実現することができる。一実施形態では、アプリケーション定義ウィザードは、アプリケーション識別子プレフィックス、デフォルトアイコン、スプラッシュスクリーン、デフォルトアプリケーション/特徴テンプレート、設定エンタープライズプロビジョニングプロファイル/キーストアなどのアプリケーションデフォルトを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。
【0170】
ある実施形態では、アプリケーション定義ウィザードは、アプリケーション名、フォームファクタ(電話またはタブレットデバイスなど)、ナビゲーションタイプ(たとえば、スプリングボード、ナビゲーションバー(navigation bar:NavBar)、スプリング/Navコンボなどとして、単一の特徴またはUIを意味しないもの)、および任意のアプリケーションの好みを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。
【0171】
820で、アプリケーション定義が受信される。ここに説明されるように、アプリケーション定義は、少なくとも最小限機能的なモバイルアプリケーションを作成するために必要とされるあらゆる情報を含み得る。830で、アプリケーション定義に基づいてモバイルアプリケーションが生成される。一実施形態では、モバイルアプリケーションは、ターゲットデバイスのシミュレータにおいて表わされ、解釈時にコンパイルされたモバイルアプリケーションとして機能する一組の定義を含み得る。
【0172】
840で、特徴選択ウィザードが生成される。ここに使用されるような特徴選択ウィザードは、1つ以上の予め定義されたクラウドアクセス可能なサービスを利用するモバイルアプリケーションの開発プロセス中にユーザを誘導する一組の1つ以上のUIを表わす。特徴選択ウィザードは、アプリケーション開発プロセスの一部に各々関連付けられた、1つ以上のワークフローを実現することができる。一実施形態では、特徴選択ウィザードは、モバイルアプリケーションとともに使用可能な特徴、UIモジュール、ビジネスオブジェクトなどを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。
【0173】
ある実施形態では、特徴選択ウィザードは、モバイルアプリケーションの第1の画面のコンポーネントを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。コンポーネントは、コンポーネントのカタログから選択され得る。
【0174】
ある実施形態では、特徴選択ウィザードは、モバイルアプリケーションの他の画面のコンポーネントを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。これらの他の画面は、1つ以上のUIモジュールの一部を形成することができる。ある実施形態では、特徴選択ウィザードは、モバイルアプリケーションの1つ以上のUIモジュールを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。UIモジュールは、モバイルアプリケーションに対して行なわれ得るプロセッサ、タスク、またはフローを表わす。UIモジュールは、UI要素およびページフローの結束した集合を提供する一組のテンプレートまたはUIモジュールのカタログから選択され得る。UIモジュールのいくつかの例は、承認ワークフロー、ワーカータスク、データ入力タスク、レポートビルダなどである。テンプレートは、一組のUI要素からなる予め設定された配置/バインディングを提供するため、ユーザは、個々のUI要素を配置およびバインドする必要なく、それらのUI要素を構成してテンプレートをバインドするだけでよい。一実施形態では、ユーザは、自分のテンプレートを、別のユーザにとって利用可能なテンプレートのセットに与えてもよい。ユーザは、UIモジュールを表わす一連のページを構成するかまたは他の態様で指定することができる。ページごとに、従来と同様に一組のレイアウトテンプレートをユーザに提示することができる。各レイアウトテンプレートは、二次的テンプレートを選択するなどのいくつかの局面を有していてもよい。
【0175】
いくつかの実施形態では、特徴選択ウィザードは、予め定義されたビジネスオブジェクトといった、モバイルアプリケーションの追加特徴を指定するよう、ユーザを促すかまたは他の態様で誘導することができる。ユーザは、バックエンドサービス、API、またはコネクタのうちのどのリソースが、使用されるべきか、または、各コンポーネント、画面、UIモジュールなどのUI要素に他の態様で関連付けられるべきかを指定することができる。
【0176】
850で、特徴定義が受信され、860で、データバインディングウィザードが生成される。ここに使用されるようなデータバインディングウィザードは、1つ以上の予め定義されたクラウドアクセス可能なサービスを利用するモバイルアプリケーションのデータバインディングプロセス中にユーザを誘導する一組の1つ以上のUI、または既存のUIのUI要素を表わす。データバインディングウィザードは、アプリケーション開発プロセスの一部に各々関連付けられた、1つ以上のワークフローを実現することができる。一実施形態では、データバインディングウィザードは、特徴、画面、UIモジュールなどが、モバイルアプリケーションとともに使用可能なビジネスオブジェクト、サービス、APIなどにどのようにバインドされるかを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。ある実施形態では、データバインディングウィザードは、モバイルアプリケーションのビジネスオブジェクトを指定するよう、ユーザを促すかまたは他の態様で誘導することができる。ビジネスオブジェクトは、モバイルアプリケーションにとって利用可能なサービス、APIなどのカタログまたはセットから選択され得る。
【0177】
870で、データバインディング定義が受信される。さまざまな実施形態では、ステップ840〜870は、連続して、または並行に行なわれ得る。840〜870における個々のステップは、モバイルアプリケーションの個々の要素に対して、または要素のグループに行なわれ得る。図示されるように、ユーザは、モバイルアプリケーションを作成するために特徴定義およびデータバインディングのプロセスを繰返すことができる。
【0178】
880で、モバイルアプリケーションがデプロイメントされる。ユーザは、ターゲットデバイス上にデプロイメントされたテスト用アプリケーションを使用して、またはターゲットデバイス上にデプロイメントされた固有アプリケーションとして、アプリケーションをテストすることができる。
【0179】
トランザクション自動保存
現在、ほとんどのウェブアプリケーションでは、ユーザによって行なわれる明示的な保存アクションはない。代わりに、アプリケーションがそのコンテンツをユーザに代わって自動保存する。したがって、アプリケーションは、ある保存境界がいつ生じるかを判断し、次に、それに応じて自動保存を行なう必要がある。保存境界とは、アプリケーションの自動保存をトリガするように構成された条件(たとえば、時間インスタンス/間隔、ユーザアクション、アプリケーション変数値、アプリケーション/システムイベントなど)である。
【0180】
いくつかの公知のシステムは、単純な時間ベースの制御機能性に基づいて自動保存を行なう(たとえば、ある設定時間の後で自動保存する)が、より論理的な保存境界を必要とするアンドゥ/リドゥアクションの場合には理想的ではない。いくつかの公知のシステムは、ユーザがアクションを行なうと自動保存がトリガされる、アクションベースの境界を使用する。これらのシステムは、アンドゥ/リドゥアクションに応答して自動保存機能性を提供できるが、自動保存をいつ行なうか、および、同じユーザアクションに結び付けられるモデル変更をどのように調整するかを判断することについて複雑性の増加をもたらし得る。たとえば、ユーザが画面上の何らかのテキストをバックエンドサービスにバインドする場合、UI定義ファイルおよびバインディング定義ファイルにそれぞれの変更が行なわれ、これらのファイルの各々は、それらのそれぞれのモデルによって修正される。したがって、アンドゥ/リドゥアクションによってトリガされる自動保存を提供することは、これらのモデル変更の調整を必要とし、それは複雑性の増加をもたらす。モデルとは、画面上のUIコンポーネントを記述する宣言的構文を含むページスキーマなどの、実データに対する抽象化である「信頼できる情報源(source of truth)」である。
【0181】
さらに、性能およびデータの完全性に関し、クライアントは、保存アクションが無事行なわれたかどうかをサーバに確認する必要があり、そのため、クライアントは、それが保存アクションを再試行する必要があるかどうかを知っている。いくつかの公知のシステムは、サーバ応答を待ってから、さらなるユーザ入力を可能にする。しかしながら、この待機はユーザへのUIをブロックし、サーバへの接続が遅い場合には性能を著しく損なう。いくつかの公知のシステムはサーバを待たず、クライアントUIをブロックしない。しかしながら、サーバが故障した場合、サーバとクライアントとの間の状態がもはや整合しないため、クライアントは回復できないことが多い。
【0182】
対照的に、実施形態は、ユーザアクションをクライアント上の特定のモデル変更と相関させ、対応するアクションベースの保存境界を提供しつつ、データ完全性を保証する、トランザクションシステムを実現する。加えて、実施形態は、保存アクションのためにサーバ応答を待つ必要がない(そのため、クライアントUIをブロックしない)。その上、保存アクションを試みる間にサーバエラーが起こった場合には自己回復を可能にする。
【0183】
一実施形態は、クライアント側モデルに影響を与えるユーザアクションによってトリガされるクライアント側トランザクションを定義する。トランザクションとは、単一のユーザアクションによって生じる一連の関連する変更である。たとえば、UI定義ファイルおよびバインディング定義ファイルに変更が行なわれることを要求する、画面上の何らかのテキストをバックエンドサービスにバインドするユーザアクションについて、これらのファイルの各々についてそれぞれのモデル変更を適用する代わりに、一実施形態は、これらのモデル双方への変更を含むトランザクションを取込み、当該トランザクションを使用して自動保存機能性をサポートする。
【0184】
一実施形態では、モデルが修正されると、変更記録が現在のトランザクションに追加される。ユーザアクションの完了後、トランザクションはコミットされ、修正は変更記録に記録される。モデルの一例は、現在の画面上のUIコンポーネントを記述する宣言的構文であるページスキーマである。このモデルは、画面を定義する拡張可能マークアップ言語(extensible markup language:XML)コードを操作するアプリケーションプログラミングインターフェイス(API)として実現されてもよい。このモデルについての例示的なモデル変更は、以下のとおりである:
【0186】
ここで、「some_component」はページモデルにおけるUIコンポーネントであり、変更は、スタイル属性をレッドにするよう修正することである。このモデルについての例示的なトランザクションは、ユーザがボタンをクリックすることによって生じ得る一連のモデル変更(たとえば、ページスキーマおよび対応するバインディングへの前述の変更)である。このモデルについて自動保存アクションをトリガするように構成され得るユーザアクションの例は、ボタンを押下すること、何らかのテキストを入力すること、UIの何らかのピースをドラッグ・アンド・ドロップすること、などといったユーザジェスチャーである。たとえば、あるアプリケーションを開発するために「新規アプリケーションウィザード」を完了させると、ユーザは当該アプリケーションおよびその画面モデルを修正してもよく、ユーザが当該アプリケーションの開発を終了するために「終了」ボタンを押すと、自動保存がトリガされ得る。
【0187】
一実施形態は、ローカルコンテンツをサーバのリモート持続ストアに自動保存するための保存境界を定義する。持続ストアとは、データを長期間格納するストレージ(たとえば、ファイルシステム、データベースなど)である。この実施形態は、2つの別個のキュー上に2つの別個のライフサイクルを実現する。変更記録はまず、変更をローカルモデルにコミットするために、ローカルキュー上のローカルライフサイクルに適用される。このライフサイクルは非常に速く起こり、クライアントUIがこれらの変更をほぼ瞬間的に反映することを可能にする。変更記録は、それらがサーバへ送信されるためにリモートキューに入れられているリモートライフサイクルの下でも実行される。リモートキューとは、サーバのリモート持続ストアに格納されるものを管理する持続キューである。リモートキュー上に入れられた変更記録は、それらが作成された順序でサーバへ「同期して」送信される。すなわち、一実施形態では、リモートキュー上の変更記録は一度に1つずつ処理され、各変更記録は、前の変更記録がサーバ上に無事記録された場合のみ、サーバへ送信される。これは、変更の順序がサーバで維持されることを保証する。
【0188】
サーバへの変更を保存する保存要求が失敗すると、実施形態は、それらがキューに入れられた保存要求をそこから再送する必要がある、リモートキューのポイントを認識する。したがって、実施形態は、リモートキューにおける失敗した記録を再試行し、それから、次の記録を続ける。サーバ不良が続く場合、実施形態はオフラインモードへ移行して、リモートライフサイクル上に変更記録を記録し続ける。これらの記録は次に、サーバとの接続が復元された場合、またはサーバの不安定性が補正された場合に、正しい順序でサーバに保存される。
【0189】
ほぼ瞬間的なUI更新を可能にすることにより、実施形態は、データ完全性を犠牲にすることなく、クライアントUI性能を向上させる。たとえば、ユーザによって行なわれるアクション(複合アーチファクトを作成するといった、複雑なアクションを含む)が、ユーザのために直ちに完了される。また、サーバ保存は同期しているため、実施形態はサーバ停止を取扱うことができ、データが失われず、コンテンツがサーバとの最終的な整合性を有するであろうということを保証できる。
【0190】
一実施形態では、ユーザアクションがトリガされると、トランザクションが作成され、アクションが完了すると、コミットされるかまたはロールバックされる。アクションは、システムがそのアクションの結果を処理し終えたときに完了する。これらの2つのイベント(ユーザアクション、およびユーザアクションの完了)の合間に、モデル変更が、ユーザアクションに応答して起こり得る。たとえば、ユーザアクションがボタンを押下することである場合、システムはそのような押下に応答し、アクションは、システムが押下の処理を完了したときに完了する。たとえば、ページのある部分に新しい属性を追加するためにボタンが押下されたものの、その属性を追加することは違法であると考えられる場合、トランザクションはキャンセルされる。一方、属性が実際に合法である場合には、トランザクションはコミットされる。
【0191】
別の例として、ユーザが「ドラッグ・アンド・ドロップ」機能性によって画面へのボタンの追加を試みた場合、ユーザがボタンを画面に無事ドロップできれば、トランザクションは完了する。しかしながら、ユーザが、あるボタンを別のボタン内に追加するといった、受け入れがたいアクションを行なおうとした場合、ページモデルは、このアクションが受け入れがたいことを検出し、システムに通知する。これはトランザクションを失敗させ、トランザクションのすべての関連活動(すべてのモデル変更)がロールバックされる(逆戻りされる)。いくつかの実施形態では、ユーザジェスチャーによって開始された単一のモデル変更に応答して、追加のモデル変更が行なわれてもよい。たとえば、ユーザが受け入れ可能な位置でボタンをドロップした場合、システムは、別個の/追加のモデル変更としてテキストをボタンに(たとえばデフォルトで)自動的に追加してもよい。
【0192】
一実施形態は、トランザクションデータベースにおいて提供されるようなトランザクション機能性を実現する。トランザクションデータベースとは、データベース上の書込みトランザクションが(たとえば、電力または接続性の損失により)適切に完了されていない場合に、それらをロールバックすることができる、データベース管理システム(database management system:DBMS)である。いくつかのリレーショナルDBMSは、データベースにおける情報を各々読出し、および/または書込む1つ以上のデータ操作文およびクエリを含むトランザクションをサポートする。トランザクションはまた、新しいトランザクション(すなわち、サブトランザクション)を開始する文を内部に含む入れ子式トランザクションとして実現されてもよい。トランザクションは、その実行中にエラーが生じない場合にコミットされる。トランザクションコミット動作は、トランザクション内のすべてデータ操作に当てはまり、結果を対応するモデルまで持続させる。トランザクション中にエラーが生じた場合、またはユーザがロールバック動作を指定した場合、トランザクション内のデータ操作はモデルまで持続されない。部分的なトランザクションをモデルにコミットすることはできない。なぜなら、それはモデルを一貫性のない状態に置くためである。
【0193】
一実施形態では、各モデルは、変更を行ない、その変更をアンドゥするための最小の一組の命令を含む、トランザクションへのその変更を記録するように構成される。そのような最小の一組の命令は、アンドゥ/リドゥアクションを実現するために使用され得る。たとえば、XMLによって支援されるページモデルについては、「some_component.setAttribute(…)」を呼出すことはXMLを直ちに修正し、「[set attribute “foo” on element “X”]」は、アンドゥ/リドゥアクションを実現するために使用され得る特異な命令であり得る。
【0194】
一実施形態では、トランザクションがコミットされると、それは、トランザクションがそれらが完了された順序で記録されているローカルライフサイクルへ送信される。トランザクションは、その変更が対応するクライアント側モデルに適用され、あらゆる必要なUIが変更を反映するように更新されたときに、「記録された」と考えられる。トランザクションがいったんローカルに記録されると、その変更記録は、リモートライフサイクルのリモート持続キューに追加される。リモートライフサイクルとは、サーバに保存される必要があるトランザクション変更記録のキューである。これらの記録は一度に1つずつ処理され、コンテンツがサーバ上にどのように持続されているかを示す。サーバへの変更記録の持続が完了した場合、変更記録はリモート持続キューから除去される。しかしながら、サーバ保存が失敗した場合、または、ある期間後(たとえば、持続動作を試みてから20秒後)に応答が受信されない場合、持続動作は失敗したと判断される。この場合、一実施形態は、指数バックオフアルゴリズムを使用して保存アクションを再試行する。たとえば、一実施形態は、1秒後に保存アクションの第1の再試行を試み、第1の再試行が失敗した場合、2秒待って第2の再試行を試み、第2の再試行が失敗した場合、4秒待って第3の再試行を試みる、などとなっている。失敗が続く場合、一実施形態はオフラインモードへ移行し、サーバ接続が復元されたかどうかを判断するためにより長い時間間隔で(たとえば毎分)チェックする。これは、持続キューのヘッドでトランザクションの保存を再試行することによって行なわれてもよい。
【0195】
実施形態は、クラウド環境におけるものといった、あらゆるウェブベースのアプリケーションに適用可能である。たとえば、クラウドベースのIDEにおけるウェブベースのアプリケーションのユーザが、UIにおける設計キャンバス上にオブジェクトをドラッグ・アンド・ドロップした場合、別個ではあるものの論理的に関連する多くのファイルが更新され、これらのファイルへの変更は単一の論理トランザクションとして取扱われて、単一のアトミックトランザクションとしての組合されたアクションのアンドゥ/リドゥを可能にする。IDEを提供する分散型システムでは、特定のトランザクションの一部であるオブジェクトのうちのいくつかは、ユーザにとってリモートであってもよい。したがって、実施形態は、これらのリモート更新の調整がユーザ観点からブロックしていないこと、および、失敗したトランザクションが再実行されないよう、リモートシステムへ送信された変更が順序に関して調整されることを保証する。
【0196】
一実施形態は、アンドゥまたはリドゥされ得るコミットされたトランザクションの履歴を含むアンドゥ履歴リストを管理する「TransactionManager」JavaScriptモジュールを実現する。TransactionManagerはシングルトンであり(すなわち、このJavaScriptモジュールの1つだけのインスタンスが作成される)、呼出し側が変更の記録を開始できるように、呼出し側に「startTransaction」JavaScript方法を提供する。呼出し側はいつでも、「getCurrentTransaction()」JavaScript方法を使用して現在のトランザクションを検索することができる。いったんすべての変更が行なわれると、「TransactionManager」は、変更記録をアンドゥ履歴に保存するために、「commitTransaction()」JavaScript方法を呼出す。何らかの理由でトランザクションの寿命中にエラーがある場合、またはコミット動作が失敗した場合には、「TransactionManager」は、記録された変更を除去する「rollbackTransaction()」JavaScript方法を呼出す。最新のトランザクションをアンドゥするために、「(undo()」JavaScript方法を呼出すことができる。「undo()」を繰り返し呼出すことは、各トランザクションをアンドゥすることによってトランザクションの履歴を逆探知する。どの時点でも、最も最近のアンドゥトランザクションをリドゥするために、「redo」JavaScript方法を呼出すことができる。「redo」は、「undo」が呼出されたのと同じくらい多く呼出され得る。各「undo」/「redo」は、アンドゥ/リドゥタイプの「TransactionEvent」JavaScript方法をトリガする。「undo」および「redo」JavaScript方法は、トランザクション内で呼出されるべきでない。
【0197】
一実施形態は、トランザクションの一部を構成する変更記録のためのベースJavaScriptモジュールとして、「ChangeRecord」JavaScriptモジュールを実現する。各トランザクションは1つ以上の変更記録を含むことができ、すべての記録はアトミックにトランザクションされる(すなわち、すべてが生じるか、またはどれも生じない)。1つの変更記録をロールバックすべき場合、その同じトランザクションにおけるすべての変更記録がその後ロールバックされる。変更記録は、ローカルおよびリモートという2つのライフサイクルを有する。
【0198】
ローカルライフサイクルは、ローカルクライアント上で起こる非ブロッキング動作を含む。非ブロッキング動作とは、サーバ応答が続くのを待たないといった、処理が生じている間にUIを停止させない動作である。クライアント上で起こるライフサイクルJavaScript方法は、「localCommit」、「localRevert」、および「localReplay」の3つがある。「localCommit」は、変更記録が最初にコミットされるときに1回だけ呼出される。「localRevert」は、記録が逆戻りされるとき(たとえば、アンドゥ動作またはロールバック動作時)はいつでも呼出される。「localReplay」は、記録が再実行されるよう求められるとき(たとえば、リドゥ動作時)はいつでも呼出される。
【0199】
リモートライフサイクルはローカルライフサイクルと並行して起こるが、リモートライフサイクルJavaScript方法は非同期に(すなわち、同時にまたは並行して)行なわれるため、それらは、ローカルライフサイクルJavaScript方法に比べ、遅延されるかもしれない。リモート動作のためのJavaScript方法は、「remotePersist」および「remoteRestore」の2つがある。「remotePersist」は、変更の結果をリモートサーバまで持続させる(すなわち、変更をデータベースへ保存する)。一方、「remoteRestore」は、元の状態(すなわち変更前の状態)をリモートサーバに復元する。
【0200】
一実施形態では、変更記録は、システムにおける単一のリソースを表わす固有のタイプによって識別される。リソースは、画面、画面に関連するバインディング、アプリケーションのナビゲーションフロー、アプリケーションメタデータなどといったモデルであってもよい。タイプはまた、動作のJavaScript方法を識別する。一実施形態では、変更記録およびリスナが動作の契約を定義することを可能にするために、タイプは非特異的なままである。タイプとは、変更の動作およびリソースのIDを含むタプルである。動作はまた、どのタイプのリソースが修正されているかを一意的に識別してもよい。たとえば、以下の機能性では、「resourceType」は、どのタイプのモデルが影響されるか(すなわち、データベースにおけるあるテーブルに相関するか)を示し、「id」は、そのリソースの特定のインスタンス(すなわち、そのテーブルにおけるある行)を識別する。
【0202】
あるタイプについては、持続動作は、複数の変更記録のリモートライフサイクルを組合わせてもよい。たとえば、同じタイプについて2つの持続動作が起こる場合、第2の動作が第1の動作のデータをオーバーライドするであろうと仮定して、第1の動作がスキップされてもよい。一実施形態では、単一の変更記録は単一のリソースに影響を与え、同じトランザクションで複数のリソースが修正される場合には複数の変更記録が使用される。たとえば、画面上の何らかのテキストをバックエンドサービスにバインドするユーザアクションが、UI定義ファイルおよびバインディング定義ファイルに変更が行なわれることを必要とする場合、一実施形態は、これらのモデル双方への変更を含むトランザクションを取込み、各モデルへの変更についてのそれぞれの変更記録を追加する。
【0203】
一実施形態はまた、UI専用変更記録がローカルライフサイクルにおいて追加されることを可能にするJavaScript方法を提供する。そのような変更記録は、UI変更にローカルに影響を与えるために、ローカルライフサイクルにおいてのみ使用される。UI専用変更記録のみを必要とする変更の一例は、画面上のタブを変更することである。この変更はデータ変更を必要としないため、サーバに何も同期させる必要はない。偶発的なUI取扱い(たとえば、トランザクションの前/後にUI状態を取込むこと)については、ローカルライフサイクルイベント化中に利用可能なトランザクションメタデータが使用される。たとえば、ユーザが画面上のタブを切替える場合、実施形態は、ユーザがアンドゥを行なった場合にタブを元に戻すよう切替える必要がある。UI専用トランザクションに記録されたメタデータは、どのタブがアクティブであったかを取込むであろう。そのため、それはアンドゥ中に復元され得る。このメタデータは、トランザクションメタデータ(たとえば、「the_current_transaciton.setMetadata(CurrentTab, "some tab")」)を介して格納される。
【0204】
「ChangeRecord::localCommit」JavaScript方法は、トランザクションをローカルにコミットする。いくつかのモデルは動作をコマンドで直ちに行ない、このため、コミットするものは何もない。これらの場合、このJavaScript方法は、コミットが完了した場合にモデルに通知するよう機能することができる。このJavaScript方法はオプションで、ブーリアンを返すことができる。いくつかのモデルでは、動作は一時的に行なわれ、コミットされる実際の変更はないかもしれない。それらの場合、このJavaScript方法は、根底的なモデルに変更が行なわれなかったことを示すために、「偽」を返す。このJavaScript方法が「偽」を返した場合、トランザクションは打ち切られないが、この特定の変更はトランザクションによって無視される。このJavaScript方法のためにその記録のすべてに「偽」を返させるトランザクションは静かに処分され、ロールバックされない。UI専用変更記録は、このJavaScript方法によって返されるものによって影響されない。
【0205】
呼出し側がモデル上のプロパティを修正すると直ちにその変更を行なうモデルの一例は、XMLによって支援されるページモデルである。このモデルについては、「some_component.setAttribute(…)」を呼出すことはXMLを直ちに修正する。モデルはトランザクションが完了する前に修正されるため、トランザクションが完了すると、コミット動作中に行なわれる作業はない。
【0206】
いくつかのモデルは、それらの根底的なソースを直ちに修正しない。いくつかのモデルは、テンポラリーストレージにおいてそのモデルに行なわれた変更を取込み、コミット動作中にトランザクションが完了すると、それらの変更はそのテンポラリーストレージから読み出され、モデルに書込まれる。変更が必要でないモデルの一例は、ユーザがボタンのテキストを「a」から「b」に変更し、次に同じトランザクションでそれを「b」から「a」に戻す場合である。「a」という値はトランザクションの開始からトランザクションがコミットされるときまで変更されなかったため、モデルは、何もしないことを選択することができる。なぜなら、その動作のアンドゥはモデルに何の影響も与えないためである。
【0207】
「ChangeRecord::remoteCommit」JavaScript方法は、変更をリモートサーバまで持続させる。持続動作が完了すると、このライフサイクルJavaScript方法は、それが完了したことを示す。持続動作が拒否されると、このライフサイクルJavaScript方法は、エラーが生じたことを示し、持続動作が将来再試行されるようスケジュールする。
【0208】
図9は、一実施形態におけるウェブアプリケーション開発のためのシステム900のブロック図である。ユーザは、アプリケーション開発サーバ904に対応するアプリケーション開発ウェブサイト910を実行するウェブブラウザ902を使用することにより、アプリケーションを開発する。ユーザによって行なわれるアクションは、要求/応答メカニズムを通してアプリケーション開発サーバ904で反映され、要求/応答メカニズムでは、各変更がアプリケーション開発サーバ904へ送信され、アプリケーション開発サーバ904が次に、変更がアプリケーション開発サーバ904で持続されたかどうかを示す対応する応答を送り返す。
【0209】
いくつかの公知のシステムでは、最後に行なわれた変更がアプリケーション開発サーバ904で持続されていることを示す返答がアプリケーション開発サーバ904から受信されない限り、ユーザは、アプリケーション開発ウェブサイト910と対話してさらに変更を行なうことを継続することを許可されない。しかしながら、これは、たとえば、アプリケーション開発サーバ904がロードされること、アプリケーション開発サーバ904への接続が遅いこと、セルラー/無線シナリオにおけるアプリケーション開発サーバ904との接続の不良などに起因して返答の受信に遅延がある場合に、ユーザ体験および全体性能の劣化をもたらし得る。実際、いくつかの公知のシステムでは、ユーザは、各変更後、継続できるようになるまで2〜3秒待つ必要があるかもしれない。この問題は、一連のアクションがユーザによって行なわれ、ユーザが次にそれらのアクションをすべてアンドゥするつもりである場合に、増幅される。なぜなら、ユーザは、結局変更はないのに、各アクションを行なうために2〜3秒待たなければならず、次に各アクションをアンドゥするためにさらに2〜3秒待たなければならないためである。
【0210】
対照的に、システム900は、ローカルキュー906およびリモートキュー908を実現することにより、クライアント側(すなわち、ウェブブラウザ902)でトランザクションシステムを維持する。たとえば、アプリケーション開発ウェブサイト910において変更「A」がユーザによって行なわれると、この変更は、トランザクション(すなわち、明らかな始点および終点を有する作業の単位/ブロック)の観点から見られる。たとえば、「A」は、アプリケーション開発ウェブサイト910上の画面へのフォームの追加であってもよい。したがって、すべての個別動作は、それ自体のトランザクションである。トランザクションがコミットされる(すなわち、トランザクションがシステムに入り、ユーザが対応するアクションを行なうと決める)と、「A」はローカルキュー906に配置される。アプリケーション開発ウェブサイト910は、ローカルキュー906のコンテンツを一度に1つずつ処理し、対応する変更を行なう。たとえば、「A」がローカルキュー906において最も古い未処理のアイテムである場合、アプリケーション開発ウェブサイト910はローカルキュー906から「A」を取り出し、ウェブブラウザ902の画面上にその影響を示す。
【0211】
トランザクションは、ローカルキュー906から独立して、リモートキュー908にも入れられる。リモートキュー908も順序付けられ、そのコンテンツは一度に1つずつ処理される。たとえば、ウェブブラウザ902の画面にフォームを追加するための変更「A」について、「A」がアプリケーション開発サーバ904と通信されるためにリモートキュー908で依然として待っているかもしれない間に、ユーザは結果を直ちに見る。アプリケーション開発サーバ904が遅い場合(たとえば、アプリケーション開発サーバ904へ変更をアップロードするのに5秒かかる場合)、「A」がアプリケーション開発サーバ904へ無事送信されるのを待つ代わりに、ユーザは前進して、他の変更「B」、「C」および「D」をローカルに行なうことができる。クライアント側では、サーバが遅いにもかかわらず、変更「A」〜「D」が即座に起こり、記録される。したがって、ローカルキュー906は非常に速く処理される。
【0212】
重篤なイベント(たとえば、サーバがダウンすること)がアプリケーション開発サーバ904で起こった場合、システム900はオフラインモードへ移行し、アプリケーション開発サーバ904でまだ反映されていない変更は、再開時にアプリケーション開発サーバ904と通信され得るように、リモートキュー908にとどまる。ウェブブラウザ902が終了されても、リモートキュー908はそのような変更を保持する。アプリケーション開発サーバ904が再び利用可能になった後でリモートキュー908を参照することにより、システム900は、どの変更が、アプリケーション開発サーバ904と通信すべき次の変更かを識別する。リモートキュー908におけるアイテムは、当該アイテムがアプリケーション開発サーバ904で無事格納されたことを示す対応する応答をアプリケーション開発サーバ904から受信した後にのみ削除される。アイテムは一度に1つずつアプリケーション開発サーバ904と通信されるため、いかなる場合も、システム900は、どのアイテムがアプリケーション開発サーバ904と無事通信されたかを知っている。
【0213】
一実施形態では、最も最近の変更がリソース全体を保存する場合、そのリソースへの前の変更は、ローカルキュー906および/またはリモートキュー908から削除され得る。たとえば、一連の変更「A」〜「D」において、「B」および「D」が同じリソースを修正し、「C」および「D」が独立している場合、「B」がキューから削除され得る。そのようなリソースの一例はウェブブラウザ902上のUIであり、1つのフォームフィールドを別のフォームフィールドへ移動させることは、同じリソースを修正する。
【0214】
一実施形態では、ローカルキュー906および/またはリモートキュー908を処理する場合、トランザクション自体を移動させる代わりに、それぞれのポインタを移動させる。一実施形態では、他のトランザクションと全く同様に、アンドゥ動作がリモートキュー908でスケジュールされる。しかしながら、対応する元のトランザクションがリモートキュー908において依然として待っている間に、アンドゥトランザクションがリモートキュー908に追加された場合、双方のトランザクションはリモートキュー908においてキャンセルされてもよい。
【0215】
一実施形態では、開始時間(たとえば、アプリケーション開発ウェブサイト910に初めて到達した時間)から、アンドゥ履歴がローカルキュー906において維持される。この実施形態では、ローカルキュー906は持続的なオブジェクトである。
【0216】
図10は、本発明の実施形態に従った自動保存機能性のフロー図である。
1010で、クライアントデバイスのウェブブラウザが、サーバに対応するウェブサイトと対話するユーザによって行なわれたユーザアクションを受信する。ウェブサイトはアプリケーション開発ウェブサイトであってもよく、サーバはアプリケーション開発サーバであってもよい。
【0217】
1020で、ユーザアクションに対応する変更記録が判断され、1030で、変更記録は、ローカルモデルへの対応する変更をコミットするために、第1のキューに入れられる。一実施形態では、第1のキューは、ウェブサイトと対話する際にアンドゥ動作およびリドゥ動作を行なうために変更記録の履歴を維持する、順序付けられた持続キューである。
【0218】
1040で、変更記録は、変更記録をサーバで持続させるために、サーバと通信する第2のキューに入れられる。一実施形態では、第2のキューは、変更記録が一度に1つずつ処理され、各変更記録は、第2のキューにおける前の変更記録がサーバ上に無事記録された場合のみ、サーバへ送信される、順序付けられたキューである。変更記録は、サーバと無事通信された後に第2のキューから除去される。第2のキューは要求/応答メカニズムを通してサーバと通信し、要求/応答メカニズムでは、第2のキューにおける各変更記録はサーバへ送信され、サーバは次に、変更記録がサーバで持続されたかどうかを示す対応する応答を送り返す。
【0219】
一実施形態では、変更記録は、ウェブサイトにおけるユーザアクションによって生じたモデル変更を反映しており、関連するモデル変更を構成するトランザクションにおいて追加される。トランザクションがコミットされると、トランザクションにおける変更記録が第1のキューに配置される。トランザクションは、その実行中にエラーが生じない場合にコミットされる。ウェブサイトは、第1のキューのコンテンツを一度に1つずつ処理し、対応する変更を行なう。トランザクションが記録されると、トランザクションにおける変更記録が第2のキューに配置される。トランザクションは、その変更が対応するクライアント側モデルに適用され、あらゆる必要なユーザインターフェイスが対応する変更を反映するように更新されたときに記録される。
【0220】
一実施形態は、要求への応答が時間しきい値の満了後にサーバから受信されていないと判断して、第2のキューのコンテンツを保護し、引き続き第2のキューに新しい変更記録を入れながら、オフラインモードへ移行する。実施形態は次に、サーバとの通信が復元されていると判断して、オンラインモードへ戻るよう移行し、第2のキューのコンテンツをサーバで持続させることを再開する。ウェブブラウザが終了されても、第2のキューはそのコンテンツを保持する。
【0221】
一実施形態は、変更記録がリソース全体を保存していると判断して、リソースへの前の変更記録を第1のキューおよび第2のキューから除去する。
【0222】
一実施形態では、対応する元のトランザクションが第2のキューにおいて依然として待っている間に、アンドゥトランザクションが第2のキューに追加された場合、アンドゥトランザクションおよび対応する元のトランザクションは双方とも、第2のキューからキャンセルされる。
【0223】
開示されたように、実施形態は、サーバ接続問題、またはクライアントで行なわれるアンドゥ/リドゥアクションが生じた場合でも、データを失うことなく、またはクライアントとサーバとの間に不整合を引き起こすことなく、クライアント側変更がほぼ瞬間的であり、かつ、それらの変更がリモートサーバで持続されることを可能にする、トランザクション自動保存システムを提供する。したがって、ユーザ変更をリモートサーバで持続させつつ、ユーザをブロックする必要性がないため、実施形態は非常に性能を高め、ユーザ体験を向上させる。
【0224】
UI状態の復元
現在、いくつかのトランザクショナルシステムは、モデル変更を逆戻りさせるために、または再度適用するために、アンドゥおよびリドゥ機能性を提供している。しかしながら、UI状態(すなわち、ユーザがどんなUIを見ているか)を復元することも望ましいものの、UI状態情報はモデルデータの一部ではないかもしれず、したがって、モデルを復元することはUI状態を自動的に復元しないかもしれない。たとえば、ユーザは、システムにおいてページ「X」上にいて、ページ「X」にモデル変更を行ない、次に、ページ「Y」に切替える/ナビゲートするかもしれない。ユーザがページ「X」へのモデル変更に対してアンドゥを行なう場合、ビューをページ「X」に戻すよう切替えることが非常に望ましいであろう。なぜなら、そこは、ユーザがそのモデル変更を行なった場所であるためである。しかしながら、ページ「X」へのモデル変更をアンドゥするだけでは、ユーザを自動的にページ「Y」からページ「X」に連れてくることにはならない。システムがより複雑になるにつれ、好ましくは復元を必要とするUI状態の量も増加する。
【0225】
いくつかの公知のシステムは、問題に全く対処しない(すなわち、UIはアンドゥ/リドゥに対して変更されない)か、または、UI状態をある程度だけ復元する。たとえば、いくつかの公知のシステムでは、アンドゥまたはリドゥアクションが受信されると、ユーザは、アンドゥ/リドゥアクションに特有の詳細なUIにではなく、何らかのメイン/デフォルトUIに連れ戻される。
【0226】
いくつかの公知のシステムは、ユーザにどのUIを見せるかを判断するために、変更を検査することを試みる。しかしながら、この機能性を実現することはシステムを複雑にし、また、維持することが難しい。
【0227】
公知のシステムとは対照的に、実施形態は、トランザクションがロールバックされる場合、またはそれがその後再びコミットされる場合(すなわち、アンドゥ/リドゥ機能性において典型的な動作)にUI状態が復元され得る、トランザクションシステムを提供する。一実施形態は、トランザクションをコミットする前および後の双方でUI状態およびモデル状態を格納して、アンドゥまたはリドゥ動作がトランザクションに対して行なわれると、格納された状態を使用して適切なUI状態およびモデル状態を復元する。したがって、実施形態は、相当な量のUI状態が復元を必要とする複雑なシステムについても、UI復元を、トランザクション環境内で管理可能にし、自動的にする。
【0228】
一実施形態では、あるアクションをアンドゥすると、ユーザは、そのアクションを行なう前に自分が見ていたのと同じUIを見る。一実施形態は、リドゥについて同様の機能性を提供する。すなわち、アンドゥされたアクションをリドゥすると、ユーザは、そのアクションを行なった後に自分が見ていたのと同じUIを見る。したがって、実施形態は、ユーザがUI内のコンテキストを失わないようにすることにより、ユーザ体験を著しく向上させる。
【0229】
実施形態は、UIの任意のピースが復元機能性に関与することを可能にするように拡張可能であり、また、トランザクションシステムの意味論を理解することをUIを要求しない。すなわち、UIは、どのモデル変更がトランザクションによって実際に行なわれるか、そのトランザクションがシステムにとって何を意味するか、または、トランザクションは一般にどのように作用するか(たとえば、コミット動作、ロールバック動作などがどのように作用するか)を理解する必要がない。
【0230】
一実施形態では、ウェブページがブラウザ上でレンダリングされると、そのウェブページのコンポーネントが初期化される。すなわち、ウェブページがレンダリングされると、UI要素/アクターが、まずブラウザにダウンロードされ、次に実行される。この実施形態では、システムにおけるUIアクターは、初期化時にトランザクションフレームワークに登録可能である。登録はまた、作業セッション中に作成されるUIがトランザクションフレームワークに登録され、そのUIが除去されると登録解除され得るように、動的であり得る。
【0231】
一実施形態では、トランザクションが開始されると、トランザクションフレームワークは登録されたUIをクエリし、それらの現在のUI状態のスナップショットを検索する。一実施形態では、UI状態は、トランザクションから生じる変更の意味論上の意味を含む。トランザクションに関与するUIアクターは、そのようなUI状態をどのように復元するかを知っている。なぜなら、これらのアクターが、最初にUI状態を作成したためである。以下は、ボタンの現在の色がブルーであることを記録するためにUI状態に含まれ得る例示的な機能性である。
【0233】
トランザクションは次に、システムにおける対応するモデルをコミットし、更新する。これらの変更がUIにおいていったん反映されると、登録されたUIは再びクエリされ、それらの現在のUI状態の別のスナップショットが撮られる。一実施形態では、スナップショットは、それらがトランザクション内でどのライフサイクルにいるか(たとえば、トランザクションのライフサイクル状態がコミットか、アンドゥか、リドゥかなど)を示さない。たとえば、UIは、ユーザがアクション、アンドゥ動作、リドゥ動作などを行なったかどうかにかかわらず、単にその現在のスナップショットを撮る。一実施形態では、UI状態の「トランザクション前」および「トランザクション後」スナップショットが、対応するトランザクション変更記録とともに格納される。
【0234】
一実施形態では、変更記録は、対応するモデル状態から独立して格納され、そのモデル状態を修正するための命令を格納する。モデル状態は、任意の時点で正しい(たとえば、任意の時点でユーザに提供されているUIと整合する)と仮定される。一実施形態では、変更記録は「アンドゥ」スタックに格納される。各変更記録は、対応するアクションを行なうこと、またはそれをアンドゥすることができる一組の命令を含む。したがって、ユーザがアクションをアンドゥすると、最後の変更記録がアンドゥスタックから検索され、対応するアンドゥ命令を行なうために呼出される。
【0235】
一実施形態では、(たとえばアンドゥ動作を行なうことによって)その後ロールバックされるトランザクションにおいてモデル変更が適用されると、登録されたUIには、トランザクションが開始したときに撮られたそれらの対応するUIスナップショットが提供され、UIは、それらの対応するUIスナップショットを復元するよう促される。同様に、(たとえばリドゥ動作を行なうことによって)その後再実行されるロールバックされたトランザクションにおいてモデル変更が復元されると、登録されたUIは、トランザクションがコミットされたときに撮られたそれらの対応するUIスナップショットに復元される。
【0236】
一実施形態では、UIの1ピースのスナップショットを復元することは、UIの他のピースに影響を与えない。たとえば、スナップショットが復元される場合、1つのUIピースは、別のUIピースに対してイベント化しない。なぜなら、他のUIピースをそれ自体のライフサイクル外で更新することは、予測不能の挙動を招くかもしれないためである。したがって、一実施形態では、このプロセス中、影響されたUIの各ピースは、そのUI状態を、他のUIピースから独立して登録して管理し、他のUIピースのイベントに反応せず、また、他のUIピースへイベントを送信しない。
【0237】
実施形態は、アンドゥ/リドゥ機能性をサポートする任意のシステムまたはウェブアプリケーションに適用可能である、
図11は、一実施形態に従った例示的なUI1100を示す。UI1100は、たとえば、モバイルアプリケーションまたは別のタイプのアプリケーションを構成/設計するために使用されてもよい。UI1100は、テンプレート選択ピース1102、テンプレートピース1104、およびコンポーネント選択ピース1106という3つのUIピースを含む。一例では、テンプレート選択ピース1102は、テンプレートA 1110、テンプレートB 1112、またはテンプレートC 1114を選択するオプションを提供してもよい。テンプレート選択ピース1102においてあるテンプレートオプションを選択すると、選択されたテンプレートは、テンプレートピース1104に示される。一実施形態では、テンプレートピース1104における選択されたテンプレートに対応する、テンプレート選択ピース1102におけるUIコンポーネントは、テンプレート選択ピース1102において強調表示されてもよい。
【0238】
テンプレートピース1104はさらに、コンポーネント選択ピース1106において提供されるコンポーネントによって定義および/または修正されてもよい。コンポーネント選択ピース1106において提供されるオプションは、テンプレートピース1104に示されているテンプレートの選択と関連していてもよい。たとえば、コンポーネント選択ピース1106は、ボタンD 1116、ボタンE 1118、またはボタンF 1120をテンプレートピース1104に追加するためのオプションを提供してもよい。一例では、ボタン1108が、コンポーネント選択ピース1106における対応するオプションが選択されると、テンプレート1104に示されてもよい。一実施形態では、テンプレートピース1104において追加されたボタンに対応する、コンポーネント選択ピース1106におけるUIコンポーネントは、コンポーネント選択ピース1006において強調表示されてもよい。
【0239】
一実施形態では、UI1100におけるUIピースは互いに関連しているが、各UIピースのUI状態は他のUIピースから独立して格納され、各UIピースの復元は他のUIピースの復元に影響を与えず、または他のUIピースの復元をイベント化しない。したがって、各UIピースは独立して復元されてもよく、UIピースは他のUIピースからイベントを受信せず、または他のUIピースへイベントを送信しない。たとえば、テンプレート選択ピース1102における強調表示されたUIコンポーネントが、テンプレートピース1104における選択されたテンプレートに対応する場合、テンプレート選択ピース1102のUI状態はそのような強調情報を含むものの、その復元は、対応するテンプレートを示すためにテンプレートピース1104をイベント化しない。このシナリオでは、テンプレートピース1104のUI状態は、適切なテンプレートを示すために独立して保存され、復元されて、それにより、2つの関連するUIピース間の相互に関連するイベント化の必要性をなくす。同様の独立した復元機能性が、相互に関連する情報を保持するものの、復元時に互いをイベント化しない、テンプレートピース1104およびコンポーネント選択ピース1106のために実現される。したがって、UI1100のすべてのUIピースは、それ自体の状態を、他のUIピースから独立して格納するため、どのUIピースも復元のために別のUIピースを待つ必要がない。
【0240】
一実施形態では、UIのすべてのピースはそれぞれの状態を保存できるが、アクションの影響を受けたUIのピースだけが保存/復元される必要がある。一実施形態では、いくつかのUIピースは、アクションが何を行なっているか(すなわち、アクションの影響が何であるか)知らないかもしれず、したがって、それらがアクションの影響を受けていなくても、目に見える各UIピースはその状態を保存/復元させる。一実施形態では、アクションが行なわれるとUIピースが見えなくなる場合、そのようなUIピースは、それがアクションが行なわれた時点で表示されてさえいなかったため、それはアクションの影響を受けていない、ということを知っている。したがって、アクション中に見えないUIピースの状態は、保存/復元されなくてもよいかもしれない。
【0241】
以下は、メインコンテンツエリアとサイドバーとを有するページのためにUIを保存し復元する一例を提供しており、サイドバーは、メインコンテンツエリアよりも若干暗い背景色を有するべきである。ページは、主コンテンツエリアが「グレー」、およびサイドバーが「ダークグレー」で始まってもよい。メインコンテンツエリアの背景色は、以下のように「レッド」に変更されてもよい:
・ユーザは、メインコンテンツエリアの背景色を変更するためのジェスチャーを行ない、対応するトランザクションが開始される;
・フレームワークはまず、UI状態をすべて記録する。メインコンテンツエリア用のカラーピッカーとサイドバー用のカラーピッカーとを含む2つのUIのみがあると仮定して、各カラーピッカーはその現在の状態を以下の機能性に従って記録する:
【0243】
・メインコンテンツカラーピッカーは、その色が変わると、サイドバーカラーピッカーも、メインコンテンツカラーピッカーの新しい色のより暗いバージョンに自動的に変化すべきであるということを知っているコードを含む。したがって、メインコンテンツカラーピッカーはサイドバーカラーピッカーに、その色を「ダークレッド」にするよう命じる。
【0244】
・トランザクションがコミットされ、モデル状態は以下のようになる:
【0246】
ユーザがその後、このトランザクションをアンドゥした場合:
・モデル状態は以下の状態に逆戻りされる:
【0248】
この時点で、モデルは正しく、アンドゥアクションを反映しているが、カラーピッカーは依然として、間違った色である「レッド」を示している。
【0249】
・UIのピース(すなわちカラーピッカー)は、それらの状態を、トランザクション前の状態に復元するよう命じられる。すなわち、以下の通りである:
【0251】
メインコンテンツカラーピッカーは次に、その状態を「グレー」に復元し、サイドバーカラーピッカーは、その状態を「ダークグレー」に復元する。これらの状態を復元する際、メインカラーピッカーを変更することはもはや、自動的にサイドバーカラーピッカーに、メインコンテンツカラーピッカーの復元された色のより暗いバージョンになるよう命じない。すなわち、通常のUI変更と同様の「イベント化」はなく、各UIピースはその状態をそれ自体で管理する。この実施形態では、UIピースは、それらの状態が何かを知るために、それらの対応するモデルを読出してもよい。しかしながら、UIピースのUI状態を追跡することは、カラーピッカーが目に見えるべきか否かといった、対応するモデルに記録されていないかもしれないUI変更も追跡/格納する。
【0252】
図12は、いくつかの実施形態に従った、例示的なコミットフロー1202、例示的なアンドゥフロー1204、および例示的なリドゥフロー1206を示す。
【0253】
コミットフロー1202では、トランザクションが起こると、トランザクションが始まる前の1208で(すなわち「INIT」状態で)、対応するモデル状態およびUI状態が記録される。
図12では、そのようなモデル状態およびUI状態は、それぞれ「INIT MODEL」および「INIT UI」として示される。次に、1210でのコミット前状態は、外部リスナに、コミット状態の前にアクションを行なう機会を提供する。1212で、トランザクションは終了し(すなわち、トランザクションは「COMMIT」状態でコミットされ)、対応するモデル状態およびUI状態が再び記録される。
図12では、そのようなモデル状態およびUI状態は、それぞれ「COMMIT MODEL」および「COMMIT UI」として示される。
【0254】
アンドゥフロー1204では、アンドゥ(逆戻り)動作が、トランザクション前のUI状態およびモデル状態(すなわち、1208で取込まれた「INIT MODEL」状態および「INIT UI」状態)を復元しようと試みる。そうするために、1214で、「INIT MODEL」状態が、逆戻り動作の前に、逆戻り前状態で復元される。1216で、逆戻り動作が行なわれる。逆戻り動作は、アンドゥアクションを行なうことを含む。たとえば、テキストが「A」から「B」に変更され、次にアンドゥアクションが示された場合、逆戻り動作は「B」を「A」に戻す。逆戻り動作の完了後、1218で、「INIT UI」状態が逆戻り後状態で復元される。
【0255】
リドゥフロー1206では、リドゥ(再実行)動作が、トランザクションがコミットされた後のUI状態およびモデル状態(すなわち、1212で取込まれた「COMMIT MODEL」状態および「COMMIT UI」状態)を復元しようと試みる。そうするために、1220で、「COMMIT MODEL」状態が、リドゥ動作の前に、リドゥ前状態で復元される。1222で、再実行動作が行なわれる。再実行動作は、リドゥアクションを行なうことを含む。たとえば、テキストが「A」から「B」に変更され、次にアンドゥアクションが「B」を「A」に戻した場合、リドゥアクションは再び「A」を「B」に戻す。再実行動作の完了後、1224で、「COMMIT UI」状態が再実行後状態で復元される。
【0256】
図13は、本発明の実施形態に従ったUI復元機能性のフロー図である。
1310で、UIと対話するユーザによって行なわれたアクションが受信される。ユーザアクションの例は、ボタンを押下すること、何らかのテキストを入力すること、UIの何らかのピースをドラッグ・アンド・ドロップすること、などといったユーザジェスチャーである。一実施形態では、アクションは、ユーザのクライアントデバイスのウェブブラウザによって受信され、ユーザは、UIをホストするサーバに対応するウェブサイトと対話する。一実施形態では、ウェブサイトはアプリケーション開発ウェブサイトであり、サーバはアプリケーション開発サーバである。
【0257】
1312で、アクションに基づいてトランザクションが判断され、トランザクションは、UIに対応するモデルを修正するように構成される。一実施形態では、トランザクションは、多くの関連するモデル変更を構成する。
【0258】
モデルの一例は、現在の画面上のUIコンポーネントを記述する宣言的構文であるページスキーマである。このモデルは、画面を定義するXMLコードを操作するAPIとして実現されてもよい。このモデルについての例示的なモデル変更は、以下のとおりである:
【0260】
ここで、「some_component」はページモデルにおけるUIコンポーネントであり、変更は、スタイル属性をレッドにするよう修正することである。このモデルについての例示的なトランザクションは、ユーザがボタンをクリックすることによって生じ得る一連のモデル変更(たとえば、ページスキーマおよび対応するバインディングへの前述の変更)である。
【0261】
1314で、UIの第1のUI状態およびモデルの第1のモデル状態が格納される。
1316で、トランザクションがコミットされる。一実施形態では、トランザクションは、その実行中にエラーが生じない場合にコミットされる。
【0262】
1318で、第1のユーザ対話に基づいて、トランザクションをアンドゥすることが判断される。
【0263】
1320で、UIは第1のUI状態に復元され、モデルは第1のモデル状態に復元される。一実施形態では、第1のモデル状態はトランザクションをアンドゥする前に復元され、第1のUI状態はトランザクションをアンドゥした後に復元される。一実施形態では、UIは2つ以上のUIピースを含み、第1のUI状態は、UIの各ピースについてのUI状態を含む。一実施形態では、UIの各UIピースのUI状態は、UIの他のUIピースから独立して格納され、復元される。
【0264】
一実施形態では、トランザクションがコミットされた後、および第1のユーザ対話の前に、UIの第2のUI状態およびモデルの第2のモデル状態が格納される。
【0265】
一実施形態では、第2のユーザ対話に基づいて、トランザクションをリドゥすることが判断され、次に、UIは第2のUI状態に復元され、モデルは第2のモデル状態に復元される。一実施形態では、第2のモデル状態はトランザクションをリドゥする前に復元され、第2のUI状態はトランザクションをリドゥした後に復元される。
【0266】
開示されたように、実施形態は、トランザクションをコミットする前/後にUI状態およびモデル状態の格納されたスナップショットを使用し、アンドゥ/リドゥ動作が行なわれると適切なUIおよびモデル状態を復元する、トランザクションシステムを提供する。一実施形態では、あるアクションをアンドゥすると、ユーザには、そのアクションを行なう前に自分が見ていたのと同じUIが提供される。一実施形態では、あるアクションをリドゥすると、ユーザには、そのアクションを行なった後に自分が見ていたのと同じUIが提供される。したがって、実施形態は著しくユーザ体験を向上させ、UI設計プロセスの効率を向上させる。
【0267】
いくつかの実施形態がここに具体的に例示および/または説明されている。しかしながら、開示された実施形態の変更および変形は、発明の精神および意図された範囲から逸脱することなく、上述の教示によって網羅され、添付された請求項の範囲内にある。