JP2005521931A - 交換インフラシステム及び方法 - Google Patents

Abstract

異質なソフトウェア構成要素の集まりのメッセージベース交換及び統合用交換インフラを開示する。交換インフラは、複数のソフトウェア構成要素の設計時協働記述を記憶するためのリポジトリと、ランタイムシステム特性の構成専用協働記述を記憶するためのディレクトリとを含む。更に、交換インフラは、構成専用協働記述に基づく情報のメッセージベース交換のために構成されたランタイムエンジンを含む。実行時、ランタイムエンジンは、メッセージを受信し、ディレクトリからの構成専用協働記述によって提供されるメッセージコンテンツ及びパラメータに基づき、対象又は要求された受信者を決定する。

Description

以下の説明は、企業システム及び関連するアーキテクチャ並びに協働ビジネスプロセス用の手法に関する。

企業は、企業情報及び企業ソフトウェアシステムの統合並びにそれらの間における協働に対する次第に増加しつつある必要性に直面している。ほとんどの現システム特性では、数多くの構成要素が、１対１の関係で他の構成要素と直接接続されており、統合機能は、アプリケーション構成要素及び個々のマッピングプログラムに物理的に組み込まれている。これらの条件下で、情報又はプロセス制御の協働的共有は、不可能でないにしろ困難である。直接接続される構成要素のインフラに対するアップグレード、変更、又は拡張は、難しくまた多くの資源を要する。

しかしながら、新しい電子的ビジネス協働は、通常、企業の境界内外にある全てのアプリケーション間の接続性を必要とする。インターネット等のネットワークは、システムが他のシステム又は個人とほとんど瞬時に通信を行う機会を提供する。かつてイントラネット及びそれらのユーザに限定されていたビジネスプロセスは、今やインターネットに移行し、ウェッブサービスの有効な要素になりつつある。ウェッブサービスは、開放型インターネット標準を通して、公表したり、発見したり、あるいは呼び出したりできるプログラム可能な自己完結型で自己説明的モジュール方式のアプリケーション機能である。

供給チェーン計画、調達、及び需要予測等のプロセスは、企業間及び地域内において自動化されており、システム間においてほんのわずかな通信コストで実現し得る。この結果を実現するために、異なる調達先からの構成要素は、理想的には、一貫したインフラに統合されるべきである。しかしながら、既存の企業ソフトウェアの総合的なシステムアップグレード又は異質なシステム特性の大規模な置き換え戦略は、費用がかかり過ぎたり、あるいはまた単に、時間及び資金的資源コストの点で不可能であったりしがちである。

技術的な接続性が、ハイパーテキスト転送プロトコル（ＨＴＴＰ）及び拡張性マークアップ言語（ＸＭＬ）などの開放型プロトコル及び標準を用いて提供される一方で、異なるビジネスのセマンティクスをマッピングする課題が残る。効率化による収益還元を将来得るために、企業は、益々、企業間又は企業内の機能を横断する新しい種類の協働ビジネスプロセスを展開する必要がある。更に、企業は、益々、バッチ処理を行う代わりに、リアルタイムでシナリオを処理する必要がある。これらの協働プロセスは、従来のプロセスより更に大幅に複雑な統合要件を有する。

本文書は、ビジネスプロセスツール及びアプリケーションの統合を支援する交換システム及び方法を開示する。

１つの側面において、異質の集まりのソフトウェア構成要素を統合するためのシステムが提供される。本システムは、多数のソフトウェア構成要素の設計時協働記述を記憶するためのリポジトリを含む。本システムは、また、ランタイムシステム特性の構成専用協働記述を記憶するためのディレクトリを含む。ランタイムシステム特性は、リポジトリに記述されたソフトウェア構成要素の少なくとも一部を含む。構成専用記述は、少なくとも部分的にリポジトリの設計時記述に基づくことができ、また、情報のメッセージベースの交換を実行する必要がある構成専用情報を追加し得る。

設計時協働記述は、ビジネスシナリオ、ビジネスプロセス、ルーティングオブジェクト、メッセージ変換マッピング、及びソフトウェア構成要素用メッセージインターフェイスを含む。構成専用協働記述は、ビジネスシナリオ、ビジネスプロセス、ルーティングオブジェクト、メッセージ変換マッピング、及びランタイムシステム特性における各ソフトウェア構成要素用メッセージインターフェイス、のランタイム記述を含む。また、システム特性ディレクトリを開示する。システム特性ディレクトリは、ソフトウェア構成要素の設計時記述並びにランタイムシステム特性の構成専用記述を含む。

また、異質の集まりのソフトウェア構成要素を統合するための方法を開示する。本方法において、複数のソフトウェア構成要素の設計時協働記述は、リポジトリに記憶される。次に、ランタイムシステム特性の構成専用協働記述は、設計時記述に基づき生成される。構成専用協働記述は、ディレクトリに記憶される。このディレクトリは、企業によって設定された１つ又は複数のビジネスプロセスに基づき、情報のメッセージベースの交換を実行するためのランタイムエンジンによってアクセス可能である。本方法において、各メッセージの受信者は、指定される必要はないが、ビジネスプロセスは、少なくとも部分的に、各メッセージのコンテンツ及びディレクトリによって提供されるパラメータに基づき実行される。

