特許 6026992 多様なデータ接続のためのサービスおよびマネージメント層

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6026992

(24)【登録日】2016年10月21日

(45)【発行日】2016年11月16日

(54)【発明の名称】多様なデータ接続のためのサービスおよびマネージメント層

(51)【国際特許分類】

   G06F 9/54 20060101AFI20161107BHJP

   G06F 13/00 20060101ALI20161107BHJP

【ＦＩ】

   G06F9/46 480F

   G06F13/00 353A

【請求項の数】12

【外国語出願】

【全頁数】18

(21)【出願番号】特願2013-262237(P2013-262237)

(22)【出願日】2013年12月19日

(65)【公開番号】特開2014-123363(P2014-123363A)

(43)【公開日】2014年7月3日

【審査請求日】2015年1月21日

(31)【優先権主張番号】13/721,506

(32)【優先日】2012年12月20日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】300015447

【氏名又は名称】エスアーペー エスエー

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100064908

【弁理士】

【氏名又は名称】志賀 正武

(74)【代理人】

【識別番号】100089037

【弁理士】

【氏名又は名称】渡邊 隆

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】ミハエル・シュミット

(72)【発明者】

【氏名】ティム・ファルター

【審査官】 井上 宏一

(56)【参考文献】

【文献】 特開平 ４−２９９７５８（ＪＰ，Ａ）

【文献】 特表２００４−５２３８５４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／０２８２９４９（ＵＳ，Ａ１）

【文献】 特開２０１０− ９５２０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４６ −９／５４

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

プロセッサと、
メモリと、
前記プロセッサおよびメモリに基づくコンピューティングプラットフォーム(20;100)とを備えるシステムであって、
前記コンピューティングプラットフォーム(20;100)が、その上で起動されるアプリケーション(30;160)に1つまたは複数のサービスを提供するように構成され、
前記コンピューティングプラットフォーム(20;100)が、前記アプリケーション(30;160)との間の多様なタイプのデータ接続のマネージメントのための層(210)を含み、
前記マネージメントのための層(210)は、
前記アプリケーションとの間の前記多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントと、
前記アプリケーションとの間の前記多様なタイプのデータ接続の各々用に、それぞれのメッセージアセンブラモジュールと
を含み、前記メッセージアセンブラモジュールが、前記共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の前記タイプに従って、前記特定の外部受信者に送信するためのメッセージとしてアセンブルするように構成され、前記それぞれのメッセージアセンブラモジュールが、前記共通エントリポイントにおいて受信されたデータに基づいてアセンブルされたメッセージに、補足データを追加するように構成された拡張フックポイントを含み、各タイプのデータ接続は独自のプログラミングモデルを有するシステム。

【請求項2】

前記アプリケーションとの間の前記多様なタイプのデータ接続が、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、およびSAP ALEタイプのデータ接続のうちの1つまたは複数を含む、請求項1に記載のシステム。

【請求項3】

前記マネージメント層が、前記アプリケーションとの間の前記多様なタイプのデータ接続のための共通エラーハンドリング、監視、非同期ハンドリング、およびアドレス指定の
うちの少なくとも1つを含む1つまたは複数の共通サービスを提供するように構成される、請求項1または2に記載のシステム。

【請求項4】

前記マネージメント層が、外部送付者から多様な接続性タイプのデータ接続を介してデータを受信するように、および多様な接続性タイプの前記データ接続のいずれかを介して受信された前記データを共通データ構造またはフォーマットにマップするように構成される、請求項1〜3のいずれか一項に記載のシステム。

【請求項5】

前記マネージメント層が、前記データを前記共通データ構造またはフォーマットにマップした後、前記コンピューティングプラットフォーム上で受信者にデータをハンドオーバするための、少なくとも1つのアドレス指定可能データハンドオーバポイントを含む、請求項4に記載のシステム。

【請求項6】

前記マネージメント層が、前記少なくとも1つのアドレス指定可能データハンドオーバポイントの前に少なくとも1つの拡張フックポイントを含み、前記少なくとも1つの拡張フックポイントが、前記コンピューティングプラットフォーム上で起動される前記アプリケーションの論理によってデータがハンドリングされないデータを受信メッセージから抽出するように構成される、請求項5に記載のシステム。

【請求項7】

前記マネージメント層が、前記データ接続の接続性タイプとは無関係に、前記コンピューティングプラットフォームへのデータ接続を介して送られ、または受信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを含む、請求項1〜6のいずれか一項に記載のシステム。

【請求項8】

コンピューティングプラットフォーム(20;100)上のアプリケーション(30;160)との間の多様なタイプのデータ接続のマネージメントのための層(210)を提供するステップと、
前記コンピューティングプラットフォーム(20;100)上で、前記アプリケーション(30;160)との間の前記多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを提供するステップとを含み
前記マネージメントのための層(210)は、
前記アプリケーションとの間の前記多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントと、
前記アプリケーションとの間の前記多様なタイプのデータ接続の各々用に、それぞれのメッセージアセンブラモジュールと
を含み、前記メッセージアセンブラモジュールが、前記共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の前記タイプに従って、前記特定の外部受信者に送信するためのメッセージとしてアセンブルするように構成され、前記それぞれのメッセージアセンブラモジュールが、前記共通エントリポイントにおいて受信されたデータに基づいてアセンブルされたメッセージに、補足データを追加するように構成された拡張フックポイントを含み、各タイプのデータ接続は独自のプログラミングモデルを有する方法。

【請求項9】

コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、外部送付者から多様な接続性タイプのデータ接続を介してデータを受信するための、および多様な接続性タイプの前記データ接続を介して受信された前記データを共通データ構造またはフォーマットにマップするための前記マネージメント層を構成するステップを含む、請求項8に記載の方法。

【請求項10】

コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、前記マネージメント層が、前記データを前記共通データ構造またはフォーマットにマップした後、前記コンピューティングプラットフォーム上で受信者にデータをハンドオーバするための、少なくとも1つのアドレス指定可能データハンドオーバポイントを提供するステップを含む、請求項9に記載の方法。

【請求項11】

コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、前記マネージメント層が、前記少なくとも1つのアドレス指定可能データハンドオーバポイントの前に少なくとも1つの拡張フックポイントを提供するステップを含み、前記少なくとも1つの拡張フックポイントが、前記コンピューティングプラットフォーム上で起動される前記アプリケーションの論理によってハンドリングされないデータを受信メッセージから抽出するように構成され、
および/または
コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、前記データ接続の接続性タイプとは無関係に、前記コンピューティングプラットフォームへのデータ接続を介して通信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを提供するステップを含む、請求項10に記載の方法。

【請求項12】

コンピュータプログラムであって、コンピュータシステムおよび/またはコンピュータネットワークシステムにおいてロードされ、かつ実行されたとき、前記コンピュータシステムおよび/または前記コンピュータネットワークシステムに、請求項8〜11のいずれか一項に記載の方法に基づく動作を実施させるコンピュータ実行可能な命令を含むコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、多様なデータ接続のためのサービスおよびマネージメント層に関する。

【背景技術】

【0002】

コンピューティングプラットフォームは単純には、アプリケーションソフトウェアを起動するための場所と定義することができる。コンピューティングプラットフォームは、アプリケーションソフトウェアを稼働させるように設計されたハードウェアアーキテクチャおよびソフトウェアフレームワーク(アプリケーションフレームワークを含む)を含み得る。コンピューティングプラットフォームは、様々なシステムがコンピューティングプラットフォームをサポートする限り、それらのシステムのいずれにおいても論理コード(またはアプリケーション)が一貫して稼働するであろうという確信を、ソフトウェア開発者にもたせる。論理コードは、バイトコード、ソースコード、および機械コードを含む。

【0003】

コンピューティングプラットフォーム上で稼動するアプリケーションは、特定のプログラムされたデータ接続を介して、他のコンピューティング要素またはエンティティ(たとえば、データベース、他のアプリケーション、他のコンピューティングプラットフォームもしくはシステムなど)と対話することも、データを交換することもできる。アプリケーションとの間のデータ接続は、特定の接続性タイプ(たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、SAP ALEなど)であってよい。各特定のデータ接続タイプは、独自の(たとえば、構成、ランタイム、監視、アドレス指定態様、エラーハンドリングなどのための)プログラミングモデルを有し得る。

【0004】

実際、コンピューティングプラットフォーム上で稼動するアプリケーションは、多様な接続性タイプおよびプログラミングモデルを使うことができる。接続性タイプおよびプログラミングモデルにおける多種性または多様性により、コンピューティングプラットフォームにおけるアプリケーション統合および接続性管理の複雑さが増し得る。

【0005】

アプリケーション向けの特定のデータ接続タイプは、たとえば、特定の接続性タイプの利点および欠点の考慮に基づいて、アプリケーション開発者によって選択することができる。ある接続性タイプのデータ接続を介して着信する着信データはほとんど、同じ接続性タイプのエンティティによって、アプリケーション内で処理される(たとえば、着信RFCデータはしばしば、受信側RFC機能モジュールにおいて事前処理される)。その結果、アプリケーションによって新規または追加データ接続タイプがサポートされることになるたびに、アプリケーション論理は、アプリケーション開発者によって書き換えられなければならない。いくつかのアプリケーションプログラミングインターフェース(API)、たとえば、データを受信するためのAPIであって、少なくともビジネスロジックのいくつかの部分を含むAPIは、最新の状態に保つために書き換えられなければならない場合がある。

【発明の概要】

【発明が解決しようとする課題】

【0006】

アプリケーション統合および接続性管理を簡易にすることを目的とするコンピューティングプラットフォームフレームワークが検討されるべきである。
米国特許出願公開第2012/246334号は、変換ミドルウェアピースを検証することに関する。第1の要求が、変換ミドルウェアピースを含むフロントエンドユーザサービスのための適切なプロトコルを使用して、前記フロントエンドユーザサービスに提供される。前記変換ミドルウェアピースは、前記フロントエンドサービスに提供された要求を、バックエンドストアのための要求に変換する。応答に基づいて、フロントエンド、バックエンドまたは変換ミドルウェアピースの少なくとも一つに対して機能状態が決定される。
米国特許第6507589号明細書には、装置内のアドレス可能な部分(例えば、プロセス)にメッセージをルーティングするための技術に関する。それにルーティングされるメッセージを受信した後、前記アドレス可能な部分は、メッセージを処理し、かつ、おそらく応答メッセージを返すことが可能である。メッセージの処理は、典型的には、無線通信システムに接続されたモバイルデバイスにネットワーク上のリモートコンピュータのうちの1つまたは複数から特定の情報を転送するメッセージを生成するように作用する。
米国特許第6134618号明細書は、呼制御処理を実行するための汎用メッセージフォーマットを利用し、かつ、通信アプリケーション及びネットワークシグナリングプロトコルの要件を満たすようにカスタマイズ可能なユニバーサルホストスイッチ(universal host-to-switch)アプリケーション・プログラム・インターフェース(API)に関する。

【課題を解決するための手段】

【0007】

本発明は、特許請求の範囲の独立請求項に記載されているように、システム、コンピュータ実施の方法及びコンピュータプログラム製品に関する。好適な態様は、その従属請求項において定義される。
システムは、プロセッサと、メモリと、プロセッサおよびメモリに基づくコンピューティングプラットフォームとを含む。コンピューティングプラットフォームは、その上で起動されるアプリケーションに、1つまたは複数のサービスおよびプロセスを提供する。アプリケーションは、他のエンティティ、データベースまたはアプリケーションへのデータ接続セットを有し得る。データ接続セットは、異なる特定の接続性タイプ(たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、SAP ALE接続性タイプなど)の異なるデータ接続を含み得る。異なる特定の接続性タイプのデータ接続セットは、同じ接続性タイプのいくつかのデータ接続を含み得ることが理解されよう。さらに、本明細書で使用する場合、「データ接続のタイプ」、「データ接続タイプ」、または「接続タイプ」という用語は、データ接続の特定の接続性タイプを指すことが理解されよう。

【0008】

1つの一般的態様によると、コンピューティングプラットフォームは、アプリケーションとの間のデータ接続のサービス品質およびマネージメントのための層を含む。アプリケーションとの間のデータ接続は、異なる特定の接続性タイプの、1つまたは複数のデータ接続を含み得る。

【0009】

