(57)【要約】本発明は、自動プラグイン、設定可能プラグイン、および視覚に基づく、システム構築され、カスタマイズされた拡張を含む一連のネットワーク接続要素を備える。これらの要素は、本発明の実施の形態に従って使用され、１つまたは２つ以上の異種システムを相互に接続するためのビルディングブロックとして機能する。本発明のいくつかの実施の形態では、これらビルディングブロックは、視覚に基づく環境に配置可能であり、当該システムの統合を容易にすることを助ける。好ましい実施態様では、ＡＰＩサーバは、４方向のソリューションを提供し、統合されたデータアクセスを提供する。この実施態様の４つの構成要素は、内部統合エンジン、ＥＴＬおよびＢ２Ｂアプリケーションアダプタ、ＸＭＬゲートウェイ、ならびに特定アプリケーション向け高性能インタフェースである。
2004511034.tif 000002
【特許請求の範囲】
【請求項１】
異種アプリケーションを統合するシステムであって、内部インテグレータと、ＥＴＬアダプタと、Ｂ２Ｂアダプタとを有するＡＰＩサーバを備えるシステム。
【請求項２】
前記ＥＴＬアダプタは、ファイアウォール内のアプリケーションを統合し、前記Ｂ２Ｂアダプタは、前記ファイアウォールにより分離されたアプリケーションを統合する、請求項１に記載のシステム。
【請求項３】
前記ＥＴＬアダプタおよび前記Ｂ２Ｂアダプタは、ビジネスロジックを含む、請求項１に記載のシステム。
【請求項４】
アプリケーションインタフェースをさらに備える、請求項１に記載のシステム。
【請求項５】
前記アプリケーションインタフェースは、ＪＡＶＡベースである、請求項４に記載のシステム。
【請求項６】
前記ＡＰＩサーバは、ＸＭＬゲートウェイをさらに含む、請求項１に記載のシステム。
【請求項７】
アプリケーションインタフェースをさらに備える、請求項６に記載のシステム。
【請求項８】
前記ＡＰＩサーバは、アプリケーション接続レイヤをさらに含む、請求項１に記載のシステム。
【請求項９】
前記ＡＰＩサーバは、データノーマライザをさらに含む、請求項１に記載のシステム。
【請求項１０】
前記ＡＰＩサーバは、ルールおよびマッピングエージェントをさらに含む、請求項１に記載のシステム。
【請求項１１】
前記ルールおよびマッピングエージェントは、ＪＡＶＡアプリケーションである、請求項１０に記載のシステム。
【請求項１２】
前記ＡＰＩサーバは、メッセージングエージェントをさらに含む、請求項１に記載のシステム。
【請求項１３】
前記ＡＰＩサーバは、プロセス実行マネージャをさらに含む、請求項１に記載のシステム。
【請求項１４】
前記ＡＰＩサーバは、セキュリティインタフェースをさらに含む、請求項１に記載のシステム。
【請求項１５】
前記ＡＰＩサーバは、ログレポータをさらに含む、請求項１に記載のシステム。
【請求項１６】
前記ＡＰＩサーバは、データアナライザをさらに含む、請求項１に記載のシステム。
【請求項１７】
前記ＡＰＩサーバは、サービススケジューラをさらに含む、請求項１に記載のシステム。
【請求項１８】
異種アプリケーションを統合する方法であって、
ＡＰＩを通じて前記アプリケーションを直接統合するステップと、
ＥＴＬアダプタまたはＢ２Ｂアダプタであるデータアダプタを通じて前記アプリケーションを統合するステップと
を含む方法。
【請求項１９】
前記ＥＴＬアダプタは、ファイアウォール内のアプリケーションを統合し、前記Ｂ２Ｂアダプタは、前記ファイアウォールにより分離されたアプリケーションを統合する、請求項１８に記載の方法。
【請求項２０】
分散ネットワーク上で前記アプリケーションを統合するステップをさらに含む、請求項１８に記載の方法。
【請求項２１】
分散ネットワーク上で前記アプリケーションを統合する前記ステップは、ＸＭＬゲートウェイの使用をさらに含む、請求項２０に記載の方法。
【請求項２２】
ダイレクトアプリケーションインタフェースを通じて前記アプリケーションを直接統合するステップをさらに含む、請求項１８に記載の方法。
【請求項２３】
第１のアプリケーションを第２の異種アプリケーションと統合する方法であって、
前記第１のアプリケーションおよび前記第２のアプリケーション間の関係を順位付けするステップと、
ＡＰＩを通じた直接の統合、データアダプタによる統合、または分散ネットワーク上での統合のいずれかにより、前記第１のアプリケーションおよび前記第２のアプリケーションを前記関係の前記順位付けに従って統合するステップと
を含む方法。
【請求項２４】
前記データアダプタは、ファイアウォール内のアプリケーションを統合するＥＴＬアダプタまたは前記ファイアウォールによって分離されたアプリケーションを統合するＢ２Ｂアダプタである、請求項２３に記載の方法。
【請求項２５】
前記分散ネットワーク上の前記第１のアプリケーションおよび前記第２のアプリケーションを統合することは、ＸＭＬゲートウェイの使用をさらに含む、請求項２３に記載の方法。
【請求項２６】
前記第１のアプリケーションおよび前記第２のアプリケーションを前記関係の前記順序付けに従って統合する前記ステップの間、前記第１のアプリケーションおよび前記第２のアプリケーションは、アプリケーションインタフェースを通じて直接統合可能でもあり得る、請求項２３に記載の方法。
【請求項２７】
異種アプリケーションのインテグレータであって、内部統合のための手段と、ＥＴＬ適合のための手段と、Ｂ２Ｂ適合のための手段とを有するＡＰＩサーバを備えるインテグレータ。
【請求項２８】
前記アプリケーションは、ビジネス管理アプリケーションである、請求項２７に記載のインテグレータ。
【請求項２９】
前記ＡＰＩサーバは、ＸＭＬゲートウェイを形成する手段をさらに含む、請求項２７に記載のインテグレータ。
【請求項３０】
アプリケーションインタフェースのための手段をさらに備える、請求項２７に記載のインテグレータ。
【請求項３１】
前記ＡＰＩサーバは、アプリケーションを接続する手段をさらに含む、請求項２７に記載のインテグレータ。
【請求項３２】
前記ＡＰＩサーバは、データを正規化する手段をさらに含む、請求項２７に記載のインテグレータ。
【請求項３３】
前記ＡＰＩサーバは、ルールおよびマッピングを管理する手段をさらに含む、請求項２７に記載のインテグレータ。
【請求項３４】
前記ルールおよびマッピング手段は、ＪＡＶＡアプリケーションである、請求項３３に記載のインテグレータ。
【請求項３５】
前記ＡＰＩサーバは、メッセージングのための手段をさらに含む、請求項２７に記載のインテグレータ。
【請求項３６】
前記ＡＰＩサーバは、プロセス実行管理のための手段をさらに含む、請求項２７に記載のインテグレータ。
【請求項３７】
前記ＡＰＩサーバは、セキュリティインタフェースのための手段をさらに含む、請求項２７に記載のインテグレータ。
【請求項３８】
前記ＡＰＩサーバは、ログ報告のための手段をさらに含む、請求項２７に記載のインテグレータ。
【請求項３９】
前記ＡＰＩサーバは、データ解析のための手段をさらに含む、請求項１に記載のインテグレータ。
【請求項４０】
前記ＡＰＩサーバは、サービススケジューリングのための手段をさらに含む、請求項１に記載のインテグレータ。
【発明の詳細な説明】
【０００１】
［関連出願］
この出願は、２０００年８月１１日に出願された米国仮出願第６０／２２４，５３８号からの優先権を主張するものであり、これにより、この米国仮出願の開示は、参照によってそっくりそのまま援用される。
【０００２】
［発明の分野］
本発明は、電子商取引および通信に使用される異種のソフトウェアおよびハードウェアシステムを統合するシステムおよび方法に関する。特に、本発明は、電子商取引および通信の管理および最適化を容易にするために、モジュール形式の標準化された方法で個々の電子システムを電子的に接続するシステムおよび方法に関する。
【０００３】
［発明の背景］
企業が、それらの組織内において、および、取引先に渡って電子商取引および通信の能力の拡大を試みるにつれて、企業は、様々な技術的課題により、自身が、限られた、かつ、費用を要する選択肢を持っていることに気付く。一般に行われることは、企業が、一連の仕様書に従ってビジネス機能を実行するアプリケーションを記述するか、または購入し、次に、サーバ、ネットワークセキュリティ装置およびネットワーク接続ソフトウェアからなる、内部で設計され、多くは自社独自のインフラを介してそのアプリケーションを配備することであった。使用される技術は、基本的に、その組織の内部で使用される技術の拡張であった。これら自社独自のシステムを有するこのような多くの企業にとって、それらの取引先との電子商取引および通信は、これらの組織が、特注のゲートウェイを介してレガシーシステムまたはニアレガシーシステムへ通信することを必要としていた。異なる企業の内部システムを接続する結果として生じるネットワークは、結局、市販の電子ファイアウォールによって多くの場合保護される一連のフレームリレー接続または専用回線接続によって構成されることが多い。同様に、企業は、自身が、複数の内部システムを統合する際に困難に直面する類似のシナリオに向かい合っていることに気付くことが多い。これに構うことなく、２つの既存のシステム間の統合は、それが内部であろうが企業間であろうが、ネットワークアドレスのプロキシングおよび変換の紛れもない間に合わせの仕事を通じて生じることが多い。
【０００４】
このような特注のネットワーク（例えば、広域ネットワーク、構内ネットワーク、またはイントラネット）を通じた通信は、様々な問題を引き起こす。これら複雑なシステムは、設計、実施および保守を行うために大量のリソースを必要とする。さらに、新たなアプリケーション機能性が必要とされるときは常に、より多くのリソースが、異種システム間のあらゆる接続に適合するように費されなければならない。
【０００５】
新しいビジネスアプリケーションは、より幅広い特定産業向けの要求、例えば、カリフォルニア州サンフランシスコのＧｌｏｂａｌＮｅｔＸｃｈａｇｎｅによる、統合に基づくコラボラティブプランニング（Ｃｏｌｌａｂｏｒａｔｉｖｅ　Ｐｌａｎｎｉｎｇ）、フォアキャスト（Ｆｏｒｅｃａｓｔｉｎｇ）、およびリプレニシュメント（Ｒｅｐｌｅｎｉｓｈｍｅｎｔ）（ＣＰＦＲ）サービス、ＲｏｓｅｔｔａＮｅｔ、電子データ交換（ＥＤＩ）、個人情報端末（ＰＤＡ）サポート、統合に基づくビジネス分析ならびに他の拡張されたソリューション、を満たす必要がある。現在、統合アプリケーションへの動きがある。多くの会社および分析者は、ビジネス統合システムを通過した時にこれまでは捨てられるか、または無視されてきた情報の真の価値を一様に認識してきた。最近、会社は、具体的な経営的意思決定を行ってオンタイムデリバリおよび取引先の業績の類を確保するために、この情報を使用し始めている。このタイプの情報の多くは、企業のサプライチェーンマネージメント（ＳＣＭ），カスタマリレーションマネージメント（ＣＲＭ）、および企業間（Ｂ２Ｂ）取引実行にとって一般に有用であるので、この情報の統合は、ビジネスの最適化をさらに改善する。
【０００６】
全体的に見れば、望ましいビジネス管理アプリケーション統合のソリューションは、好ましくは、６つの核となる戦略的な統合要素を含み、ユーザに必要とされる、最も意味があり価値のある機能性のセットを提供すべきである。この６つの統合要素は、（１）企業レベルオープンアプリケーション統合、（２）オープンスタンダードに基づいた企業間統合、（３）内部アプリケーションプロセス呼び出し（ｉｎｖｏｃａｔｉｏｎ）、（４）取引先、プロセス、セキュリティおよびワークフロー管理、（５）企業レベルメッセージングサービス、ならびに（６）統合に基づく企業分析である。
【０００７】
このようなことから、企業間の電子商取引および通信ネットワークを実現するより簡単で効率的な方法に対する要求が存在する。このようなシステムまたは方法は、企業内および取引先の間の様々な異種ネットワークを統合すべきである。本発明のシステムおよび方法は、さらに、互換性が様々な異種システムのあらゆる所で達成されるように、統合された電子ネットワークをモジュールとして接続することを可能にすべきである。その上、このシステムは、ネットワーク接続が十分に柔軟性を有し、カスタマイズ可能であることにより、共通の標準の上で動作していない顧客の社内コンピュータシステムおよび他のシステムを容易にサポートすることを可能にすべきである。
【０００８】
［発明の概要］
これらの要求および他の要求を受けて、本発明は、自動プラグイン、設定可能プラグイン、および視覚に基づく、システム構築され、カスタマイズされた拡張を含む一連のネットワーク接続要素を備える。これらの要素は、本発明の実施の形態に従って使用され、１つまたは２つ以上の異種システムを相互に接続するためのビルディングブロックとして機能する。本発明の好ましい実施の形態では、これらビルディングブロックは、視覚に基づく環境に配置可能であり、当該システムの統合を容易にすることを助ける。このように、異種ネットワークを統合するのに、プログラミング言語の知識は必要とされない。
【０００９】
本発明による自動プラグインは、予め構築された統合フローを提供する。この統合フローは、望ましい、または、適当なフォーマットへのデータの変換だけでなく、システム間のデータの転送を提供する。さらに、アプリケーションプログラミングインタフェース（ＡＰＩ）は、ある特定のベースシステム、プラットフォーム、またはアプリケーションへカスタマイズされることが可能な統合フローに対するビジネスプロセス管理を提供する。
【００１０】
本発明の実施の形態では、ビルディングブロックは、ホームシステムを外部アプリケーションサーバと相互接続するために使用される。ホームシステム用のＡＰＩは、上述した一連のビルディングブロックとインタフェースする一方、外部アプリケーションサーバのＡＰＩは、第２の組のビルディングブロックとインタフェースする。その結果、２つのシステムは、カスタム統合の必要なく、完全に統合される。
【００１１】
本発明の他の実施の形態は、内蔵型統合、分散型統合、および例えばインターネット上における拡張型統合のために使用することができる。さらに、本発明の実施の形態によるビルディングブロックは、マルチプラットフォームの統合をさらに可能にする。
【００１２】
本発明による自動プラグインは、主な業界トップのアプリケーションおよびシステムを他のシステムと統合することを助けるビルディングブロックを含む。これらのプラグインは、ベースシステム（例えば、所定のプラットフォーム上で実行されるある特定のアプリケーション）への統合を最小限の入力により可能とするために、予め設定され、かつ／または、設定可能である。
【００１３】
統合ソリューションの提供において、本発明は、ＡＰＩサーバを使用する。このＡＰＩサーバは、マルチプラットフォームのデータ交換およびプロセス管理のバスである。実際には、ＡＰＩサーバは、様々なビジネス管理アプリケーションに特有のネイティブＡＰＩインタフェースを介して、当該様々なビジネス管理アプリケーションに対するユビキタスデータアクセスのための単一のエントリーポイントを提供する。次に、ＡＰＩサーバは、統合されたアプリケーションフレームワーク内でいくつかの役割を果たす。ＡＰＩサーバは、バッチおよびイベント単位の双方でオブジェクトレベルのデータマッピングサービスを提供することにより、開発者の内部アプリケーション統合のための主要なコンジットとして機能する。ＡＰＩサーバを使用して形成される統合ソリューションは、第三者の抽出、変換および挿入（ＥＴＬ）ツールを使用してそのアプリケーションのそれぞれ１つにアダプタを構築することにより、そのアプリケーションのそれぞれを統合する要件を容易にする。ＡＰＩサーバの究極の目標は、外部ＥＡＩおよびＥＴＬ製品へのユーザの接続能力を簡素化するだけでなく、開発者のアプリケーションを統合するユーザの能力を改善することである。カスタムプログラミングをほとんど、または、まったく行うことなく、すべてのビジネスアプリケーションを相互に接続する機能は、実装時間およびコストを組織的に減少させ、統合されたビジネスアプリケーションからユーザへの利益を最大にする。
【００１４】
ＡＰＩサーバは、ユーザ定義の欄および属性といったデータ要素を処理するために、限られたデータ変換および集約機能を提供する。また、ＡＰＩサーバは、クライアントが、計測単位変換のような簡単な算術を実行するために、簡単な計算を実行することを可能にするインタフェースも提供する。同様に、ＡＰＩサーバは、バッチおよびイベント駆動プロセスの双方を起動し、監視するメカニズムを提供する。ＡＰＩサーバは、開発者のアプリケーションに最も近いレイヤであるので、ＡＰＩサーバは、最も内部のビジネスプロセス自動化タスクを管理する内部ワークフローエンジン全体を提供する。これらの全ての機能は、管理ユーザが既存のビジネスフローに対する小さな変更をプログラムするためのメカニズムを提供するルールおよびマッピングエンジンを介して管理される。
【００１５】
ＡＰＩサーバの第２の機能は、アプリケーションデータおよびプロセスに対する外部アクセスを提供することである。ＡＰＩサーバは、２つの異なる方法でこのタスクを達成する。主なアクセス方法は、アダプタの使用を介して行うものである。ＥＡＩ／ＥＴＬに基づくアプリケーション用に、あるアダプタが使用され、Ｂ２Ｂアクセスをサポートするために、別のアダプタが使用される。真性のアダプタを欠く第三者の統合ベンダのためのアプリケーションへの接続は、ＸＭＬサポートを有する単層ファイル、汎用ＲＤＢＭＳ接続、およびメッセージングキューのような汎用のアクセスアダプタを介して達成することができる。
【００１６】
本発明のこれらの利点および他の利点は、以下の図面および添付のテキストにおいてより十分に説明される。この図面および添付のテキストでは、同じ参照符号が対応する構成要素を表している。
【００１７】
［好ましい実施の形態の詳細な説明］
図１に一般的に示すように、本発明は、統合システム１０を提供する。具体的には、この統合システム１０は、２つの異種のビジネスアプリケーション２０および３０の間の仲介者として動作し、２つのアプリケーション２０および３０の間のデータ交換を可能にする。アプリケーション２０および３０のそれぞれは、通常、関連する特定用途向けのアプリケーションプログラミングインタフェース（ＡＰＩ）２１および３１を含む。これらＡＰＩ２１および３１は、アプリケーション２０および３０へ、ならびに、アプリケーション２０および３０からデータを導き、フォーマットする。しかしながら、第１のアプリケーション２０から出力されるデータは、第２のアプリケーション３０によって使用可能でない場合もあり得、またその逆の場合もあり得る。例えば、データが適当な型、サイズまたはタイトルでないこともあり得る。これにより、たとえデータの共有が非常に好都合であっても、一方のアプリケーションのデータを他方のアプリケーションで使用することが困難になる。統合システム１０は、一方のアプリケーションからのデータを、第２のアプリケーションでの使用に適合させることにより、この問題に対処する。
【００１８】
統合システム１０は、図２に、より完全に示されており、ＡＰＩサーバ１００を備える。ＡＰＩサーバ１００は、必要とされるすべての機能性をそのユーザに可能にするために、単一のエントリーポイントを開発者に提供する。さらに、ＡＰＩサーバ１００は、エンタープライズアプリケーション統合（ＥＡＩ）およびＢ２Ｂデータ転送の双方のためのデータ、プロセス起動、ならびにセキュリティおよび内部ワークフロー管理を整理するメカニズムを提供する。単一のものがデータソースを通過するので、ＡＰＩサーバ１００は、様々な全てのビジネス管理アプリケーションにとって有益なビジネス関連統合情報を記憶および提示する論理的な場所でもある。以下に、これらの機能のすべてをより詳細に説明する。
【００１９】
一般に、ＡＰＩサーバ１００は、マルチプラットフォームのデータ交換およびプロセス管理のバスである。ＡＰＩサーバ１００は、様々なビジネス管理アプリケーションに特有のネイティブＡＰＩインタフェース（例えば図１に示されるＡＰＩ２１および３１）を介して、該様々なビジネス管理アプリケーションに対するユビキタスデータアクセスのための単一のエントリーポイントを提供する。ＡＰＩサーバ１００は、統合システム１０内でいくつかの役割を果たす。この役割には、バッチおよびイベント単位の双方でオブジェクトレベルのデータマッピングサービスを提供することにより、開発者のアプリケーション間統合のための主要なコンジットとしての役割がある。さらに、ＡＰＩサーバ１００は、ユーザ定義の属性といったデータ要素を処理するために、限られたデータ変換および集約機能を提供する。同様に、ＡＰＩサーバ１００は、バッチおよびイベント駆動プロセスの双方を開始し、監視するメカニズムを提供する。ＡＰＩサーバ１００は、開発者のアプリケーションに最も近いレイヤであるので、ＡＰＩサーバ１００は、最も内部のビジネスプロセス自動化タスクを管理する内部ワークフローエンジンを提供することができる。これらの機能性の全ては、ＡＰＩサーバ１００内のルールおよびマッピングエンジン１０６を介して管理される。ルールおよびマッピングエンジン１０６は、管理ユーザが既存のビジネスデータフローに対する小さな変更をプログラミングするためのメカニズムを提供する。
【００２０】
ＡＰＩサーバ１００の第２の機能は、アプリケーションのデータおよびプロセスに対する外部アクセスを提供することである。ＡＰＩサーバ１００は、このタスクを２つの異なる方法で達成する。主要なアクセスは、ビルディングブロックの使用を通じて行われる。例えば、あるビルディングブロックは、ＥＡＩ、または、抽出、変換および挿入（ＥＴＬ）に基づくアプリケーションに使用することができ、他のビルディングブロックは、Ｂ２Ｂアクセスをサポートするために使用することができる。異種アプリケーション間のデータ転送は、ＸＭＬゲートウェイ１３０を介して達成することもできる。
【００２１】
ＡＰＩサーバ１００は、アプリケーション接続レイヤ１０２、データ正規化レイヤ１０４、ルールおよびマッピングエンジン１０６、メッセージングエージェント１０８、ＸＭＬゲートウェイ１３０、および外部アダプタ１２０を含む６つのレイヤを含むことができる。ＡＰＩサーバ１００は、１つのアプリケーションユニットとして配備されてもよい。一方、新しいリリースが作成され、機能性が向上するか、修正されるか、または変更されるので、ＡＰＩサーバ１００は、ユーザが、これら６つの領域のそれぞれに存在するロジックをアップグレードできる能力を有することが好ましい。このように、ＡＰＩサーバ１００を、新しいアプリケーションおよび／または様々なユーザの要求に適合させることができる。
【００２２】
アプリケーション接続レイヤ１０２は、データの移送メカニズムを提供し、遠隔のアプリケーションインスタンスからＡＰＩサーバ１００へ移動させる。このレイヤの究極の責務は、異なるビジネス管理アプリケーションに関連したデータおよびプロセスオブジェクトをエクスポーズするのに必要とされる複雑さをマスクすることである。長期間に亘って、接続レイヤ１０２は、ターゲットアプリケーション内で利用可能なすべてのデータオブジェクトおよびプロセスにアクセスするように設計される多数の製品のＡＰＩからなる。これらのＡＰＩは、データ移送機能およびビジネスロジックの双方を含み、移送要求がバッチに基づくものであるか、トランザクションに基づくものであるかに関わらず、予め指定されたアプリケーションからのいずれのデータオブジェクトも処理する。データオブジェクトがそれらのネイティブフォーマットで検索されると、該データオブジェクトは、別の関連したアプリケーションにマッピングされてもよいし、または、データ正規化レイヤ１０４に渡される。アプリケーション接続レイヤは、最も高速の利用可能なインタフェースをＡＰＩサーバ１００に保証するために必要となるいかなる技術も使用することができる。エンドユーザは、いくつかの異種アプリケーションを統合するためにそれ以外に必要とされるツールを確保する必要はないので、この機能性は、エンドユーザに対するＡＰＩサーバ１００の価値を高める。
【００２３】
アプリケーションレイヤ１０２は、ビジネス管理アプリケーションの内外のすべてのトランザクションのための主報告レイヤとして機能することもできる。これらのレイヤは、最初は、ファイルに出力されるが、次のリリースは、関係データベースへのログ更新およびシグナリングネットワーク管理プロトコル（ＳＮＭＰ）のトラップへのログ更新を行う能力を含むであろう。
【００２４】
対照的に、データ正規化レイヤ１０４は、あるアプリケーションから検索されるデータが他のアプリケーションによる使用のために正規化されるレイヤである。性能を改善するために適当な場合には、いくつかのアプリケーション内に存在する同様のデータ要素が正規化され、より一般的な定義を持つこともできる。例えば、データがソースアプリケーションから検索されると、データをデータオブジェクトの一般的な表現に変換することができる。同様にして、データがターゲットアプリケーションに送信されようとするとき、該データは、そのオブジェクトの特定製品向けのバージョンに変換されてもよい。データ正規化レイヤ１０４は、１つのアプリケーションにのみ現れるデータ要素、または、アプリケーション間で異なって使用されるデータ要素を通過させるように動作してもよい。
【００２５】
ルールおよびマッピングエンジン
ＡＰＩサーバ１００は、ルールおよびマッピングエンジン１０６をさらに含んでいてもよい。ルールおよびマッピングエンジン１０６は、あるアプリケーション用のあるビジネスオブジェクトに含まれるデータが他のアプリケーションに含まれるデータにマッピングされるレイヤである。開発者がほとんどのビジネスフローをハードコード化して最良の性能を保証できるように、このレイヤは、専ら内部統合用に使用される。新たな統合がリリースされると、新たな追加のマッピングがルールおよびマッピングエンジン１０６に加えられる。
【００２６】
あるいは、ＡＰＩサーバ１００は、訓練を受けた実装者が、現在の機能性を変更するか、ユーザ定義の属性値を管理するか、または、様々なデータ変換作業を実行することを可能にするプログラミング環境を有していてもよい。このプログラミング環境は、ルールおよびマッピングエンジン１０６内に存在するルールを変更するために技術スタッフにより使用され、通常、ハイレベルなテキストに基づくプログラミングインタフェースを特徴とする。このプログラミングインタフェースは、プログラミングシンタックスの違反に対して非常に基本的な検証を行う。
【００２７】
一般に、Ｊａｖａのような分散型プログラミング言語は、ＡＰＩサーバ１００内で使用され、あるアプリケーションから次のアプリケーションにデータをマッピングすることを可能にする。この言語は、各アダプタに関連したクラスおよびメソッドをエクスポーズし、ユーザが、一組のデータ変換関数を使用することによりデータを操作できるようにする。この一組のデータ変換関数は、関連するデータオブジェクトに様々なデータマッピングおよび変換作業を実行するために使用可能である。別の実施の形態においては、統合をより容易に達成するために、Ｊａｖａに類似した擬似言語を使用してもよい。
【００２８】
ＡＰＩサーバ１００は、そのユーザに最大の柔軟性を与えるために、実行時に変更可能なハードコード化されたマッピングおよび設計時間を開発する能力を提供することができる。この場合、条件付きロジック保証がよく使用され、ヌル値が外部ソースから受信されるとデフォルト定数が加えられることがある自動プラグインでの統合を容易にする。
【００２９】
ＡＰＩサーバ１００は、事前にプログラミングされたマッピングであって、必要とされるビジネスソリューションの機能性に従った各ビジネス管理アプリケーション間のマッピングを含んでいてもよい。この統合は、独創的な、関連するアプリケーション間を移動するエンドツーエンドのソリューションを顧客に提供する。データの経路は、ポイントツーポイントか、または、アプリケーション間でデータを移送するメッセージキューを使用するかのいずれかで決定することができる。
【００３０】
パッケージ化され、統合されたビジネス管理アプリケーションのユーザは、彼らのビジネスマッピングの要求の大部分が、予め設定された統合内に既に存在することに気付くかもしれない。一方、機能性がどこで欠けていようとも、クライアントは、ルールおよびマッピングエンジン１０６を使用して、その場で変更する能力を有する。ユーザのクライアントがこれらデータマッピングの変更を必要とするいくつかの理由には、システム間での測定単位の変換およびデータのユーザ定義属性値の使用に加えて、接尾部コードの使用および他の文字列操作の必要性があることが含まれる。ルールおよびマッピングエンジン１０６に対する可能な操作のリストは、表Ａとして添付されている。
【００３１】
好ましい実施の形態では、ＡＰＩサーバ１００は、メッセージングエージェント１０８をさらに含む。このメッセージングエージェントは、上掲した構成要素と共に動作して、１つまたは２つ以上のアプリケーション間のデータを収集および使用する。メッセージングエージェント１０８は、発行および引用の情報書き込み（ｐｕｂｌｉｓｈ−ａｎｄ−ｓｕｂｓｃｒｉｂｅ ｐｏｓｔｉｎｇ）メカニズムを使用して、データ正規化レイヤ１０４を経由してアプリケーション接続レイヤの適当なＡＰＩへデータを移動させる。メッセージングエージェント１０８は、主として、外部ソースからターゲットアプリケーション用の適当なキューへ外部データを書き込むために使用される。メッセージングエージェント１０８は、さらに、この機能性のために必要な内部マッピングを行うものを付加的に有してもよい。
【００３２】
ＸＭＬゲートウェイ１３０は、自己文書化された単層ファイル内において、または、リアルタイムＸＭＬ接続ポータルを通してのいずれかで外部にデータをエスクポーズするＡＰＩサーバ１００の構成要素である。ＸＭＬ１３０を介してエクスポーズされるデータは、基礎となるアプリケーションの高水準なビジネス表現である。いくつかのデータ型定義により、ユーザは、そのオブジェクトの用途に適した定義型を検索することができる。ＸＭＬゲートウェイ１３０は、以下に、より詳細に示される。
【００３３】
アダプタ１２０は、統合ベンダの精鋭によって提供される技術によって、統合システム１０がＡＰＩサーバ１００の内外のデータを移動させることを可能にする。アダプタ１２０は、共通のアクセスポイントを提供する。この共通のアクセスポイントにより、開発者は、予め用意されたサブ統合および自動プラグインの開発を継続することができる。
【００３４】
ＡＰＩサーバ１００は、一般に、様々なビジネス管理アプリケーションに一貫して共通に使用されるいくつかのプログラミングツールを使用する。ＡＰＩサーバ１００は、一般に、すべてのアプリケーションにユビキタスアクセスを提供するので、ＡＰＩサーバ１００は、今日、一般に使用されている技術のすべてを含んでいてもよい。これらのツールは、Ｅｎｔｅｒｐｒｉｓｅ　Ｊａｖａ　Ｂｅａｎｓ、ｐｕｒｅ　ＪＡＶＡ、Ｃ＋＋、Ｃｏｒｂａ、ＪＭＳ、ＪＤＢＣおよび他の同様の技術を含む。
【００３５】
ＡＰＩサーバ１００は、いくつかの異なる動作プラットフォームをサポートするのが好ましい。例えば、ＡＰＩサーバ１００は、Ｗｉｎｄｏｗｓ　ＮＴ　４．０　ＳＰ６およびＷｉｎｄｏｗｓ　２０００　ＳＰ１、ＨＰ−ＵＸ　１１および１１ｉ、ＳＵＮ　Ｓｏｌａｒｉｓ　２．７および２．８、またはＡＩＸ　４．３．３および４．３．４を使用して動作してもよい。また、ＡＰＩサーバ１００は、アプリケーションを拡大縮小する手段としてクラスタリングを利用する環境と互換性を有することが好ましい。具体的には、ＬｅｇａｔｏおよびＶｅｒｉｔａｓの互換性が望ましい。
【００３６】
ＡＰＩサーバ１００は、ビジネス管理アプリケーションが許容する場合には、一般に、当該ビジネス管理アプリケーションが存在するサーバと同じサーバに配備され、インストールされる。ＡＰＩサーバ１００は、同じサーバ上に存在するアプリケーションに接続する機能を有していなければならない。この特徴は、性能および拡張性が問題となる場合に備えてスタンドアロンサーバに配備される能力をＡＰＩサーバ１００に与える。
【００３７】
また、ＡＰＩサーバ１００は、一般に、あるタイプのエラー処理を含む。エラー処理、すなわちエラーの記憶および分析は、（１．）標準出力、（２．）トランザクションおよびジョブ要約レベル出力を有する単層ファイル、（３．）関係データベース、（４．）Ｊａｖａ（登録商標）メッセージサービス（ＪＭＳ）のメッセージ出力、または（５．）シグナリングネットワーク管理プロトコル（ＳＮＭＰ）のトラップと通して提供することができる。
【００３８】
一般の動作では、ＡＰＩサーバ１００は、顧客の要求を満足させる比較的高速のコンピュータである。現在、レコードボリュームの要件は、ほとんどのクライアントデータボリュームの要件を１０万行と６０００万行との間に置いている。１時間の平均バッチ時間枠を仮定すると、ＡＰＩサーバ１００は、通常のバッチサイクル内で１０００万個程度のエントリを有するクライアントを収容すべきである。したがって、平均トランザクションボリュームは、毎分１５万から２０万トランザクションの範囲にある。
【００３９】
図２に戻って、ＡＰＩサーバ１００の好ましい実施態様は、統合されたデータアクセスを提供する４方向からのソリューションを使用する。この実施態様の４つの構成要素は、（１）内部統合エンジン１１０、（２）ＥＴＬおよびＢ２Ｂアダプタ１２０、（３）ＸＭＬゲートウェイ１３０、ならびに（４）特定用途向け高性能インタフェース１４０である。各構成要素は、利用可能で最も頑丈な統合フットプリントを有するビジネス管理製品を提供するように特別に設計される。
【００４０】
内部統合エンジン
ＡＰＩサーバ１００は、予め指定された関連するビジネス管理製品に、内部統合のための共通の統合プラットフォームを提供する。通常、これらのアプリケーションは、一人の開発者または関連した開発者達のチームによって開発される。具体的には、ＡＰＩサーバ１００は、様々なビジネスオペレーションアプリケーションに、それらアプリケーションのネイティブＡＰＩを介して接続する。データがＡＰＩサーバ１００によって検索されるとすぐに、当該データは、他のアプリケーションのデータオブジェクトに直接マッピングされてもよいし、または、共通のデータ正規化レイヤ１０８にエクスポーズされてもよい。データ正規化レイヤ１０８は、その後、外部アダプタまたはＸＭＬに基づくデータ移送メカニズムへ当該データをマッピングする。データは共通のデータ正規化レイヤ内でオブジェクトとして存在するので、あるアプリケーションから次のものへのオブジェクトのマッピングは、かなり高速に行うことができる。次に、内部で渡された情報は、ターゲットアプリケーションへアプリケーションのネイティブＡＰＩを介して転送される。このアーキテクチャは、メッセージキューを使用してもよいし、または、アプリケーションを直接更新する直接的なポイントツーポイントアクセスを使用してもよい。この機能により、バッチまたはイベントに基づく方式のいずれかでデータを容易に転送することができる。同様に、同じ移送メカニズムを使用して、バッチおよびイベントの双方に基づく修復アルゴリズムを、ターゲットアプリケーションへ渡される引数として実行することができる。データ転送およびプロセス起動は、マルチスレッド化され、かつ、並列処理可能な実行時環境内で実行可能であるので、この方法論の利点は、当該方法が本質的に拡張性を有することである。また、データ入力プロセスをさらに効率化するために、各スレッドには、ステートフル同期方式またはステートレス非同期方式のいずれかで、統合に必要とされる所定のビジネスロジックをターゲットアプリケーションへインポーズするタスクを割り当てることができる。
【００４１】
ＡＰＩサーバ１００の一実施態様は、関連するアプリケーションを統合するユニバーサルデータモデル（ＵＤＭ）ビルディングブロックを含む。ＵＤＭビルディングブロックは、一般に、アプリケーションの上部にある統合ソリューションのレイヤを構築するために使用される。ＵＤＭビルディングブロックは、ダイレクトインテグレータのために接続数の増加を犠牲にして動作する。同時に、ユーティリティビルディングブロックも、関連するビジネスアプリケーション間のデータを記憶し、抽出するために、ＡＰＩサーバ１００で使用することができる。内部統合エンジン１１０は、必要に応じて開発者によりカスタム開発されてもよいし、あるいは、市販の統合アプリケーションを利用することもできる。例えば、マサチューセッツ州ウォルサムのＶｉｇｎｅｔｔｅ Ｃｏｒｐ．により製作されたＢｕｓｉｎｅｓｓ　Ｉｎｔｅｇｒａｔｉｏｎ　Ｓｔｕｄｉｏは、２つの異なるアプリケーション間でデータを共有するために使用可能な統合プログラムである。
【００４２】
好ましい実施態様では、内部統合エンジン１１０は、ビジネスロジック１１３をさらに含む。このビジネスロジック１１３は、エラーチェック、ログ収集およびトレースといった要望された機能に応じて、ビルディングブロックの上に追加され、さらに、改良されたデータ、ユーザフレンドリなデータ表現を付加する。ビジネスロジック１１３は、内部統合エンジン１１０が新しいアプリケーションに適合できるように調整されてもよい。
【００４３】
アダプタ
ＡＰＩサーバ１００は、ローカルに操作される、異なるビジネス管理アプリケーションをアダプタ１２０を通じて統合する機能をさらに有することができる。具体的には、ＡＰＩサーバ１００の正規化レイヤ１０４にエクスポーズされたデータが、あるビジネス管理アプリケーションに存在し、既に正規化されている場合に、唯一のビルディングブロック、すなわちアダプタが、通常、このデータにアクセスするために必要とされる。アダプタ１２０は、付加的な関係完全性（ｒｅｌａｔｉｏｎａｌ ｉｎｔｅｇｒｉｔｙ）およびビジネス機能を必要としないアプリケーションへの接続を提供するために使用することができる。アダプタ１２０は、一般に、ＡＰＩサーバ１００の基礎をなすスレッド化されたアクセスに頼ることにより、より大きな拡張性および配備柔軟性を提供することができる。例えば、データフォーマットおよび全体的なプロセスの目的は、一般に、サプライチェーン管理最適化アプリケーションに焦点を合わせるビジネス管理アプリケーションと、Ｂ２Ｂ電子商取引に焦点を合わせるアプリケーションとの間で異なる。それにもかかわらず、２つの対応するデータブロックを、ビジネス管理アプリケーションのこれらの型の双方に合致するように構成することができる。
【００４４】
拡張されたマッピング、データ変換および集約機能性を提供するために、アダプタ１２０を利用することができる。例えば、アダプタ１２０は、アプリケーションから、ＥＴＬおよびＢ２Ｂシステムの機能を処理するためにより良く装備されたＥＴＬおよびＢ２Ｂシステムへデータを転送することができる。ＥＴＬ対Ｂ２Ｂ統合で実行される操作の多くは、大きく異なる場合があるので、ＡＰＩサーバ１００は、これら２つの個別の目的に適した２つのアダプタを含むことが好ましい。
【００４５】
上述したＵＤＭビルディングブロックと同様に、ＥＴＬアダプタ１２１（ＥＡＩアダプタとも呼ばれる）は、メーカ独自のグラフィカルインタフェースをＡＰＩサーバ１００に提供することができる。ＥＴＬアダプタ１２１は、バッチに基づくアプリケーションのためにデータオブジェクトおよびプロセスの双方をエクスポーズする。ＥＴＬアダプタ１２１は、特定用途向けのサブ統合へデータを外部エクスポーズするので、ＥＴＬアダプタ１２１は、イベントおよびバッチの双方に基づく生成、読み出し、更新および削除（ＣＲＵＤ）の操作をさらに可能とする。
【００４６】
ＥＴＬアダプタ１２１は、ユーザが連携を計画した高水準データオブジェクトを選択することを可能にする。このデータは、そのオブジェクトのサブ構成要素と共に、ＳＫＵのような項目識別子を含む。ユーザは、１）インストールされたアプリケーションを更新のため選択し、２）そのデータオブジェクトにどの操作を行うかを決定する。これらの操作は、通常、挿入、更新、削除、カスケード削除、および表示を含む。他の操作は、上掲された操作のバッチおよびイベントに基づくバージョンを含むことができる。インストールされたアプリケーションに利用可能な操作は、ユーザに視覚的に表示することができる。
【００４７】
図２を再び参照して、ＡＰＩサーバ１００は、Ｂ２Ｂアダプタ１２２をさらに含んでいてもよい。Ｂ２Ｂアダプタは、ＥＴＬアダプタ１２１と酷似しており、後述する最上層のベンダといった、参加するアプリケーション開発者に外部統合機能を提供する。Ｂ２Ｂアダプタ１２２は、より多くのイベントに基づく機能性を提供する点において、ＥＴＬアダプタ１２１と異なる。これは、多くのＥＡＩベンダが市販または自社独自のメッセージングバスのいずれかで動作することから必要とされる。Ｂ２Ｂアダプタ１２２は、下部にあるメッセージバスと連携し、外部のＢ２ＢシステムとＡＰＩサーバ１００との間の効率的なデータ整理機能を提供する。ワークフローおよびビジネスプロセス管理機能を提供するＥＡＩツールのための企業内プロセスの構成要素として、Ｂ２Ｂアダプタ１２２を配備することもできる。ＥＴＬアダプタ１２１と同様に、Ｂ２Ｂアダプタ１２２は、より複雑なソリューションが基礎を置くことができる要素を提供する。
【００４８】
上述したように、エラーの検出および報告といった様々なビジネスロジック１１３を、ユーザのニーズを満足させるために必要に応じてアダプタ１２０に追加することができる。また、アダプタ１２０は、新しいビジネス管理アプリケーションおよび統合に基づくビジネスソリューションの開発の基盤として機能することもできる。
【００４９】
アダプタを形成するときに、暗号化アルゴリズムが、関係データベース、単層ファイル、ＬＤＡＰ、および環境管理アダプタに必要となる。このアルゴリズムにより、高度に保護された環境にこれらアダプタを配備することができる。この環境では、初期化ファイル、データベース、およびそのシステム環境内での可読テキストの設定情報の使用を禁止する標準がある。暗号化メカニズムは、統合フローに使用される特定のアダプタのみによって暗号化および復号化可能な２つのアルゴリズムを含むべきである。この特徴により、ユーザは、ファイルまたはデータベースへの、および、ファイルまたはデータベースからのデータのストリームを暗号化または復号化することができる。さらに、この特徴により、ユーザは、可読テキスト以外のフォーマットでパスワードおよびログインＩＤを格納することができる。
【００５０】
性能についても、アダプタを形成するときに考慮されるべきである。性能は、ＡＰＩサーバの最終目標でないが、この製品に究極の拡張性を保証するために多くの異なる技術および方法を使用することにより、受け入れ可能な性能を達成することができる。これらの方法は、使用されている基礎をなす技術のために、アダプタごとに異なる。しかしながら、ＡＰＩ技術が許容する全体の速度および性能を保証するために、一般に、カーソル移動、並列性、マルチスレッド処理、およびパイプライン処理と共に、データベースおよびファイルへのデータキャッシュを使用することができる。他の選択肢には、データがシステムからシステムへより効率的に渡されるように、ＡＰＩサーバ内でデータを自動的に分割する特定のアルゴリズムの開発が含まれる。これらのアルゴリズムには、濃度または単純なアルファベット順に基づいた論理的なチャンクにデータを分割することが含まれる。
【００５１】
ＸＭＬゲートウェイ
ＡＰＩサーバ１００は、汎用タグ付き階層データを任意の外部のアプリケーションおよび統合システムにエクスポーズするために使用可能な拡張可能なマークアップ言語（ＸＭＬ）インタフェース１３０を有していてもよい。ハイパーテキストマークアップ言語（ＨＴＭＬ）と同様に、ＸＭＬは、インターネットのような分散ネットワーク上で使用される分散アプリケーションを定義するプログラミング言語である。ＨＴＭＬアプリケーションが、一般にマルチメディアの表現のために使用されるのに対して、ＸＭＬアプリケーションは、一般にデータを取得し、転送するように機能する。ＸＭＬインタフェース１３０は、アプリケーションデータに対する汎用アクセスを提供する。また、ＸＭＬインタフェース１３０により、ユーザまたはアプリケーションは、ＸＭＬによりコード化された引数を特定のアプリケーションに送信し、２次プロセスを開始することができる。ＸＭＬは自己文書化されているので、ユーザおよび開発者の双方の顧客は、ＸＭＬインタフェース１３０を利用して、統合および拡張されたビジネス機能性の双方を提供することができる。
【００５２】
ＡＰＩサーバ１００に記憶されるＸＭＬに基づく単層ファイルから情報を容易に読み出すことができるように、ＸＭＬゲートウェイ１３０は、ファイルベースのアクセス方法を提供する。さらに、ＸＭＬゲートウェイ１３０は、アプリケーションからのデータを生のリアルタイム接続を介して提供することを可能とする非同期ＸＭＬメッセージングポータルを提供する。
【００５３】
ＸＭＬゲートウェイ１３０は、ＡＰＩサーバ１００の内部統合エンジン１１０またはアダプタ１２０よりもアプリケーションの性能において劣るものの、ＸＭＬゲートウェイ１３０により、ユーザは、異種ビジネス管理アプリケーションがデータを共有するように適合していない場合に、これらのアプリケーションの内外でデータを得ることができる。好ましい実施の形態では、ＸＭＬゲートウェイ１３０は、現在の業界トップのＸＭＬ関連標準、例えば拡張可能なスタイルシート言語（ＸＳＬ）、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、およびＬｉｇｈｔｗｅｉｇｈｔ　Ｄｉｒｅｃｔｏｒｙ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌ（ＬＤＡＰ）に準拠するように適合している。ＳＯＡＰは、コンピュータシステム間でメソッド起動を指定するためのＸＭＬに基づくフォーマットである。ＳＯＡＰは、いずれのプラットフォーム、オペレーティングシステム、またはプログラミング言語からも完全に独立しており、ユビキタスＨＴＴＰおよびＳＭＴＰプロトコルと共にインターネット上で容易に使用することができる。具体的には、ＸＭＬインタフェース１３０は、必要なプロセスを起動する特定のアプリケーションにＸＭＬ引数を渡すことができる。データ転送に必要とされる、新たに現れる技術および将来開発される技術を使用するために、ＸＭＬゲートウェイを同様にして適合させることができることは、理解されるべきである。
【００５４】
ビジネスオペレーションアプリケーション高性能インタフェース
相互に関係するアプリケーションは、低水準のＪＡＶＡデータベース接続（ＪＤＢＣ）に基づくアプリケーションインタフェースを有することができる。このインタフェースは、上記３つのインタフェースの実装を容易にするものではないが、ＪＤＢＣインタフェースは、多くの関連するビジネスアプリケーションの至る所にあるデータへの最速のアクセス手段を提供する。この実装は、様々な周知の企業資源計画システムに類似しており、このシステムでは、データボリュームおよび統合性能の要件が比較的に大きくなってきている。具体的には、アプリケーションは、いずれの統合をも迂回して、データベースといった情報記憶装置に記憶されたデータにアクセスするだけでもよい。このデータは、利用可能なフォーマットで別のアプリケーションにより予め預けられている。
【００５５】
データをインポートするロジックが複雑であり、かつ、時間に敏感であるアプリケーションに対しては、ステージングテーブルがデータのインポートに使用される。次に、データが最終格納場所に到達する前に、Ｏｒａｃｌｅ（登録商標）により実装されるプロシージャのようなデータベース記憶プロシージャが、データを処理し、集約するために使用される。この構成は、最も複雑な処理ロジックを、それを最も効率的に実行できるデータベースレベルにする。他のタイプのビジネスアプリケーションに対しては、当該アプリケーションを様々なデータベースへ直接接続する特定製品向けのＪＤＢＣドライバを記述することができる。
【００５６】
図２に戻って、ＡＰＩサーバ１００は、実行マネージャ１５０、セキュリティインタフェース１６０、レポータ１７０、アナライザ１８０、およびスケジューラ１９０をさらに含んでいてもよい。
【００５７】
統合されたビジネスアプリケーションフレームワークのプロセス起動要件を満たすために、ＡＰＩサーバ１００は、様々なビジネスアプリケーションプロセスの開始および監視の双方を行う機能をさらに有することができる。プロセス実行マネージャ（ＰＥＭ）１５０は、ＡＰＩサーバ１００の残りの部分と同じ技術に基づいて構築されるが、適用可能な各ビジネスアプリケーション内のバッチおよびイベントの双方に基づくプロセスを遠隔で開始するという別の目的を果たす。そのうえ、ＰＥＭ１５０は、開始されたアプリケーションの進行および完了状態を監視する。さらに、ＰＥＭ１５０は、いずれのタスクまたはアプリケーションが起動される前でも、満たさなければならない特定の依存関係を管理する。例えば、ＰＥＭ１５０は、ジョブを順序付けし、マルチストリーム化することもできる。また、ＰＥＭ１５０は、外部システム環境と相互に作用し、シェルまたはリモートシェルに基づくルーチンを介して外部プログラムを実行し、また、システム環境設定ファイルまたはＷｉｎｄｏｗｓ（登録商標）のレジストリから外部環境値を検索するといったタスクを完了することもできる。
【００５８】
エンドツーエンドの統合およびビジネスワークフローオペレーションは、上述したルールおよびマッピングエンジン１０６を用いて配備ターゲットを作成することにより構築される。ルールおよびマッピングエンジン１０６により、ユーザは、事前にプログラミングされたカスタムデータ統合をコンパイルし、それらを実行ファイルとして配備することができる。小さな一組の機能性を実行するより小さな統合を開発することにより、ユーザは、モジュール形式で再利用可能な統合を開発することができる。また、これにより、２つ以上のアプリケーションが使用される場合に、エンドツーエンド全体の統合を再び作成する必要もなくなる。ＰＥＭ１５０は、そのデータベースに登録されているジョブの実行を管理する。ＰＥＭ１５０は、マッピングがいつ、どのようにして実行され、アプリケーションの更新を提供するかを制御する。この特徴により、開発者は、１つまたは２つ以上のアプリケーション間のかなり複雑なワークフロー指向型プロセスをプログラムすることができる。このワークフローの構成要素は、実際のプログラミング言語をあるレベルだけ抽象化したものを開発者に提供するように意図されており、開発者は、以前のマッピングを再利用して、ビジネスソリューションプロセスに対するより複雑な目標を作成することができる。ＰＥＭ１５０は、拡張性のために、クラスタ化されたサーバの至るところに配備されるプロセスを管理する。
【００５９】
ＰＥＭ１５０は、実行時のすべての統合設定情報の格納場所として機能する関係データベースを保守する。その上、ＰＥＭ１５０は、いくつかの外部イベントからの入力に基づいてサブ統合を起動する能力を有する。ＰＥＭ１５０は、通常、ジョブ名、トリガするイベントおよび時間、ならびにジョブ依存関係を定義する欄を備えたグラフィックユーザインタフェース（ＧＵＩ）を有していてもよい。この依存関係の欄により、ユーザは、ジョブ実行のための条件ロジックを規定することができる。また、ＰＥＭ１５０は、一般に、標準出力、ログファイル、およびＳＮＭＰトラップにログを書き込む機能も有する。
【００６０】
また、ＰＥＭ１５０は、これらに限定されるものではないが、コマンドライン引数、スケジューリングされたジョブ、キューに書き込まれたイベント、ファイル変更、およびデータベーストリガを含んでいてもよい。ＰＥＭ１５０がコマンドライン引数から起動可能であることにより、ＡＴ、ＣＲＯＮ、ＣＡのＵｎｉｃｅｎｔｅｒ、またはＭａｅｓｔｒｏといった他のスケジューリングツールの方を好むユーザは、それらの製品から起動される簡単なスクリプトを記述し、ＰＥＭ１５０を呼び出してアプリケーション統合を実行することができる。同様に、ＰＥＭ１５０は、スケジューリングツールを含み、このスケジューリングツールにより、これらの製品を有するユーザは、外部のスケジューリングツールを必要とすることなく、ＰＥＭ１５０からサブ統合を起動するメカニズムを持つことができる。ＰＥＭ１５０は、バッチ、トランザクションまたはデーモンモードによりジョブ実行を操作する。したがって、時限バッチの更新によるのとまさに同程度の容易さで、データベーストリガおよびイベントからメッセージキューへとジョブを起動することができる。
【００６１】
ＰＥＭ１５０は、一方のジョブ内のイベントが、他方のジョブ内のイベントを体系的にトリガすることを可能とするので、ＰＥＭ１５０には、ジョブおよびワークフロー管理を行う能力が本来的に備わっている。ＰＥＭ１５０は、一般に、あるアダプタからデータを移動させ、特定の実行基準に基づいて、当該データを１つまたは２つ以上のアダプタに移動させる能力を有する。さらに、同じイベントに基づくトリガ方法を使用して、ＰＥＭ１５０は、いくつかの異なるシステムの内外のデータフローを同時に管理可能であってもよい。この機能性も、いくつかの統合を並列に設定し、同じターゲットにアクセスできるようにすることによって、拡張性を改善する。データをいくつかの並列経路に渡す統合を設定することにより、ステートレスエンタープライズＪａｖａＢｅａｎｓ（ＥＪＢ）がアプリケーションサーバ内で動作する方法と同様の方式で拡張性を達成することができる。ＰＥＭ１５０は、それ自身の設定データの格納場所を有し、実行予定の各ジョブに関する情報を記憶する。
【００６２】
ＰＥＭ１５０は、一般に、１日２４時間利用可能であるべきであり、１日を通して実行するジョブを管理する。さらに、ＰＥＭ１５０は、通常、１つの１次インスタンスがダウンしたときにフェールオーバを提供するために、第２のインスタンスが利用可能である時を認識する。このように、２次システムから１次システムへ規則的な間隔で呼び出しを送信することにより、システムが今もなお操作可能であることが保証される。１次システムがダウンすると、２次システムが引き継ぐ。
【００６３】
上記で提言したように、プロセス実行マネージャ１５０は、内部ワークフロー監視ツールとして使用することもできる。このように、プロセス実行マネージャ１５０は、特定のプロセス中継基準に基づいて複雑なビジネス統合プロセスをモデル化する能力をユーザに提供する。ユーザは、一組の定義済みステータスチェックポイントを使用してエンドツーエンドのプロセスを設計するために、内部プログラミングインタフェースを使用することができる。また、ユーザは、多くのプロセスまたは変化する複雑さのレベルをモデル化することができる。
【００６４】
プロセス実行マネージャ１５０は、ＸＭＬインタフェースを通じて送られるコマンドライン引数、アダプタ１２０を通じて送られる行動入力、またはＡＰＩサーバ１００の上に作成されるグラフィカルインタフェース（図示せず）のいずれかにより使用されてもよい。
【００６５】
図２に戻って、ＡＰＩサーバ１００は、セキュリティインタフェース１６０をさらに含んでいてもよい。一組の製品をＷｅｂに実装すると、開発者には、複雑な一組のセキュリティに関係する事項が新たに提供される。ＡＰＩサーバ１００を介した統合は、セキュリティの問題も引き起こす。したがって、ＡＰＩサーバ１００は、システム１０の外部から、適用可能ないずれのアプリケーションにもセキュリティ関連情報を渡す能力を有することが好ましい。同様に、ＡＰＩサーバ１００は、アプリケーション間の情報を合わせる特定セキュリティ向けのＡＰＩを有してもよい。このため、ＡＰＩサーバ１００は、Ｌｉｇｈｔｗｅｉｇｈｔ　Ｄｉｒｅｃｔｏｒｙ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌ（ＬＤＡＰ）およびＪａｖａ　Ｎａｍｉｎｇ　ａｎｄ　Ｄｉｒｅｃｔｏｒｙ　Ｉｎｔｅｒｆａｃｅ（ＪＮＤＩ）といった市販のセキュリティプロトコルをサポートしてもよい。同様に、このセキュリティ機能性は、Ｖｅｒｉｓｉｇｎ（登録商標）およびＥｎｔｒｕｓｔ（登録商標）により構築されたセキュリティアプリケーションのような他のサードパーティの製品の強度をうまく利用するように拡張されてもよい。
【００６６】
プロセスのステータスおよび故障のログ収集および報告は、統合システムを成功させるために望ましい機能である。したがって、他の実施の形態では、ＡＰＩサーバ１００は、トランザクションレベル、プロセス要約レベル、およびリターンコードを有するオペレーティングシステムレベルでログ収集を行うといった多段ログ収集機能を提供する自動記録器１７０を有してもよい。これらログ収集のＡＰＩサーバ１００への記録は、最初は、オペレーティングシステムの応答を除き単層ファイルであってもよい。オペレーティングシステムの応答は、標準出力に向かうが、ログファイルに行き先を変えることができる。あるいは、ＡＰＩサーバ１００は、これらのメッセージをデータベースに記録し、取引のノンレピュテーション（ｔｒａｎｓａｃｔｉｏｎａｌ ｎｏｎ−ｒｅｐｕｔａｔｉｏｎ）および文書アーカイブのインタフェースを提供してもよい。一方、ＡＰＩサーバ１００は、ＳＮＭＰ互換システム管理ツールを備えた統合を含んでいてもよい。
【００６７】
図２を再び参照して、ＡＰＩサーバ１００の他の実施態様は、アナライザ１８０を含む。統合は、統合システム１０を通過するデータからの最近の極めて重大な情報を利用する要望により推進されてもよい。この要求は、特にＢ２Ｂ部門で普及している。Ｂ２Ｂ部門では、情報応答時間といった綿密な統合細部の測定を、利益および損失を取り囲む意思決定を推進するために使用することができる。さらに、多くのアプリケーション開発者は、オフィスオートメーションシステムを実装することによって得られる価値を増大するために、これら領域のそれらの機能の拡張を試みている。同様に、開発者は、このタイプの統合に基づく情報を利用して、その別の最適化エンジンの価値提案を広げることができる。統合システム１０内において、ビジネスアプリケーションを推進するために使用されるデータは、ある時点にＡＰＩサーバ１００を通過する。この情報により、収益性を追求するために使用可能な各統合トランザクションについての大量の情報が存在する。Ｂ２Ｂ交換のような環境で使用される場合に、付加的価値を提供し、かつ、具体的なビジネス選択を推進するために、当該情報を取引相手に販売することができる。このタイプの情報は、典型的なＣＲＭシステムによって収集される性能メトリクスに非常に類似している。さらに、特定のキープロセス指示子を、ある特定の統合ソリューションの有効性を検討するために生成することができる。
【００６８】
図２を参照して、ＡＰＩサーバ１００の別の実施態様は、統合管理サービススケジューラ１９０を含んでいてもよい。このスケジューラ１９０は、一般に、ＩＳ　３００の構成要素である。ＩＳ　３００の主な機能は、フィールドレベルで生成および変更された統合のための文書化されたコード制御を保守することである。スケジューラ１９０は、ＡＰＩサーバ１００を使用して記述された、統合されたアプリケーションのためのチェックインおよびチェックアウトサービスを提供する。これにより、クライアントは、どのバージョンのコードを生産に導入するかを決定することができる。このサービスは、コードアーカイブ、日付および作者のログ収集サービスを含む。
【００６９】
また、スケジューラ１９０は、テキストベースのＣＲＯＮまたはＡＴスタイルのスケジューラを有していてもよい。このスケジューラを用いて、ユーザは、統合を開始する時限イベントまたはトリガされたイベントのいずれかを定義する。このスケジューラは、直列または並列に実行されるイベントをトリガおよび監視し、リターンコードを、ＳＮＭＰのような外部ターゲットに、または、他の統合にパラメータとして適当に渡す機能も有する。
【００７０】
図３は、統合システム１０を使用して異種アプリケーションを統合する方法２００を示している。具体的には、この方法は、異種アプリケーション間の関係に従って動作する。複数のアプリケーションが、単一の開発者または連係した開発者達のいずれかを通じて同時に開発される場合には、これらアプリケーションをステップ２１０で直接統合することができる。一般に、これらアプリケーションは、共存するように設計されるか、または、それらの関連した開発を通じて、本質的に共存することができる。直接統合ステップ２１０は、上述した内部統合エンジン１１０といった装置を通じて実施することができる。あるいは、関連したアプリケーションは、ステップ２２０において、アプリケーションインタフェースを通じて情報を交換するように接続されてもよい。このように、関連したアプリケーションは、統合サーバまたは他のタイプの中間ＡＰＩなしで相互に作用することができる。
【００７１】
図３に戻って、別の方法として、アプリケーションを、ステップ２３０において、アダプタの使用を通じて統合することができる。例えば、上述したＥＴＬアダプタ１２１は、ファイアウォール内で実行される異種アプリケーション間のデータ交換を可能にする。通常、ＥＴＬアダプタ１２１は、単一のシステム内またはネットワーク内で実行されるアプリケーションを結合する。逆に、Ｂ２Ｂアダプタ１２２は、ファイアウォールによって分離された異種アプリケーション間のデータ交換を可能にする。このように、ユーザは、関係しないアプリケーション間でデータを共有するために協力することができる。しかしながら、アダプタは、２つの別個のアプリケーション間の仲介者として機能するように具体的に作成されなければならない。同様に、アダプタは、一般に、それらアプリケーションの新しいバージョン用に更新される必要がある。
【００７２】
あるいは、ユーザは、ステップ２４０で、分散ネットワーク上において、異なるアプリケーション間でデータを転送することができる。例えば、アプリケーション間のアダプタがたとえ作成されていなくとも、ＸＭＬゲートウェイ１４０は、ファイアウォールを横切ってアプリケーションを結合することができる。
【００７３】
ステップ２１０から２４０の組み合わせを使用して、アプリケーション間でデータを交換できることが、理解されるであろう。例えば、他のデータを分散ネットワーク上で交換しながら、あるデータを交換するように、アプリケーションを直接統合することができる。
【００７４】
開発者は、統合方法２００を使用して、他のアプリケーション開発者とビジネスパートナシップを形成することができる。この開発者は、いくつかの異なるアプリケーション開発者からの技術製品の提供物を使用して、統合されたアプリケーションを納品することができる。開発者は、上述した統合インフラ内で種々の程度の結合を有するアプリケーションを提供することができる。結合の異なるレベルは、パートナシッププログラム内の開発者に特有のレベルに基づいている。統合されたビジネスアプリケーションは、最も高い層の最初に開発された製品から最も低い層の簡素な再販業者または統合認証同意にまで及んでいてもよい。
【００７５】
図４に示す一実施態様において、この統合されたマルチベンダ戦略は、３層のパートナの階層である。最上層のベンダ、すなわち最も高いレベルのベンダは、彼らの潜在的な市場インパクトだけでなく、彼らがビジネス管理統合ソリューションに追加する彼らの機能および業績の双方の大きさにより判断されてもよい。高層のパートナは、ステップ２１０および２２０で上述したように、開発者のアプリケーションと直接統合可能である。全面的な統合のために、開発者は、そのアプリケーションの多くの情報をパートナと共有する。ほとんどの内部統合はＡＰＩサーバ１００を介して行われる一方、最上層のベンダのアプリケーションは、ＡＰＩサーバ１００内では直ちに利用できない拡張されたデータ変換および集約サービスを提供することができる。また、最上層のパートナは、高性能の関係データベース管理システム（ＲＤＢＭＳ）アダプタ１２０を提供することもできる。このアダプタ１２０は、ＡＰＩサーバ１００を迂回し、データベースレベルで他のアプリケーションのデータにアクセスするメカニズムを有する。この機能により、開発者は、高速に実行できる統合ソリューションだけでなく、予め構成されたサブ統合およびプラグインを使い易く提供することができる。
【００７６】
中段のパートナは、ステップ２３０において上述したように、アダプタを通じて開発者のアプリケーションと統合可能である。この統合レベルについて、開発者は、そのアプリケーションのいくつかの情報をパートナと共有するが、情報は全面的な統合に必要とされるものよりは少ない。下層のパートナは、ステップ２４０で上述したように、分散ネットワークを通じて開発者のアプリケーションと統合可能である。この関係により、開発者は、一般のクライアント統合要求を満たすために、ＡＰＩサーバ１００のＸＭＬインタフェース１３０を使用することにより、限られた量の情報のみをパートナに示すことができる。拡張された統合の要求は、ユーザの技術的要求およびアプリケーションの要求に従ってカスタマイズされてもよい。
【００７７】
本発明の好ましい実施の形態の上記説明は、例示および説明の目的のため示されたものである。それは、網羅することを意図したものではなく、また、開示された正確な形に本発明を限定することを意図したものではない。上記教示に照らして、多くの変更および変形が可能である。本発明の範囲は、この詳細な説明ではなく、正しくは、この説明に添付された特許請求の範囲によって限定されることが意図されている。上記明細書、例およびデータは、本発明の構成からなる製品および使用の全体的な説明である。本発明の精神および範囲から逸脱することなく、本発明の多くの実施の形態を作成することができるので、本発明は、併記の特許請求の範囲に存在する。
【００７８】
【表１】
2004511034.tif 000003
【表２】
2004511034.tif 000004
【表３】
2004511034.tif 000005
【表４】
2004511034.tif 000006
【図面の簡単な説明】
【図１】本発明の一実施の形態によるアプリケーション統合システムを概略的に示す。
【図２】本発明の一実施の形態によるアプリケーション統合システムを概略的に示す。
【図３】本発明の一実施の形態による図１および図２のシステムを使用する方法のステップを示すフローチャートである。
【図４】本発明の一実施の形態による図３の統合方法の実施態様の概略図である。
【図１】
2004511034.tif 000007
【図２】
2004511034.tif 000008
【図３】
2004511034.tif 000009
【図４】
2004511034.tif 000010
【国際公開パンフレット】
2004511034.tif 000011
2004511034.tif 000012
2004511034.tif 000013
2004511034.tif 000014
2004511034.tif 000015
2004511034.tif 000016
2004511034.tif 000017
2004511034.tif 000018
2004511034.tif 000019
2004511034.tif 000020
2004511034.tif 000021
2004511034.tif 000022
2004511034.tif 000023
2004511034.tif 000024
2004511034.tif 000025
2004511034.tif 000026
2004511034.tif 000027
2004511034.tif 000028
2004511034.tif 000029
2004511034.tif 000030
2004511034.tif 000031
2004511034.tif 000032
2004511034.tif 000033
2004511034.tif 000034
2004511034.tif 000035
2004511034.tif 000036
2004511034.tif 000037
2004511034.tif 000038
2004511034.tif 000039
2004511034.tif 000040
2004511034.tif 000041
2004511034.tif 000042
2004511034.tif 000043
2004511034.tif 000044
2004511034.tif 000045
2004511034.tif 000046
2004511034.tif 000047
2004511034.tif 000048
2004511034.tif 000049
【国際公開パンフレット（コレクトバージョン）】
2004511034.tif 000050
2004511034.tif 000051
【国際調査報告】
2004511034.tif 000052
2004511034.tif 000053