異質の集まりのソフトウェア構成要素を統合するための方法は、ＸＩを介して接続されるランタイムシステム特性におけるソフトウェア構成要素間でメッセージを交換する段階を含む。本方法には、送信アプリケーションからメッセージを受信する段階と、ディレクトリに記憶された構成専用協働記述により定義されたルーティング規則に基づき、メッセージの論理受信アプリケーションを決定する段階と、が含まれる。更に、本方法は、送信アプリケーションに対応する発信インターフェイス記述から論理受信アプリケーションに対応する着信インターフェイス記述にメッセージをマッピングする段階を含む。従って、メッセージのコンテンツ及びディレクトリによって提供されるパラメータに少なくとも部分的に基づき、受信アプリケーションに対応する物理アドレスを決定する方法が開示される。

１つ又は複数の実施例の詳細について、添付の図面及び以下の説明に記載する。他の特徴及び利点は、説明及び図面並びに請求項から明らかになるであろう。

これらの及び他の側面について、以下の図面を参照して詳細に説明する。

ここに記述されたシステム及び手法は、様々な処理構成要素間における協働処理のための交換インフラに関する。

図１は、交換ベースの統合用システム１００を示す概略ブロック図である。システム１００には、企業の内部構成要素（ＩＣ）１０２間、及びファイヤウォール１０５を介して１つ又は複数のＩＣ１０２に通信を行う外部構成要素（ＥＣ）１０４間における協働処理のための交換インフラ（ＸＩ）１１０が含まれる。ＩＣ並びにＥＣ１０２及び１０４は、ウェッブポータルサイト、購入又は販売プログラム、電子メール、ビジネス・マネジメント・プログラム、プロジェクト計画プログラム等、多数のプロセス又はサービス、及びそれらのソフトウェア及びハードウェアのいずれかを表し、好適には、ウェッブベースのアプリケーションである。各ＩＣ／ＥＣ１０２、１０４は、少なくとも多数の通信プロトコル又は標準の１つに基づき、１つ又は複数の他の構成要素と通信を行う。

ＸＩ１１０は、構成要素１０２、１０４間の協働を推進するための自己完結型でモジュール方式の交換プラットフォームである。交換インフラ１１０は、共有協働情報を記憶する中央統合リポジトリ及びディレクトリを含む。ＸＩ１１０は、拡張性マークアップ言語（ＸＭＬ）、ウェッブサービス記述言語（ＷＳＤＬ）、及び簡易オブジェクト・アクセス・プロトコル（ＳＯＡＰ）など様々な標準マークアップ言語等の開放型標準をサポートし、構成要素１０２、１０４に対して、また、異質の構成要素インターフェイス間のメッセージベース通信に対して、概念的技術インターフェイスを提供する。ＸＩ１１０の自己完結型でモジュール方式の機能は、標準のインターネット技術に基づき、１つ又は複数のウェッブサービスとして提供でき、また従って、開放型標準を用いて、構成要素１０２、１０４からなるネットワーク内において、公表、発見、及びアクセスし得る。

図２は、ＸＩ１１０のブロック図である。一般的に、ＸＩ１１０は、統合リポジトリ２０２、統合ディレクトリ２０４、システム特性ディレクトリ２０３、及び統合サーバ２０６を含む。統合リポジトリ２０２は、ＸＩ１１０を用いて互いに協働するソフトウェア構成要素に関する設計時協働情報を取り込む。統合ディレクトリ２０４は、ランタイム協働記述を取り込むが、これには、実際の構成要素のインストール及び外部構成要素の接続性記述を記憶する段階と、これにアクセスする段階とが含まれ、これらは全て、ランタイムシステム特性の共有ビジネスセマンティクスを表す。ソフトウェア構成要素の設計時及びランタイム記述は、システム特性ディレクトリ２０３に記憶される。実行時、統合サーバ２０６は、統合ディレクトリ２０４からの共有ビジネスセマンティクスを用いて、ランタイムシステム特性における動作中のソフトウェア構成要素間で協働処理及びメッセージ交換を実行する。

統合サーバ２０６には、サービスを接続するために、また、価値連鎖図のプロセスフローを管理するために、実行時、メッセージング及びビジネスプロセス制御を行うランタイムエンジン２１４が含まれる。また、統合サーバ２０６は、通常、アプリケーション専用の実装が必要な他の交換サービス２１６を含む。交換サービス２１６は、解析及びマスタデータサービスを含む。交換サービス２１６は、システム特性内における全てのビジネス文書にアクセスし得る。各企業の場合、ウェッブベースのアプリケーションを含み、自社開発及びサードパーティの構成要素が、多数のアダプタ２０９の１つを介して、統合サーバと通信を行う。