一態様では、サービス品質およびマネージメントのための層は、アプリケーションへの多様なタイプのデータ接続のための、エラーハンドリング、監視、非同期ハンドリング、およびアドレス指定のうちの少なくとも1つを含む1つまたは複数の共通サービスを提供する。

【0010】

別の態様では、サービス品質およびマネージメントのための層は、アプリケーションとの間の多様な接続性タイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを含む。サービス品質およびマネージメントのための層は、アプリケーションとの間の多様な接続性タイプのデータ接続の各々のための、それぞれのメッセージアセンブラモジュールを含む。メッセージアセンブラモジュールは、共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続のタイプに従って、特定の外部受信者への送信用メッセージとしてアセンブルする。

【0011】

さらに別の態様では、サービス品質およびマネージメントのための層は、受信データを共通データ構造またはフォーマットにマップした後、コンピューティングプラットフォーム上で、受信データを受信者にハンドオーバするための少なくとも1つのアドレス指定可能データハンドオーバポイントを含む。

【0012】

さらなる態様では、サービス品質およびマネージメントのための層は、コンピューティングプラットフォームへのデータ接続を介して送られ、または受信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを含む。

【0013】

1つの一般的態様によると、方法は、コンピューティングプラットフォーム上のアプリケーションとの間の多様な接続性タイプのデータ接続のサービス品質およびマネージメントのための層を提供するステップと、アプリケーションとの間の多様な接続性タイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを提供するステップとを含む。

【0014】

一態様では、方法は、アプリケーションとの間の多様な接続性タイプのデータ接続の各々のための、それぞれのメッセージアセンブラモジュールを提供するステップを含む。メッセージアセンブラモジュールは、共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の接続性タイプに従って、特定の外部受信者への送信用のメッセージとしてアセンブルするように構成される。

【0015】

別の態様では、方法は、外部送付者から多様なタイプのデータ接続を介してデータを受信するため、および多様な接続性タイプのデータ接続を介して受信されたデータを共通データ構造またはフォーマットにマップするための、サービス品質およびマネージメントのための層を構成するステップを含む。

【0016】

さらに別の態様では、方法は、受信データを共通データ構造またはフォーマットにマップした後、コンピューティングプラットフォーム上で受信者にデータをハンドオーバするための、少なくとも1つのアドレス指定可能データハンドオーバポイントを提供するステップを含む。

【0017】

さらなる態様では、方法は、データ接続の接続性タイプとは無関係に、コンピューティングプラットフォームへのデータ接続を介して送られ、または受信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを提供するステップを含む。

【0018】

1つの一般的態様によると、非一時的コンピュータ可読媒体は、コンピュータシステム上で実行されることが可能な命令を含む。命令は、コンピュータシステム上で実行されると、コンピューティングプラットフォーム上のアプリケーションとの間の多様な接続性タイプのデータ接続のサービス品質およびマネージメントのための層と、アプリケーションとの間の多様な接続性タイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントとを生成する。

【0019】

一態様では、命令は、コンピュータシステム上で実行されると、アプリケーションとの間の多様な接続性タイプのデータ接続の各々のための、それぞれのメッセージアセンブラモジュールをさらに生成する。メッセージアセンブラモジュールは、共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の接続性タイプに従って、特定の外部受信者への送信用のメッセージとしてアセンブルすることができる。

【0020】

別の態様では、命令は、コンピュータシステム上で実行されると、外部送付者から多様な接続性タイプのデータ接続を介してデータを受信するため、および多様な接続性タイプのデータ接続を介して受信されたデータを共通データ構造またはフォーマットにマップするためのサービス品質およびマネージメントのための層を構成する。

【0021】

1つまたは複数の実装形態の詳細について、添付の図面および以下の説明において述べる。他の特徴は、説明および図面、ならびに特許請求の範囲から明らかになろう。

【図面の簡単な説明】

【0022】

【図1】本明細書における本開示の原理による、データ送付シナリオにおいて使うことができる、例示的コンピューティングプラットフォームのサービスおよびプロセス要素を示すブロック図である。

【図2】本明細書における本開示の原理による、データ受信シナリオにおいて使うことができる、図1の例示的コンピューティングプラットフォームのサービスおよびプロセス要素を示すブロック図である。

【図3】本明細書における本開示の原理による、データ送付シナリオにおける、図1のコンピューティングプラットフォームにおけるセマンティックアドレス指定手法の例示的実装形態を示すブロック図である。

【図4】本明細書における本開示の原理による、データ受信シナリオにおける、図2のコンピューティングプラットフォームにおけるセマンティックアドレス指定手法の例示的実装形態を示すブロック図である。

【図5】コンピューティングマシンによってサポートされるコンピューティングプラットフォームを示す概略的なブロック図である。

【図6】本明細書における本開示の原理による、コンピューティングプラットフォーム上で起動されるアプリケーションとの間の多様なデータ接続のサービス品質およびマネージメントのための例示的方法の流れ図である。

【発明を実施するための形態】

【0023】

コンピュータシステムは、他のアプリケーション、データベース、サーバ、ストレージ、コンピュータシステムまたはエンティティなどに接続し、または対話するアプリケーション(たとえば、ビジネスアプリケーション)を起動するのに使うことができる。コンピュータシステムは、たとえば、ネットワーク化された配置で展開することができる1つまたは複数の物理または仮想コンピューティングマシンによってホストまたはサポートされるコンピューティングプラットフォームを含み得る。コンピューティングプラットフォームは、たとえば、ホストコンピューティングマシンのハードウェア構成要素(たとえば、プロセッサ、メモリ、キーパッド、ディスプレイ、ネットワークカードなど)ならびに他の構成要素およびプロセスを支配するオペレーティングシステムを含み得る。図5は、ネットワーク化されたコンピュータシステム内の物理または仮想マシンを表し得るコンピューティングマシン10によってサポートされる例示的コンピューティングプラットフォーム20を概略的に示す。ホストコンピューティングマシン10は、CPU11、メモリ12、I/O13およびO/S14を含み得る。CPU11は、いかなる一般的プロセッサであってもよく、メモリ12は、CPU11によって、いくつかの機能を実施するのに使われるデータを記憶するように構成された1つまたは複数の記憶デバイスであってよい。

【0024】

