JP2008537818A - モバイルデータシステムのためのアダプタアーキテクチャ - Google Patents

Abstract

データアーキテクチャは、コネクタを介した、及びまたコマンドにより定義されたデータオブジェクトによる、アプリケーションへの企業データソースインターフェースを定義するビューオブジェクトを提供する。従って、データオブジェクトは、コマンドを介し企業データソースのアダプタに発行される構成可能なデータ要求を含む。本アーキテクチャは、異種のバックエンド企業データソースへのカスタムの企業接続性を生成する能力をアプリケーション開発者に提供する。

Description

本出願は、同時係属中のロバート・オファエル（Ｒｏｂｅｒｔ Ｏ’Ｆａｒｒｅｌｌ）らによる２００５年３月２１日出願の米国仮特許出願第６０／６６４，１２１号明細書、「モバイルデータシステムのためのデータ管理（Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ ｆｏｒ Ｍｏｂｉｌｅ Ｄａｔａ Ｓｙｓｔｅｍ）」、同時係属中のロバート・ローファン（Ｒｏｂｅｒｔ Ｌｏｕｇｈａｎ）による２００５年３月２１日出願の米国仮特許出願第６０／６６４，０８８号明細書、「モバイルデータシステムのためのモジュラーアプリケーション（Ｍｏｄｕｌａｒ Ａｐｐｌｉｃａｔｉｏｎｓ ｆｏｒ Ｍｏｂｉｌｅ Ｄａｔａ Ｓｙｓｔｅｍ）」、同時係属中のロバート・オファエルらによる２００５年３月２１日出願の米国仮特許出願第６０／６６４，１２２号明細書、「モバイルデータシステムのためのアダプタアーキテクチャ（Ａｄａｐｔｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｍｏｂｉｌｅ Ｄａｔａ Ｓｙｓｔｅｍ）」、及び同時係属中のロバート・オファエルらによる２００５年４月１日出願の米国仮特許出願第６０／６６７，８１６号明細書、「モバイルデータシステムのためのモジュラーアプリケーション（Ｍｏｄｕｌａｒ Ａｐｐｌｉｃａｔｉｏｎｓ Ｍａｎａｇｅｍｅｎｔ ｆｏｒ Ｍｏｂｉｌｅ Ｄａｔａ Ｓｙｓｔｅｍ）」の優先権の利益を要求する。それぞれの出願日の優先権をここに要求し、またこれらの仮特許出願の開示を参照して本明細書に組み込む。

本特許文書の開示の一部は著作権保護を受ける資料を含む。本著作権者は、本特許文書ないし特許の開示の任意の者によるファクシミリによる複製に対しては本特許文書ないし特許の開示が米国特許商標庁のファイルないし記録にあることから異存がないが、他の場合にはいかなる著作権も全て留保する。

本発明は、一般的にはモバイルコンピューティングシステムに関し、特にモバイルコンピューティングシステムにおけるデータ管理とデータ展開（ｄａｔａ ｄｅｐｌｏｙｍｅｎｔ）に関する。

バックオフィス及びフロントオフィス処理の自動化を改善するために、高度な顧客管理（ｃｕｓｔｏｍｅｒ ｒｅｌａｔｉｏｎｓｈｉｐ ｍａｎａｇｅｍｅｎｔ：ＣＲＭ）及び企業全体業務管理（ｅｎｔｅｒｐｒｉｓｅ ｒｅｓｏｕｒｃｅ ｐｌａｎｎｉｎｇ：ＥＲＰ）システムが利用可能である。多くの会社はこのようなシステムの展開により大幅な節約と効率を達成したが、一方でこのようなシステムを実施するのは厄介であり、既存のレガシーデータシステムと統合するのは困難であると多くの組織体が感じているのも事実である。

最近になって、事業体及び企業は、モバイル従業員が主としてページャー、携帯電話、また携帯情報端末（ＰＤＡ）などのモバイルコンピューティング装置を利用することを支援するＣＲＭ及びＥＲＰシステムを展開している。このような移動体装置を使用するＣＲＭ及びＥＲＰシステムを大規模に採用するための一つの重要な障害は、企業内の他のデータとの統合に係る。

モバイルアプリケーションは企業の他のデータシステムとの統合を妨げる独自仕様の（ｐｒｏｐｒｉｅｔａｒｙ）閉じたアーキテクチャ内にしばしば導入されるので、企業データ統合問題が発生し得る。例えば、企業におけるデータは４つ又は５つの異なるソースにおいて維持されると考えられる。データソースのいくつかとして、ＣＲＭシステム、ディスパッチシステム、ＥＲＰシステム、財務記録システムが挙げられる。これらのデータソースの各々は異なるデータアーキテクチャ、フォーマット、プロトコルを利用することができる。格納されているデータ、そしてこのデータ及びアクセスメカニズムの構成は、絶えず変化している。多くのモバイルコンピューティングシステムは、企業内の様々なソースからのデータが収集される中間的なデータ記憶装置を作成する。このようにして、それぞれが異なるデータアーキテクチャ及びフォーマットを有する異なる企業データソースからのデータを単一の共通データベース内に収集することができる。モバイルユーザは、実際の企業データソースではなく中間的なデータ記憶装置にアクセスすることにより企業データにアクセスすることができる。しかしながら、中間的な記憶装置は、それ自身のデータ更新問題及びデータコンフリクト問題を生ずる。中間的なデータ記憶装置内のデータが企業データソース内のデータの忠実な複製であることを保証するために、同期動作と他の保護手段が頻繁に実行されなければならない。

ネットワークサーバを介して企業データソースへインターフェースするモバイルコンピューティング装置を利用することができるデータ統合ソリューションを提供することは知られている。このようなシステムは米国ワシントン州、ボセル（Ｂｏｔｈｅｌｌ）のデクステラ（Ｄｅｘｔｅｒｒａ）社に譲渡された２００３年１２月２３日出願の特許文献１に記載される。本出願の内容は参照により本明細書に組み込まれる。

デクステラ社の特許文献１は、モバイルクライアントからの企業データ要求が受信され、要求されたデータを含む適切な企業データソースが確定され、確定された企業データソースからこの企業データが取り出されないし検索される（retrieved）といった分散的なやり方で、データが、複数の企業データソースからモバイルクライアントまでの間で利用されるシステムについて記載している。企業データが検索される際、たとえデータが様々な非リレーショナルタイプの複数の企業データソース（例えばファイルシステム、電子メール等）に由来するとしても、企業データはリレーショナルフォーマットに変換される。変換された企業データは、モバイルクライアント内のリレーショナルデータ記憶装置に格納される。このようにして、モバイルアプリケーションは複数の企業データソースからのデータに完全に統合され、そしてデータ更新と構成変更（Ｃｏｎｇｉｇｕｒａｔｉｏｎ Ｃｈａｎｇｅ）は中間的なデータ保存記憶装置を使用することなくリアルタイムでモバイルクライアントとの間で配信されるので、企業データソースとモバイルクライアント間の複雑な同期及び非同期データ問題を回避する。リアルタイムのデータ変更は、データ更新だけでなくモバイルアプリケーション自体の変更の展開も含むことができる。リアルタイムの変更は、さらにデータコンフリクト検出及び解決にも適応される。

上記で参照したデクステラ社のシステムは、目標のないしターゲットの企業データソースがオブジェクト又はデータテーブルを含み、各ターゲットデータテーブルがビュー（Ｖｉｅｗ）と呼ばれるデータオブジェクトへマッピングされるシステムアーキテクチャに基づく。すなわち、企業データソース内の各データテーブルに対応するビューが定義され、そこからアプリケーションはデータを取得する。ビューはアプリケーション開発者により定義されてもよいし、あるいは他のベンダーから定義されてもよい。ビュー内のデータは、ビジネスオブジェクトと呼ばれる一つ又は複数のデータエンティティ間で共有される。単一のビジネスオブジェクトは複数のビューからのデータを利用することができるので、複数の企業データソースからの（非互換のデータフォーマットを有するデータソースからも）データを利用することができる。

一組のビジネスオブジェクトが定義されると、アプリケーション開発者は、ビューとコネクタを記述し定義することに関与するのではなく、ビジネスオブジェクトへのインターフェースを介しデータを扱いつつアプリケーションを設計することができる。このように、開発者にはフォーマットフリーのデータインターフェースが提示され、従ってターゲットにおける差異は開発者から取り除かれる。

上記で参照したデクステラ社の特許文献１に記載のシステムは、多種多様の企業データソースへのアクセスを許容するモバイルコンピューティングプラットフォームのための強力な開発ツールを提供する。また一方、データインターフェースにおける優れた順応性はシステムの能力を拡張しアプリケーション開発をさらに容易にすることができると考えられる。本発明はこのような優れた柔軟性を提供する。
米国特許出願第１０／７４６，２２９号明細書

本発明によると、データアーキテクチャは、コネクタを介した、及びまたコマンドにより定義されたデータオブジェクトによる、アプリケーションへの企業データソースインターフェースを定義するビューオブジェクトを提供する。従って、データオブジェクトは、コマンドを介して企業データソースのアダプタに発行される構成可能なデータ要求を含む。本アーキテクチャは、異種のバックエンド企業データソースへのカスタムの企業接続性を生成する能力を開発者に提供する。開発者は、また、特定の実行インスタンスへの構成及び適応性を有する任意のバックエンド企業システムへの接続性を分離することができる。これにより、「．ＮＥＴ」システムとバックエンドシステム間の技術（接続）が、バックエンドシステムにより必要とされる情報の構成とは別に開発できるようにし、こうしてアブストラクション層を生成して、コンフィギュレーションツールがその適応性を管理できるようにする。「デクステラ スタジオ ブイエス ネット（Ｄｅｘｔｅｒｒａ Ｓｔｕｔｉｏ ＶＳ．ＮＥＴ）プラグインを利用する任意の支援されたアダプタへユーザがデータコンポーネントを接続し構築できるようにする開発ツールキット環境を提供することができる。ツールキット環境のためのコンポーネントは、コネクションオブジェクト、コマンドオブジェクト、データオブジェクト、ビューを含む。

本発明の他の特徴と利点は、本発明の原理を一例として例示する以下の好ましい実施形態の説明から明らかである。

本発明により構築されるモバイルデータ統合システムでは、ビューオブジェクトは、コネクタを介した、及びまたコマンドにより定義されたデータオブジェクトによる、アプリケーションへの企業データソースインターフェースを定義する。従って、データオブジェクトは、コマンドを介し企業データソースのアダプタに発行される構成可能なデータ要求を含む。本アーキテクチャは、異種のバックエンド企業データソースへのカスタムの企業接続性を生成する能力を開発者に提供する。以下の最初の説明は、上に参照したデクステラ社の特許出願に記載されたシステムに関するものである。次に、その従来のシステムからの本発明のアーキテクチャ上の変更の詳細は「Ｖ．アダプタアーキテクチャ」とそれに続く節において説明される。

