JP2011086291A - システムランドスケープ対応アプリケーション間通信インフラストラクチャ - Google Patents

Abstract

【課題】システムランドスケープ対応のアプリケーション間通信インフラストラクチャに関わるシステム、方法およびソフトウェアを提供する。
【解決手段】このアプリケーション間通信インフラストラクチャは、アプリケーションがアプリケーション間通信にどのように参加できるかを記述する1つのメタモデルを実施することができる。このメタモデルは、アプリケーションおよびその可能な出力を除いて、受け入れられる入力パラメータを記述することができる。公開されるか、またはその他の形で関与アプリケーションにとって入手可能なメタデータに基づいた、アプリケーション間の通信フローを定義するプロトコルがある。
【選択図】図1

Description

本開示は、システムランドスケープ対応のアプリケーション間通信インフラストラクチャに関わるシステム、方法およびソフトウェアに関する。詳細には、本開示は、アプリケーションまたは他のプログラムがアプリケーション間通信にどのように参加できるかを記述する1つのメタモデル(各種関与アプリケーションで一貫して使用される)の作成または使用を含む。

コンピュータプログラムは、アプリケーション(ビジネスアプリケーションなど)と呼ばれることもあるが、オペレーティング環境内で動作する。一部の例では、オペレーティング環境は、1020 102nd Ave NE Bellevue、WA 98004のMicrosoft CorporationによるMicrosoft Windows（登録商標）などのコンピュータオペレーティングシステムである。一部の例では、オペレーティング環境は、オペレーティング環境内で動作する1つまたは複数のアプリケーションが使用できる、必須または必要というだけでなく、オプショナルの操作性または機能も提供する。一般的には、オペレーティング環境の機能は事前に知られており、アプリケーションは、この事前情報に基づいて構築またはその他の形で構成される。すなわち、アプリケーションは、オペレーティング環境によって提供されることが分かっている機能に基づいて限定的に作成される。より具体的には、一般的に、異なるベンダから、異なるバージョンで、異なるテクノロジーを用いてインストールされるソフトウェアがある。単一のベンダに関わるランドスケープの場合であっても、その会社は、異なるプロダクトの多様な異なるバージョンを有することがある(さらに、それらの単一ベンダのプロダクトであっても、異なるテクノロジー、言語、プロトコル、またはメッセージング構造に基づくことがある)。したがって、動的にリンクされたライブラリを介して実施される場合でも、各種アプリケーションとオペレーティング環境間には静的な関係がある。

本開示の態様は、ランドスケープ対応のアプリケーション間通信インフラストラクチャに関する。例えば、ランドスケープ対応アプリケーション間通信インフラストラクチャを介して通信するためのコンピュータプログラムプロダクトは、コンピュータ読み取り可能な命令を記憶する有形の記憶媒体を含む。一例では、命令は、メモリに記憶された情報を異種アプリケーションに伝達するために収集し、少なくとも部分的にその収集された情報を用いて異種アプリケーション宛のメッセージを生成するように動作可能である。コンピュータプログラムプロダクトはそのメッセージを、後で異種アプリケーションに送信してもらうために、アプリケーション間通信インフラストラクチャに伝達する。これで、アプリケーション間通信インフラストラクチャは、異種アプリケーションの通信構造を識別し、この識別された構造に基づいてメッセージを変換することができる。

別の例では、アプリケーション間通信インフラストラクチャは、第1の異種アプリケーションから、第2の異種アプリケーション宛のメッセージを受信する。このコンピュータプログラムプロダクト内の命令は、第2の異種アプリケーションによって公開され、第2の異種アプリケーション用に記憶されている通信構造を動的に識別するように動作可能である。アプリケーション間通信インフラストラクチャは、そのメッセージを、この識別された構造に基づいて第2の異種アプリケーションと互換性があるメッセージに変換し、その変換されたメッセージを第2の異種アプリケーションに伝達して処理してもらう。

様々な実施形態が以下の機能のうちの1つまたは複数を実施または利用することができる。具体的には、通信構造は、異種アプリケーション用に入手可能な入力および出力を保管することができる。別の例では、通信構造は、異種アプリケーション用に入手可能なイン ポート（in ports）およびアウト ポート（out ports）を保管することができる。さらに別の例では、通信構造は、特定のメッセージの各パラメータについてデータタイプ、カーディナリティ、およびマンダトリーを記憶することができる。さらに別の例では、通信構造は、異種アプリケーションとは切り離された、XMLファイルである公開ファイルであってよい。

態様の一部または全部は、それぞれのデータを処理して変換する、コンピュータが実施するソフトウェアとして概略的に説明されるが、それらはコンピュータが実施する方法であってよいし、この説明された機能を実行するためにそれぞれのシステムまたは他のデバイスにさらに組み込まれていてもよい。本開示のこれらの態様および他の態様、ならびに実施形態の詳細は、添付の図面および以下の説明に記載される。本開示の他の機能、目的および利点は、添付の図面および以下の説明、ならびに特許請求の範囲の請求項から明らかになろう。