コンピューティングプラットフォーム20は、その上で起動されるアプリケーション(たとえば、ビジネスアプリケーション30)用のアプリケーションフレームワークと、プロセスまたはサービスとを提供することができる。アプリケーション30は、機能する際、他の外部エンティティ(たとえば、アプリケーション、データベース、システムなど)に接続して、たとえば、データを送り、受信し、または交換することができる。送付側エンティティと受信側エンティティとの間のデータ接続には、「接続性」タイプについてのカスタムまたは業界標準データ接続プロトコル(たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、SAP ALEなど)が使われ得る。

【0025】

コンピューティングプラットフォームフレームワークまたはプログラミングモデルの下では、本明細書における本開示の原理により、多様な接続性タイプのデータ接続のための共通接続性サービス品質およびマネージメント層(「共通マネージメント層」)が、コンピューティングプラットフォーム内に設けられる。

【0026】

共通マネージメント層は、コンピューティングプラットフォーム上でホストされるアプリケーションによって使われ、または要求され得る、多様な接続性タイプの1つまたは複数の共通サービス(たとえば、エラーハンドリング、監視、非同期ハンドリング、アドレス指定など)をデータ接続に提供するように構成される。共通サービスについての2つのシナリオを想定することができ、第1のシナリオでは、コンピューティングプラットフォーム上でホストされるアプリケーションが、データ接続を介してデータを送り、第2のシナリオでは、コンピューティングプラットフォーム上でホストされるアプリケーションが、データ接続を介してデータを受信する。

【0027】

データ送付シナリオ
データ送付シナリオにおけるデータは、アプリケーション環境から、またはデータベース環境から発し得る。このシナリオにおけるサービスに対して、共通マネージメント層は、コンピューティングプラットフォームまたはコンピューティングプラットフォーム上でホストされるアプリケーションに結合されたデータベースであり得る送付エンティティから、外部受信者に向けられたデータ(およびデータ属性)を受信するための共通エントリポイントを有し得る。送付エンティティによって共通エントリポイントにおいて共通マネージメント層にハンドオーバされるデータ属性は、たとえば、データ接続が同期であるか、非同期であるか、信頼できるかどうかなどのデータ属性を含み得る。さらに、ハンドオーバされるデータ属性は、意図されたデータ受信者へのデータ接続のタイプの直接または間接識別を含み得る。

【0028】

共通マネージメント層は、共通エントリポイントにおいて受信されたデータおよびデータ属性を処理して、データの意図された外部受信者へのデータ接続のタイプと整合するメッセージをアセンブルするように構成することができる。アセンブルされたメッセージは、共通マネージメント層内の、接続性タイプ用のそれぞれの基底層またはスタブから、データの意図された外部受信者に送出され得る。共通エントリポイントは、アプリケーション環境からの、それともデータベース環境からのデータからメッセージがアセンブルされるかにかかわらず同じであり得る。

【0029】

図1は、本明細書における本開示の原理による、データ送付シナリオにおいて使うことができる、例示的コンピューティングプラットフォーム100のサービスおよびプロセス要素を示すブロック図である。図に示すように、コンピューティングプラットフォーム100は、データベース120/データベーステーブル122に結合され得る。さらに、コンピューティングプラットフォーム100は、1つまたは複数のアプリケーション(たとえば、アプリケーション160)をホストすることができる。1つまたは複数のアプリケーションは、たとえば、データベース120/データベーステーブル122に記憶されたデータを処理またはアクセスするように構成され得る。

【0030】

コンピューティングプラットフォーム100は、一般に、多様な接続性タイプのデータ接続またはチャネルを介した、コンピューティングプラットフォームから様々な外部受信者(たとえば、RFC受信者142、HTTP/OData受信者144、XYZ受信者146など)への送付データを管理するように構成された接続性サービス品質およびマネージメント層110(「共通マネージメント層110」)を含み得る。コンピューティングプラットフォーム100は、様々な受信者のうちいずれかに送られるべきデータ150が、送付エンティティ(たとえば、アプリケーションやデータベース)によって共通マネージメント層110にハンドオーバされる共通エントリポイント140を含み得る。図示するように、データ150のハンドオーバは、たとえば、アプリケーション160が、共通エントリポイント140においてデータへのハンドル(たとえば、アクセスキー、トークンまたは他の識別子)を共通マネージメント層110に提供することを伴い得る。代替的に、または追加として、データベース120によるデータ150のハンドオーバは、共通エントリポイント140において、データベーストリガ、キーまたは類似のデータ識別子を共通マネージメント層110にハンドオーバすることを伴い得る。データ150のハンドオーバは、たとえば、意図されたデータ受信者および/またはデータ接続タイプの識別を含む関連データ属性のハンドオーバも伴い得ることが理解されよう。

【0031】

共通マネージメント層110は、コンピューティングプラットフォーム100によってサポートされ得る様々な接続タイプの各々用のそれぞれの基底層またはスタブ(たとえば、RFC基底層113、HTTP/OData基底層115、XYZ基底層117など)に供給を行う、それぞれのメッセージアセンブリモジュール(たとえば、メッセージアセンブラモジュール112、メッセージアセンブラモジュール114、メッセージアセンブラモジュール116など)を含み得る。特定の基底層またはスタブが、特定のデータ接続タイプ用の、受信者とのコンピューティングプラットフォームのインターフェースを定義することができる。共通マネージメント層110は、それぞれのメッセージアセンブラモジュール112を使って、特定の受信者への送信用データ150に基づいてメッセージをアセンブルするように、および特定の受信者へのデータ接続タイプに対応する基底層またはスタブを使って、アセンブルされたメッセージを特定の受信者にさらに送るように構成され得る。

【0032】

メッセージアセンブラモジュール112〜116は、(たとえば、メッセージアセンブリの後の)拡張性のために構成された拡張フックポイント118を含み得る。これらの拡張フックポイント118は、データ150に基づいてアセンブルされたメッセージに補足データを随意に追加するのに使うことができる。メッセージに追加される補足データは、アプリケーションチェックなどのアプリケーション関与なしで、直接データベースアクセスによって取得することができる。

【0033】

共通マネージメント層110が、接続インターフェースを提供し、様々な接続性タイプのデータ接続のためのメッセージを準備するので、様々な接続性タイプの各々用の個々の論理またはアプリケーションプログラミングインターフェース(API)でアプリケーション(たとえば、アプリケーション160)をカスタマイズする必要はなくてよい。さらに、たとえば、適切なメッセージアセンブラモジュールを共通マネージメント層110に含めることによって、アプリケーション160自体をプログラムまたは修正する必要なしで、新規または将来の接続性タイプのデータ接続がサービスされ得る。