Ｉ．システム概要
本発明は、モバイルアプリケーションが複数の企業データソースに統合されるようにデータが、複数の企業データソースから、モバイルアプリケーションを実行するモバイルクライアントまで利用されるシステムであって、中間的なデータ記憶装置を使用することなくデータ更新と構成変更がリアルタイムでモバイルクライアントに配布されかつモバイルクライアントから受信されるシステムを提供する。中間的なデータ保存設備を排除することにより、企業データソースとモバイルクライアント間の複雑な同期と非同期データ問題を回避する。こうして、モバイルアプリケーションのデータ更新と構成更新は、リアルタイムで企業からモバイルクライアントへ、またモバイルクライアントから企業へ伝達することができる。本システムを介しリアルタイムで変更は伝達され得るので特別の同期操作は必要ではない。

ＩＩ．システムプラットフォーム
図１は、上記参照されたデクステラ社の特許文献１において説明したように構築された本発明による好適なコンピュータシステム環境１００のブロック図である。図１に、マイクロソフトポケットＰＣ又はパームＰＤＡオペレーティングシステムと共に動作する個人用デジタル情報処理端末（ＰＤＡ）装置などのモバイルクライアントデバイス１０２を示す。サーバからデータを要求し、データ更新を受信し、新しいデータを提供し、構成変更を受信するために、モバイルクライアントデバイス１０２はネットワーク接続１０４上でアプリケーションサーバ１０６と通信を行う。複数のモバイルクライアント１０２がサーバ１０６と通信を行うことができることを理解すべきである。図の簡潔性のため、図１には単一のクライアントデバイス１０２のみが示される。

モバイルクライアント１０２は、複数の企業データ記憶装置から検索されるリアルタイムのデータのためのサーバ側コネクタウェブサービスを使用する。さらに、モバイルクライアントは、リアルタイムのクライアント側データ更新、サーバ側データ更新及び構成更新の管理のためにサーバ側データマネージャウェブサービスを使用する。

アプリケーションサーバ１０６は、ＣＲＭデータソース、ＥＲＰソース、財務システム資源、レガシーデータ記憶装置等の企業データソース１０８と通信を行う。図１に図示された例示的企業データソースは、米国カリフォルニア州サンマテオ（Ｓａｎ Ｍａｔｅｏ，Ｃａｌｉｆｏｒｎｉａ，ＵＳＡ）のジーベルシステムズ社（Ｓｉｅｂｅｌ Ｓｙｓｔｅｍｓ，Ｉｎｃ）による「ジーベル（Ｓｉｅｂｅｌ）」ソフトウェア、米国カリフォルニア州レッドウッドショアズ（Ｒｅｄｗｏｏｄ Ｓｈｏｒｅｓ，Ｃａｌｉｆｏｒｎｉａ，ＵＳＡ）のオラクル社（Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ）による「オラクル（Ｏｒａｃｌｅ）」ソフトウェア、独国ウォルドルフのＳＡＰ社（ＳＡＰ ＡＧ ｏｆ Ｗａｌｌｄｏｒｆ，Ｇｅｒｍａｎｙ）による「ＳＡＰ」ソフトウェア、及び従来のソフトウェアを含むデータを含む。管理者アプリケーション１１０と開発者アプリケーション１１２は、以下にさらに説明されるように、システム用メタデータ１１４も格納するアプリケーションサーバ１０６と通信を行う。

アプリケーションサーバ１０６は、データ交換と更新、ユーザ認証、セキュリティ、及びロギングサービスのための、データマネージャ、構成ないしコンフィギュレーション、及びデータコネクタウェブサービスを提供する。アプリケーションサーバ１０６は、また、ビジネス情報及びビジネスルールの形式でビジネスプロセス管理を扱う。

また、モバイルクライアント１０２は、ビジネスデータ１２０を格納するリレーショナルデータベース１１８と、モバイルクライアント１０２上のアプリケーション実行のためのメタデータ１２２を格納するリレーショナルデータベースとを含むデータ記憶装置１１６を含む。モバイルクライアント１０２側にインストールされるアプリケーション１２４は、好適な機能を実行する様々なソフトウエアコンポーネントを含む。例えば、このアプリケーション１２４は、サービスが要求された場所についてフィールドサービス要員に通知し、このサービス要求の性質について説明し、このサービスアクセスをログに記憶してアカウントを設定するフィールドサービスアプリケーションを含んでもよい。アプリケーション１２４は、モバイルクライアント１０２により要求されたデータを処理する複数のアプリケーションを含むことができる。

アドミニストレータアプリケーションないし管理者アプリケーション１１０と、ディベロッパアプリケーションないし開発者アプリケーション１１２とは、ともに「スタジオ（Ｓｔｕｄｉｏ）」コンポーネント１３０を含む。例示された実施形態では、管理者アプリケーションと開発者アプリケーションは２つの個別のアプリケーションとして設けられ、メタデータとアプリケーションインターフェースとを含むシステムを構成する手段を提供する。

システム１００は、サービスアプリケーション１２４を支援するモバイル企業プラットフォームを含む。このシステムは、モバイルビジネスプロセスを強化するモバイル化ソフトウェアソリューションを効果的に配置管理する一組のウェブサービスを提供する。通常の例としては、ＣＲＭ又はＥＲＰへの統合化、セールスフォース自動化（ＳＦＡ）、企業のカスタマーサポート及びヘルプデスク機能が挙げられる。このような企業アプリケーションは、一つの機能又はシステムからのデータが、異なる機能又はシステムによりしばしば使用されるという点で、異アプリケーション相互作用（ｃｒｏｓｓ−ａｐｐｌｉｃａｔｉｏｎ ｉｎｔｅｒａｃｔｉｏｎ）に依存する。モバイルクライアント上で実行されると、既存のアプリケーション機能及び企業情報は、複数の企業ソフトウェアアプリケーションと、レガシーデータシステムと、モバイル従業員との間で利用される。このようにして、これらのアプリケーションに対し、そしてモバイル企業プラットフォームに対し大きな投資回収を達成することができる。

モバイル企業プラットフォーム１００は、フィールドにおけるモバイルクライアント及び関連する携帯機器の利用を簡単化するウェブサービスを提供する。これらのウェブサービスはデータマネージャ機能、環境設定機能及びコネクタ機能を含む。これらは、以下にさらに詳細に説明される。モバイルクライアント１０２にインストールされたアプリケーション１２４は、これらの機能がアプリケーションサーバ１０６により正常に開始された後、接続又は非接続状態いずれにおいても完全に機能することができる。

ＩＩＩ．論理アーキテクチャ
図１に例示されたモバイル企業プラットフォームを利用する任意のクライアントアプリケーションは、図２のブロック図に例示されたシステムコンポーネントを利用する。これらのコンポーネントは次のものを含む。

ビジネスオブジェクト：ビジネス概念に基づくプログラム可能なオブジェクトであり、異なる企業データソースからのフィールドと関連情報とを組み合わせる（例えば、顧客、コンタクト、資産、タスクなどのデータソース）。

ビジネスルール：企業データソースからのビジネスデータに対し適用されるチェック付きのビジネス定数を利用する、ビジネスプロセスを実施するためのカスタム論理。

ビジネス定数：クライアントアプリケーションを介して使用するためのユーザ構成可能な変数と、クライアント及びサーバ側のビジネスルール（例えば、ビジネスルール、警告メッセージ等）。

データソースコネクタ：広範囲の種類の企業データソースへのアクセスをシームレスに提供するように設計されたデータソースコネクタ（例えば、オラクル及びＳＱＬサーバに従ってフォーマットされたようなデータベース、ＭＱシリーズ又はＭＳＭＱのようなメッセージ通信システム、ジーベル又はピープルソフト（Ｐｅｏｐｌｅｓｏｆｔ）のようなＣＲＭアプリケーション、一般的なウェブサービス等）。

ビジネスプロセス：米国ワシントン州ボセルのデクステラ社の、ビジネスプロセスをモデル化するためのフォームツーフォーム（ｆｏｒｍ−ｔｏ−ｆｏｒｍ）ナビゲーションパラダイムを定義する「フォースフロー（Ｆｏｒｃｅ Ｆｌｏｗ）」処理のようなメタフォー（ｍｅｔａｐｈｏｒ）。

フォーム：情報を示し、情報を集め、所与のビジネスプロセスを通してユーザを導くように設計されたイベントドリブン論理を有する標準表示画面の組合せ（例えば、見る、編集、検出等）であり、ここでは「フォースフロー」又は「フィールドフロー（ＦｉｅｌｄＦｌｏｗ）」と呼ばれる。

ビュー：一つ又は複数のビジネスオブジェクトにより利用される企業データソース又はアプリケーションから識別された変更可能なデータのテーブル表現。

フィルタ：ビジネスオブジェクトに利用可能なデータを修正するための、ビューに対し適用可能なフィルタ。

これらのコンポーネントは、マイクロソフト社の「．ＮＥＴ」等のテクノロジーフレームワークと、マイクロソフト社の「ビジュアル スタジオ ネット（Ｖｉｓｕａｌ Ｓｔｕｄｉｏ．ＮＥＴ）」等のツールとを利用することにより構築される任意のクライアントアプリケーションの環境設定（論理アーキテクチャ）を指定するために使用することができる。当業者は、アプリケーション及びそれに関連するデータオブジェクトを指定するこのようなプログラミングツールに精通するであろう。

図１に例示されたモバイル企業プラットフォームは、メタデータドリブンフレームワークとして実施される。このフレームワークは統合化クライアント・サーバウェブサービスを提供し、フェールセーフかつミッションクリティカルなモバイル企業ソリューションを展開するのに必要な接続、環境設定、及びデータ管理サービスを可能にする。

図２は、図１のモバイル企業プラットフォームにおいて、リレーショナルデータベーステーブル及び外部アプリケーションビジネスオブジェクトの構造がメタデータとしてビューにマッピングされたことを示す。一つ又は複数のビューはビジネスオブジェクトにより使用され、メタデータで定義され、次にモバイルアプリケーションにより利用される。モバイルアプリケーションは「デクステラスマートクライアント（Ｄｅｃｓｔｅｒａ Ｓｍａｒｔｃｌｉｅｎｔ）」と呼ばれるクライアントフレームワークを利用する。このクライアントフレームワークは、データマネージャ及び／又はコネクタウェブサービスを介してのクライアントサーバデータ通信だけでなく、ビジネスオブジェクトのインスタンス化、モバイルクライアントデバイス上に常駐する内在物理データベースへのローカルデータアクセス、デバイス統合化を管理する。プラットフォームにおいて、すべての論理層（例えば、ビジネスオブジェクト、ビュー、フィルタ、コネクタ）に対する仕様はメタデータ内に定義され維持される。