本開示の一実施態様による、ランドスケープ対応アプリケーション間通信インフラストラクチャを介したシステム通信例を示した図である。 図1で説明されるシステム内のハイレベルなコンポーネントの構成例を示した図である。 本開示の一実施態様による、マッシュアップ構成例を示した図である。 本開示の一実施態様による、マッシュアップ構成例を示した図である。 ランドスケープ対応アプリケーション間通信インフラストラクチャを介してデータの流れを伝達するためのフローチャートの例である。 ランドスケープ対応アプリケーション間通信インフラストラクチャを介してデータの流れを伝達するためのフローチャートの例である。

本発明の態様は、ランドスケープ対応のアプリケーション間通信インフラストラクチャに関する。一部の構成では、このインフラストラクチャはクライアント側またはサーバ側の手法に限定されないし、ある特定のシステムランドスケープに限定されないし、いずれの固有なUI手法にも限定されない。より具体的には、アプリケーション間通信インフラストラクチャは、アプリケーションがアプリケーション間通信にどのように参加できるかを記述するための1つのメタモデル(関与アプリケーションで一貫して使用される)を実装することができる。メタモデルは、アプリケーションおよびその可能な出力を除いて、受け入れられる入力パラメータを記述することができる。一般的なマッシュアップシナリオでは、これは、それぞれのアプリケーションの入力/出力とも呼ばれる。とにかく、このメタモデルは、多くの場合、入力/出力データの単なる存在を定義するだけでなく、構造(データタイプまたはカーディナリティなど)も定義するし、このデータはアプリケーションのメッセージングにとって必須(またはオプショナル)であるか、そうでないかも定義する。公開されるか、またはその他の形で関与アプリケーションにとって入手可能なメタデータに基づいた、アプリケーション間の通信フローを定義するプロトコルがある。マッシュアップシナリオでは、これは、アプリケーション間の「ワイヤリング」と呼ばれることがある。言い換えれば、アプリケーションのメタモデルおよびプロトコルはアプリケーションのワイヤリングを定義しやすくし、必要なアプリケーション間通信を記述できるようにする。メタモデルのほかに、システムランドスケープ(すなわち、各関与アプリケーションはどのマシン/テクノロジースタック/UIテクノロジーで実行されているか)の記述もあってよい。これは、より簡単に「通信モデル」と呼ぶことができる。通信モデルは、関与アプリケーションのプラットフォーム用に実装される通信ランタイムによって実行できる。通信ランタイムは、多くの場合、通信ハブの一部である。そのため、通信ハブは相互間で接続することができ、したがって、現行システムランドスケープに基づいて、最適化された通信処理を提供することができる。一部の実施形態では、ランドスケープ対応アプリケーション間通信インフラストラクチャは、既存の機能/アプリケーションを結合して新しいアプリケーション/シナリオを構成する要求に対処する上で役立つ。別の言い方をすれば、ビジネス組織または他の組織は、より緩く結合されたアプリケーションランドスケープを有する必要性を認識しているので、それに対応して、既存の(異種)システムランドスケープを採用できる柔軟なアプリケーション間通信インフラストラクチャに対する要望があり得る。

アプリケーション間通信用の上述のインフラストラクチャは、アプリケーション間通信の様々なバージョン、事例およびタイプ(例えば、イベントベース型)に使用できる。本実施態様によれば、このインフラストラクチャは、JAVA（登録商標）スタック、ABAPスタック、または他の言語の一部としても、およびそれらの組合せとしても使用できる。1つの実施態様の例では、マッシュアップシナリオが使われ、(異なるUIテクノロジーで潜在的に実行される)アプリケーションは、結合された結果、単一のアプリケーションのように動作するような方法で接続される。イベントドリブン型アプリケーション間通信インフラストラクチャは、アプリケーション間のデータフローを実現する上で役立つことができる。この例では、異なるマシンおよび/または異なるUIテクノロジーが混在している場合、通信は、今後は、アプリケーション間の具体的ワイヤリングにより、必ずしもクライアント側またはサーバ側で単独で実行されるわけではない。

例示された実施形態を参照すると、図1は、ランドスケープ対応アプリケーション間通信インフラストラクチャを実装したシステム例100を示している。システム100は、ネットワーク112などの1つまたは複数のネットワークにわたる分散クライアント/サーバシステムであってよい。そのような実施態様では、データは、任意の標準または独自の暗号化アルゴリズムを使用する暗号化フォーマットで伝達または保管することができる。しかし、システム100は、-ローカルエリアネットワークまたはサブネットにわたる-専用企業環境か、または本開示の範囲から逸脱しない他の何らかの適切な環境にあり得る。システム100は、サーバ102、1つまたは複数のクライアント104、およびネットワーク112を含むこともできるし、または、それらと通信上で結合することもできる。

