(57)【要約】【課題】本方法は、コンピューティングプラットフォーム上で起動されるアプリケーションとの間の多様なデータ接続のサービス品質およびマネージメントに関する。【解決手段】アプリケーションとの間の多様なタイプのデータ接続は、たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、およびSAP ALEタイプのデータ接続のうちの1つまたは複数を含み得る。方法は、コンピューティングプラットフォームにおいて、アプリケーションとの間の多様なタイプのデータ接続のサービス品質およびマネージメントのための層を提供するステップと、アプリケーションとの間の多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを提供するステップとを含む。【選択図】図1
2014123363.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサと、
メモリと、
前記プロセッサおよびメモリに基づくコンピューティングプラットフォームとを備えるシステムであって、
前記コンピューティングプラットフォームが、その上で起動されるアプリケーションに1つまたは複数のサービスを提供するように構成され、
前記コンピューティングプラットフォームが、前記アプリケーションとの間の多様なタイプのデータ接続のマネージメントのための層を含むシステム。
【請求項２】
前記アプリケーションとの間の前記多様なタイプのデータ接続が、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、およびSAP ALEタイプのデータ接続のうちの1つまたは複数を含む、請求項1に記載のシステム。
【請求項３】
前記マネージメント層が、前記アプリケーションとの間の前記多様なタイプのデータ接続のための共通エラーハンドリング、監視、非同期ハンドリング、およびアドレス指定のうちの少なくとも1つを含む1つまたは複数の共通サービスを提供するように構成される、請求項1に記載のシステム。
【請求項４】
前記マネージメント層が、前記アプリケーションとの間の前記多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを含む、請求項1に記載のシステム。
【請求項５】
前記マネージメント層が、前記アプリケーションとの間の前記多様なタイプのデータ接続の各々用に、それぞれのメッセージアセンブラモジュールを含み、前記メッセージアセンブラモジュールが、前記共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の前記タイプに従って、特定の外部受信者に送信するためのメッセージとしてアセンブルするように構成される、請求項4に記載のシステム。
【請求項６】
前記それぞれのメッセージアセンブラモジュールが、前記共通エントリポイントにおいて受信されたデータに基づいてアセンブルされたメッセージに、補足データを追加するように構成された拡張フックポイントを含む、請求項5に記載のシステム。
【請求項７】
前記マネージメント層が、外部送付者から多様な接続性タイプのデータ接続を介してデータを受信するように、および多様な接続性タイプの前記データ接続のいずれかを介して受信された前記データを共通データ構造またはフォーマットにマップするように構成される、請求項1に記載のシステム。
【請求項８】
前記マネージメント層が、前記データを前記共通データ構造またはフォーマットにマップした後、前記コンピューティングプラットフォーム上で受信者にデータをハンドオーバするための、少なくとも1つのアドレス指定可能データハンドオーバポイントを含む、請求項7に記載のシステム。
【請求項９】
前記マネージメント層が、前記少なくとも1つのアドレス指定可能データハンドオーバポイントの前に少なくとも1つの拡張フックポイントを含み、前記少なくとも1つの拡張フックポイントが、前記コンピューティングプラットフォーム上で起動される前記アプリケーションの論理によってデータがハンドリングされないデータを受信メッセージから抽出するように構成される、請求項8に記載のシステム。
【請求項１０】
前記マネージメント層が、前記データ接続の接続性タイプとは無関係に、前記コンピューティングプラットフォームへのデータ接続を介して送られ、または受信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを含む、請求項1に記載のシステム。
【請求項１１】
コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメントのための層を提供するステップと、
前記コンピューティングプラットフォーム上で、前記アプリケーションとの間の前記多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを提供するステップとを含む方法。
【請求項１２】
コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、前記アプリケーションとの間の前記多様なタイプのデータ接続の各々用に、それぞれのメッセージアセンブラモジュールを提供するステップを含み、前記メッセージアセンブラモジュールが、前記共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の前記タイプに従って、特定の外部受信者に送信するためのメッセージとしてアセンブルするように構成される、請求項11に記載の方法。
【請求項１３】
前記アプリケーションとの間の前記多様なタイプのデータ接続の各々用にそれぞれのメッセージアセンブラモジュールを提供するステップが、前記共通エントリポイントにおいて受信されたデータに基づいてアセンブルされたメッセージに、補足データを追加するように構成された拡張フックポイントを提供するステップを含む、請求項12に記載の方法。
【請求項１４】
コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、外部送付者から多様な接続性タイプのデータ接続を介してデータを受信するための、および多様な接続性タイプの前記データ接続を介して受信された前記データを共通データ構造またはフォーマットにマップするための前記マネージメント層を構成するステップを含む、請求項11に記載の方法。
【請求項１５】
コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、前記マネージメント層が、前記データを前記共通データ構造またはフォーマットにマップした後、前記コンピューティングプラットフォーム上で受信者にデータをハンドオーバするための、少なくとも1つのアドレス指定可能データハンドオーバポイントを提供するステップを含む、請求項14に記載の方法。
【請求項１６】
コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、前記マネージメント層が、前記少なくとも1つのアドレス指定可能データハンドオーバポイントの前に少なくとも1つの拡張フックポイントを提供するステップを含み、前記少なくとも1つの拡張フックポイントが、前記コンピューティングプラットフォーム上で起動される前記アプリケーションの論理によってハンドリングされないデータを受信メッセージから抽出するように構成される、請求項15に記載の方法。
【請求項１７】
コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメント層を提供するステップが、前記データ接続の接続性タイプとは無関係に、前記コンピューティングプラットフォームへのデータ接続を介して通信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを提供するステップを含む、請求項15に記載の方法。
【請求項１８】
コンピュータシステム上で実行されることが可能な命令を備える非一時的コンピュータ可読記録媒体であって、命令が、前記コンピュータシステム上で実行されると、
コンピューティングプラットフォーム上のアプリケーションとの間の多様なタイプのデータ接続のマネージメントのための層と、
前記アプリケーションとの間の前記多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントとを生成する、非一時的コンピュータ可読記録媒体。
【請求項１９】
前記命令が、前記コンピュータシステム上で実行されると、前記アプリケーションとの間の前記多様なタイプのデータ接続の各々用に、それぞれのメッセージアセンブラモジュールを生成し、前記共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の前記タイプに従って、前記メッセージアセンブラモジュールが、特定の外部受信者に送信するためのメッセージとしてアセンブルするように構成される、請求項18に記載の非一時的コンピュータ可読記録媒体。
【請求項２０】
前記命令が、前記コンピュータシステム上で実行されると、外部送付者から多様なタイプのデータ接続を介してデータを受信するための、および多様な接続性タイプのデータ接続を介して受信された前記データを共通データ構造またはフォーマットにマップするための前記マネージメント層を構成する、請求項18に記載の非一時的コンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多様なデータ接続のためのサービスおよびマネージメント層に関する。
【背景技術】
【０００２】
コンピューティングプラットフォームは単純には、アプリケーションソフトウェアを起動するための場所と定義することができる。コンピューティングプラットフォームは、アプリケーションソフトウェアを稼働させるように設計されたハードウェアアーキテクチャおよびソフトウェアフレームワーク(アプリケーションフレームワークを含む)を含み得る。コンピューティングプラットフォームは、様々なシステムがコンピューティングプラットフォームをサポートする限り、それらのシステムのいずれにおいても論理コード(またはアプリケーション)が一貫して稼働するであろうという確信を、ソフトウェア開発者にもたせる。論理コードは、バイトコード、ソースコード、および機械コードを含む。
【０００３】
コンピューティングプラットフォーム上で稼動するアプリケーションは、特定のプログラムされたデータ接続を介して、他のコンピューティング要素またはエンティティ(たとえば、データベース、他のアプリケーション、他のコンピューティングプラットフォームもしくはシステムなど)と対話することも、データを交換することもできる。アプリケーションとの間のデータ接続は、特定の接続性タイプ(たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、SAP ALEなど)であってよい。各特定のデータ接続タイプは、独自の(たとえば、構成、ランタイム、監視、アドレス指定態様、エラーハンドリングなどのための)プログラミングモデルを有し得る。
【０００４】
実際、コンピューティングプラットフォーム上で稼動するアプリケーションは、多様な接続性タイプおよびプログラミングモデルを使うことができる。接続性タイプおよびプログラミングモデルにおける多種性または多様性により、コンピューティングプラットフォームにおけるアプリケーション統合および接続性管理の複雑さが増し得る。
【０００５】
アプリケーション向けの特定のデータ接続タイプは、たとえば、特定の接続性タイプの利点および欠点の考慮に基づいて、アプリケーション開発者によって選択することができる。ある接続性タイプのデータ接続を介して着信する着信データはほとんど、同じ接続性タイプのエンティティによって、アプリケーション内で処理される(たとえば、着信RFCデータはしばしば、受信側RFC機能モジュールにおいて事前処理される)。その結果、アプリケーションによって新規または追加データ接続タイプがサポートされることになるたびに、アプリケーション論理は、アプリケーション開発者によって書き換えられなければならない。いくつかのアプリケーションプログラミングインターフェース(API)、たとえば、データを受信するためのAPIであって、少なくともビジネスロジックのいくつかの部分を含むAPIは、最新の状態に保つために書き換えられなければならない場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
アプリケーション統合および接続性管理を簡易にすることを目的とするコンピューティングプラットフォームフレームワークが検討されるべきである。
【課題を解決するための手段】
【０００７】
システムは、プロセッサと、メモリと、プロセッサおよびメモリに基づくコンピューティングプラットフォームとを含む。コンピューティングプラットフォームは、その上で起動されるアプリケーションに、1つまたは複数のサービスおよびプロセスを提供する。アプリケーションは、他のエンティティ、データベースまたはアプリケーションへのデータ接続セットを有し得る。データ接続セットは、異なる特定の接続性タイプ(たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、SAP ALE接続性タイプなど)の異なるデータ接続を含み得る。異なる特定の接続性タイプのデータ接続セットは、同じ接続性タイプのいくつかのデータ接続を含み得ることが理解されよう。さらに、本明細書で使用する場合、「データ接続のタイプ」、「データ接続タイプ」、または「接続タイプ」という用語は、データ接続の特定の接続性タイプを指すことが理解されよう。
【０００８】
1つの一般的態様によると、コンピューティングプラットフォームは、アプリケーションとの間のデータ接続のサービス品質およびマネージメントのための層を含む。アプリケーションとの間のデータ接続は、異なる特定の接続性タイプの、1つまたは複数のデータ接続を含み得る。
【０００９】
一態様では、サービス品質およびマネージメントのための層は、アプリケーションへの多様なタイプのデータ接続のための、エラーハンドリング、監視、非同期ハンドリング、およびアドレス指定のうちの少なくとも1つを含む1つまたは複数の共通サービスを提供する。
【００１０】
別の態様では、サービス品質およびマネージメントのための層は、アプリケーションとの間の多様な接続性タイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを含む。サービス品質およびマネージメントのための層は、アプリケーションとの間の多様な接続性タイプのデータ接続の各々のための、それぞれのメッセージアセンブラモジュールを含む。メッセージアセンブラモジュールは、共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続のタイプに従って、特定の外部受信者への送信用メッセージとしてアセンブルする。
【００１１】
さらに別の態様では、サービス品質およびマネージメントのための層は、受信データを共通データ構造またはフォーマットにマップした後、コンピューティングプラットフォーム上で、受信データを受信者にハンドオーバするための少なくとも1つのアドレス指定可能データハンドオーバポイントを含む。
【００１２】
さらなる態様では、サービス品質およびマネージメントのための層は、コンピューティングプラットフォームへのデータ接続を介して送られ、または受信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを含む。
【００１３】
1つの一般的態様によると、方法は、コンピューティングプラットフォーム上のアプリケーションとの間の多様な接続性タイプのデータ接続のサービス品質およびマネージメントのための層を提供するステップと、アプリケーションとの間の多様な接続性タイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを提供するステップとを含む。
【００１４】
一態様では、方法は、アプリケーションとの間の多様な接続性タイプのデータ接続の各々のための、それぞれのメッセージアセンブラモジュールを提供するステップを含む。メッセージアセンブラモジュールは、共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の接続性タイプに従って、特定の外部受信者への送信用のメッセージとしてアセンブルするように構成される。
【００１５】
別の態様では、方法は、外部送付者から多様なタイプのデータ接続を介してデータを受信するため、および多様な接続性タイプのデータ接続を介して受信されたデータを共通データ構造またはフォーマットにマップするための、サービス品質およびマネージメントのための層を構成するステップを含む。
【００１６】
さらに別の態様では、方法は、受信データを共通データ構造またはフォーマットにマップした後、コンピューティングプラットフォーム上で受信者にデータをハンドオーバするための、少なくとも1つのアドレス指定可能データハンドオーバポイントを提供するステップを含む。
【００１７】
さらなる態様では、方法は、データ接続の接続性タイプとは無関係に、コンピューティングプラットフォームへのデータ接続を介して送られ、または受信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを提供するステップを含む。
【００１８】
1つの一般的態様によると、非一時的コンピュータ可読媒体は、コンピュータシステム上で実行されることが可能な命令を含む。命令は、コンピュータシステム上で実行されると、コンピューティングプラットフォーム上のアプリケーションとの間の多様な接続性タイプのデータ接続のサービス品質およびマネージメントのための層と、アプリケーションとの間の多様な接続性タイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントとを生成する。
【００１９】
一態様では、命令は、コンピュータシステム上で実行されると、アプリケーションとの間の多様な接続性タイプのデータ接続の各々のための、それぞれのメッセージアセンブラモジュールをさらに生成する。メッセージアセンブラモジュールは、共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続の接続性タイプに従って、特定の外部受信者への送信用のメッセージとしてアセンブルすることができる。
【００２０】
別の態様では、命令は、コンピュータシステム上で実行されると、外部送付者から多様な接続性タイプのデータ接続を介してデータを受信するため、および多様な接続性タイプのデータ接続を介して受信されたデータを共通データ構造またはフォーマットにマップするためのサービス品質およびマネージメントのための層を構成する。
【００２１】
1つまたは複数の実装形態の詳細について、添付の図面および以下の説明において述べる。他の特徴は、説明および図面、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００２２】
【図１】本明細書における本開示の原理による、データ送付シナリオにおいて使うことができる、例示的コンピューティングプラットフォームのサービスおよびプロセス要素を示すブロック図である。
【図２】本明細書における本開示の原理による、データ受信シナリオにおいて使うことができる、図1の例示的コンピューティングプラットフォームのサービスおよびプロセス要素を示すブロック図である。
【図３】本明細書における本開示の原理による、データ送付シナリオにおける、図1のコンピューティングプラットフォームにおけるセマンティックアドレス指定手法の例示的実装形態を示すブロック図である。
【図４】本明細書における本開示の原理による、データ受信シナリオにおける、図2のコンピューティングプラットフォームにおけるセマンティックアドレス指定手法の例示的実装形態を示すブロック図である。
【図５】コンピューティングマシンによってサポートされるコンピューティングプラットフォームを示す概略的なブロック図である。
【図６】本明細書における本開示の原理による、コンピューティングプラットフォーム上で起動されるアプリケーションとの間の多様なデータ接続のサービス品質およびマネージメントのための例示的方法の流れ図である。
【発明を実施するための形態】
【００２３】
コンピュータシステムは、他のアプリケーション、データベース、サーバ、ストレージ、コンピュータシステムまたはエンティティなどに接続し、または対話するアプリケーション(たとえば、ビジネスアプリケーション)を起動するのに使うことができる。コンピュータシステムは、たとえば、ネットワーク化された配置で展開することができる1つまたは複数の物理または仮想コンピューティングマシンによってホストまたはサポートされるコンピューティングプラットフォームを含み得る。コンピューティングプラットフォームは、たとえば、ホストコンピューティングマシンのハードウェア構成要素(たとえば、プロセッサ、メモリ、キーパッド、ディスプレイ、ネットワークカードなど)ならびに他の構成要素およびプロセスを支配するオペレーティングシステムを含み得る。図5は、ネットワーク化されたコンピュータシステム内の物理または仮想マシンを表し得るコンピューティングマシン10によってサポートされる例示的コンピューティングプラットフォーム20を概略的に示す。ホストコンピューティングマシン10は、CPU11、メモリ12、I/O13およびO/S14を含み得る。CPU11は、いかなる一般的プロセッサであってもよく、メモリ12は、CPU11によって、いくつかの機能を実施するのに使われるデータを記憶するように構成された1つまたは複数の記憶デバイスであってよい。
【００２４】
コンピューティングプラットフォーム20は、その上で起動されるアプリケーション(たとえば、ビジネスアプリケーション30)用のアプリケーションフレームワークと、プロセスまたはサービスとを提供することができる。アプリケーション30は、機能する際、他の外部エンティティ(たとえば、アプリケーション、データベース、システムなど)に接続して、たとえば、データを送り、受信し、または交換することができる。送付側エンティティと受信側エンティティとの間のデータ接続には、「接続性」タイプについてのカスタムまたは業界標準データ接続プロトコル(たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、SAP ALEなど)が使われ得る。
【００２５】
コンピューティングプラットフォームフレームワークまたはプログラミングモデルの下では、本明細書における本開示の原理により、多様な接続性タイプのデータ接続のための共通接続性サービス品質およびマネージメント層(「共通マネージメント層」)が、コンピューティングプラットフォーム内に設けられる。
【００２６】
共通マネージメント層は、コンピューティングプラットフォーム上でホストされるアプリケーションによって使われ、または要求され得る、多様な接続性タイプの1つまたは複数の共通サービス(たとえば、エラーハンドリング、監視、非同期ハンドリング、アドレス指定など)をデータ接続に提供するように構成される。共通サービスについての2つのシナリオを想定することができ、第1のシナリオでは、コンピューティングプラットフォーム上でホストされるアプリケーションが、データ接続を介してデータを送り、第2のシナリオでは、コンピューティングプラットフォーム上でホストされるアプリケーションが、データ接続を介してデータを受信する。
【００２７】
データ送付シナリオ
データ送付シナリオにおけるデータは、アプリケーション環境から、またはデータベース環境から発し得る。このシナリオにおけるサービスに対して、共通マネージメント層は、コンピューティングプラットフォームまたはコンピューティングプラットフォーム上でホストされるアプリケーションに結合されたデータベースであり得る送付エンティティから、外部受信者に向けられたデータ(およびデータ属性)を受信するための共通エントリポイントを有し得る。送付エンティティによって共通エントリポイントにおいて共通マネージメント層にハンドオーバされるデータ属性は、たとえば、データ接続が同期であるか、非同期であるか、信頼できるかどうかなどのデータ属性を含み得る。さらに、ハンドオーバされるデータ属性は、意図されたデータ受信者へのデータ接続のタイプの直接または間接識別を含み得る。
【００２８】
共通マネージメント層は、共通エントリポイントにおいて受信されたデータおよびデータ属性を処理して、データの意図された外部受信者へのデータ接続のタイプと整合するメッセージをアセンブルするように構成することができる。アセンブルされたメッセージは、共通マネージメント層内の、接続性タイプ用のそれぞれの基底層またはスタブから、データの意図された外部受信者に送出され得る。共通エントリポイントは、アプリケーション環境からの、それともデータベース環境からのデータからメッセージがアセンブルされるかにかかわらず同じであり得る。
【００２９】
図1は、本明細書における本開示の原理による、データ送付シナリオにおいて使うことができる、例示的コンピューティングプラットフォーム100のサービスおよびプロセス要素を示すブロック図である。図に示すように、コンピューティングプラットフォーム100は、データベース120/データベーステーブル122に結合され得る。さらに、コンピューティングプラットフォーム100は、1つまたは複数のアプリケーション(たとえば、アプリケーション160)をホストすることができる。1つまたは複数のアプリケーションは、たとえば、データベース120/データベーステーブル122に記憶されたデータを処理またはアクセスするように構成され得る。
【００３０】
コンピューティングプラットフォーム100は、一般に、多様な接続性タイプのデータ接続またはチャネルを介した、コンピューティングプラットフォームから様々な外部受信者(たとえば、RFC受信者142、HTTP/OData受信者144、XYZ受信者146など)への送付データを管理するように構成された接続性サービス品質およびマネージメント層110(「共通マネージメント層110」)を含み得る。コンピューティングプラットフォーム100は、様々な受信者のうちいずれかに送られるべきデータ150が、送付エンティティ(たとえば、アプリケーションやデータベース)によって共通マネージメント層110にハンドオーバされる共通エントリポイント140を含み得る。図示するように、データ150のハンドオーバは、たとえば、アプリケーション160が、共通エントリポイント140においてデータへのハンドル(たとえば、アクセスキー、トークンまたは他の識別子)を共通マネージメント層110に提供することを伴い得る。代替的に、または追加として、データベース120によるデータ150のハンドオーバは、共通エントリポイント140において、データベーストリガ、キーまたは類似のデータ識別子を共通マネージメント層110にハンドオーバすることを伴い得る。データ150のハンドオーバは、たとえば、意図されたデータ受信者および/またはデータ接続タイプの識別を含む関連データ属性のハンドオーバも伴い得ることが理解されよう。
【００３１】
共通マネージメント層110は、コンピューティングプラットフォーム100によってサポートされ得る様々な接続タイプの各々用のそれぞれの基底層またはスタブ(たとえば、RFC基底層113、HTTP/OData基底層115、XYZ基底層117など)に供給を行う、それぞれのメッセージアセンブリモジュール(たとえば、メッセージアセンブラモジュール112、メッセージアセンブラモジュール114、メッセージアセンブラモジュール116など)を含み得る。特定の基底層またはスタブが、特定のデータ接続タイプ用の、受信者とのコンピューティングプラットフォームのインターフェースを定義することができる。共通マネージメント層110は、それぞれのメッセージアセンブラモジュール112を使って、特定の受信者への送信用データ150に基づいてメッセージをアセンブルするように、および特定の受信者へのデータ接続タイプに対応する基底層またはスタブを使って、アセンブルされたメッセージを特定の受信者にさらに送るように構成され得る。
【００３２】
メッセージアセンブラモジュール112〜116は、(たとえば、メッセージアセンブリの後の)拡張性のために構成された拡張フックポイント118を含み得る。これらの拡張フックポイント118は、データ150に基づいてアセンブルされたメッセージに補足データを随意に追加するのに使うことができる。メッセージに追加される補足データは、アプリケーションチェックなどのアプリケーション関与なしで、直接データベースアクセスによって取得することができる。
【００３３】
共通マネージメント層110が、接続インターフェースを提供し、様々な接続性タイプのデータ接続のためのメッセージを準備するので、様々な接続性タイプの各々用の個々の論理またはアプリケーションプログラミングインターフェース(API)でアプリケーション(たとえば、アプリケーション160)をカスタマイズする必要はなくてよい。さらに、たとえば、適切なメッセージアセンブラモジュールを共通マネージメント層110に含めることによって、アプリケーション160自体をプログラムまたは修正する必要なしで、新規または将来の接続性タイプのデータ接続がサービスされ得る。
【００３４】
データ受信シナリオ
データ受信シナリオにおいて、コンピューティングプラットフォーム上のアプリケーションまたはデータベースに向けられたデータは、様々な接続性タイプのうちのいずれかのデータ接続を介してコンピューティングプラットフォーム上で受信することができる。各データ接続タイプは、独自のプログラミングモデルを有し得る。このシナリオにおけるサービスに対して、コンピューティングプラットフォームは、外部送付者から受信したデータを、コンピューティングプラットフォーム上でホストされるアプリケーションに、またはコンピューティングプラットフォームにリンクされたデータベースに渡すための単一のデータハンドオーバポイント(または「ユニバーサルAPI」)を有し得る。単一のデータハンドオーバポイントまたはユニバーサルAPIは通常、コンピューティングプラットフォームにおいてデータが受信される際に経由するデータ接続またはチャネルの接続性タイプとは無関係に、いくつかの外部受信者のうちのいずれかから受信されるデータのための特定のアプリケーション用に使うことができる。コンピューティングプラットフォームにおいて受信されたデータは、データがそれを介して受信される接続またはチャネルのタイプおよびプログラミングモデルに従って、異なるように準備または調整することができると予想され得る。共通マネージメント層は、異なる接続性タイプのデータ接続を介して受信された、異なるように準備または調整されたデータを、ユニバーサルAPIに適合するようにマップするように構成され得る。
【００３５】
共通マネージメント層は、コンピューティングプラットフォームによってサポートされる多様な接続性タイプのすべてに関して、共通サービス品質(たとえば、エラーハンドリング、監視、非同期ハンドリングなど)を提供することができる。共通マネージメント層が実装されると、アプリケーションによってデータ接続に使われる各接続性タイプに関して、特定のサービスツール(たとえば、管理ツール、エラーハンドリングツール、監視ツール、構成ツール、および独自のランタイム(すなわち実行オブジェクト)など)を別個に提供する必要をなくすことができる。共通マネージメント層は、中心的環境において、通常、データ接続およびアプリケーションによるデータ接続によって使われる接続性タイプのすべてに関して等価なサービスまたは機能性を提供することができる。
【００３６】
図2は、本明細書における本開示の原理による、データ受信シナリオにおいて使うことができる、例示的コンピューティングプラットフォーム100のサービスおよびプロセス要素の概略図である。図1で先に示したように、コンピューティングプラットフォーム100は、データベース120/データベーステーブル122に結合され得る。さらに、コンピューティングプラットフォーム100は、1つまたは複数のアプリケーション(たとえば、図1のアプリケーション160だが、図2ではアプリケーション論理165として表される)をホストすることができる。
【００３７】
コンピューティングプラットフォーム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)と互換性があり得る。
【００３８】
データマッピングモジュール214〜218は、拡張フックポイント119をさらに含んでよく、フックポイント119は、送付者側における拡張フックポイント(たとえば、拡張フックポイント118)の相対物でよい。拡張フックポイント119は、受信メッセージから拡張データを取り出すように構成してよく、これには、受信されたメッセージからアプリケーション論理165によって提供されない別個のハンドリングが要求される。拡張フックポイント119は、接続性タイプ固有のデータマッピングモジュール214〜218の後、ただし少なくとも1つのAPI170の前に配置してよい。
【００３９】
さらに、コンピューティングプラットフォーム100は、様々な送付者のいずれかによって送られるデータを、共通データ構造またはフォーマットにマップした後に、共通マネージメント層210によって指定受信者(たとえば、アプリケーション160、データベーステーブル122)にハンドオーバすることができるようにするための少なくとも1つのアドレス指定可能データハンドオーバポイント(たとえば、アプリケーション固有API170)を含み得る。図示するように、マップされたデータは、たとえば、データベース120への直接データベースアクセスによって、またはアプリケーション論理165に対する呼によって、アプリケーション固有API170からハンドオーバすることができる。
【００４０】
コンピューティングプラットフォーム100は、様々なデータ接続タイプをサポートし、かつ/または様々なアプリケーションをホストすることができるが、特定の接続性タイプのデータ接続または外部送付者のために、どの特定のデータマッピングモジュールが呼び出されるべきか、ならびに/あるいは、たとえば、外部送付者からデータが受信されたときに、どのアプリケーション固有APIが呼び出されるべきかを示し得るパラメータまたは設定で、手動で構成することができる。
【００４１】
共通マネージメント層210が、様々なデータ接続タイプに対して共通アプリケーション固有API(たとえば、API170)を提供するので、コンピューティングプラットフォーム100上でホストされ得るアプリケーション160を、様々なデータ接続タイプの各々向けの個々の論理またはアプリケーションプログラミングインターフェースでカスタマイズする必要はなくてよい。さらに、たとえば、適切なデータマッピングモジュールを共通マネージメント層110に含めることによって、アプリケーション160またはアプリケーション論理165を変更し、または書き換える必要なく、新規または将来のデータ接続タイプをサービスすることができる。
【００４２】
それぞれ、データ送付シナリオおよびデータ受信シナリオに対応する、図1および図2の例示的共通マネージメント層は、説明の便宜上、異なるように、すなわち「110」および「210」と標示されていることが理解されよう。コンピューティングプラットフォームにおける単一の共通マネージメント層は、図に示す2つの例示的共通マネージメント層110および210の要素を含み、データ送付シナリオとデータ受信シナリオの両方の下で接続性サービスを提供することができる。さらに、共通マネージメント層は、様々な接続性タイプのためのサービス品質のマネージメントまたは提供に関連した追加要素またはモジュールを含み得る。図3および図4は、たとえば、コンピューティングプラットフォーム100によってサポートされる様々なデータ接続タイプを介して送られ、または受信されるデータまたはメッセージの「アドレス指定」態様に関する追加モジュールまたは要素(たとえば、Who-am-I API350、論理受信者判断API360、およびWho-Is-who API450など)を含む共通マネージメント層310および410を示す。
【００４３】
コンピューティングプラットフォーム100の共通マネージメント層に含まれ得る追加モジュールまたは要素は、データ接続のためのアドレス指定可能エンティティが、たとえば、アプリケーションエンティティであるセマンティックアドレス指定手法に基づき得る。このアプリケーション中心手法は、RFC宛先やURLなどの技術的エンティティによる、システムまたはクライアントのアドレス指定を伴う他のアドレス指定手法とは対照的であり得る。本開示のセマンティックアドレス指定手法は、アプリケーションレベルエンティティと、システムまたはクライアントよりも微細なエンティティとに適用可能であり得る。さらに、コンピューティングプラットフォーム100の共通マネージメント層は、データ接続の特定の接続性タイプとは無関係に、多様なデータ接続を介したセマンティックアドレス指定手法を中心に実装することができる。
【００４４】
本明細書において以降の説明で言及され得る例示的アドレス指定問題は、コンピュータシステム上のエンティティの間のデータ通信に関するものでよく、エンティティでは、組織ユニット1および2が、コンピュータシステムにより接続され、それらのセマンティック識別情報(たとえば、それぞれ、「会社のドイツ北部営業所」および「会社のドイツ南部営業所」)によってシステム上で露出され得る。組織ユニット2の顧客は、「Baunatal Engine Device自動車工場」というセマンティック識別情報をもち得る。ただし、この顧客は、ユニット2では、システム上のURL/RFC宛先としてのみ識別され得る。
【００４５】
セマンティックアドレス指定手法に基づく例示的ソリューションでは、エンティティ(たとえば、会社のドイツ南部営業所など)は、割り当てられたセマンティック識別情報または「識別可能ビジネスコンテキスト」(IBC)名をもつことができ、これらは、たとえば、エンティティ所有者(たとえばアプリケーション、顧客、業種(LOB)など)によって作成することができる。例示的IBC名はタプルであってよく、たとえば、ビジネスコンテキストまたは対応する担当者の住所、電話番号、eメールアドレスなどのエンティティ識別情報を含む。エンティティのIBC名またはタプルは、それが作成されたシステムまたは環境からエクスポートすることができ、(たとえば、メールによって)共有し、そうでなければ、IBC固有表現がそこからアドレス指定される必要がある送付またはアドレス指定システム、アプリケーション、または環境にインポートすることができる。IBCは、コンピューティングプラットフォーム100における技術的および論理的受信者判断のための基盤であり得る。
【００４６】
セマンティックアドレス指定手法に基づくソリューションでは、システム上のエンティティの間のデータ接続のための技術的パラメータは、送付側または「アドレス指定側」エンティティ(たとえば、アプリケーション、システムなど)のセマンティック識別情報および受信側または「アドレス指定先」エンティティ(たとえば、アプリケーション、システムなど)のセマンティック識別情報のタプルから導出することができる。
【００４７】
データ送付シナリオ(図1)において、送付者および受信者エンティティのIBCタプルを知っていることにより、送付者と受信者との間で提供または実装することができる接続性を技術的に判断することができるようになる。技術的判断は、たとえば、接続性タイプ(たとえば、RFC)、対応するメッセージアセンブラモジュール(たとえば、RFCメッセージアセンブリモジュール)、受信者側で呼び出されるべき機能モジュール(たとえば、RFC受信者)、およびセキュリティ設定などの判断を含み得る。
【００４８】
論理的ルーティングが必要とされるケースでは、アプリケーションが定義した基準に基づいてルーティング規則を生成することが可能であり得る。たとえば、ドイツにいる顧客が、コンピューティングプラットフォーム上でホストされるアプリケーションにより、本の購入発注を行うケースでは、購入発注は、「ドイツの倉庫」というIBCに論理的にルーティングされ得る。対照的に、顧客が米国にいるケースでは、購入発注は、「米国の倉庫」というIBCに論理的にルーティングされ得る。
【００４９】
データ送付シナリオ
図3は、図1を参照して上述したデータ送付シナリオにおける、コンピューティングプラットフォーム100上でのセマンティックアドレス指定手法の例示的実装形態300を示す。実装形態300において、コンピューティングプラットフォーム100の共通マネージメント層310は、セマンティックアドレス指定手法を実装するように構成されたAPI(たとえば、Who-am-I API350および論理的受信者判断API360)を含み得る。API用のIBCデータは、ハードコードされ得る。コンピューティングプラットフォーム100の例示的実装形態において、IBCタプルデータは、たとえば、APIまたはコンピューティングプラットフォーム100にとってアクセス可能なデータストアに手動入力することができる。さらに、APIは、IBCタプルデータの分析によって、送付者の識別情報および受信者の識別情報についての情報を生成するように構成され得る。APIは、IBCタプルデータに基づいて、送付者と受信者の間のデータ接続についての技術的データを生成するようにも構成され得る。
【００５０】
Who-am-I API350は、たとえば、IBCタプルデータのセマンティック分析に基づいて、自身または自己識別情報IBCタプルを送付エンティティに提供するように構成され得る。さらに、論理的受信者判断API360は、たとえば、IBCタプルデータのセマンティック分析に基づいて、受信者識別情報を提供するように構成され得る。送付者が、データを送る間にシステムまたはクライアントを技術的に(たとえば、URL/RFC宛先などとして)アドレス指定済みである可能性があるとしても、送付者IBCおよび受信者IBCは、送付データとともに転送されてよい。
【００５１】
セマンティックアドレス指定の使用を示す例では、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名のセマンティック分析に基づく識別情報で応答することができる。
【００５２】
データ受信シナリオ
図4は、図2を参照して上述したデータ受信シナリオにおける、コンピューティングプラットフォーム100上でのセマンティックアドレス指定手法の例示的実装形態400を示す。実装形態400において、コンピューティングプラットフォーム100の共通マネージメント層410は、セマンティックアドレス指定手法を実装するように構成されたAPI(たとえば、「Who-is who」API450)を含み得る。上のデータ送付シナリオについて説明したように、コンピューティングプラットフォーム100の例示的実装形態では、API用のIBCデータは、ハードコードされ得る。IBCタプルデータは、たとえば、APIまたはコンピューティングプラットフォーム100にアクセス可能なデータストアに手動入力することができる。さらに、APIは、送付者の識別情報および受信者の識別情報についての情報を生成するように構成され得る。APIは、送付者および受信者のIBCタプルデータに基づいて、送付者と受信者の間のデータ接続についての技術データを生成するようにも構成され得る。
【００５３】
Who-is-who API450は、たとえば、IBCタプルデータのセマンティック分析に基づいて、送付側エンティティおよび受信側エンティティの識別情報を確認するように構成され得る。上述した例示的データ送付シナリオでは、ビジネスエンティティ(WERKS 002、MATNR 4711)は、RFCチャネルを介して、外部受信者/共通マネージメント層410に品目配送発注を送ることができる。共通マネージメント層410内のWho-is-who API450は、たとえば、品目配送発注を受信すると、送付者が誰であるか、配送発注が誰に対してアドレス指定されるかを、「送付者はAUTO Werk Baunatal、Engine Deviceです」、および「あなたは、米国ニューヨークの倉庫2です」のように確認することができる。
【００５４】
図3を参照して前述したように、システムまたはクライアントが、URL/RFC宛先として送付者によって技術的にアドレス指定され得るとしても、送付品目配送発注は、送付者のIBCと受信者のIBCの両方を含み得る。ビジネスシステム内のいくつかの受信側サブエンティティを表す受信側アプリケーションは、受信者のセマンティックアドレス(すなわち、受信者IBC名)によって、いくつかの受信側サブエンティティのうちのどれが、配送発注が属す送付品目の指定受信者であるか(たとえば、組織ユニット001またはユニット002)を見分けることが可能であってよい。
【００５５】
上述した様々なセマンティックアドレス指定APIおよび機能性は、コンピューティングプラットフォーム100によってサポートされる接続性タイプ/チャネルとは無関係であることに留意されたい。これらのAPIおよび機能性は、コンピューティングプラットフォーム100上の共通マネージメント層の一部であり得る。さらに、コンピューティングプラットフォーム100上の共通マネージメント層に含まれ得る機能性は、図1〜図4を参照して説明したものに限定されない。共通マネージメント層の様々な実装形態は、やはり接続性タイプ非依存であり得る代替または追加機能性を含み得る。これらの代替または追加機能性は、たとえば、セマンティックアドレス指定概念を、関与し得る技術的エンティティについての情報と組み合わせることによって、多様なシステム上で稼動する分散型アプリケーションの統合をサポートするためのAPIを含み得る。さらに、代替または追加機能性は、たとえば、分散型アプリケーションの技術的およびセマンティックなエンドツーエンドの監視のためのAPIを含み得る。
【００５６】
図6は、コンピューティングプラットフォーム上で起動されるアプリケーションとの間の多様なデータ接続のサービス品質およびマネージメントのための例示的方法600を示す。アプリケーションとの間の多様なタイプのデータ接続は、たとえば、HTTP、ウェブサービス、OData/REST、OData/HTTP、SAP RFC、およびSAP ALEタイプのデータ接続のうちの1つまたは複数を含み得る。
【００５７】
方法600は、コンピューティングプラットフォームにおいて、アプリケーションとの間の多様なタイプのデータ接続のサービス品質およびマネージメントのための層を提供するステップ(601)と、アプリケーションとの間の多様なタイプのデータ接続を介して、外部受信者に向けられたデータを受信するための共通エントリポイントを提供するステップ(602)とを含む。
【００５８】
コンピューティングプラットフォームにおいて、アプリケーションとの間の多様なタイプのデータ接続のサービス品質およびマネージメントのための層を提供するステップ601は、アプリケーションとの間の多様なタイプのデータ接続の各々用に、それぞれのメッセージアセンブラモジュールを提供するステップ(603)を含み得る。メッセージアセンブラモジュールは、共通エントリポイントにおいて受信されたデータを、特定の外部受信者へのデータ接続のタイプに従って、特定の外部受信者への送信用メッセージとしてアセンブルするように構成され得る。アプリケーションとの間の多様なタイプのデータ接続の各々用のそれぞれのメッセージアセンブラモジュールを提供するステップ603は、共通エントリポイントにおいて受信されたデータに基づいてアセンブルされたメッセージに、補足データを追加するように構成された拡張フックポイントを提供するステップ(604)を含み得る。
【００５９】
さらに、方法600は、外部送付者から、多様なタイプのデータ接続のうちのいずれかを介してデータを受信するため、および多様な接続性タイプのデータ接続を介して受信されたデータを共通データ構造またはフォーマットにマップするための、サービス品質およびマネージメントのための層を構成するステップ(605)と、データを共通データ構造またはフォーマットにマップした後、コンピューティングプラットフォーム上で受信者にデータをハンドオーバするための、少なくとも1つのアドレス指定可能データハンドオーバポイントを提供するステップ(606)と、コンピューティングプラットフォーム上で起動されるアプリケーションの論理によってハンドリングされない受信メッセージからデータを抽出するように構成された、少なくとも1つのアドレス指定可能データハンドオーバポイントの前で、少なくとも1つの拡張フックを提供するステップ(607)とを含み得る。
【００６０】
方法600は、データ接続の接続性タイプとは無関係に、コンピューティングプラットフォームへのデータ接続を介して送られ、または受信されるデータメッセージの送付者および受信者についてのセマンティックアドレスを確立するように構成されたモジュールを提供するステップも含み得る。
【００６１】
本明細書で説明した様々な技法の実装形態は、デジタル電子回路要素で、もしくはコンピュータハードウェア、ファームウェア、ソフトウェアで、またはそれらの組合せで実装することができる。実装形態は、コンピュータプログラム製品、すなわち、データ処理装置、たとえば、プログラム可能プロセッサ、コンピュータ、もしくは複数のコンピュータによる実行のために、またはその動作を制御するための情報キャリアで、たとえば、機械可読記憶デバイスで、もしくは伝播信号で有形に具現化されるコンピュータプログラムとして実装することができる。上述したコンピュータプログラムなどのコンピュータプログラムは、コンパイルまたはインタープリタ型言語を含む、どの形のプログラミング言語で書かれてもよく、スタンドアロンプログラムとして、またはモジュールとして、コンピューティング環境での使用に適した構成要素、サブルーチン、または他のユニットを含む、どの形でも展開することができる。コンピュータプログラムは、1つの場所における1つのコンピュータ上または複数のコンピュータ上で実行されるように展開されても、複数の場所に分散され、通信ネットワークによって相互接続されてもよい。
【００６２】
方法ステップは、インプットデータに対して動作し、アウトプットを生成することによって機能を実施するためのコンピュータプログラムを実行する1つまたは複数のプログラム可能プロセッサによって実施することができる。方法ステップは、特殊目的論理回路要素、たとえば、FPGA(フィールドプログラム可能ゲートアレイ)やASIC(特定用途向け集積回路)によって実施することもでき、装置が、そのような回路要素として実装されてもよい。
【００６３】
コンピュータプログラムの実行に適したプロセッサは、例として、汎用および特殊目的マイクロプロセッサの両方、ならびにどの種類のデジタルコンピュータのどの1つまたは複数のプロセッサも含む。概して、プロセッサは、読出し専用メモリもしくはランダムアクセスメモリまたは両方から、命令およびデータを受信することになる。コンピュータの要素は、命令を実行するための少なくとも1つのプロセッサと、命令およびデータを記憶するための1つまたは複数のメモリデバイスとを含み得る。概して、コンピュータは、データを記憶するための1つまたは複数の大容量記憶デバイス、たとえば、磁気、光磁気ディスク、または光ディスクも含み、あるいは大容量記憶デバイスからデータを受信し、もしくはデータを転送し、または両方を行うように大容量記憶デバイスに動作可能に結合され得る。コンピュータプログラム命令およびデータを実施するのに適した情報キャリアは、例として、半導体メモリデバイス、たとえば、EPROM、EEPROM、およびフラッシュメモリデバイスと、磁気ディスク、たとえば、内部ハードディスクまたは取外し可能ディスクと、光磁気ディスクと、CD-ROMおよびDVD-ROMディスクとを含む、あらゆる形の不揮発性メモリを含む。プロセッサおよびメモリは、特殊目的論理回路要素によって補完されても、組み込まれてもよい。
【００６４】
ユーザとの対話を可能にするために、実装形態は、ユーザに情報を表示するための表示デバイス、たとえば、陰極線管(CRT)や液晶ディスプレイ(LCD)モニタと、ユーザがコンピュータにインプットを与え得るためのキーボードおよびポインティングデバイス、たとえば、マウスやトラックボールとを有するコンピュータ上で実装することができる。他の種類のデバイスも、ユーザとの対話を可能にするのに使うことができ、たとえば、ユーザに与えられるフィードバックは、どの形の感覚フィードバックでも、たとえば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックでもよく、ユーザからのインプットは、音響、発話、または触覚インプットを含む、どの形でも受信することができる。
【００６５】
実装形態は、バックエンド構成要素を、たとえば、データサーバとして含む、またはミドルウェア構成要素、たとえば、アプリケーションサーバを含む、またはフロントエンド構成要素、たとえば、ユーザが実装形態と対話し得るためのグラフィカルユーザインターフェースもしくはウェブブラウザを有するクライアントコンピュータ、あるいはそのようなバックエンド、ミドルウェア、またはフロントエンド構成要素のどの組合せも含むコンピューティングシステムで実装することができる。構成要素は、どの形または媒体のデジタルデータ通信、たとえば、通信ネットワークによっても相互接続することができる。通信ネットワークの例には、ローカルエリアネットワーク(LAN)およびワイドエリアネットワーク(WAN)、たとえば、インターネットがある。
【００６６】
説明した実装形態のいくつかの特徴を、本明細書で説明したように示したが、ここで、多くの修正、置換、変更および等価物が、当業者には思い付くであろう。したがって、添付の請求項は、実施形態の範囲内であるようなすべての修正および変更をカバーすることを意図していることを理解されたい。
【符号の説明】
【００６７】
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
【図１】
2014123363.tif 000003
【図２】
2014123363.tif 000004
【図３】
2014123363.tif 000005
【図４】
2014123363.tif 000006
【図５】
2014123363.tif 000007
【図６】
2014123363.tif 000008
【外国語明細書】
2014123363000001.pdf