モバイル企業プラットフォームは論理スタックとして設計され、論理アーキテクチャにおける層を、非隣接メンバーを除くすべてから隔離するように設計される。論理スタックの最下部（ターゲット層）には、バックエンドの企業データソースに常駐するデータが存在する。プラットフォームは所定位置のソースデータと連動し、従ってレコードのバックエンドシステム内の情報が中間層の複製データベースに複製されることを必要としない。すなわち、中間的なデータ記憶装置は必要ではない。これは、リアルタイムのデータアクセスだけでなく設計の柔軟性を提供し、プラットフォーム及びアプリケーションの維持管理総経費を低減するのに役立つことができ、データ管理プロセスの簡易化を支援する。

論理スタックにおける次の上位層はコネクタ層である。コネクタ層は、アプリケーションサーバへのバックエンドデータ格納をリレーショナルフォーマットで記述するプログラマチック構成体を提供する。セキュリティ設定（認証方法、ユーザ及びグループ定義等）だけでなく、企業データソースに接続する方法に関する情報もまたメタデータ内に格納され、そしてアドミニストレータコンポーネント（Ａｄｍｉｎｉｓｔｒａｔｏｒ ｃｏｍｐｏｎｅｎｔ）を使用することにより維持される。

スタックにおける次の層はビュー層であり、ビュー層はバックエンドの企業データソース内のオブジェクト又はテーブルへの１対１マッピングを提供するオブジェクトを含む。例えば、バックエンドシステムがＣＵＳＴ＿ＡＤＤＲ（顧客アドレス）と呼ばれるテーブルを有し、かつアプリケーションにおける使用のためにこのテーブルからのデータが必要とされる場合、アドミニストレータコンポーネント内にビューが生成される。企業データソース外では、モバイル企業プラットフォームの環境におけるこのデータを表すために、アドミニストレータビューは例えばＣＵＳＴＯＭＥＲ＿ＡＤＤＲＥＳＳと呼んでもよい。ビューはバックエンドシステムにおけるデータオブジェクトのプロパティ又はコラムに対応するプロパティを有するということを理解すべきである。しかしながら、バックエンドデータソース内のすべてのプロパティがビューにおけるプロパティとして必ずしも要求されない。実際は、必要とされるプロパティは、管理用コンポーネント（ａｄｍｉｎｉｓｔｒａｔｉｖｅ ｃｏｍｐｏｎｅｎｔ）において定義され、メタデータとして格納される。先ほどの例では、プロパティは、ＩＤ、番地（ＳＴＲＥＥＴ＿ＡＤＤＲ）、市、州、ジップコー（ドＺＩＰ＿ＣＯＤＥ）のようなフィールドを含んでもよい。

さらに、ユーザは、ビュー内でプロパティのデータタイプを定義することができ、そしてこれらのデータタイプは、企業データソース内の対応するプロパティのデータタイプとは独立していてもよい。識別可能なビュープロパティの他の選択肢は、一意的な識別子、リードオンリー、インデクシング、必要プロパティ、長さである。上記情報はすべてメタデータとして格納される。

また、ビュー層は、データコンフリクトの識別を提供し、そしてこのようなコンフリクトを解決する手段を提供する。データコンフリクトは、例えばモバイルクライアントからアップロード中のものとサーバに存在するものとの間にデータ変更がある場合は常に発生し得る。このようなコンフリクトの解決はビュー層において実行することができ、最新のデータ変更が常に優先することを許容する、あるいは特定のソース（例えば、モバイルクライアント又は企業データソースのいずれか）からのデータ変更がデータタイプ（例えば、フィールドデータ又は顧客アカウントデータ）に依存して優先することを許容する等のビジネスルールを実施する。これは、データマネージャウェブサービスに関連して以下にさらに説明される。

図２に図示されるように、複数のデータ記憶装置内の複数のオブジェクトに対してビューを定義することができ、従ってデータ複製の負担なしに、アプリケーション展開の際、また現場システムの使用の際の柔軟性を提供する。コネクタと同様に、ビューの定義はメタデータに格納されアドミニストレータにより管理される。当業者は、さらなる説明なしにメタデータ内のデータ定義の詳細を理解するであろう。上記のように、次の層に渡されるデータを修正するために、フィルタをビューに適用することができる。前述の管理者アプリケーションは、バックエンドデータ格納オブジェクト（企業データソースからの）のオブジェクトインターフェース又はテーブル定義に基づいてビューを自動的に生成するビューウィザードを含むビュー管理機能を提供する。

図２の図表における次の上位層は、一つ又は複数のビューにマッピング又は関連付けられるビジネスオブジェクトを含む。プラットフォームのビジネスオブジェクトは、カスタム化モバイルアプリケーションを構築する際に開発者がインターフェースするプログラマチックエンティティ（ｐｒｏｇｒａｍｍａｔｉｃ ｅｎｔｉｔｙ）である。ビジネスオブジェクトは、それぞれが簡易データタイプであってもよいし、あるいは別のビジネスオブジェクトであってもよい複数のプロパティを含む。プラットフォームのビジネスオブジェクトは複数のビューにマッピングされてよいので、開発者は、複数の異種混合のデータソースから供給されるデータを表す単一のエンティティを扱うことができる。従って、本発明のモバイル企業プラットフォームに従って定義された単一のビジネスオブジェクトは、複数の恐らく非互換の企業データソース（異なる独自フォーマット等）からのデータを含むことができる。

モバイルアプリケーション及びモバイルクライアントデバイス用のアプリケーションを作成するか修正する際、開発者はもっぱらビジネスオブジェクト層とやり取りすればよい。これにより、開発者はソースデータ用のバックエンドシステム（企業データソース）を理解するかあるいはそれと直接やり取りするためのいかなる要件からも逃れることができる。このようにして、ビジネスオブジェクト層は、アプリケーション開発者に対しオブジェクトベースのインターフェースを提供し、データの持続性（ｐｅｒｓｉｓｔｅｎｃｅ）及び検索の詳細を抽出する。開発者は移動体装置上のローカルデータ記憶装置と直接やり取りする必要はない。さらに、データが有する分離された性質により、モバイルクライアントは、更新処理中にアプリケーションサーバに渡されることになるデータ変更をクライアント内にローカルに格納することにより、ビジネスオブジェクトのインターフェースを介して自動的にこのデータ変更の処理を管理する。これにより、開発者はさらにこの機械的なプログラミングタスクからも逃れることができる。

ビジネスオブジェクトはメタデータとしてモバイルクライアントデバイス上に存在し、また、アドミニストレータ（図１）を使用することにより管理される。モバイル企業プラットフォームを通じてメタデータを使用することにより、ほとんどのデータエンティティの属性及び振る舞い（ｂｅｈａｖｉｏｒ）がコーディングではなくグラフィカルユーザインターフェースを介して構成することができる環境を提供する。

モバイル企業プラットフォームのメタデータ駆動的（ｍｅｔａｄａｔａ−ｄｒｉｖｅｎ）性質により、ステートレスサーバアーキテクチャによるモバイルクライアント上でのビジネスプロセスが実行できるようになる。メタデータを介することにより、モバイルアプリケーションを構成しカスタマイズすることができる。メタデータは、企業データを移動体装置へ参照させるビジネスオブジェクトの構造を定義し、また、ビジネスプロセスを管理するビジネスルールをトリガする事象を定義する。

メタデータデータベースは、ビジネスオブジェクトを構成するためにコネクタを介してエクスポーズないし公開（ｅｘｐｏｓｅ）されるクロスファンクショナル・クロスアプリケーション・バックエンドビジネス情報の参照子（ｒｅｆｅｒｅｎｃｅ）を含む。この処理は、接続する企業データソースビジネス情報をビジネスオブジェクトにより構成し参照するスタジオ（Ｓｔｕｄｉｏ）コンポーネント（図１）を介して達成される。これにより、このモバイルアプリケーションの特定データにパスを提供し、従って企業データソースからのいかなるビジネスデータも本来のデータフォーマットでアプリケーションサーバ上に、あるいはデータ更新のためにシステムの他のいかなる中間データ記憶装置上にも格納されないということを保証する。メタデータを使用するこの非侵入的でリアルタイムの同期手法は、クロスファンクショナルなデータアクセス、データ一貫性、及びデータ完全性を最大化する一方で、混乱を最少にしつつモバイル企業プラットフォームがバックエンドシステムに効果的に接続することを可能にする。

ＩＶ．モバイル企業プラットフォームコンポーネント
Ａ．モバイルアプリケーション
上記のように、モバイルクライアント１０２（図１）は、企業のビジネスプロセスを実施するインストール済みアプリケーション１２４を含むことができる。このアプリケーションは上述のモバイル企業プラットフォームを活用することができ、メタデータ内に構成されたビジネスプロセスを駆動するビジネスオブジェクトをアプリケーションがどのようにインスタンス化するかを示す。

例えば、タスク又は作業命令情報はビューを介してモバイルアプリケーションに提供され、ビジネスオブジェクトを介してアクセスされるであろう。ビュー定義を介したビジネスデータの検索では、データマネージャウェブサービスを利用することにより、ビジネスオブジェクトは、タスクを説明するために、モバイルアプリケーションにビジネスデータを配信することができる。このデータは移動体装置上のローカルリレーショナルデータベースに格納される。タスクデータに対する更新がアプリケーションからの要求内のタスクビジネスオブジェクトに委ねられると、スマートクライアントアプリケーションは、モバイルクライアント上のビューにより定義済みのデータ記憶装置への変更を保持する。次にスマートクライアントは、データマネージャウェブサービスを介しこのデータ更新を元のデータソースへ戻す管理を行い、こうしてデータの完全性と一貫性を保証する。

ここで説明されるモバイル企業プラットフォームにおいて利用可能なウェブの深さ、広さ、パワー、サービス（例えば、接続、構成、及びデータマネージャサービス）を利用することにより、セールスフォースの生産性、顧客サービス、及び支援ソリューション等のアプリケーションを含む大規模なモバイルアプリケーション群を容易に構築することができる。このようなアプリケーション群は、石油／ガス、ヘルスケア／医療、及び金融サービス産業のソリューションを含む広範囲な一組の垂直形アプリケーションに統合することができる。

Ｂ．サーバコンポーネント
アプリケーションサーバは一種のメタデータ駆動のプラットフォームアプリケーションであり、情報、アプリケーション及びビジネスプロセスをモバイルクライアントに提供し、モバイル企業プラットフォームとバックエンド企業データソースのホストとの間のデータ完全性の管理を保証する。アプリケーションサーバは、米国ワシントン州レドモンド（Ｒｅｄｍｏｎｄ， Ｗａｓｈｉｎｇｔｏｎ， ＵＳＡ）のマイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）の技術「ネット（．ＮＥＴ）」上に構築される処理ベースの高性能ソリューションである。「．ＮＥＴ」技術を使用することにより、モバイル企業ソリューションは、データ交換とデータ移送のためのＸＭＬとＳＯＡＰを利用した固有のウェブサービスであるフレームワークとなる。アプリケーションサーバは、図１の機能アーキテクチャ図に示すように３つのコアウェブサービスを提供する。