サーバ102は、システム100に関連付けられたデータを受信、送信、処理および保管するように動作可能な電子コンピューティングデバイスを備える。一般的に、図1は、本開示で使用できるコンピュータの一例を示しているだけである。各コンピュータは、一般的には、任意の適切な処理デバイスを包含するように意図されている。例えば、図1は、本開示で使用できる1つのサーバ102を示しているが、システム100は、サーバ以外のコンピュータおよびサーバプールを使用して実装することができる。実際、サーバ102は任意のコンピュータまたは処理デバイスでよく、例えば、ブレードサーバ、汎用パーソナルコンピュータ(PC)、Macintosh、ワークステーション、UNIX（登録商標）系コンピュータまたは任意の他の適切なデバイスなどでよい。言い換えれば、本開示は、汎用コンピュータ以外のコンピュータおよび従来のオペレーティングシステムを持たないコンピュータを想定している。サーバ102は、例えば、Linux、UNIX（登録商標）、Windows（登録商標） Server、または他の何らかの適切なオペレーティングシステムなど、いずれかのオペレーティングシステムを実行するように構成できる。一実施形態によれば、サーバ102は、ウェブサーバおよび/またはメールサーバを含むこともできるし、または、それらと通信上で結合することもできる。

サーバ102はローカルメモリ120を含むことができる。メモリ120は、磁気媒体、光媒体、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、取り外し可能媒体、あるいは他の何らかの適切なローカルメモリコンポーネントまたはリモートメモリコンポーネントを含む(ただし、これらには限定されない)揮発性メモリまたは不揮発性メモリの形態を取る任意のメモリモジュールまたはデータベースモジュールを含むことができる任意の有形のコンピュータ読み取り可能メモリである。例示されたメモリ120は、とりわけ、ランドスケープ対応アプリケーション間通信インフラストラクチャ130および複数のアプリケーション140を含むことができるが、これらについては、以下でより詳しく説明する。さらに、メモリ120は、1つまたは複数のオペレーティング環境135を含むこともできる。メモリ120は、また、他のタイプのデータ、例えば、環境および/またはアプリケーション記述データ、1つまたは複数のアプリケーション用のアプリケーションデータ、およびVPNアプリケーションまたはサービス、ファイヤウォールポリシー、セキュリティまたはアクセスログ、印刷または他の報告用ファイル、ハイパーテキストマークアップ言語(HTML)ファイルまたはテンプレート、関連または無関連のソフトウェアアプリケーションまたはサブシステムなどに関わるデータも含むことができる。結果的に、メモリ120は、データのリポジトリ、例えば、1つまたは複数のアプリケーションからのローカルデータリポジトリなどと考えることもできる。

より具体的には、アプリケーション140は、それ自体がソフトウェアであるランドスケープ対応アプリケーション間通信インフラストラクチャを使用できるか、またはその使用を容易にする任意のアプリケーション、プログラム、モジュール、プロセス、または他のソフトウェアである。特定の実施態様に関わらず、「ソフトウェア」としては、ソフトウェア、ファームウェア、ワイヤまたはプログラムされたハードウェア、または有形のコンピュータ読み取り可能な媒体に収録されたそれらの任意の組合せがある。実際、形式変換モジュール130は、C、C++、Java（登録商標）、Visual Basic、アセンブラ、Perl、任意の適切なバージョンの4GLなど、任意の適切なコンピュータ言語で書く、または記述することができる。例えば、形式変換モジュール130は部分がEnterprise Java（登録商標） Beans (EJBs)として実装できる複合アプリケーションでもよいし、設計時コンポーネントが実行時の実装を、J2EE(Java（登録商標） 2 Platform、Enterprise Edition)、ABAP(Advanced Business Application Programming)オブジェクト、またはMicrosoftの.NETなど、異なるプラットフォームの中に生成する機能を持つこともできる。アプリケーション140は図1では単一のモジュールとして示されているが、アプリケーション140は多数の他のサブモジュールを含むこともできるし、そうではなく、様々なオブジェクト、方法、または他のプロセスによって様々な機能および機能性を実施する単一のマルチタスクモジュールであってもよい。さらに、サーバ102に内蔵されるものとして示されているが、アプリケーション140に関連付けられた1つまたは複数のプロセスは、リモートで保管、参照、または実行できる。例えば、アプリケーション140のある部分は、リモートで呼び出されるウェブサービスであってよいし、アプリケーション140の別の部分は、リモートクライアント104での処理用にバンドルされるインターフェースオブジェクトであってよい。さらに、アプリケーション140は、この開示の範囲から逸脱することなく、別のソフトウェアモジュールまたはエンタープライズアプリケーション(図示せず)の子またはサブモジュールであってよい。