統合リポジトリ２０２及び統合ディレクトリ２０４と同様に、統合サーバ２０６は、任意の既設のシステムインフラ内に配置するように構成されている。統合サーバ２０６は、ランタイム協働環境において、サポートされるシステム特性の統合ディレクトリ２０４の共有協働記述を適用する専用サーバであってよい。ランタイムワークベンチ２０８は、組織又はユーザがＸＩ１１０の動作を高い信頼性で効率良く管理できるようにする監視アプリケーションを含む。

図３は、ＸＩ１１０を含むシステム特性２００のブロック図である。ＸＩ１１０は、統合サーバ２０６と、自社開発アプリケーション２１１、ウェッブベースのサービス２１３、及びサードパーティのアプリケーション２１５との間の接続を提供するように構成された様々なアダプタ２０９を含む。また、ＸＩ１１０は、例えば、ジャバ及び高度ビジネスアプリケーションプログラミング（ＡＢＡＰ）言語等のウェッブ専用プログラミング言語を用いて、標準のコンピュータ処理プラットフォームによりプログラムされたウェッブベースアプリケーションを提供するウェッブアプリケーションサーバ２１０を含み得る。また、ウェッブアプリケーションサーバ２１０は、ジャバアプリケーション２２０、ＡＢＡＰアプリケーション２２２、及び／又は他のソフトウェア構成要素等のウェッブベースアプリケーション間でメッセージング及びビジネスプロセス制御を行うためのランタイムエンジン２１４を含む。

ＸＩ１１０を用いて、プロキシを採用している任意のアプリケーションに対して新しいインターフェイスを定義し得る。プロキシは、アプリケーションからの通信技術スタックを非表示にし、また、そのアプリケーションにプログラミング言語依存のインターフェイスを提供する。従って、このアプリケーションのインターフェイスは、ＸＩ１１０でローカルに実現でき、また、プロキシは、全ての通信ステップを実現し、また、ＸＩ１１０から新しいインターフェイスへの下位レベルの通信を実施する必要性を無くする。

統合リポジトリ２０２に記憶された情報に基づくプロキシ発生器２１８は、オンデマンドでプロキシを生成し得る。プロキシ発生器２１８は、ＷＳＤＬ又はＸＭＬスキーマ等の標準ウェッブベース言語を介して記述されたインターフェイス情報を用いて、アプリケーション開発システムにおいて、プラットフォーム依存及びプログラミング言語依存のコードを生成する。通信ロジックは、ジャバ、ＡＢＡＰ、及びウェッブベースアプリケーション２１３用の．ＮＥＴ等、それぞれの開発プラットフォームのインターフェイス記述を表すプロキシに基づき実現し得る。プロキシは、発信側では、プラットフォーム専用データタイプをＸＭＬに変換し、着信側では、その逆の変換を行い、構成要素専用ローカルランタイムエンジン２１４へのアクセスを提供する。発信側において、プロキシは、完全に生成される。発信プロキシは、アプリケーション開発者によって提供されるサービス呼び出しを介して、呼び出し得る。着信側では、受信アプリケーションによって実現されるように、プロキシの骨組みのみを生成する必要がある。着信プロキシは、アプリケーション開発者によって提供されるであろうアプリケーションのサービス実施が必要である。

次に、統合リポジトリ２０２、システム特性ディレクトリ２０３及び統合ディレクトリ２０４の構造及び動作について、更に詳細に説明する。図４を参照すると、統合リポジトリ２０２は、ビジネスプロセス２３２、ルーティングオブジェクト２３４、マッピング２３６、及びインターフェイス２３８の記述を含み、これらは全て、１つ又は複数のビジネスシナリオ２３０に基づき定義される。統合リポジトリ２０２のビジネスシナリオ２３０は、アプリケーション構成要素又はビジネスエンティティ間のメッセージベース対話を記述し構成する。ユーザは、ＸＩ１１０の迅速な構成のための最適な手法として、統合リポジトリ２０２に記述された１つ又は複数のビジネスシナリオ２３０を選択し得る。

ビジネスプロセス２３２は、ビジネスプロセスエンジン（図示せず）を用いて実行される拡張性複合ウェッブサービスである。各ビジネスプロセス２３２は、統合リポジトリ２０２において一元的にモデル化し得る。企業又はユーザは、そのビジネスニーズに基づき、技術的な実現とは独立に、各ビジネスプロセス２３２を設計する。幾つかのカテゴリのビジネスプロセス２３２テンプレート、即ち、例えば、汎用ビジネスプロセス、業界専用のプロセス、及び企業専用のプロセスが存在し得る。各ビジネスプロセス２３２は、必要とされるまた相互接続しなければならないウェッブサービスを識別する。１つの具体的な実施例において、ビジネスプロセス２３２は、グラフィックインターフェイスを用いて定義され、そして、例えば、ビジネスプロセスモデル化言語（ＢＰＭＬ）等の標準フォーマットに記憶される。次に、ビジネスプロセスエンジンは、これらのモデルを解釈して実行し、ビジネスプロセス２３２に対応するソフトウェア構成要素間の協働を推進する。