コネクタウェブサービス
コネクタウェブサービスは、モバイルクライアントと個別の企業データソース間のデータ完全性条件（Ｄａｔａ−Ｉｎｔｅｇｒｉｔｙ Ｃｏｎｄｉｔｉｏｎｓ）を常に制御する一方で、既存の企業アプリケーションインフラストラクチャーの非侵入的な統合を提供する。

コンフィギュレーションウェブサービス
コンフィギュレーションウェブサービスは、ビジネスデータ、ビジネスオブジェクト、ビジネスルール、ビジネス定数、及び認証、ロギング、セキュリティ、モバイルクライアントに渡されるモバイルアプリケーション（移動体装置上に常駐するコンポーネントアプリケーション）を包含する役割などのシステム構成を定義するメタデータを管理する。

データマネージャウェブサービス
データマネージャウェブサービスは、モバイルクライアントアプリケーション、アプリケーションサーバ、第三者企業データソース間の更新対話処理を指揮する。加えて、データマネージャウェブサービスは、リアルタイムの照会のためにコネクタ層と直接通信を行う能力を提供する。データマネージャウェブサービスは、データの保全を実施するために、複数の企業データソースに対する複数ユーザによる複数の更新に関する様々な条件を管理する方法における柔軟性を提供する。データマネージャウェブサービスはアプリケーションサーバを介してこれを行うか、あるいは任意のＡＰＩ、及び／又は第三者の公開ウェブサービスにこれを導いてもよい。

このようにして、データマネージャウェブサービスは、システムのモバイルクライアントを通じてアプリケーション更新とデータ変更の展開を管理することができる。これらのコンポーネントの各々について次にさらに詳細に説明する。

１．コネクタウェブサービス
コネクタウェブサービスは、すべてのＯＤＢＣ準拠データソース又はウェブサービスＡＰＩとの通信を支援するように設計される。コネクタウェブサービスは、顧客が、一つ又は複数の第三者システムに格納されたデータに基づいてビューを定義し構築することを可能にする。コネクタウェブサービスは、モバイルクライアントからのリアルタイムデータアクセスだけでなく標準的なバッチ更新も許容する公開インターフェース（Ｐｕｂｌｉｓｈｅｄ ｉｎｔｅｒｆａｃｅ）を有する。

コネクタウェブサービスは、アプリケーションサーバメタアプリケーションと企業データソースの特定インターフェースとの間の物理層接続を提供する。このコネクタは、データベース競合管理及び通知サービス、トランザクション管理、エラー処理を支援する。デフォルトの顧客構成（ｃｕｓｔｏｒｍｅｒ ｃｏｎｆｉｇｕｒａｔｉｏｎ）では、モバイル企業プラットフォームシステムはＯＤＢＣコネクタ又はウェブサービスコネクタを備えた顧客に展開される。当業者は、ジーベル、ＳＡＰ、ピープルソフト、オラクル、ＳＱＬサーバのような最も一般的な企業システムへのコネクタを形成することができるであろう。

例えば、「オラクル」アプリケーションコネクタにより、顧客が有するＡＰＩ（ＰＬ／ＳＱＬ手順等）に最も近いデータ構造を介して顧客がオラクルサポートサービスを呼び出す、あるいは顧客がＯＤＢＣを介して直接企業データベース自体を呼び出すことができるようにする。すべてのＯＤＢＣコネクタと同様に、ＲＤＢＭＳスキーマの動的な問合せは自動的に実行され、特定のデータベースの物理的設計を公開する。これにより、このシステム内への実際のインターフェースの階層的ビューを顧客に与える。

図３は、どのようにコネクタが企業データソースをモバイル企業プラットフォームへインターフェースするかの例を示す。図３の左側には、ＥＲＰデータソース３０２、ＣＲＭデータソース３０４、人事／財務データソース３０６、レガシー／ＯＤＢＣデータソース３０８を含む複数の企業データソースが表されているが、他のウェブサービス又は他のソース（図示せず）を含んでもよい。図３の中間部には、異なる企業データソースからのデータがどのように図３の右側に示すモバイルクライアント３１６内に格納され関連付けられるかをアプリケーションサーバ３１４に対して規定する、メタデータ３１２が表されている。

この例では、ＯＲＤＥＲ＿ＩＤとして識別されるデータがＥＲＰデータソース内に存在する。Ｆ＿ＮＡＭＥ及びＬ＿ＮＡＭＥとして識別されるデータがＣＲＭデータソース内に存在する。ＣＲＥＤ＿ＬＩＭと識別されるデータは人事／財務データソース上に存在し、保証（ＷＡＲＲＡＮＴＹ）と識別されるデータはレガシー／ＯＤＢＣデータソース内に格納される。これらの識別されたデータはすべて、バックエンドオフィスシステムなどの企業データソース内に格納される。

メタデータ３１２内では、企業データソースからのデータ定義は、クライアント上にデータ記憶装置を作成することと、モバイルクライアント上のこのビジネスデータ（企業データソースからのもの）をリレーショナルデータベースに格納することとのために使用されるビューにマッピングされる。このビジネスデータへのアクセスは、モバイルクライアント上のメタデータ内に定義され格納されたビジネスオブジェクト層を介して行われる。図３に示すように、ＥＲＰデータソースからのＯＲＤＥＲ＿ＩＤは注文ＩＤと呼ばれるビジネスオブジェクトプロパティにマッピングされる。注文ＩＤのリレーショナル定義はモバイルクライアント３１６上のメタデータ３１８に格納され、そしてメタデータにおいても定義された一つ又は複数のモバイルアプリケーションにより利用される。ＣＲＭ企業データソースからのＦ＿ＮＡＭＥデータは、モバイルクライアントデータベース内に格納されたファーストネームのビジネスオブジェクトプロパティ定義にマッピング（格納）され、Ｌ＿ＮＡＭＥデータはラストネームのビジネスオブジェクトプロパティにマッピングされる。同様に、人事／財務データソースからのＣＲＥＤ＿ＬＩＭデータはクレジット限度のビジネスオブジェクトプロパティにマッピングされ、レガシー／ＯＤＢＣデータソースからのＷＡＲＲＡＮＴＹデータは保証のビジネスオブジェクトプロパティにマッピングされる。従って、恐らく類似しない非互換の異種の企業データソース３０２、３０４、３０６、３０８、３１０からのデータは、モバイルクライアント上のビジネスオブジェクトの一つ（モバイルクライアント３１６内では実際の値で示す）を使用するアクセスに対し、適切なフォーマットでデータマネージャウェブサービスを介しモバイルクライアントへ、そしてローカルデータ記憶装置へ伝達される（企業データソースからアプリケーションサーバ３１４に到る線により示す）。

コネクタタイプ
コネクタウェブサービスにより支援されるコネクタには以下の３つのコネクタタイプがある。

１．ウェブサービスコネクタは、次の場合、すなわちモバイルプラットフォームが第三者システムに接続しており、この第三者システムが（ａ）ＯＤＢＣ非準拠である場合、又は（ｂ）ＯＤＢＣ／ＲＤＢＭＳ接続性を許容しない場合、又は（ｃ）そのインターフェースが標準ＡＰＩにより定義され、かつウェブサービス記述言語（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒ Ｌａｎｇｕａｇｅ：ＷＳＤＬ）によりラップされ定義される場合のいずれかの場合、使用される。

２．ＯＤＢＣ／ＲＤＢＭＳコネクタは、次の場合、すなわち第三者システムにモバイルプラットフォームを接続するときに（ａ）この第三者システムがＯＤＢＣ準拠であり、かつ（ｂ）直接ＯＤＢＣ／ＲＤＢＭＳアクセスを許容し、かつ（ｃ）そのデータが同じＬＡＮ環境内に物理的に配置されているか、あるいはその移送を支援する通信プロトコル（ＲＰＣ、ＴＣＰ等）を介してアクセス可能である場合に、使用される。

３．ＡＰＩコネクタは、ウェブサービスコネクタに類似しているが、（ａ）ＲＰＣ等の非インターネットプロトコルを介してアクセス可能であるＡＰＩを必要とし、かつ（ｂ）ウェブサービスインターフェースが利用可能でない場合に使用される。

ＯＤＢＣ／ＲＤＢＭＳコネクタを介しスキーマ情報を読込むことは、アドミニストレータアプリケーションを使用しモバイル企業プラットフォームのスタジオ（Ｓｔｕｄｉｏ）部１３０（図１）を使用することにより達成される。スタジオ部は、バックエンドデータソースへのビュー定義マッピングを構成するとともに一つ又は複数のビューの定義を一つ又は複数のビジネスオブジェクトにマッピングするために使用される。アドミニストレータを使用することによりビュー定義を定義するか、あるいはビューをビジネスオブジェクトにマッピングする際、この情報はメタデータとして格納される。アプリケーションサーバと企業データソースによる更新処理中、このメタデータは、データ（選択／挿入／更新／削除機能）をどのように読込み、保持し、除去するかを確定するとともにコンフリクト検出／解決、トランザクション（両者ともに固有のもの）、そして適切ならば補正などの機能を使用することによりデータの完全性を管理し実施するために読込まれる。

ＯＤＢＣ／ＲＤＢＭＳコネクタを使用することにより、データは、ＡＮＳＩ ＳＱＬステートメント、及び／又はマイクロソフト社のＳＱＬサーバ又はオラクル社のＲＤＢＭＳ（８ｉ、９ｉ等）の場合はストアドプロシージャを介して読込まれ、保持され、及び／又は除去される。ウェブサービス／ＡＰＩコネクタを使用することにより、データは、適切なＡＰＩ機能又はトランザクション方法を呼び出すことにより読込まれ、保持及び／又は除去される。

２．コンフィギュレーションウェブサービス
デクステラ スタジオにより使用されるコンフィギュレーションウェブサービスは、デクステラモバイル企業ソリューション（Ｄｅｘｔｅｒｒａ Ｍｏｂｉｌｅ Ｅｎｔｅｒｐｒｉｓｅ ｓｏｌｕｔｉｏｎ）を実施し、構成し、管理する管理者、ビジネスアナリスト、及び開発者に対し簡単で相互運用可能な方法を提供する。コンフィギュレーションウェブサービスは、モバイルアプリケーションのデータ及びプロセス定義を構成しカスタマイズするために使用されるメタデータの簡単な操作を可能にする。このサービスは、以下にさらに詳細に説明されるアドミニストレータコンポーネントの特徴を参照することにより一層理解されるであろう。

３．データマネージャウェブサービス
更新処理モデル
更新処理モデルは、簡単な相互運用性のウェブサービスとして公開された一組のコアネットコンポーネントを使用するバックエンド企業データベースによりローカルに保持されたデータ（アプリケーション又はそのビジネスオブジェクトのいずれか）を、モバイルアプリケーションが更新するシステムにおいて利用される。