ランドスケープ対応アプリケーション間通信インフラストラクチャを利用するには、複数のアプリケーション140が、同じコンピュータ上で、またはネットワーク112全体にわたって、ランドスケープ対応アプリケーション間通信インフラストラクチャ130を介して通信上で相互に結合される。この結合は、例えば、HTTP接続を使用して、または所望のフォーマットでメッセージを伝達するように動作可能な任意の他の適切な通信チャネルを使用して行うことができる。アプリケーション間通信インフラストラクチャ130は、一般的に、実行時に、宛先の異種アプリケーション用の通信構造を識別し、この識別された構造に基づいてメッセージを変換することができるイベントドリブン型モジュールで構成される。例えば、アプリケーション間通信インフラストラクチャ130は、第1の異種アプリケーションから、第2の異種アプリケーション宛のメッセージを受信することができる。アプリケーション間通信インフラストラクチャ130は、次に、第2の異種アプリケーション用に記憶されている通信構造を動的に識別するが、ここで、通信構造は第2の異種アプリケーションによって公開されている。アプリケーション間通信インフラストラクチャ130は、そのメッセージを、この識別された構造に基づいて第2の異種アプリケーションと互換性があるメッセージに変換し、その変換されたメッセージを第2の異種アプリケーションに伝達して処理してもらう。

一部の実施態様によれば、通信構造145は、1つまたは複数の拡張可能マークアップ言語(XML: eXtensible Markup Language)ドキュメントファイルという形でもよいし、構造化照会言語(SQL: Structured Query Language)ステートメント、またはスクリプト記述言語、スクリプト言語あるいは拡張言語のスクリプトの一部分という形であってもよい。例えば、通信構造145は、様々なデータ構造として、テキストファイル、仮想記憶アクセス方式(VSAM: Virtual Storage Access Method)ファイル、フラットファイル、Btrieveファイル、カンマ区切り値(CSV: comma-separated-value)ファイル、内部変数、または1つまたは複数のライブラリの中にフォーマット化、保管または定義することができる。XMLのほかに、他のスクリプト記述言語として、Java（登録商標）Script、カスケードスタイルシート(CSS: Cascading Style Sheets)、HTML、非同期Java（登録商標）ScriptおよびXML (AJAX)、その他を挙げることができる。特定の言語またはフォーマットとは関係なく、通信構造145は、特定のアプリケーション140に緊密に関連付けられたファイル、特定のアプリケーション140によって公開された物理的に分離したファイル、または複数のアプリケーション140用にランドスケープ対応アプリケーション間通信インフラストラクチャ130に関連付けられた単一のファイルでよいことが理解できよう。

以下に示された通信構造例145は、仮定のドメインxyz.com用のXMLスクリプト形式で書かれている。特に、そのようなインフラストラクチャで使用されるプロトコルは、例えば、XML体系のプロトコルでもよい。例えば、通信構造145のうちの、アプリケーション間で「コマンド」または他のメッセージを送信する可能性のある1つのXML部分は、以下に示すフォーマット例のようにすることができる。
<?xml version="1.0" encoding="iso-8859-1"?>
<ccp:CommandsIn
xmlns:ccp="http://www.xyz.com/namespaces/ccp">
<ccp:Command name="FireInport">
<ccp:Port name="airline">
<atom:feed
xmlns:atom="http://www.w3.org/2005/Atom">
<atom:event>
<CARRID>
UA
</CARRID>
</atom:event>
</atom:feed>
</ccp:Port>
</ccp:Command>
</ccp:CommandsIn>
ここで、ユーザがコマンド「FireInport」を転送し、そのインポート（inport）の具体的データがATOM互換フォーマットで定義される。この背景のXML体系は、最後に、「Communication Model(通信モデル)」を定義している。当然であるが、前述のことは例示の目的で記載されているのであって、本開示の範囲を制限するようには意図されていないことを理解されたい。言い換えれば、上記のスクリプト例はコンテキストおよび記述を記載しやすくするように意図されているのであって、他のスクリプトは、本開示の範囲内で、それとは別の機能および機能性を実施することができる。

サーバ102は、プロセッサ125も含むことができる。プロセッサ125は、前述のソフトウェアなど、命令を実行し、サーバ102の動作を行うためにデータを操作し、例えば、中央処理装置(CPU)、ブレード、特定用途向け集積回路(ASIC: Application Specific Integrated Circuit)、またはフィールドプログラマブルゲートアレイ(FPGA: field-programmable gate array)であってよい。図1はサーバ102内に単一プロセッサ125を示しているが、特に必要があれば、複数のプロセッサ125を使用することができ、プロセッサ125と言及した時、該当する場合、その言及は複数のプロセッサ125を含むように意図されている。例示された実施形態では、プロセッサ125は、アプリケーション140およびアプリケーション間通信インフラストラクチャ130を実行する。