【0034】

データ受信シナリオ
データ受信シナリオにおいて、コンピューティングプラットフォーム上のアプリケーションまたはデータベースに向けられたデータは、様々な接続性タイプのうちのいずれかのデータ接続を介してコンピューティングプラットフォーム上で受信することができる。各データ接続タイプは、独自のプログラミングモデルを有し得る。このシナリオにおけるサービスに対して、コンピューティングプラットフォームは、外部送付者から受信したデータを、コンピューティングプラットフォーム上でホストされるアプリケーションに、またはコンピューティングプラットフォームにリンクされたデータベースに渡すための単一のデータハンドオーバポイント(または「ユニバーサルAPI」)を有し得る。単一のデータハンドオーバポイントまたはユニバーサルAPIは通常、コンピューティングプラットフォームにおいてデータが受信される際に経由するデータ接続またはチャネルの接続性タイプとは無関係に、いくつかの外部受信者のうちのいずれかから受信されるデータのための特定のアプリケーション用に使うことができる。コンピューティングプラットフォームにおいて受信されたデータは、データがそれを介して受信される接続またはチャネルのタイプおよびプログラミングモデルに従って、異なるように準備または調整することができると予想され得る。共通マネージメント層は、異なる接続性タイプのデータ接続を介して受信された、異なるように準備または調整されたデータを、ユニバーサルAPIに適合するようにマップするように構成され得る。

【0035】

共通マネージメント層は、コンピューティングプラットフォームによってサポートされる多様な接続性タイプのすべてに関して、共通サービス品質(たとえば、エラーハンドリング、監視、非同期ハンドリングなど)を提供することができる。共通マネージメント層が実装されると、アプリケーションによってデータ接続に使われる各接続性タイプに関して、特定のサービスツール(たとえば、管理ツール、エラーハンドリングツール、監視ツール、構成ツール、および独自のランタイム(すなわち実行オブジェクト)など)を別個に提供する必要をなくすことができる。共通マネージメント層は、中心的環境において、通常、データ接続およびアプリケーションによるデータ接続によって使われる接続性タイプのすべてに関して等価なサービスまたは機能性を提供することができる。

【0036】

図2は、本明細書における本開示の原理による、データ受信シナリオにおいて使うことができる、例示的コンピューティングプラットフォーム100のサービスおよびプロセス要素の概略図である。図1で先に示したように、コンピューティングプラットフォーム100は、データベース120/データベーステーブル122に結合され得る。さらに、コンピューティングプラットフォーム100は、1つまたは複数のアプリケーション(たとえば、図1のアプリケーション160だが、図2ではアプリケーション論理165として表される)をホストすることができる。

【0037】

コンピューティングプラットフォーム100は、通常は様々な外部送付者(たとえば、RFC送付者152、HTTP/ODATA送付者154、XYZ送付者156など)からの、多様な接続性タイプのデータ接続を介した、コンピューティングプラットフォーム上でのデータ受信を管理するように構成された接続性サービス品質およびマネージメント層210(「共通マネージメント層210」)を含み得る。共通マネージメント層210は、それぞれの基底層またはモジュール(たとえば、RFC基底層213、HTTP/ODATA基底層215、XYZ基底層217など)を、コンピューティングプラットフォーム100によってサポートされ得る様々な外部送付者データ接続タイプの各々のための、コンピューティングプラットフォーム100上のパートナーデータ受信モジュールとして含み得る。さらに、共通マネージメント層210は、パートナーデータ受信モジュール213〜217の各々向けに、それぞれのデータマッピングモジュール(たとえば、RFC-ユニバーサルAPIマッパー214、HTTP/ODATA-ユニバーサルAPIマッパー216、XYZ-ユニバーサルAPIマッパー218など)を含み得る。データマッピングモジュールは、様々なデータ受信モジュールによって多様な接続性タイプのデータ接続を介して受信されたデータを、コンピューティングプラットフォーム100上でさらに処理または使用するために共通データ構造またはフォーマットにマップするように構成され得る。共通データ構造またはフォーマットは、たとえば、コンピューティングプラットフォーム100上でホストされるアプリケーション(たとえば、アプリケーション160)のうちの少なくとも1つのアプリケーション固有のアプリケーションプログラミングインターフェース(たとえば、API170)と互換性があり得る。

【0038】

データマッピングモジュール214〜218は、拡張フックポイント119をさらに含んでよく、フックポイント119は、送付者側における拡張フックポイント(たとえば、拡張フックポイント118)の相対物でよい。拡張フックポイント119は、受信メッセージから拡張データを取り出すように構成してよく、これには、受信されたメッセージからアプリケーション論理165によって提供されない別個のハンドリングが要求される。拡張フックポイント119は、接続性タイプ固有のデータマッピングモジュール214〜218の後、ただし少なくとも1つのAPI170の前に配置してよい。

【0039】

さらに、コンピューティングプラットフォーム100は、様々な送付者のいずれかによって送られるデータを、共通データ構造またはフォーマットにマップした後に、共通マネージメント層210によって指定受信者(たとえば、アプリケーション160、データベーステーブル122)にハンドオーバすることができるようにするための少なくとも1つのアドレス指定可能データハンドオーバポイント(たとえば、アプリケーション固有API170)を含み得る。図示するように、マップされたデータは、たとえば、データベース120への直接データベースアクセスによって、またはアプリケーション論理165に対する呼によって、アプリケーション固有API170からハンドオーバすることができる。

【0040】

コンピューティングプラットフォーム100は、様々なデータ接続タイプをサポートし、かつ/または様々なアプリケーションをホストすることができるが、特定の接続性タイプのデータ接続または外部送付者のために、どの特定のデータマッピングモジュールが呼び出されるべきか、ならびに/あるいは、たとえば、外部送付者からデータが受信されたときに、どのアプリケーション固有APIが呼び出されるべきかを示し得るパラメータまたは設定で、手動で構成することができる。

【0041】