データマネージャウェブサービスは、モバイルアプリケーションと、その関連ビジネスオブジェクトで定義されたデータすべてを更新する。更新処理モデルは、デクステラアプリケーションサーバを介した企業データソースとモバイルクライアント間の双方向データ転送を可能にし、これによりモバイルクライアントがネットワークに接続中に更新が行われるようにし、両者が接続される際にクライアント同士間で更新をマージする。非接続状態時は、接続状態が達成され更新要求が開始可能となるまで更新はクライアント環境において管理される。

更新処理モデルは「オールオアナッシング（ａｌｌ ｏｒ ｎｏｔｈｉｎｇ）」の手法を取る。全ストリームがアプリケーションサーバからモバイルクライアントへダウンロードされる前に（あるいは全ストリームがクライアントからサーバへアップロードされる前に）故障が発生した場合、アプリケーションサーバ上のデータマネージャウェブサービスはダウンロードトランザクション（又はアップロード）に関する確認を受付けない。この結果、サーバは、それがデータのロールバックを必要とするか、又は単に再試行を必要とするかに関し、クライアント状態を管理するための情報を運ぶ。モバイルクライアントが２回目の更新処理操作を行う際、アプリケーションサーバは元の情報状態を考慮し、そしてアプリケーションサーバが処理を完了した場合、アプリケーションサーバはその結果を提供してよい、あるいはアプリケーションサーバがすべての必要情報を決して受信していなく、従って信頼できる情報配送を一回、かつモバイルクライアントとアプリケーションサーバとの間で一回のみ実施する場合、アプリケーションサーバは再度処理を行ってよい。データがモバイルクライアントから一つ又は複数のバックエンドデータソースへ移動する際、念のためデータの保全を実施する。

更新処理の詳細
２つのタイプの更新処理がサポートされる。

１：最新版を入手：この更新タイプでは、モバイルクライアントは、デクステラアプリケーションサーバを介して企業データソースから最新情報を入手するための要求を行う。デクステラアプリケーションサーバはこの要求を処理し、デクステラコネクタウェブサービスを使用することにより複数のデータソースからビジネス情報を検索し、このビジネス情報をモバイルクライアントに送る。

２：更新（双方向更新）：この更新タイプでは、クライアントとサーバエンドの両方の側の記録は、モバイルクライアントと、デクステラコンフリクトレゾリューション（Ｄｅｘｔｅｒｒａ Ｃｏｎｆｌｉｃｔ Ｒｅｓｏｌｕｔｉｏｎ）で構成されたパラメータを使用するバックエンド企業データソースと、の両方の側でデータの保全を実施することにより交換される。

コンフリクト検出／解決
コンフリクト解決は、モバイルクライアントと一つ又は複数のバックエンド企業データソースとの間でなされた変更に起因するデータコンフリクトに関する調停に使用される規則を記述する。これは、最初にコンフリクトを識別し（検知）、次に一つ又は複数の様々な方法でコンフリクトを解決することにより実行される。

デクステラアプリケーションサーバは次の３つの方法、すなわち、版数、日時スタンプ、又は手動のうちの一つの方法で検出できるだけでなく、行又は列レベルによりコンフリクト状況を識別できる。

版数は、改版された単一レコードソース内の特定フィールド又はプロパティが識別される設定であり、デクステラアプリケーションサーバはこれを使用することによりバックエンドデータソース又はモバイルクライアントのいずれかでデータが変更されたかどうかを判断する。

日時スタンプ
日時スタンプは、特定フィールド又はプロパティが日時スタンプとして単一レコードソース内で識別され、何らかの挿入／更新又は削除があると更新される設定であり、デクステラアプリケーションサーバはこれを使用することにより、バックエンドデータソース又はモバイルクライアントのいずれかでデータが変更されたかどうかを判断する。

マニュアルは、単一レコードソース内にコンフリクト状況を識別するための特定フィールド又はプロパティがない設定であり、従ってデクステラアプリケーションサーバはすべてのフィールド又はプロパティデータを比較して一意性を定義し、バックエンドデータソース又はモバイルクライアントのいずれかでデータが変更されたかどうかを検知する。

デクステラアプリケーションサーバの構成に依存して、コンフリクトは次の４つの方法、すなわち最初の更新が勝つ、最後の更新が勝つ、アドミニストレータ解決、サーバ側規則のうちの一つの方法で解決される。

最初の更新が勝つ
最初の更新が勝つモデルでは、アプリケーションサーバは、更新を行う最初のものである任意のレコードの変更を受理するのみである。記録がバックエンドデータソースにより最初に更新され、そしてコンフリクトが更新ウェブサービスにより検知された場合、エラーを戻す代わりに、データマネージャウェブサービスはクライアントにより提供されたバージョンをやめて、このレコードの最新バージョンの複製をバックエンド企業データソースからモバイルクライアントに戻す。

最後の更新が勝つ
最後の更新が勝つモデルではサーバはコンフリクトを検知する必要はない。その代り、サーバはバックエンド企業データソース内の現在の記録に上書きすることにより、モバイルクライアントからバックエンド企業データソースへの変更を単に保持する。

アドミニストレータ（又はマニュアル）解決
アドミニストレータ／マニュアル解決として構成された場合、サーバは、すべてのコンフリクトを、解決すべきマニュアル介入を必要とするものとして処理し、バックエンド企業データソースから現在の記録の複製を戻し、そして随意に、コンフリクト状況が発生した旨を任意の通知サービス（ＳＭＳ、Ｅｍａｉ等）を介して通知し、デクステラアドミニストレータを介し解決することができる。このアドミニストレータが選択的にバックエンド企業データソースに再適用すべき値を判断するので、このようにすることによりコラムレベルのコンフリクト解決が可能となる。

サーバ側規則
カスタマイズ可能なサーバ側規則は、あるコンフリクト状況をどのように解決すべきかをよりプログラマブルにかつ具体的に判断するために作成することができる。例えば、コンフリクトは記録内のデータの値に基づいて解決されてよい。この柔軟性により、コンフリクト解決シナリオを取り巻く具体的なアクション全体の完全な制御が可能となる。

サーバからのクライアント展開
アプリケーションサーバはモバイルクライアントにダウンロードされる一つ又は複数のモバイルフィールドアプリケーションの定義を含み、これはビジネスプロセス／ワークフロー内に構築されるタスク（「フォームフロー（ＦｏｒｍＦｌｏｗｓ）」と呼ばれる）、データ対話処理（「フィールドフロー（ＦｉｅｌｄＦｌｏｗ）」と呼ばれる）、フォームフローとフィールドフローのグループ（「フォースフロー（ＦｏｒｃｅＦｌｏｗ）」と呼ばれる）として表されるフォーム／画面を含む。フォームフロー、フィールドフロー、フォースフローについては以下にさらに説明される。アプリケーション定義は、また、ビュー、ビジネスオブジェクト、ビジネス定数定義のようなアプリケーションに関連する構成済みメタデータを含む。また展開の際に含まれるのは、「時々の」接続状態においてモバイルクライアントを走らせるのに必要な一つ又は複数のバックエンド企業データソースからの特定のビジネスデータである。

アプリケーションサーバは、アプリケーションを提供し管理するとともに既存の企業データソース及びシステムに接続するための基盤を提供する。モバイル企業プラットフォームアプリケーションは、アプリケーションサーバにより、ポケットＰＣ、タブレット型ＰＣ装置などの移動体装置に配布され管理され、これによりフィールドにおけるすべてのユーザインターフェースを高度に管理可能とする。

Ｃ．アドミニストレータコンポーネント
上記のように、アドミニストレータコンポーネント（図１）により、システム管理者は比較的通常の又は頻繁な変更を行うことができる。アドミニストレータコンポーネントは、ビジネスアナリスト又は管理者が管理するための適切なフォーマットで、判断変数、ドロップダウン式リストコンテンツ、その他情報へのアクセスを提供する。この管理の手法により、システム管理者はシステム完全性を妥協することなく、多くの機能をアドミニストレータレベルまで拡張できるようになる。

例えば、企業のビジネスプロセスを定義するために使用されるビジネス情報から成るデータは、ビジネスオブジェクト定義フォームを介して受信することができる。コンフィギュレーションウェブサービスは、アドミニストレータコンポーネントのこの様相へのアクセスを提供する。

Ｄ．クライアントコンポーネント
上記のように、企業プラットフォームアーキテクチャにおけるクライアント１０２は、モバイルアプリケーションが「フォースフロー」、「フィールドフロー」、「フォームフロー」と呼ばれる技術を使用するとともにウェブサービスを使用する役割ベースのビジネスプロセスの使用を可能にするフレームワークを提供し、従って有線及び無線接続を介した、モバイルクライアントと、デクステラアプリケーションサーバと、インターネットなどのＬＡＮ／ＷＡＮネットワーク上の企業データソースとの間の通信が可能となる。クライアントデバイス上で走るモバイルアプリケーションは、ユーザ体験を習得するのがことの他容易な小型装置に対し最適化されたやり方で機能する。

例示されたシステムでは、クライアントは、メタデータを考慮するマイクロソフト社の「．ＮＥＴコンパクトフレームワーク」を利用して構築されるオブジェクトフレームワークである。クライアントコンポーネントは、好ましくはマイクロソフト社の「ポケットＰＣ」オペレーティングシステム又はマイクロソフトタブレットＰＣオペレーティングシステムに従って動作する企業向けアプリケーション機能の移動体装置上への配送を可能にする。クライアントコンポーネントは、また、ポケットＰＣインターフェースのカレンダー、タスク、トゥデイスクリーン（Ｔｏｄａｙ ｓｃｒｅｅｎ）機能とのシームレス統合を提供するために、既存の「ポケットＰＣ」機能と一体化する。これによりクライアントコンポーネントは、作業するための安定した効果的な環境を提供する。

フォームフロー、フィールドフロー、フォースフロー
表示画面形式のすべてのビジネスプロセスタスク、すべての工程、又はすべての操作は、「フォームフロー」と呼ばれる。フォームフローは、「フォースフロー」と呼ばれるビジネスプロセスの開始を許可する「フィールドフロー」と呼ばれるプロセス対話処理を開始するために使用される。フィールドフローは、実世界の融通性をビジネスプロセスにもたらすために「帯域外（ｏｕｔ ｏｆ ｂａｎｄ）」フォースフローの開始を許可する。

フォームフローは、（１）情報、（２）活動、（３）更新の３つのカテゴリに分解される。情報フォームフローは、ビジネスプロセス内の次の論理タスクを遂行するために、モバイルユーザにより必要とされる情報を示す画面である。活動フォームフローは、ユーザが実行する必要があり得るものを示す画面である。更新フォームフローは、モバイルユーザがホストアプリケーション（企業データソース）に戻されるデータを入力することを指示された際に表示される画面である。