サーバ102は、クライアントサーバまたは他の分散環境内のクライアント104などの他のコンピュータシステムとネットワーク112を介して通信するためのインターフェース117も含むことができる。一部の実施形態では、サーバ102は、メモリ120に保管するために、および/またはプロセッサ125によって処理するために、インターフェース117を介して内部または外部センダからデータを受信する。一般的に、インターフェース117は、ソフトウェアおよび/またはハードウェアとして適切な組合せで符号化された、ネットワーク112と通信するように動作可能なロジックで構成される。より具体的には、インターフェース117は、通信ネットワーク112に関連付けられた1つまたは複数の通信プロトコルをサポートするソフトウェア、または物理的信号を伝達するように動作可能なハードウェアで構成できる。

ネットワーク112は、コンピュータサーバ102と任意の他のローカルまたはリモートコンピュータ、例えば、クライアント104との間の無線または有線通信を促進する。ネットワーク112は、企業ネットワークまたはセキュアネットワークの全体または一部分であってよい。別の例では、ネットワーク112は、有線または無線リンクを介した、単にサーバ102とクライアント104間のVPNであってもよい。そのような無線リンクの例は、802.11a、802.11b、802.11g、802.20、WiMax、およびその他多くを経由してよい。単一または連続ネットワークとして示されているが、ネットワーク112は、少なくともその一部分がサーバ120と少なくとも1つのクライアント104間の通信を促進できる限り、本開示の範囲から逸脱せずに、論理的に各種サブネットまたは仮想ネットワークに分割することができる。例えば、サーバ102は、ある1つのサブネットを介してリポジトリに通信上で結合して、同時に別のサブネットを介して特定のクライアント104に通信上で結合してよい。言い換えれば、ネットワーク112は、システム100内の各種コンピューティングコンポーネント間の通信を促進するように動作可能な、すべての内部または外部ネットワーク、ネットワーク、サブネットワーク、またはそれらの組合せを包含する。ネットワーク112は、ネットワークアドレス間で、例えば、インターネットプロトコル(IP)パケット、フレームリレーフレーム、非同期転送モード(ATM: Asynchronous Transfer Mode)セル、音声、ビデオ、データ、および他の適切な情報を伝達することができる。ネットワーク112は、1つまたは複数のローカルエリアネットワーク(LAN: Local Area Network)、無線アクセスネットワーク(RAN: Radio Access Network)、メトロポリタンエリアネットワーク(MAN: Metropolitan Area Network)、ワイドエリアネットワーク(WAN: Wide Area Network)、インターネットとして知られるグローバルコンピュータネットワークの全体または一部分、および/あるいは1つまたは複数の場所にある任意の他の1つまたは複数の通信システムを含むことができる。一部の実施形態では、ネットワーク112は、一部のローカルまたはリモートクライアント104を介してユーザがアクセスできるセキュアネットワークであってもよい。

クライアント104は、任意の通信リンクを使用してサーバ102またはネットワーク112と接続または通信するように動作可能な任意のコンピューティングデバイスでよい。ハイレベルで、各クライアント104は、少なくともGUI 136を有するか、実行し、システム100に関連付けられた任意の適切なデータを受信、送信、処理および保管するように動作可能な電子コンピューティングデバイスで構成される。任意の数のクライアント104をサーバ102に通信上で結合できることが理解できよう。さらに、「クライアント104」および「ユーザ」は、この開示の範囲から逸脱することなく、適宜、同義的に使用できる。さらに、例示を容易にするために、各クライアント104は、1人のユーザによって使用されているものとして説明されている。しかし、この開示は、多数のユーザが1つのコンピュータを使用できる、または1人のユーザが複数のコンピュータを使用できることを想定している。本開示で使用される場合、クライアント104は、パーソナルコンピュータ、タッチスクリーン端末、ワークステーション、ネットワークコンピュータ、キオスク、無線データポート、スマートフォン、パーソナルデータアシスタント(PDA)、これらおよび他のデバイス内の1つまたは複数のプロセッサ、または任意の他の適切な処理デバイスを包含するように意図されている。例えば、クライアント104は、無線で外部ネットワークまたは非セキュアネットワークと接続するように動作可能なPDAであってよい。別の例では、クライアント104は、キーパッド、タッチスクリーン、マウス、または情報を受け入れることが可能な他のデバイスなどの入力デバイス、およびサーバ102またはクライアント104の動作に関連付けられた情報、例えば、デジタルデータ、ビジュアル情報、またはGUI 136などを伝達する出力デバイスを備えたラップトップコンピュータで構成されてよい。入力デバイスおよび出力デバイスは、両方とも、固定または取り外し可能記憶媒体を含めることができる。例えば、磁気コンピュータディスク、CD-ROM、またはディスプレイを介して、すなわち、GUIまたはアプリケーションインターフェース136のクライアント部分を介してクライアント104のユーザから入力も受信し、同ユーザに出力も提供する他の適切な媒体であってよい。