共通マネージメント層210が、様々なデータ接続タイプに対して共通アプリケーション固有API(たとえば、API170)を提供するので、コンピューティングプラットフォーム100上でホストされ得るアプリケーション160を、様々なデータ接続タイプの各々向けの個々の論理またはアプリケーションプログラミングインターフェースでカスタマイズする必要はなくてよい。さらに、たとえば、適切なデータマッピングモジュールを共通マネージメント層110に含めることによって、アプリケーション160またはアプリケーション論理165を変更し、または書き換える必要なく、新規または将来のデータ接続タイプをサービスすることができる。

【0042】

それぞれ、データ送付シナリオおよびデータ受信シナリオに対応する、図1および図2の例示的共通マネージメント層は、説明の便宜上、異なるように、すなわち「110」および「210」と標示されていることが理解されよう。コンピューティングプラットフォームにおける単一の共通マネージメント層は、図に示す2つの例示的共通マネージメント層110および210の要素を含み、データ送付シナリオとデータ受信シナリオの両方の下で接続性サービスを提供することができる。さらに、共通マネージメント層は、様々な接続性タイプのためのサービス品質のマネージメントまたは提供に関連した追加要素またはモジュールを含み得る。図3および図4は、たとえば、コンピューティングプラットフォーム100によってサポートされる様々なデータ接続タイプを介して送られ、または受信されるデータまたはメッセージの「アドレス指定」態様に関する追加モジュールまたは要素(たとえば、Who-am-I API350、論理受信者判断API360、およびWho-Is-who API450など)を含む共通マネージメント層310および410を示す。

【0043】

コンピューティングプラットフォーム100の共通マネージメント層に含まれ得る追加モジュールまたは要素は、データ接続のためのアドレス指定可能エンティティが、たとえば、アプリケーションエンティティであるセマンティックアドレス指定手法に基づき得る。このアプリケーション中心手法は、RFC宛先やURLなどの技術的エンティティによる、システムまたはクライアントのアドレス指定を伴う他のアドレス指定手法とは対照的であり得る。本開示のセマンティックアドレス指定手法は、アプリケーションレベルエンティティと、システムまたはクライアントよりも微細なエンティティとに適用可能であり得る。さらに、コンピューティングプラットフォーム100の共通マネージメント層は、データ接続の特定の接続性タイプとは無関係に、多様なデータ接続を介したセマンティックアドレス指定手法を中心に実装することができる。

【0044】

本明細書において以降の説明で言及され得る例示的アドレス指定問題は、コンピュータシステム上のエンティティの間のデータ通信に関するものでよく、エンティティでは、組織ユニット1および2が、コンピュータシステムにより接続され、それらのセマンティック識別情報(たとえば、それぞれ、「会社のドイツ北部営業所」および「会社のドイツ南部営業所」)によってシステム上で露出され得る。組織ユニット2の顧客は、「Baunatal Engine Device自動車工場」というセマンティック識別情報をもち得る。ただし、この顧客は、ユニット2では、システム上のURL/RFC宛先としてのみ識別され得る。

【0045】

セマンティックアドレス指定手法に基づく例示的ソリューションでは、エンティティ(たとえば、会社のドイツ南部営業所など)は、割り当てられたセマンティック識別情報または「識別可能ビジネスコンテキスト」(IBC)名をもつことができ、これらは、たとえば、エンティティ所有者(たとえばアプリケーション、顧客、業種(LOB)など)によって作成することができる。例示的IBC名はタプルであってよく、たとえば、ビジネスコンテキストまたは対応する担当者の住所、電話番号、eメールアドレスなどのエンティティ識別情報を含む。エンティティのIBC名またはタプルは、それが作成されたシステムまたは環境からエクスポートすることができ、(たとえば、メールによって)共有し、そうでなければ、IBC固有表現がそこからアドレス指定される必要がある送付またはアドレス指定システム、アプリケーション、または環境にインポートすることができる。IBCは、コンピューティングプラットフォーム100における技術的および論理的受信者判断のための基盤であり得る。

【0046】

セマンティックアドレス指定手法に基づくソリューションでは、システム上のエンティティの間のデータ接続のための技術的パラメータは、送付側または「アドレス指定側」エンティティ(たとえば、アプリケーション、システムなど)のセマンティック識別情報および受信側または「アドレス指定先」エンティティ(たとえば、アプリケーション、システムなど)のセマンティック識別情報のタプルから導出することができる。

【0047】

データ送付シナリオ(図1)において、送付者および受信者エンティティのIBCタプルを知っていることにより、送付者と受信者との間で提供または実装することができる接続性を技術的に判断することができるようになる。技術的判断は、たとえば、接続性タイプ(たとえば、RFC)、対応するメッセージアセンブラモジュール(たとえば、RFCメッセージアセンブリモジュール)、受信者側で呼び出されるべき機能モジュール(たとえば、RFC受信者)、およびセキュリティ設定などの判断を含み得る。

【0048】

論理的ルーティングが必要とされるケースでは、アプリケーションが定義した基準に基づいてルーティング規則を生成することが可能であり得る。たとえば、ドイツにいる顧客が、コンピューティングプラットフォーム上でホストされるアプリケーションにより、本の購入発注を行うケースでは、購入発注は、「ドイツの倉庫」というIBCに論理的にルーティングされ得る。対照的に、顧客が米国にいるケースでは、購入発注は、「米国の倉庫」というIBCに論理的にルーティングされ得る。

【0049】

データ送付シナリオ
図3は、図1を参照して上述したデータ送付シナリオにおける、コンピューティングプラットフォーム100上でのセマンティックアドレス指定手法の例示的実装形態300を示す。実装形態300において、コンピューティングプラットフォーム100の共通マネージメント層310は、セマンティックアドレス指定手法を実装するように構成されたAPI(たとえば、Who-am-I API350および論理的受信者判断API360)を含み得る。API用のIBCデータは、ハードコードされ得る。コンピューティングプラットフォーム100の例示的実装形態において、IBCタプルデータは、たとえば、APIまたはコンピューティングプラットフォーム100にとってアクセス可能なデータストアに手動入力することができる。さらに、APIは、IBCタプルデータの分析によって、送付者の識別情報および受信者の識別情報についての情報を生成するように構成され得る。APIは、IBCタプルデータに基づいて、送付者と受信者の間のデータ接続についての技術的データを生成するようにも構成され得る。

【0050】