フィールドフローは、例えば、部品が故障したかもしれなく、そして解決法にマッチする部品又は同様の問題が存在しかつ利用可能かどうかを調べるために在庫データベースの探索（照合（ｌｏｏｋｕｐ）と呼ばれる）が実行される必要があり得る場合に必要とされるか、あるいは、クライアントへの配送のために、部品を注文又は割り当て又はスケジューリングする必要があるかもしれない場合に必要とされ得る（更新と呼ばれるフィールドフロー）。

フォースフローはビジネスプロセスであって、従ってフォームフローとフィールドフローの集合である。フォースフローの一例は、仕事又は派遣イベントに関連する時間、出張、費用を記録することであろう。

再度図２を参照すると、このブロック図は、ターゲットアプリケーションにおけるコラムとフィールドとの関係がどのように「フォームフロー」（アプリケーションでは「フォーム」と表示されるビジネスプロセスにおける工程）における情報に関係するか、そして次にフォースフロー（ビジネスプロセス）に関係するかを示す。すべてのビジネスプロセスでは、一つのフォームフローそして可能性として二つ以上のフォームフローにおいて多くのビジネスオブジェクトが存在し得る。

フィルタは、モバイルアプリケーションにおいて参照されると、特性と条件がデータに付加されるようにする。例えば、データタイプ（例えば、日付）、有効なタイプ（例えば月曜から金曜までのみ）、任意のコンフリクト条件が検知されてもよい。他のフィルタ特性及び条件が構成されてもよい。

ビューは一つ又は複数のビジネスオブジェクトで使用されるデータと記憶場所を定義し、ビジネスオブジェクトは一つ又は複数のビューに基づいてよい。これにより、追加の特性を関連付けることができる。例えば、ビジネスオブジェクトは「顧客」と呼ばれ、「顧客」は、標準的な顧客詳細である場所、接触、在庫、そしてまたアプリケーションが顧客として分類したいが同じターゲットテーブル又はターゲットアプリケーション内に保持したくないＳＬＡ及び他の属性を含んでよい。

Ｖ．アダプタアーキテクチャ
本発明によるアダプタアーキテクチャは図４に例示される。図４に例示されたコンポーネントのいくつかは図１に例示されたコンポーネントに類似している。図１のシステムに提供された対応するコンポーネントの機能を実行する図４におけるコンポーネントは、「１」ではなく「４」で始まることを除いて図４では同じ参照符号により識別される。

図４は、本発明により構築された、好適なコンピュータシステム環境４００のブロック図である。図４は、マイクロソフトポケットＰＣ又はパームＰＤＡオペレーティングシステムと共に動作する個人用デジタル情報処理端末（ＰＤＡ）装置のようなモバイルクライアントデバイス４０２を示す。クライアントデバイス４０２は図１のクライアントデバイス１０２に関連して説明されたのと同じコンポーネントを含むが、図解の単純化のために図４では例示されない。サーバからデータを要求し、データ更新を受信し、新しいデータを提供し、構成変更を受信するために、モバイルクライアントデバイス４０２は、ネットワーク接続４０４上でアプリケーションサーバ４０６と通信を行う。複数のモバイルクライアント４０２がサーバ４０６と通信を行うことができることを理解すべきである。図の簡潔性のため、図４では単一のクライアントデバイス４０２のみが示される。

モバイルクライアント４０２は、複数の企業データ記憶装置からのリアルタイムデータ検索のためにサーバ側コネクタウェブサービスを使用する。さらに、モバイルクライアントは、リアルタイムのクライアント側データ更新、サーバ側データ更新、システム構成更新の管理のためにサーバ側データマネージャウェブサービスを使用する。

アプリケーションサーバ４０６は、ＣＲＭデータソース、ＥＲＰソース、財務システム資源、レガシーデータ記憶装置等の企業データソース４０８と通信を行う。

「デクステラ スタジオ」コンポーネント４３０はサーバ４０６と通信を行い、管理者アプリケーションと開発者アプリケーション（図４では図示せず）を含む。特に、スタジオ（Ｓｔｕｄｉｏ）コンポーネントはサーバ４０６のコンフィギュレータとインターフェースし、データサーバＤＤＳは、サーバとサーバ４０６のアダプタフレームワークとインターフェースし、このアダプタフレームワークは企業データソース４０８と通信を行う。

アダプタフレームワークは、サーバ４０６と他の任意の企業データソースとの間のデータを移動させる際に必要とされる特定の入力と出力を実行するインターフェースを提供する。サーバ４０６のデータマネージャは、アダプタフレームワークを介して企業データソース４０８と通信を行うために、すべての適切に定義されたコネクタコンポーネントに対し要求し応答する。こうして、サーバ４０６は接続オブジェクト、コマンドオブジェクト、データオブジェクト、ビューの定義を使用して、どのようにして、どのデータを検索又はバックエンド企業データソースに保持するかを判断する。

開発者がアダプタフレームワークのコンポーネントを指定できるように、設計ツールキット（「デクステラアダプタデザイナー」又はＤＡＤ）はスタジオ（Ｓｔｕｄｉｏ）４３０を備える。すなわち、ＤＡＤ４３０は、開発者に、デクステラ スタジオ ＶＳ．ＮＥＴプラグインを利用する任意のデクステラ支援アダプタ（デクステラ Ｓｕｐｐｏｒｔｅｄ Ａｄａｐｔｅｒ）にアダプタフレームワークデータコンポーネントを接続し構築する手段を与える。コンポーネントとしては、接続オブジェクト、コマンドオブジェクト、データオブジェクト、ビューが挙げられる。

ＤＡＤ４３０を使用し、開発者は、デクステラ支援アダプタを使用することによりバックエンドデータソースに対する接続オブジェクトを作成する。この接続オブジェクトは、テーブル、ストアドプロシージャ、スクリプト、又はオブジェクト（ＥＡＩ等）のいずれかとしてアダプタを介し利用可能なデータインターフェースオブジェクトを公開する（発見／内部観測（Ｉｎｔｒａｓｐｅｃｔｉｏｎ）又は説明のいずれかを使用することにより）。次に、デクステラアダプタデザイナーを使用し、開発者は、選択、挿入、更新、及び／又は削除などのアダプタを介した特定のアクションを実行する一連のコマンドオブジェクトを作成する。次に、開発者はデータオブジェクトを定義し、そこで適切な選択コマンド、挿入コマンド、更新コマンド、及び／又は削除コマンドを選択する。次に、ビューは、その要求／応答アクションに対するデータオブジェクトに結合される。このツールとアーキテクチャを使用することにより、開発者は、デクステラサーバ４０６内の単独に定義されたデータオブジェクトにマッピングされた一つ又は複数のバックエンド企業データソースからデータを要求し保持し、こうしてアブストラクション層を物理データ構造に与え、インターフェース能力を与えることができる。これらのアクションは以下に記載されるようにツール４３０のユーザインターフェースによって実行することができる。

Ａ．コマンドオブジェクト
アダプタフレームワークのコマンドオブジェクトは、データを検索又は保持するために、アダプタ（すなわちコネクタ）を介して実行されるアクションを定義する。例えば、アダプタを介して企業データソースへ顧客データオブジェクトを保存するために「顧客保存（ＳａｖｅＣｕｓｔｏｍｅｒ）」コマンドを定義することができる。コマンドタイプ又はコマンドフォーマットは、それらがインターフェースし、従って支援しなければならない企業データソースに応じてアダプタにより確定される。例えば、モバイルデータシステムに対して可能なコマンドタイプとしては、テーブル、手順、ＳＱＬ、スクリプト、オブジェクトが挙げられよう。

コマンドオブジェクトは、実行されるアクションを指定する。本発明によると、コマンドアクションタイプは次の５つの定義済みアクションを含む。（１）読込、（２）追加、（３）更新、（４）削除、（５）編集読込（ＲＥＡＤ ｆｏｒ ＥＤＩＴ）。これらのコマンドアクションは、データオブジェクトの議論に関連し以下にさらに説明される。コマンドオブジェクトは、コマンドが実行されると動作することになるフィルタを指定することができる。各フィルタは、対応するコマンドタイプのデータタイプに従ってデータに作用する。コマンドは、コマンドが実行されると戻されるコラムデータから成るコラム属性を含む。最後に、コマンドは、コマンドの適切な実行のために必要な値を指定するパラメータを含む。

Ｂ．データオブジェクト
データオブジェクトはデータを検索又は保持するためにコマンドオブジェクトを関連付け、それらを単独のオブジェクト（例えば顧客オブジェクト）に論理的にグループ化する。データオブジェクトは、アダプタを介して企業データソース上で実行されるコマンドにより（すなわち、コマンドの結果として）定義される。上記のように、コマンドは読込、追加、更新、削除、編集読込を含む。読込コマンドは、データを検索し、どのデータコラムが戻されるか、それらの属性は何かを定義するコマンドオブジェクトであり、アダプタから「．ＮＥＴ」パラダイムへキャスティングするデータタイプを上書きする。追加コマンドは、新しいデータインスタンスを元の対応する企業データソースに挿入するために、アダプタを介してデータの新しいインスタンスを保持するコマンドオブジェクトである。更新コマンドは、既存データ要素への変更を、元の対応する企業データソースへアダプタを介して保持するコマンドオブジェクトである。削除コマンドは、アダプタを介して企業データソースからデータを削除するコマンドオブジェクトである。編集読込コマンドは、アダプタを介した行ロック（ＲｏｗＬｏｃｋ）により単一レコードを検索するコマンドオブジェクトである。

定義されたデータオブジェクトは、読込コマンドの戻り要素を、追加、更新、削除、編集読込コマンドのパラメータへマッピングする。単一の定義されたデータオブジェクトは、恐らく異なるアダプタへの異なるコマンドを介してデータを検索し保持することができる。

Ｃ．接続（コネクション）
前と同様に、モバイルクライアントアプリケーションによるデータアクセスを実現するために、接続は企業データソースにインターフェースする。本発明に関連して説明されたアダプタフレームワーク４３０において、接続は、ビューと直接通信を行わないがその代り、コマンドオブジェクトと直接インターフェースし、最終的にデータオブジェクト及びビューとデータを交換する。

ＶＩ．構成とユーザインターフェース
図４の構成のサーバ４３０のアダプタフレームワークでは、本発明を有しないシステムにおける場合にそうであるように（そして図２に示すように）、ビューは単一データテーブルに結合されていない。むしろ、ビューは、読込、追加、更新、削除、編集読込に対して定義されたコマンドを有するデータオブジェクトに結合される。こうして、さらに汎用性のあるデータインターフェースが提供される。ビューの構造は、データオブジェクトの読込コマンド内に指定された、選択データコラムにより定義される。