GUI 136は、クライアント104のユーザが何らかの適切な目的、例えば、アプリケーションデータまたは他のトランザクションデータを表示するなどの目的でシステム100の少なくとも一部分とインターフェース接続できるように動作可能なグラフィカルユーザインターフェースで構成される。例えば、GUI 136は、アプリケーション間通信インフラストラクチャ130を介して異種アプリケーション140間で通信されたビジネス情報に関する様々なビューを表示することができる。一般的に、GUI 136は特定のユーザに、システム100によって提供されるデータ、またはシステム100内で伝達されるデータを効率のよい、ユーザフレンドリーな表示で提供する。GUI 136は、対話式フィールドを有する複数のカスタマイズ可能なフレームまたはビュー、プルダウンリスト、およびユーザによって操作されるボタンで構成することができる。GUI 136は、複数のポータルまたはダッシュボードも提示することができる。例えば、GUI 136は、ユーザが1つまたは複数のモジュールに対して検索パラメータを入力および定義できるようにするセキュアウェブページを表示することもできる。グラフィカルユーザインターフェースという用語は単数形または複数形で使用できて、1つまたは複数のグラフィカルユーザインターフェース、および特定のグラフィカルユーザインターフェースの表示画面のそれぞれを表すことを理解されたい。実際、GUI 136と言及した時、それは、本開示の範囲から逸脱することなく、適宜、フロントエンド、またはアプリケーション140のコンポーネントへの言及、およびクライアント104を介してアクセス可能な特定のインターフェースへの言及を表すことができる。したがって、GUI 136は、システム100内で情報を処理し、結果をユーザに効率よく表示する、汎用ウェブブラウザまたはタッチスクリーンなど、任意のグラフィカルユーザインターフェースを想定している。サーバ102はウェブブラウザ(例えば、Microsoft Internet ExplorerまたはNetscape Navigator)を介してクライアント104からデータを受け入れて、ネットワーク112を使用して適切なHTMLまたはXML応答をブラウザに返すことができる。

図2は、システム100内のハイレベルなコンポーネントの構成例200である。具体的には、図2は、それぞれのアプリケーションランタイム内でそれぞれが1つまたは複数のアプリケーション140を実行している3つのシステム例(X、YおよびZ)を示している。さらに、各システムは、通信ランタイムモジュールおよび通信モデルを備えた(または、それにリンクされた)通信ハブを実装している。この実施態様では、他のアプリケーションは、異なるランタイムにまたがって動的データフローをより容易に実施するマッシュアップシナリオで収集できる。このデータフローをリモート呼び出しによってローカルシステムで扱うのではなく、データフロー(部分または全体)を通信メタモデルを介してリモートシステムによって実施することができる。言い換えれば、ローカルシステムは通信インフラストラクチャを介してリモートの異種アプリケーションを認識することができる。すなわち、通信インフラストラクチャが、リモートアプリケーションが所望のプロトコルでデータメッセージを受信できるようにする。より詳しい構成が図3に示されている。図3は、通信メタモデルを実施するワイヤリングを含む拡張マッシュアップシナリオを示している。例えば、ABAPは、CHIPモジュールまたはアプレットを含むバックエンドシステムを表すことができる。通信メタモデルは、ワイヤリングがフロントエンドおよびバッケンエンドのどちらか、または両方に存在できるようにする。言い換えれば、Java（登録商標）フロントエンドは、バックエンドシステムの1つまたは複数がABAPランタイムを実行中であることを認識できるが、ABAPシステムの各種コンポーネントへの「ハードワイヤされた」リンクを必要としない。このように、ABAPシステムは、ABAPアプリケーションまたはサブモジュール間のメッセージおよびデータフローを、それらがJava（登録商標）システムによって生成中であっても、より効率よく管理することができ、それにより、ラウンドトリップが大幅に減り、パフォーマンスが上がる。

動作の一態様では、図4Aは、図2で説明されたシステムのようなシステムX内のアプリケーションA1とアプリケーションB1間の通信用のコンピュータプロセス例400を示したフローチャートである。説明を分かりやすくするために、以下の説明は、図2に示された環境200について方法400を概略的に説明する。しかし、方法400は、適宜、他の何らかの適切なシステム、環境、またはシステムと環境の組合せによって別法で実施できることを理解されたい。

例示の方法400は、通信モデル(すなわち、適切なメタデータ)を定義することによって、行われる通信を設計時に可能にするステップ402から始まる。この場合、通信モデルは、アプリケーションA1からアプリケーションB1へのデータフローを定義する。示されていないが、例えば、A1によって公開されたアドレスデータを、アプリケーションB1によって必要とされる緯度/経度データに変換するために、このデータフローには、いずれかの種類のデータ変換プログラムが関わってよい。