Who-am-I API350は、たとえば、IBCタプルデータのセマンティック分析に基づいて、自身または自己識別情報IBCタプルを送付エンティティに提供するように構成され得る。さらに、論理的受信者判断API360は、たとえば、IBCタプルデータのセマンティック分析に基づいて、受信者識別情報を提供するように構成され得る。送付者が、データを送る間にシステムまたはクライアントを技術的に(たとえば、URL/RFC宛先などとして)アドレス指定済みである可能性があるとしても、送付者IBCおよび受信者IBCは、送付データとともに転送されてよい。

【0051】

セマンティックアドレス指定の使用を示す例では、IBC名(WERKS 002、MATNR 4711)をもつビジネスエンティティは、アプリケーション160によりコンピュータシステムを介して品目配送発注を送りたい場合がある。Who-am-I API350は、アプリケーション160における、エンティティ(WERKS 002、MATNR 4711)による自己識別リクエスト「自分は何者か(WERKS 002、MATNR 4711)」に、「あなたは「AUTO Werk Baunatal、Engine Device」です」のような、IBC名のセマンティック分析に基づく識別情報で応答することができる。さらに、論理的受信者判断API360は、エンティティ(WERKS 002、MATNR 4711)からの品目配送発注についての受信者識別を求めるリクエスト(たとえば、「自分の受信者は誰か?自分はAUTO Werk Baunatal、Engine Deviceであり、配送されるべきMATNRは4711で、米国への配送です」)に、「あなたの受信者は、米国ニューヨークの倉庫2です」のようなIBC名のセマンティック分析に基づく識別情報で応答することができる。

【0052】

データ受信シナリオ
図4は、図2を参照して上述したデータ受信シナリオにおける、コンピューティングプラットフォーム100上でのセマンティックアドレス指定手法の例示的実装形態400を示す。実装形態400において、コンピューティングプラットフォーム100の共通マネージメント層410は、セマンティックアドレス指定手法を実装するように構成されたAPI(たとえば、「Who-is who」API450)を含み得る。上のデータ送付シナリオについて説明したように、コンピューティングプラットフォーム100の例示的実装形態では、API用のIBCデータは、ハードコードされ得る。IBCタプルデータは、たとえば、APIまたはコンピューティングプラットフォーム100にアクセス可能なデータストアに手動入力することができる。さらに、APIは、送付者の識別情報および受信者の識別情報についての情報を生成するように構成され得る。APIは、送付者および受信者のIBCタプルデータに基づいて、送付者と受信者の間のデータ接続についての技術データを生成するようにも構成され得る。

【0053】

Who-is-who API450は、たとえば、IBCタプルデータのセマンティック分析に基づいて、送付側エンティティおよび受信側エンティティの識別情報を確認するように構成され得る。上述した例示的データ送付シナリオでは、ビジネスエンティティ(WERKS 002、MATNR 4711)は、RFCチャネルを介して、外部受信者/共通マネージメント層410に品目配送発注を送ることができる。共通マネージメント層410内のWho-is-who API450は、たとえば、品目配送発注を受信すると、送付者が誰であるか、配送発注が誰に対してアドレス指定されるかを、「送付者はAUTO Werk Baunatal、Engine Deviceです」、および「あなたは、米国ニューヨークの倉庫2です」のように確認することができる。

【0054】

図3を参照して前述したように、システムまたはクライアントが、URL/RFC宛先として送付者によって技術的にアドレス指定され得るとしても、送付品目配送発注は、送付者のIBCと受信者のIBCの両方を含み得る。ビジネスシステム内のいくつかの受信側サブエンティティを表す受信側アプリケーションは、受信者のセマンティックアドレス(すなわち、受信者IBC名)によって、いくつかの受信側サブエンティティのうちのどれが、配送発注が属す送付品目の指定受信者であるか(たとえば、組織ユニット001またはユニット002)を見分けることが可能であってよい。

【0055】

上述した様々なセマンティックアドレス指定APIおよび機能性は、コンピューティングプラットフォーム100によってサポートされる接続性タイプ/チャネルとは無関係であることに留意されたい。これらのAPIおよび機能性は、コンピューティングプラットフォーム100上の共通マネージメント層の一部であり得る。さらに、コンピューティングプラットフォーム100上の共通マネージメント層に含まれ得る機能性は、図1〜図4を参照して説明したものに限定されない。共通マネージメント層の様々な実装形態は、やはり接続性タイプ非依存であり得る代替または追加機能性を含み得る。これらの代替または追加機能性は、たとえば、セマンティックアドレス指定概念を、関与し得る技術的エンティティについての情報と組み合わせることによって、多様なシステム上で稼動する分散型アプリケーションの統合をサポートするためのAPIを含み得る。さらに、代替または追加機能性は、たとえば、分散型アプリケーションの技術的およびセマンティックなエンドツーエンドの監視のためのAPIを含み得る。

【0056】

図6は、コンピューティングプラットフォーム上で起動されるアプリケーションとの間の多様なデータ接続のサービス品質およびマネージメントのための例示的方法600を示す。アプリケーションとの間の多様なタイプのデータ接続は、たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、およびSAP ALEタイプのデータ接続のうちの1つまたは複数を含み得る。

【0057】

方法600は、コンピューティングプラットフォームにおいて、アプリケーションとの間の多様なタイプのデータ接続のサービス品質およびマネージメントのための層を提供するステップ(601)と、アプリケーションとの間の多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを提供するステップ(602)とを含む。

【0058】

コンピューティングプラットフォームにおいて、アプリケーションとの間の多様なタイプのデータ接続のサービス品質およびマネージメントのための層を提供するステップ601は、アプリケーションとの間の多様なタイプのデータ接続の各々用に、それぞれのメッセージアセンブラモジュールを提供するステップ(603)を含み得る。メッセージアセンブラモジュールは、共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続のタイプに従って、特定の外部受信者への送信用メッセージとしてアセンブルするように構成され得る。アプリケーションとの間の多様なタイプのデータ接続の各々用のそれぞれのメッセージアセンブラモジュールを提供するステップ603は、共通エントリポイントにおいて受信されたデータに基づいてアセンブルされたメッセージに、補足データを追加するように構成された拡張フックポイントを提供するステップ(604)を含み得る。

【0059】