本発明のビューオブジェクト構成を利用するシステムでは、ビューオブジェクトにおいてではなくコマンドオブジェクトにおいてフィルタが生成される。サーバ４３０におけるビューオブジェクトの構成は、企業データソースへのビューＣＲＵＤ（生成、読込、更新、削除）操作の抽出を可能にし、ＣＲＵＤがハードコーディングされるのではなく定義されるのを可能にする。フィルタの生成等のために変更されるビュー構成と、付随する変更以外に、図１に例示された残りのコンポーネントは、本発明に従って構築されたモバイルプラットフォームシステムのために利用することができる。

図５は、図１に例示された、本発明の実施形態を含むモバイルプラットフォームのためのデータアーキテクチャの線図的表現を示す。図５は、データシステムのビューオブジェクトがビューＩＤを有し、定義済みデータオブジェクトに結合されることを示す。図５は、データオブジェクトが読込コマンド、追加コマンド、更新コマンド、削除コマンド、編集読込コマンドの内の一つ又は複数のコマンドを含むことができることを示す。

図５は、コマンドオブジェクトもまたデータオブジェクトに結合され、そしてまた接続オブジェクトに結合され、この接続オブジェクトは次にアダプタオブジェクトに結合されることを示す。図５は、上述のように、モバイルプラットフォームのためのデータを検索するために、アダプタオブジェクトが、企業データソースとインターフェースするメタデータ記憶装置とインターフェースすることを示す。

図６は、本発明により構築されたモバイルプラットフォームのためのデータアクセス構成の線図的表現である。図６は、モバイルクライアント（図６では「デクステラクライアント」として示す）が、サーバにおけるビューオブジェクトを介してアプリケーションサーバ（図６の「デクステラサーバ」）と通信を行うことを示す。ここで、ビューオブジェクトは、企業データ記憶装置（例えば、図６では、マイクロソフトＳＱＬサーバとジーベルデータサーバ）と最終的に直接インターフェースするアダプタオブジェクトにアクセスするコマンドオブジェクトを介して作用するデータオブジェクトとインターフェースする。クライアントデバイスにおいて、モバイルアプリケーションは、データ要求を、スマートクライアントを介してメタデータ記憶装置及びビジネスデータ記憶装置へ、そしてアプリケーションサーバにおけるビューオブジェクトへ伝達する。

図７は、モバイルプラットフォームシステムのＤＡＤ機能へのアクセスがファイルエクスプローラタイプのグラフィカルユーザインターフェースを介してどのように獲得されるかを示す。図７は、ＤＡＤコンピュータープログラムアプリケーションをホストするコンピュータ装置上の表示のスクリーンショットである。図７において、表示画面は「デクステラエクスプローラ」というタイトルのウィンドウタイプの表示であり、ファイルツリー表示を有する作業スペースを示す。ツリー表示は、ソロモン、テンペスト、アルトリム、サンダーと表示されたサーバ名を有する「サーバ」の階層を示す。サーバ名は任意に選択されてよいことは明らかである。

ＤＡＤプログラムに従って、選択されたサーバに対し多種多様のアクションを取ることができる。図７はソロモンサーバが選択されたこと、そして調査され得るデータアクセスを示すためにデータアクセスメニュー項目がハイライト表示されていることを示す。データアクセスメニュー項目下に、データソース、データソースタイプ、コマンド、データオブジェクト、ビューを含むサブメニューが表示される。ＤＡＤプログラムとエクスプローラメニューを使用することにより、モバイルアプリケーション設計者は、新しいデータソースを規定することができ、そして開発済みアプリケーションを使用するモバイルクライアントの企業データソースへアクセスするためにこののアダプタとインターフェースすることができる。

図８は、デクステラエクスプローラメニュー上の「データソースタイプ」を選択した設計者を示し、図８は、コンテキストメニューが生成され、新しいデータソースタイプを追加するか、ビューをリフレッシュするか、データソースタイプを編集するか、又はデータソースタイプを削除するかの選択肢を設計者に提供することを示す。従って、デクステラエクスプローラメニュー項目を選択することにより、選択されたメニュー項目上に追加の操作のメニューを提供するコンテキストメニューを生成することができる。図９は、図８からのデータソースメニュー項目の選択を示し、設計中のシステムにおいて利用可能な例示的なデータソースを示す。図１０は具体的なデータソースタイプの選択を示す。このデータソースタイプから、選択されたデータソースタイプ上の編集操作のためにコンテキストメニューを生成することができる。図１１は、選択のために使用可能なビュータイプを示す。他のデクステラエクスプローラメニュー項目と同様に、ビューメニュー項目を選択することにより、設計者がビュータイプに関する編集操作（作成、編集、削除を含む）を実行できるようにするコンテキストメニューを生成する。

上記のように、デクステラエクスプローラメニュー上の「データソース」ノードが選択された場合、生成されるコンテキストメニューを介して新しいデータソースを規定することができる。図１２は、新しいタイプのデータソースを作成するためにデータソースコンテキストメニューを利用することにより生成されるデータソースプロパティダイアログボックスを示す。図１２は、設計者に利用可能なデータタイプに基づいて、データアダプタの選択を許容する画面が設計者に提示されることを示す。図１２では、利用可能なアダプタタイプはＳＱＬサーバのＯＬＥ ＤＢ、オラクルのＯＬＥ ＤＢ、Ｃｌａｒｉｆｙアダプタ、Ｒｅｍｅｄｙアダプタが示される。これらのアダプタタイプは例示のためのみに示される。本発明に従って追加の異なるアダプタタイプを提供し得る。図１２は、設計者がまたコネクションタイプを規定することができることを示す。アダプタを選択した後に、設計者は、接続パラメータを規定するためにコネクション表示ボタンを選択するであろう。

図１３は、設計者がログイン情報を提供し、特定の企業データソースターゲットを選択するための認証画面を示す。設計者が許可されると、表示は選択されたアダプタに従って変更される。新しいデータソースが定義された後、ＤＡＤインターフェースを使用することにより、新しいデータソースタイプノードが、設計者の新しく定義されたデータソースタイプに従ってデクステラエクスプローラツリー表示（図１０）内に現われる。

デクステラエクスプローラツリー表示から、他のノードを作成、編集、追加、削除することができる。図１４は、ツリー表示からコマンド選択を作成する設計者を示す。図１５の「新コマンドの追加」の選択は、図１６の「新コマンド」ダイアログボックスを生成する。

図１５は、新コマンドに対し、データソース、アクション、データタイプ、ソースを規定するパラメータと、ＳＱＬステートメント入力用のスペースと共に、名前を入力することができることを示す。図１６は、追加コマンドダイアログのパラメータータブが追加のコマンド仕様を許容することを示す。

図１５の新コマンド追加ダイアログボックスに関する管理パラメータには、次のものがある。

コマンド名テキストボックス：ＤＡＤユーザは、一意的にコマンドを識別するために名前を入力する。「保存」の際、コマンド名がユニークであることの検証がある。

データソース：これは定義済みデータソースのドロップダウンリストである。この情報はメタデータから発見される。すべてのコマンドは対応するデータソースを有する必要がある。

コマンドタイプ（アクション）：これは、利用可能な異なるタイプのコマンドのドロップダウンリストである。すべてのコマンドはコマンドタイプを有する必要がある。

データグループボックス：このグループボックスは、「メイン」と「パラメータ」用のタブを含んでおり、コマンドのアクションを定義するための制御を含む。このボックスは選択されたデータソースによって異なる。例えば、図１５に示す表示はＳＱＬサーバなどのＲＤＢＭＳである。オラクル／ジーベルシステムのようなシステムは「ＳＱＬステートメント」テキストボックスを恐らく持たないであろうと当業者は理解するであろう。

ソースタイプラジオボタン：このラジオボタンを選択することにより、２つの対応するコンボボックス（データソースとソースタイプ）を有効にし、ＳＱＬステートメントテキストボックスを無効にする。このラジオボタンは、設計者が、企業データシステムにより利用可能な企業オブジェクトを使用していることを示す。

ソースタイプボックス：企業システムから利用可能な企業オブジェクトのタイプを示すリストである。ソースタイプの例としては、テーブル、ビュー、又はＳＱＬにおけるストアドプロシージャが挙げられる。

ソースボックス：タイプごとのフィルタリングに基づいてユーザが選択する利用可能な企業オブジェクトのドロップダウン式リスト。

ＳＱＬステートメントラジオボタン：このラジオボタンを選択することにより、対応するテキストボックスを有効にし、ソースタイプ及びソースコンボボックスを無効にする。このラジオボタンは、このコマンドが実行しなければならないＳＱＬステートメントを、設計者が規定しようとしていることを示す。

ＳＱＬステートメントテキストボックス：設計者は、コマンドにより実行されるＳＱＬステートメントを入力する。

新コマンド追加のためのパラメータの中で、図１６のパラメーターダイアログボックスは次のものを含む。

パラメーターリストボックス：関係する場合、選択された企業オブジェクトのパラメーターリストを含む。図１６は、戻値のパラメータと顧客ファーストネームを示す。

パラメータープロパティグループボックス：選択されたパラメータのプロパティを記述する制御のグループ分けを示す。

名前テキストボックス：選択パラメータの名前。図１６において、パラメータ名は編集されてはならないのでそれが無効であることを示すために、このテキストボックスは灰色反転表示される。

指示ボックス：これは、パラメータが有し得る入力、出力、入力／出力などの指示タイプのドロップダウン式リストを含む。

データタイプボックス：これは、この場合、パラメータに対し利用可能なデータタイプのドロップダウン式リストを含む。

必要ボックス（Ｒｅｑｕｉｒｅｄ ｂｏｘ）：ブール値の真又は偽を含み、これによりパラメータが必要かどうかを示す。

値テキストボックス：パラメータの値が強制される場合、このテキストボックスは利用可能である。

編集処理が完了した後、すべての追加項目を反映するためにデクステラエクスプローラ内のツリー表示は更新される。例えば、図１７は、「顧客照会」と呼ばれる新しいコマンドがツリー表示に追加されたことを示す。こうして、名前コマンドは、ソロモンサーバとインターフェースするためにＤＡＤを使用するすべての以降の開発者に利用可能になる。新しい顧客照会コマンドもまた、デクステラエクスプローラグラフィカルユーザインターフェースと編集コマンドを使用することにより、ツリー表示の別のノードに対し操作（コピー、移動、編集、移動、等）され得ることに留意されたい。

こうして、デクステラエクスプローラツールは、異種のバックエンドデータソースへのカスタムの企業接続性を生成する能力を提供し、また、特定の実行インスタンスへの構成及び適応性を有する任意のバックエンド企業システムへの接続性を分離する能力を提供する。これにより、「．ＮＥＴ」インターフェースとバックエンドシステム間の通信が、バックエンドシステムにより必要とされる情報の構成とは別に開発されるようにし、こうして、本明細書で説明されたように、アブストラクション層を生成するとともに、コンフィギュレーションツールがその適応性を管理できるようにする。このようにして、開示されたツールは、デクステラデータマネージャに結合し、デクステラサーバと任意の企業データソースとの間でデータを移動させる際に必要とされる特定の入力と出力を実施する特定のデクステラアダプタインターフェースを実現する。