ステップ404で、データフローが実行されようとしているか、実行中であるかが判定される。この実行は、A1内でボタンをクリックするか、A1内で表選択を変更するか、または他の何らかの適切なランタイムアクションによってトリガできる。ステップ406で、通信ランタイムが呼び出される。次に、この通信ランタイムは、定義された通信モデルを知っていて、ステップ408で、A1用に発信データフローが定義されているかを検査する。例えば、データフローの宛先はアプリケーションB1にすることができる。ステップ410で、通信ランタイムはこのデータフローを処理し(データ変換ステップも含む)、ステップ412で、結局、データをアプリケーションランタイムBに転送する(該当する場合)。アプリケーションランタイムBはこのデータをアプリケーションB1に転送し、アプリケーションB1は新しいデータで更新される。

動作の別の態様では、図4Bは、図2で説明された環境のような異なるシステムで実行されているアプリケーション間のアプリケーション間通信用のコンピュータプロセス例450を示したフローチャートである。説明を分かりやすくするために、以下の説明は、図2に示された環境200について方法450を概略的に説明する。例えば、図2に示された環境を使用して、システムY上のアプリケーションB1からシステムX上のアプリケーションA1へ、さらにシステムX上のアプリケーションB2への3ステップのデータフローを定義することができる。しかし、方法450は、適宜、他の何らかの適切なシステム、環境、またはシステムと環境の組合せによって別法で実施できることを理解されたい。

プロセス400の場合と同様に、例示された最初のステップは、ステップ452で、設計時にメタデータ/通信モデルを定義することに関する。この場合には、最適化されたシステムランドスケープ対応処理を実行時に可能にするために、ステップ454で、この通信モデルを、データフローに関与する該当の分散システムに対して使用可能にする必要がある。この「使用可能にすること」は任意の適切な方法で行うことができ、その方法には、設計時にデータを関与するシステム(すなわち、関与する通信ランタイム)に複製すること、中央リポジトリを使用して通信モデルを保管すること(それによって、この場合には、通信ランタイムは適切なリモート呼び出しによって通信モデルにアクセスすることになる)、およびデータをある1つのシステムに保管して、実行時にそのデータをデータフローに関わるシステムに渡すことが含まれる。

例の実行時、データフローは、ステップ454で、システムY内のアプリケーションB1から(上述の単純な例のとおり、任意のユーザ対話によって)開始される。アプリケーションランタイムBは、ステップ456で、これを通信ランタイムに転送する。通信ランタイムは、ステップ458で、通信モデルを検査して、データフローがリモートであるかを判定する。判定されると、ステップ460で、宛先アプリケーションにローカルな、またはその他の形で関連付けられた通信ランタイムが呼び出され、それによって、必要に応じてその通信ランタイムを開始できる。現在の通信ランタイムが、ステップ462で、これをシステムX上の宛先通信ランタイムに転送する。ステップ464で、宛先通信ランタイムは使用可能な通信モデルを使用してデータを処理する。通信モデルはシステムX上でも使用可能なので、システムX上の通信ランタイムは、システムY上の先行通信ランタイムへの呼び戻しを行うことなくデータフロー内の次の2ステップを処理することができる。そのため、データフローは、リモート呼び出しができるだけ回避されるような方法で、2つのシステムで実行される3つのアプリケーションにまたがって処理される。

本開示は、様々な開示された方法および手法に関連した手法の例を示すために複数のデータフローと処理フローおよび付随する説明を使用しているが、システム100は、これらのタスクおよび他のタスクを実行するために任意の適切な手法を使用または実施することを想定している。これらの手法は例示の目的のみで記載されていること、および説明された手法または類似の手法は、任意の時点で、例えば、並行して、個別に、または組み合わせて実行できることを理解されたい。加えて、これらのフロー中のステップの多くは、同時に実行することもできるし、および/または図示および説明された順序とは異なる順に実行することもできる。さらに、システム100は、プロセスおよび方法が適切である限り、ステップを追加、減らす、および/または変更してプロセスおよび方法を使用することができる。要するに、本開示は特定の実施態様および一般的な関連の方法について説明されているが、これらの実施態様および方法の変更および変形は当業者には明らかであろう。したがって、他の実施態様は、添付の特許請求の範囲に記載の請求項の範囲内である。

100 システム
102 サーバ
104 クライアント
112 ネットワーク
117 インターフェース
120 ローカルメモリ
125 プロセッサ
130 ランドスケープ対応アプリケーション間通信インフラストラクチャ、形式変換モジュール
135 オペレーティング環境
136 GUI
140 アプリケーション
145 通信構造

Claims (20)