ルーティングオブジェクト２３４は、協働処理時、ソフトウェア構成要素及びビジネスパートナ間で配信しなければならないメッセージの潜在的な受信者を決定する予め定義した基準である。ルーティングオブジェクト２３４に関する情報は、メッセージ全体を処理して配信する前に受信アプリケーション（１つ又は複数）を決定する際に用いられ、また、異なるインターフェイス間で一定の基準を再利用し、これらのインターフェイスに関する更に理論的な見解を提供できるように用いられる。マッピング２３６は、要求され得る統合リポジトリ２０２におけるメッセージインターフェイス２３８、メッセージタイプ、又はデータタイプ間の変換を定義する。これらの変換は、構造的な変換及び値のマッピングを含む。構造的な変換は、統語的に又は構造的に異なるが意味的に等価なタイプに用いられ、他方、値のマッピングは、オブジェクトが多数のシステムの異なるキーによって識別される場合に用いられる。具体的な実施例において、グラフィックマッピングツールが、マッピングを支援するためにユーザに提供され、データ変換は、拡張性スタイルシート言語変換（ＸＳＬＴ）、ジャバコード、又はグラフィックマッピングツールによって生成し得る他の任意のコードに基づく。

統合リポジトリ２０２は、インターフェイス開発、記憶、及び検索用入り口の中心点である。この目的のために、インターフェイスリポジトリ２０２には、その環境にある全ソフトウェア構成要素の全メッセージインターフェイスのインターフェイス記述を表す１つ又は複数のインターフェイス２３８が含まれる。インターフェイスリポジトリ２０２は、ある環境において実際に用いられるか否かに関わらず、その環境において用いられる可能性があるインターフェイスさえ提供する。従って、インターフェイス２３８は、任意の技術を用いて任意の構成要素上に実現し得る。１つの実施例において、インターフェイス２３８は、ＷＳＤＬに基づき、また、他の数多くの実施例が可能である。メッセージインターフェイスは、メッセージタイプで構成され、翻って、これらは、データタイプで構成される。データタイプは、ＸＭＬスキーマ定義言語（ＸＳＤＬ）を用いて記述し得る。データタイプの例は、“アドレス”であり、これは、メッセージタイプ“ＣｒｅａｔｅＰＯ”に用いられ、また、メッセージタイプ“ＣｒｅａｔｅＩｎｖｏｉｃｅ”に再利用し得る。インターフェイス２３８は、着信及び発信又は同期又は非同期等、任意の分類に基づき配置し得る。

統合ディレクトリ２０４は、システムにインストールされた状態で各構成要素の構成を記述する詳細な協働情報を含む。即ち、統合ディレクトリ２０４は、統合リポジトリ２０２における特性に依存しない記述に対して、具体的なシステム特性に依存する。統合ディレクトリ２０４は、その構成に特有な統合リポジトリ２０２からの情報を列挙し、また、統合リポジトリ２０２からの生成コンテンツを用いて自動的に、又は、グラフィックツールを用いて手作業で書き込み得る。ある実施例において、統合ディレクトリ２０４は、ジャバプラットフォーム上に構築され、そのコンテンツは、開放型インターネット標準を用いて、ＸＭＬを介して表現される。統合リポジトリ２０２と同様に、統合ディレクトリ２０４は、サードパーティ及びパートナ協働情報に対して開放的である。統合リポジトリ２０２は、統合ディレクトリ２０４又はいずれか動作中のランタイム協働プロセスに影響を及ぼすことなくアップグレードし得る。そして、ユーザは、所定の自動アップグレードとして又はグラフィックツールを介した手作業によって、どちらの変更を統合ディレクトリ２０４に転送すべきかを判断する。

統合ディレクトリ２０４は、ビジネスシナリオ２５０、ビジネスプロセス２５２、構成されたルーティング規則２５４、及び実行可能なマッピング２５６の記述を含む。また、統合ディレクトリ２０４は、動作中のウェッブサービス２５８及び動作中のビジネスパートナ２６０についての記述を含む。統合ディレクトリ２０４のビジネスシナリオ２５０は、具体的な実施例に関連する実際の構成の観点でインターフェイス及びマッピング２５６間の対話の全体的概観を表す。ビジネスプロセス２５２は、全ての動作中のビジネスプロセスの実行可能な記述を表す。

ルーティング規則２５４は、ビジネスレベルでのメッセージの受信者を決定する。１つの具体的な実施例において、メッセージのコンテンツは、ルーティング規則２５４として用いられる。他のパラメータもまた用い得る。関連する入力パラメータは、送信者、送信者メッセージタイプ、受信者を識別するメッセージ、及び受信者メッセージタイプを含む。ルーティング規則２５４は、ＸＭＬ経路言語を用いて（ＸＰａｔｈ、即ち、グラフィックツールを用いることによって）、宣言文として記述したり、又は、ジャバでコード化したりできる。ルーティング規則２５４に関する情報は、実行時、ランタイムエンジン２１４（図５参照）によってアクセスする。