図１８は、上述のモバイルデータプラットフォームシステムの動作を示すフロー図である。同図ではフロー図ボックス１８０２として表される最初の動作では、ユーザは、バックエンド企業データソースに格納されたデータオブジェクトへのインターフェースを提供するとともにテーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれか１つとしてコネクションオブジェクトを介し利用可能なデータインターフェースオブジェクトを公開するコネクションオブジェクトを、規定（又は作成）する。次の動作では、ボックス１８０４において、コマンドオブジェクトに従ってデータアクションを識別するデータオブジェクトにより規定され、データインターフェースオブジェクトに対して実行されるデータアクションが確定される。最後の動作のボックス１８０６では、規定されたコマンドオブジェクトデータアクションをデータインターフェースオブジェクトに対し実行するために、ビューオブジェクトはデータオブジェクトに結合される。

上述のように、デクステラツールを使用して、システム設計者は、デクステラ支援アダプタ（デクステラ−ｓｕｐｐｏｒｔｅｄ Ａｄａｐｔｅｒ）を使用することによりバックエンド企業データソースへのコネクションオブジェクトを生成する。コネクションオブジェクトは、テーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれかとしてアダプタを介し利用可能なデータインターフェースオブジェクトを公開する（発見及び内部観測（Ｉｎｔｒａｓｐｅｃｔｉｏｎ）又は説明のいずれかを使用することにより）。次に、デクステラツールを使用して、設計者は、アダプタを介し特定のアクションを実行する一連のコマンドオブジェクトを生成する。そのアクションは、選択、挿入、更新、及び／又は削除などの操作を含むことができる。次に、設計者はデータオブジェクトを定義し、適切な選択コマンド、挿入コマンド、更新コマンド、及び／又は削除コマンドを選択する。次に、ビューオブジェクトは、この要求／応答アクションに対するデータオブジェクトに結合される。この技術を使用することにより、開発者は、デクステラアプリケーションサーバ内の単独に定義されたデータオブジェクトにマッピングされた一つ又は複数のバックエンドデータソースからデータを要求し保持することができ、こうしてアブストラクション層を物理データ構造に与え、インターフェース能力を与えることができる。

モバイルプラットフォームがモバイルクライアントに応答し動作すると、アプリケーションサーバのデータマネージャは、システムのいずれかのコネクタインターフェースコンポーネントに対し要求し応答する。アプリケーションサーバは、コネクションオブジェクト、コマンドオブジェクト、データオブジェクト、ビューオブジェクトの定義を使用して、どのようにして、どのデータを検索、又はバックエンド企業データソースに保持するかを判断する。

本発明によると、モバイルアプリケーションの設計者により使用される上記では「ＤＡＤ」と呼ばれるコンピュータープログラムツールが、モバイルデータプラットフォームシステムの異種の企業データソースへのカスタムの企業接続性を生成するために設けられる。ＤＡＤアプリケーションプログラムツールは、添付図面に例示されたユーザインターフェースを介してこれらの機能を提供する。こうして、ＤＡＤアプリケーションプログラムツールは、複数の企業データソースとモバイルクライアントとの間で共有されるデータのアプリケーション処理を規定する手段を提供する。上述のように、ＤＡＤアプリケーションプログラムは、バックエンド企業データソースに格納されたデータオブジェクトへのインターフェースを提供するとともにテーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれかとしてコネクションオブジェクトを介し利用可能なデータインターフェースオブジェクトを公開するコネクションオブジェクトを規定する手段と、特定のデータアクションを実行するコマンドオブジェクトを規定する手段と、データインターフェースオブジェクト上で実行されるコマンドオブジェクトデータアクションの一つをモバイルデータクライアントが規定することを許容するデータオブジェクトを規定する手段と、規定されたコマンドオブジェクトデータアクションの実行のためにデータオブジェクトに結合されるビューオブジェクトを規定する手段と、を提供する。
ＤＡＤツールプログラムが、接続アダプタを規定する処理を実行するためにユーザ入力を受信することができ、かつデータソース、バインディング等を確認することができる限り、ＤＡＤツールを含むコンピュータープログラムは、デスクトップコンピューター、ノート型コンピュータ等のコンピュータ装置又はコンピュータシステム上にインストールされてよい。構成されたアダプタと接続オブジェクトを、移動データプラットフォームシステム内に含むことができ、上記のようなモバイルプラットフォームのアプリケーションサーバにおいてインストールすることができるので、企業データソースを操作するために、アダプタの操作機能をモバイルクライアントにおいて利用することができる。

本発明についての理解が得られるように、本発明は現在好ましい実施形態の点から上に説明された。しかしながら、本明細書では具体的に説明されないが本発明が適用可能なモバイル企業データシステムのための多くの構成が存在する。従って、本発明は本明細書で説明した特定の実施形態に限定されると見なすべきでなく、むしろ、本発明はモバイル企業データシステム一般に対して広い適用性を有するということを理解すべきである。従って、添付の特許請求項の範囲内のすべての修正、変形、又は均等な配置及び実施は、本発明の範囲内であると考えるべきである。

本発明により構築されたモバイル企業プラットフォームのための好適なコンピュータシステム環境のブロック図である。 図１に図示されたモバイル企業プラットフォームにおけるデータの論理アーキテクチャのブロック図である。 図１の企業データソースとモバイルクライアント間のコネクタインターフェースを例示するブロック図である。 本発明により構築された好適なコンピュータシステム環境４００のブロック図である。 図１に図示されたモバイルプラットフォームのためのデータアーキテクチャの線図的表現を示す。 本発明により構築されたモバイルプラットフォームのためのデータアクセス構成の線図的表現である。 ＤＡＤコンピュータープログラムアプリケーションをホストするコンピュータ装置上の表示のスクリーンショットである。 「データソースタイプ」がデクステラエクスプローラメニュー上で選択されたときのＤＡＤプログラムにより生成されたツリー表示とコンテキストメニューを示す。 図８の表示からのデータソースメニュー項目の選択を示す。 コンテキストメニューが生成される、特定のデータソースタイプの選択を示す。 選択のために利用可能なビュータイプを示す。 新しいタイプのデータソースを作成するために、データソースコンテキストメニューを利用することにより生成されるデータソースプロパティダイアログボックスを示す。 ＤＡＤログイン情報のための、及び特定の企業データソースターゲットを選択するための認証画面を示す。 ツリー表示からコマンド選択を作成する設計者を示す。 図１４における選択に応じた「新コマンド」ダイアログボックスを示す。 追加コマンドダイアログのパラメータータブを示す。 追加された「顧客参照」と呼ばれる新コマンドを有するツリー表示を示す。 本発明によるモバイルプラットフォームシステムの処理を説明するフロー図である。

符号の説明

１０２ モバイルクライアントデバイス
１０４，４０４ ネットワーク接続
１０６，４０６ アプリケーションサーバ
１０８，４０８ 企業データソース
１１０ 管理者アプリケーション
１１２ 開発者アプリケーション
１１６ データ記憶装置
１１８ リレーショナルデータベース
１２０ ビジネスデータ
１２２ メタデータ
１２４ アプリケーション
４３０ コンポーネント

Claims (7)

1. 複数の企業データソースとモバイルクライアントとの間で共有されるデータのアプリケーション処理を規定する方法であって、
   バックエンド企業データソースに格納されたデータオブジェクトへのインターフェースを提供するとともにテーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれか１つとしてコネクションオブジェクトを介し利用可能なデータインターフェースオブジェクトを公開する前記コネクションオブジェクトを規定する工程と、
   前記データインターフェースオブジェクトに対し実行されるデータアクションを確定し、このデータアクションはコマンドオブジェクトに従ってデータアクションを識別するデータオブジェクトにより規定されるものである工程と、
   前記データインターフェースオブジェクトに対し前記規定されたコマンドオブジェクトデータアクションを実行するために、ビューオブジェクトを前記データオブジェクトに結合する工程と
   を含む、方法。
2. 前記コマンドオブジェクトはデータの選択、挿入、更新、及び削除アクションの内のいずれか１つを含むデータアクションを規定することができる、請求項１に記載の方法。
3. 前記コネクションオブジェクトを規定する工程は、それぞれが異種の企業データソースと通信を行う複数のアダプタの中から選択する工程を含む、請求項１に記載の方法。
4. 複数の企業データソースとモバイルクライアントとの間で共有されるデータのアプリケーション処理を規定するためのコンピュータープログラムシステムであって、
   バックエンド企業データソースに格納されたデータオブジェクトへのインターフェースを提供するとともにテーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれかとしてコネクションオブジェクトを介し利用可能なデータインターフェースオブジェクトを公開する前記コネクションオブジェクトを規定する手段と、
   特定のデータアクションを実行するコマンドオブジェクトを規定する手段と、
   前記データインターフェースオブジェクト上で実行される前記コマンドオブジェクトデータアクションの一つをモバイルデータクライアントが規定することを許容するデータオブジェクトを規定する手段と、
   前記規定されたコマンドオブジェクトデータアクションの実行のために前記データオブジェクトに結合するビューオブジェクトを規定する手段と、を含む、システム。
5. 前記コマンドオブジェクトは、データの選択、挿入、更新、及び削除アクションの内のいずれか１つを含むデータアクションを規定することができる、請求項４に記載のシステム。
6. 前記規定されたコネクションオブジェクトは、それぞれが異種の企業データソースと通信を行う複数のアダプタの中から選択される、請求項４に記載のシステム。
7. 複数の企業データソースとモバイルクライアントとの間で共有されるデータのアプリケーション処理を規定するためのコンピュータープログラムシステムであって、前記システムは、
   前記モバイルクライアントと通信を行い、アプリケーションサーバを介して前記企業データソースにインターフェースするプロセッサと、
   前記企業データソースの１つに格納されたデータオブジェクトへのインターフェースを提供するとともにテーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれか１つとしてコネクションオブジェクトを介し利用可能なデータインターフェースオブジェクトを公開する前記コネクションオブジェクトを指定し、特定のデータアクションを実行するコマンドオブジェクトを指定し、前記データインターフェースオブジェクト上で実行される前記コマンドオブジェクトデータアクションの一つをモバイルデータクライアントが規定することを許容するデータオブジェクトを指定し、前記規定されたコマンドオブジェクトデータアクションの実行のために前記データオブジェクトに結合するビューオブジェクトを指定する、設計ツールアプリケーションとを含み、前記コマンドオブジェクトは、データの選択、挿入、更新、及び削除アクションの内のいずれか１つを含むデータアクションを規定することができ、前記コネクションオブジェクトは、それぞれが異種の企業データソースと通信を行う複数のアダプタの中から選択される、コンピュータープログラムシステム。

Images