1. ランドスケープ対応アプリケーション間通信インフラストラクチャを介して通信するためのコンピュータが実施する方法であって、1つまたは複数のプロセッサによって実行される以下のステップ、すなわち、
   メモリに記憶された情報を異種アプリケーションに伝達するために収集するステップと、
   少なくとも部分的に前記収集された情報を用いて前記異種アプリケーション宛のメッセージを生成するステップと、
   前記メッセージを、後で前記異種アプリケーションに送信してもらうために、前記異種アプリケーションの通信構造を識別し、この識別された構造に基づいて前記メッセージを変換できるイベントドリブン型アプリケーション間通信インフラストラクチャに伝達するステップと
   を含む方法。
2. 前記通信構造が前記異種アプリケーション用に入手可能な入力および出力を保管する、請求項1に記載のコンピュータが実施する方法。
3. 前記通信構造が前記異種アプリケーション用に入手可能なイン ポートおよびアウト ポートを保管する、請求項1に記載のコンピュータが実施する方法。
4. 前記通信構造が、前記異種アプリケーションとは切り離された公開ファイルを含む、請求項1に記載のコンピュータが実施する方法。
5. 前記公開ファイルがXMLファイルである、請求項4に記載のコンピュータが実施する方法。
6. 前記通信構造が、特定のメッセージの各パラメータについてデータタイプ、カーディナリティ、およびマンダトリーを記憶する、請求項1に記載のコンピュータが実施する方法。
7. ランドスケープ対応アプリケーション間通信インフラストラクチャを介して通信するための、コンピュータ読み取り可能な命令を記憶する有形の記憶媒体を含むコンピュータプログラムプロダクトであって、前記命令が、実行されると、
   メモリに記憶された情報を異種アプリケーションに伝達するために収集し、
   少なくとも部分的に前記収集された情報を用いて前記異種アプリケーション宛のメッセージを生成し、
   前記メッセージを、後で前記異種アプリケーションに送信してもらうために、前記異種アプリケーションの通信構造を識別し、この識別された構造に基づいて前記メッセージを変換できるイベントドリブン型アプリケーション間通信インフラストラクチャに伝達する
   ように動作可能であるコンピュータプログラムプロダクト。
8. 前記通信構造が前記異種アプリケーション用に入手可能な入力および出力を保管する、請求項7に記載のコンピュータプログラムプロダクト。
9. 前記通信構造が前記異種アプリケーション用に入手可能なイン ポートおよびアウト ポートを保管する、請求項7に記載のコンピュータプログラムプロダクト。
10. 前記通信構造が、前記異種アプリケーションとは切り離された公開ファイルを含む、請求項7に記載のコンピュータプログラムプロダクト。
11. 前記公開ファイルがXMLファイルである、請求項8に記載のコンピュータプログラムプロダクト。
12. 前記通信構造が、特定のメッセージの各パラメータについてデータタイプ、カーディナリティ、およびマンダトリーを記憶する、請求項7に記載のコンピュータプログラムプロダクト。
13. 前記アプリケーション間通信インフラストラクチャおよび前記異種アプリケーションが、それぞれ、異なるオペレーティング環境内の個別のプロセッサ上で実行される、請求項7に記載のコンピュータプログラムプロダクト。
14. ランドスケープ対応アプリケーション間通信インフラストラクチャを介して通信するための、コンピュータ読み取り可能な命令を記憶する有形の記憶媒体を含むコンピュータプログラムプロダクトであって、前記命令が、実行されると、
    第1の異種アプリケーションから、第2の異種アプリケーション宛のメッセージを受信し、
    前記第2の異種アプリケーションによって公開され、前記第2の異種アプリケーション用に記憶されている通信構造を動的に識別し、
    前記メッセージを、この識別された構造に基づいて前記第2の異種アプリケーションと互換性があるメッセージに変換し、
    前記変換されたメッセージを前記第2の異種アプリケーションに伝達して処理してもらう
    ように動作可能であるコンピュータプログラムプロダクト。
15. 前記通信構造が前記異種アプリケーション用に入手可能な入力および出力を保管する、請求項14に記載のコンピュータプログラムプロダクト。
16. 前記通信構造が前記異種アプリケーション用に入手可能なイン ポートおよびアウト ポートを保管する、請求項14に記載のコンピュータプログラムプロダクト。
17. 前記通信構造が、前記異種アプリケーションとは切り離された公開ファイルを含む、請求項14に記載のコンピュータプログラムプロダクト。
18. 前記通信構造が、特定のメッセージの各パラメータについてデータタイプ、カーディナリティ、およびマンダトリーを記憶する、請求項14に記載のコンピュータプログラムプロダクト。
19. 前記異種アプリケーションが、異なるオペレーティング環境内の個別のプロセッサ上で実行される、請求項14に記載のコンピュータプログラムプロダクト。
20. 異なるコンピュータプログラミング言語に基づいた前記異種アプリケーションが、それぞれ、個別のメッセージ構造を使用する、請求項14に記載のコンピュータプログラムプロダクト。

Images