ルーティング規則２５４は、論理用語を用いて、送信者及び受信者を記述し、それらを統合ディレクトリ２０４に記述されたウェッブサービス２５８によって提供される物理アドレスから分離し得る。従って、物理アドレスは、ビジネス向けのコンテンツを変えることなく、変更し得る。統合ディレクトリ２０４のマッピング２５６は、全てのサポートされたマッピングを含む統合リポジトリマッピング２３６とは対照的に、ランタイムシステム特性に必要なマッピングを表す。しかしながら、新しいシーケンスのマッピング等、幾つかの新しい項目が統合ディレクトリ２０４のみに入力され、例えば、マッピングのために追加のウェッブサービスに対応し得る。ランタイムエンジン２１４は、実行時、統合ディレクトリマッピング２５６にアクセスする。

ウェッブサービス２５８は、ビジネスパートナによってサポートされた動作中のウェッブサービスと同様に現システム特性の実装したインターフェイスを記述する。このように、ウェッブサービス情報は、ＵＤＤＩ対応のディレクトリと交換したり、又は、手作業で追加したりできる。また、各ウェッブサービス記述は、物理アドレス指定細目、アクセス情報、及びユニフォーム・リソース・ロケータ（ＵＲＬ）、プロトコル、及びセキュリティ情報等、他の特別な属性を提供する。１つの実施例において、ウェッブサービス２５８は、ＷＳＤＬに記述され、また、ＳＯＡＰ及びｅｂＸＭＬが、メッセージングプロトコルに用い得る。ランタイムエンジン２１４は、また、実行時、ウェッブサービス２５８に関する情報にアクセスする。

ビジネスパートナ２６２は、名前、アドレス、及びＵＲＬ等、企業のビジネスパートナ用の通常情報を定義するが、更に詳細で複雑な情報も含み得る。例えば、ビジネスパートナ２６２は、企業のパートナが直接受信して処理し得るメッセージフォーマットの記述もしくは安全な通信に用いられるセキュリティプロトコルの記述、又は、取引条件でさえ含み得る。ビジネスパートナ２６２に記憶される情報の種類は、ＸＩ１１０を用いて、その企業の企業特有の判断によって決定し得る。

統合リポジトリ２０２及び統合ディレクトリ２０４は、システム特性ディレクトリ２０３に記憶されるソフトウェア構成要素記述を用いる。システム特性ディレクトリ２０３は、統合リポジトリ２０２用の構成要素２４０の設計時記述、及び実行時における統合ディレクトリ２０４用のシステム特性２６２の構成専用協働記述を含む。構成要素２４０は、アプリケーション構成要素に関する情報並びにそれらの互いに対する依存性に関する情報を含む構成要素記述を表す。具体的な実施例において、構成要素記述は、分散型マネジメント分科会（ＤＭＴＦ）の標準共通情報モデルに基づく。統合リポジトリ２０２は、設計時情報を含むことから、実際のインストールとは無関係な構成要素タイプ情報だけが、構成要素２４０として記憶される。構成要素記述は、ＡＰＩを用いて、又はグラフィックユーザインターフェイスを用いて対話によって追加し得る。

システム特性２６２は、ＸＩ１１０を用いて、ランタイムシステム特性を能動的に記述する。システム特性２６２は、どの構成要素がインストールされ、また、システム内の或る装置上で利用可能であるか、どのインスタンス又はクライアントが選択されたか、インストールされた構成要素に関する他の情報、他のシステム特性等を記述する。また、システム特性２６０は、開放型アーキテクチャに基づき、また、ＣＩＭ等の広く受け入れられた標準に準拠し得る。このように、数多くの自社開発及びサードパーティの構成要素は、インストールされる際、統合ディレクトリシステム特性２６０にそれら自体を自動的に登録するように構成し得る。システム特性２６０へのアクセスインターフェイスは、ウェッブベースの企業マネジメント（ＷＢＥＭ）及びＳＯＡＰ標準等の開放型標準にも基づくこともできる。

次に、図５の統合ディレクトリ２０４、システム特性ディレクトリ２０３及びランタイムエンジン２１４の具体的な図を参照して、協働ビジネスプロセスを実行するための協働ランタイム環境２７０について、説明する。協働ランタイム環境２７０は、接続されたソフトウェア構成要素及びビジネスパートナ間におけるメッセージの交換に関連する全てのランタイム構成要素を統合する。協働ランタイム環境２７０は、統合サーバ２０６又はウェッブアプリケーションサーバ２１０によって実行され、これらは、各々、統合ディレクトリ２０４及びシステム特性ディレクトリ２０３によって提供された情報資源によるランタイムエンジン２１４のインスタンスを含み得る。