さらに、方法600は、外部送付者から、多様なタイプのデータ接続のうちのいずれかを介してデータを受信するため、および多様な接続性タイプのデータ接続を介して受信されたデータを共通データ構造またはフォーマットにマップするための、サービス品質およびマネージメントのための層を構成するステップ(605)と、データを共通データ構造またはフォーマットにマップした後、コンピューティングプラットフォーム上で受信者にデータをハンドオーバするための、少なくとも1つのアドレス指定可能データハンドオーバポイントを提供するステップ(606)と、コンピューティングプラットフォーム上で起動されるアプリケーションの論理によってハンドリングされない受信メッセージからデータを抽出するように構成された、少なくとも1つのアドレス指定可能データハンドオーバポイントの前で、少なくとも1つの拡張フックを提供するステップ(607)とを含み得る。

【0060】

方法600は、データ接続の接続性タイプとは無関係に、コンピューティングプラットフォームへのデータ接続を介して送られ、または受信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを提供するステップも含み得る。

【0061】

本明細書で説明した様々な技法の実装形態は、デジタル電子回路要素で、もしくはコンピュータハードウェア、ファームウェア、ソフトウェアで、またはそれらの組合せで実装することができる。実装形態は、コンピュータプログラム製品、すなわち、データ処理装置、たとえば、プログラム可能プロセッサ、コンピュータ、もしくは複数のコンピュータによる実行のために、またはその動作を制御するための情報キャリアで、たとえば、機械可読記憶デバイスで、もしくは伝播信号で有形に具現化されるコンピュータプログラムとして実装することができる。上述したコンピュータプログラムなどのコンピュータプログラムは、コンパイルまたはインタープリタ型言語を含む、どの形のプログラミング言語で書かれてもよく、スタンドアロンプログラムとして、またはモジュールとして、コンピューティング環境での使用に適した構成要素、サブルーチン、または他のユニットを含む、どの形でも展開することができる。コンピュータプログラムは、1つの場所における1つのコンピュータ上または複数のコンピュータ上で実行されるように展開されても、複数の場所に分散され、通信ネットワークによって相互接続されてもよい。

【0062】

方法ステップは、インプットデータに対して動作し、アウトプットを生成することによって機能を実施するためのコンピュータプログラムを実行する1つまたは複数のプログラム可能プロセッサによって実施することができる。方法ステップは、特殊目的論理回路要素、たとえば、FPGA(フィールドプログラム可能ゲートアレイ)やASIC(特定用途向け集積回路)によって実施することもでき、装置が、そのような回路要素として実装されてもよい。

【0063】

コンピュータプログラムの実行に適したプロセッサは、例として、汎用および特殊目的マイクロプロセッサの両方、ならびにどの種類のデジタルコンピュータのどの1つまたは複数のプロセッサも含む。概して、プロセッサは、読出し専用メモリもしくはランダムアクセスメモリまたは両方から、命令およびデータを受信することになる。コンピュータの要素は、命令を実行するための少なくとも1つのプロセッサと、命令およびデータを記憶するための1つまたは複数のメモリデバイスとを含み得る。概して、コンピュータは、データを記憶するための1つまたは複数の大容量記憶デバイス、たとえば、磁気、光磁気ディスク、または光ディスクも含み、あるいは大容量記憶デバイスからデータを受信し、もしくはデータを転送し、または両方を行うように大容量記憶デバイスに動作可能に結合され得る。コンピュータプログラム命令およびデータを実施するのに適した情報キャリアは、例として、半導体メモリデバイス、たとえば、EPROM、EEPROM、およびフラッシュメモリデバイスと、磁気ディスク、たとえば、内部ハードディスクまたは取外し可能ディスクと、光磁気ディスクと、CD-ROMおよびDVD-ROMディスクとを含む、あらゆる形の不揮発性メモリを含む。プロセッサおよびメモリは、特殊目的論理回路要素によって補完されても、組み込まれてもよい。

【0064】

ユーザとの対話を可能にするために、実装形態は、ユーザに情報を表示するための表示デバイス、たとえば、陰極線管(CRT)や液晶ディスプレイ(LCD)モニタと、ユーザがコンピュータにインプットを与え得るためのキーボードおよびポインティングデバイス、たとえば、マウスやトラックボールとを有するコンピュータ上で実装することができる。他の種類のデバイスも、ユーザとの対話を可能にするのに使うことができ、たとえば、ユーザに与えられるフィードバックは、どの形の感覚フィードバックでも、たとえば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックでもよく、ユーザからのインプットは、音響、発話、または触覚インプットを含む、どの形でも受信することができる。

【0065】

実装形態は、バックエンド構成要素を、たとえば、データサーバとして含む、またはミドルウェア構成要素、たとえば、アプリケーションサーバを含む、またはフロントエンド構成要素、たとえば、ユーザが実装形態と対話し得るためのグラフィカルユーザインターフェースもしくはウェブブラウザを有するクライアントコンピュータ、あるいはそのようなバックエンド、ミドルウェア、またはフロントエンド構成要素のどの組合せも含むコンピューティングシステムで実装することができる。構成要素は、どの形または媒体のデジタルデータ通信、たとえば、通信ネットワークによっても相互接続することができる。通信ネットワークの例には、ローカルエリアネットワーク(LAN)およびワイドエリアネットワーク(WAN)、たとえば、インターネットがある。

【0066】

説明した実装形態のいくつかの特徴を、本明細書で説明したように示したが、ここで、多くの修正、置換、変更および等価物が、当業者には思い付くであろう。したがって、添付の請求項は、実施形態の範囲内であるようなすべての修正および変更をカバーすることを意図していることを理解されたい。

【符号の説明】

【0067】

100 コンピューティングプラットフォーム
110 接続性サービス品質およびマネージメント層、共通マネージメント層
112 メッセージアセンブラモジュール
113 RFC基底層
114 メッセージアセンブラモジュール
115 HTTP/OData基底層
116 メッセージアセンブラモジュール
117 XYZ基底層
118 拡張フックポイント
119 拡張フックポイント
120 データベース
122 データベーステーブル
140 共通エントリポイント
142 RFC受信者
144 HTTP/OData受信者
146 XYZ受信者
150 データ
152 RFC送付者
154 HTTP/ODATA送付者
156 XYZ送付者
160 アプリケーション
165 アプリケーション論理
170 API、アプリケーション固有API

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】