ランタイムエンジン２１４は、様々な内部接続された構成要素間で全てのメッセージを交換するが、２つの層、即ち、統合層２７２及びメッセージング・トランスポート層２８０を含む。統合層２７２には、モデル化したビジネスプロセスを集中的に実行するためのビジネスプロセスエンジン２７４、論理ルーティングサービス２７６及びマッピングサービス２７８が含まれる。メッセージング・トランスポート層２８０は、好適には、ＨＴＴＰを介して、物理アドレス決定サービス２８２、メッセージング及び待ち行列サービス２８４、及びトランスポートサービス２８６を提供する。統合サーバ２０６における他の交換サービス２１６は、ランタイムエンジン２１４を補完し得る。

実行時、ビジネスプロセス２５２は、ウェッブサービス２５８に記述されたそれぞれのウェッブサービスを実行するビジネスプロセスエンジン２７４によって、ビジネスプロセスモデルに基づくそれらの位置とは独立に、インスタンス化され、実行される。従って、企業は、幾つかの方法でビジネスプロセス全体を監視及び制御し得る。即ち、与えられたプロセスインスタンスの実際のステップ及び無事に完了したウェッブサービスを追跡することによって、イベントに対処することによって、また、ポータルインフラのワークセット及び警告マネジメントを統合することによって、監視及び制御し得る。ビジネスプロセスエンジン２７４は、実行されるビジネスプロセスのセマンティクスとは独立しており、また、技術的な構成要素とのそれらの対話について、ビジネスプロセス２５２の仲介役及びまとめ役として構成されている。

図６は、アプリケーション間でメッセージを交換するためのプロセスにおけるランタイムエンジン２１４の幾つかの機能を示すブロック図である。送信アプリケーション３０３は、送信構成要素システム３０２に常駐しており、これは、送信アプリケーション３０３のハードウェア及びソフトウェアプラットフォームを表す。１つ又は複数の受信アプリケーション３０５は、各々、受信構成要素システム３０４に常駐する。メッセージ３１０用の通信経路は、送信構成要素システム３０２からランタイムエンジン２１４及びアダプタ３０９を介して受信構成要素システム３０４への発信インターフェイスにおいて発信プロキシ３０７を含み得る。また、受信構成要素システム３０４は、アダプタよりむしろ着信プロキシ３１１を利用し得る。図示した受信構成要素システム３０４の構成及び接続性は、例示のみに過ぎず、このような構成及び接続性は、任意の数の形態を取り得ることに留意されたい。図示した例は、非同期及び同期通信双方を示す。同期通信では、ルーティング及び物理アドレス決定は、応答が、既知の送信者に伝達されるため、要求に対してのみ必要である。

また、図５を参照して、任意のメッセージに対して、論理ルーティングサービス２７６は、送信アプリケーション及びメッセージインターフェイスに関する情報を用いて、３１２に示すように、対応するルーティング規則を評価することによって、受信者及び要求されたインターフェイスを決定する。ルーティング規則は、統合ディレクトリ２０４によって提供されるランタイムシステム特性の構成専用記述の一部であり、Ｘｐａｔｈ表現又はジャバコードとして実現し得る。マッピングサービス２７８は、３１４において、受信者及び受信者インターフェイスと同様に、メッセージ、送信者、及び送信者インターフェイスに依存する必要な変換を決定する。非同期通信の場合、入力、出力、及び誤りメッセージを適切に変換するためにメッセージ指示も決定される。

要求されたマッピングを統合ディレクトリ２０４から検索した後、マッピングサービス２７８は、送信されたメッセージに合わせて、ＸＳＬＴマッピング又はジャバコード（又は、与えられたシーケンスにおける任意の組み合わせ）のいずれかを実行し得る。統合層の下では、メッセージング、待ち行列、及びトランスポートサービス２８４は、対象の又は要求された受信者（単数又は複数）にメッセージを移動する。メッセージが各受信者によって予想されるフォーマットに変換された後、３１６において、要求された受信者サービスの物理アドレス及び他の関連する属性が、統合ディレクトリ２０４から検索され、メッセージにマッピングされる。

メッセージング・待ち行列サービス２８４における待ち行列エンジンは、着信、発信、誤り、及び進行中のメッセージを永続的に記憶する。ランタイムエンジン２１４のメッセージング層は、アプリケーション構成要素の物理的な切り離しのための待ち行列機能を提供し、また、メッセージが、プロトコル（即ち、“ＥＯプロトコル”）に基づき一度厳密に出力されることを保証する。トランスポートサービス２８６により、ランタイムエンジン２１４は、クライアント及びサーバの双方として機能し得る。トランスポートサービス２８６は、発信通信を可能にするクライアントと、着信する文書を受領することによって着信通信を処理するサーバと、を実現する。追加のサーバ機能は、用いられるトランスポートプロトコル上でポーリングをサポートすることによって、受信者がサーバを有さない状況に対応し得る。好適には、ＨＴＴＰを用いるが、他のトランスポートプロトコルを用いてもよい。

図７は、ＸＩを利用して、異質な集まりのソフトウェア構成要素を統合するための方法を示す。４０２において、ソフトウェア構成要素の設計時協働記述が、リポジトリに取り込まれる。設計時協働記述は、ビジネスシナリオ、ビジネスプロセス、ルーティングオブジェクト、マッピング、及び情報のメッセージベース交換のためにソフトウェア構成要素によって用いられるインターフェイスの記述を含む。ソフトウェア構成要素自体の設計時記述は、システム特性ディレクトリに記憶されリポジトリによってアクセスされる。

４０４において、構成専用協働記述は、設計時協働記述に基づき生成される。構成専用協働記述は、構成されたビジネスプロセス、構成されたルーティング規則、動作中のウェッブサービス、実行可能なマッピング、及び動作中のビジネスパートナの記述を含む。構成専用協働記述は、実行時の特定のシステム特性に関し、４０６において、ディレクトリに記憶される。ディレクトリに一度記憶されると、構成専用協働記述は、４０８において、ランタイムエンジンがアクセス可能であり、４１０に示すように、ランタイムシステム特性におけるソフトウェア構成要素間での情報のメッセージベース交換に用いられる。

図８は、ディレクトリからの情報を用いてランタイムエンジンによって実行されるメッセージ交換プロセス４１０の更に詳細を提供する。４２０において、メッセージは、ＸＩで送信アプリケーションから受信される。メッセージは、受信者を規定してもしなくてもよいが、むしろ、メッセージのコンテンツを用いて、どのソフトウェア構成要素、及びそれら構成要素内のアプリケーションが、そのメッセージを受け取って、特定のビジネスプロセスをなし遂げるべきかを決定し得る。受信者の物理アドレスが、メッセージにまだ含まれていない場合、４２２において、ランタイムエンジンを介したＸＩは、ディレクトリからの構成専用協働記述に基づき、１つ又は複数の論理受信アプリケーションを決定する。構成専用協働記述には、受信アプリケーションの着信インターフェイス記述及び送信アプリケーションの発信インターフェイス記述を含むメッセージインターフェイス記述が含まれる。

４２４において、ランタイムエンジンは、１つ又は複数の論理受信アプリケーションに対応する１つ又は複数の着信インターフェイス記述にメッセージをマッピングする。従って、１つ又は複数の論理受信アプリケーションの物理アドレスは、４２６において決定される。次に、ランタイムエンジンは、メッセージに物理アドレスを付加して、４２８に示すように、受信アプリケーションに対応する各決定された物理アドレスにメッセージを送信する。このようにして、ソフトウェア構成要素が同じ通信プロトコル又は標準を共有するかしないかに関わらず、任意のフォーマット、プロトコル又は標準のメッセージが、ＸＩに接続されたソフトウェア構成要素間で交換し得る。

幾つかの実施形態について詳細に上述したが、他の変形例も可能である。他の実施形態は、以下の請求項の範囲内にあり得る。

統合されたメッセージベース協働用交換システムを示す概略ブロック図。 交換インフラを示す詳細ブロック図。 交換インフラを含むシステム特性を示す詳細ブロック図。 統合リポジトリ、統合ディレクトリ、及びシステム特性ディレクトリを示す詳細ブロック図。 ランタイムエンジン及び統合ディレクトリの情報資源のランタイム環境を示す詳細ブロック図。 ２つのアプリケーション間で単一のメッセージを伝達するためのプロセスを示すブロック図。 交換インフラを介して異質の集まりのソフトウェア構成要素を統合するための方法を示すフローチャート。 交換インフラのランタイムエンジンによってを実行されるメッセージを交換するための方法を示すフローチャート。

符号の説明

１１０・・・交換インフラ（ＸＩ）、２０２・・・統合リポジトリ、２０３・・・システム特性ディレクトリ、２０４・・・統合ディレクトリ、２０６・・・統合サーバ、２０８・・・ランタイムワークベンチ、２０９・・・アダプタ、２１４・・・ランタイムエンジン、２１６・・・交換サービス。

Claims (20)

1. 異質の集まりのソフトウェア構成要素を統合するためのシステムであって、
   複数のソフトウェア構成要素の設計時協働記述を記憶するためのリポジトリと、
   前記複数のソフトウェア構成要素の少なくとも一部を含むランタイムシステム特性の構成専用協働記述を記憶するためのディレクトリと、
   が含まれるシステム。
2. 請求項１に記載のシステムであって、
   前記設計時協働記述には、ビジネスシナリオ、ビジネスプロセス、ルーティングオブジェクト、メッセージ変換マッピング、及び前記複数のソフトウェア構成要素用メッセージインターフェイスが含まれるシステム。
3. 請求項２に記載のシステムであって、
   前記構成専用協働記述には、前記ビジネスシナリオ、ビジネスプロセス、ルーティングオブジェクト、メッセージ変換マッピング、及び前記複数のソフトウェア構成要素の前記少なくとも一部用のメッセージインターフェイス、のランタイム記述が含まれるシステム。
4. 請求項１に記載のシステムであって、更に、
   各ソフトウェア構成要素の設計時記述を記憶するための、また、前記ランタイムシステム特性における各ソフトウェア構成要素の構成専用構成要素記述を記憶するためのシステム特性ディレクトリが含まれるシステム。
5. 請求項１に記載のシステムであって、更に、
   前記構成専用協働記述に基づき、前記ランタイムシステム特性において、メッセージベースの協働を実行するためのランタイムエンジンが含まれるシステム。
6. 請求項５に記載のシステムであって、前記ランタイムエンジンは、
   送信アプリケーションからメッセージを受信し、
   前記ディレクトリからアクセスされたメッセージインターフェイス記述により定義されたルーティング規則に基づき、前記メッセージの論理受信アプリケーションを決定し、
   前記メッセージを前記送信アプリケーションに対応する発信インターフェイス記述から前記受信アプリケーションに対応する着信インターフェイス記述にマッピングする、ように構成されているシステム。
7. 請求項６に記載のシステムであって、前記ランタイムエンジンは、更に、
   前記受信者アプリケーションに対応する物理アドレスを決定し、
   前記メッセージを前記受信者アプリケーションに対応する前記物理アドレスに送信する、ように構成されているシステム。
8. 請求項５に記載のシステムであって、前記ランタイムエンジンは、ネットワークを介して、前記複数のソフトウェア構成要素の少なくとも前記一部と通信を行っているサーバ上に記憶され、また、前記サーバによって実行されるシステム。
9. 請求項１に記載のシステムであって、前記リポジトリは、更に、
   設計時協働記述を受信するためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を含むシステム。
10. 請求項１に記載のシステムであって、前記リポジトリは、更に、
    設計時協働記述を受信するためのグラフィックユーザインターフェイス（ＧＵＩ）を含むシステム。
11. 異質の集まりのソフトウェア構成要素を統合するための方法であって、
    複数のソフトウェア構成要素の設計時協働記述をリポジトリに記憶する段階と、
    前記複数のソフトウェア構成要素の少なくとも一部を含むランタイムシステム特性の構成専用協働記述を生成する段階と、
    前記構成専用協働記述をディレクトリに記憶する段階と、
    が含まれる方法。
12. 請求項１１に記載の方法であって、更に、
    前記ディレクトリから前記構成専用協働記述にアクセスする段階と、
    前記構成専用協働記述に基づき、前記ランタイムシステム特性においてメッセージを交換する段階と、
    が含まれる方法。
13. 請求項１２に記載の方法であって、
    前記構成専用協働記述は、メッセージインターフェイス記述を含み、また、
    前記メッセージインターフェイス記述は、前記ランタイムシステム特性におけるソフトウェア構成要素用の着信及び発信インターフェイス記述を含む方法。
14. 請求項１３に記載の方法であって、メッセージを交換する段階には、更に、
    送信アプリケーションからメッセージを受信する段階と、
    前記ディレクトリからアクセスされた前記メッセージインターフェイス記述により定義されたルーティング規則に基づき、前記メッセージの論理受信アプリケーションを決定する段階と、
    前記メッセージを前記送信アプリケーションに対応する発信インターフェイス記述から前記受信アプリケーションに対応する着信インターフェイス記述にマッピングする段階と、
    が含まれる方法。
15. 請求項１４に記載の方法であって、更に、
    前記受信アプリケーションに対応する物理アドレスを決定する段階と、
    前記メッセージを前記受信アプリケーションに対応する前記物理アドレスに送信する段階と、が含まれる方法。
16. 異質の集まりのソフトウェア構成要素を統合するための方法であって、
    送信アプリケーションからメッセージを受信する段階と、
    ディレクトリに記憶された構成専用協働記述により定義されたルーティング規則に基づき、前記メッセージの論理受信アプリケーションを決定する段階と、が含まれる方法。
17. 請求項１６に記載の方法であって、
    前記構成専用協働記述は、ランタイムシステム特性におけるソフトウェア構成要素のメッセージインターフェイス記述を含む方法。
18. 請求項１７に記載の方法であって、
    前記メッセージインターフェイス記述は、前記ランタイムシステム特性における各アプリケーションの発信インターフェイス記述及び着信インターフェイス記述を含む方法。
19. 請求項１８に記載の方法であって、更に、
    前記メッセージを前記送信アプリケーションに対応する発信インターフェイス記述から前記論理受信アプリケーションに対応する着信インターフェイス記述にマッピングして、受信アプリケーションに対応する物理アドレスを決定する段階が含まれる方法。
20. 請求項１６に記載の方法であって、更に、
    前記メッセージを前記受信アプリケーションに対応する前記物理アドレスに送信する段階が含まれる方法。
    
    
    

Images