JP2004280809A - 自動化されたビジネスソフトウェアアプリケーション統合 - Google Patents

自動化されたビジネスソフトウェアアプリケーション統合 Download PDF

Info

Publication number
JP2004280809A
JP2004280809A JP2004052375A JP2004052375A JP2004280809A JP 2004280809 A JP2004280809 A JP 2004280809A JP 2004052375 A JP2004052375 A JP 2004052375A JP 2004052375 A JP2004052375 A JP 2004052375A JP 2004280809 A JP2004280809 A JP 2004280809A
Authority
JP
Japan
Prior art keywords
software
business
component
bus
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2004052375A
Other languages
English (en)
Inventor
Daniel J Rogers
ジェイ．ロジャース ダニエル
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JP2004280809A publication Critical patent/JP2004280809A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • G06Q40/123—Tax preparation or submission

Abstract

【課題】 自動ビジネスソフトウェアアプリケーションを提供すること。
【解決手段】 オブジェクト、アクティビティを含むビジネスの特徴は、包括的な標準のやり方で分類され、記述される。ビジネスソフトウェア構成要素をインストールすると、探索マネージャは、標準的な分類に従ってソフトウェアを記載した情報に基づいてソフトウェアの機能および要件を識別する。ソフトウェア構成要素は、モデル駆動式バスの１つまたは複数の役割に選択的にバインドされる。一部の態様では、標準的なソフトウェアアダプタによって、従来技術のソフトウェアシステムとともに本発明の実施形態を容易に使用することが可能になる。追加のソフトウェア層およびオーバーヘッドによって、複数のソフトウェア構成要素の管理および操作が容易になる。
【選択図】 図４

Description

本発明は、ビジネスソフトウェアソリューションに関する。より詳細には、本発明は、規範的な分類（ｐｒｅｓｃｒｉｐｔｉｖｅ ｔａｘｏｎｏｍｉｅｓ）、データモデル、およびスキーマを適用することによってビジネスソフトウェアアプリケーションを自動的に統合することに関する。
統合ビジネスソフトウェアソリューションは一般に、ビジネスセグメントをサポートし、企業のハブスポークネットワークと対話する複数の機能製品を含む。こうした製品には、金融情報、人材マネジメント、カスタマリレーションシップマネジメント、プロフェッショナルサービスオートメーション、配送、サプライチェーンマネジメントなどに関連するソフトウェアアプリケーションがある。
個々のビジネスソフトウェアソリューションは、一般に、ソフトウェアを個々のビジネスアプリケーション向けにカスタマイズできるようにするためにアプリケーション開発環境を提供するソフトウェアベンダによって普通提供される。従来、こうしたビジネスソフトウェアソリューションは、それぞれのデータベース、データモデル、オートメーションインターフェイス、画面技術、画面、およびカスタマイズツールについて完備していたという点で、相対的にスタンドアロン製品として設計されていた。したがって、こうしたソリューションのユーザは、ベンダから所与のソリューションを購入し、特定のビジネス要件に合わせてソリューションをカスタマイズし、カスタマイズされたソリューションをエンドユーザに提供していた。ビジネスソリューションの例には、Ｓｏｌｏｍｏｎ、Ａｘａｐｔａ、Ｎａｖｉｓｉｏｎなどの商品名で販売されているソフトウェアシステムがある。これらはすべて、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能である。
所与の顧客のニーズが変わるにつれて、顧客は、各自のビジネスソリューションにさらに機能を追加することを望む可能性がある。これは一般に、こうした特徴を提供できる新しいビジネスソリューションを購入する、または古いビジネスソリューションと連携するように構成できるアドオンビジネスソリューションを購入することによって行われていた。一般に、相互運用するように設計されていない個別の２つのソフトウェアシステムを互いに連動させて使用するときはいつでも問題が生じる。この問題によって、１つのソフトウェアシステムを他のソフトウェアシステムと通信できるようにするカスタマイズされたインターフェイスアダプタソフトウェアを生成することができる一産業が生み出された。一般にこうしたアダプタは、ミドルウェアとして知られるソフトウェアの一例である。ミドルウェアの必要性、およびソフトウェアシステムとビジネス環境の個々の組合せに焦点を絞る程度によって、一般に全システム実装コストが大幅に増加した。というのは、高度に熟練したソフトウェア開発エンジニアを比較的長時間必要とするからである。ミドルウェアの設計および実装は、ビジネスソフトウェアシステムと対話するための任意の数の既知の方法および技術を含み得る。これらは、キー入力、スクリーンキャプチャ分析、ソフトウェアシステムの個々のデータベースとの対話、様々なソフトウェアシステムのソースコードの変更のような簡単な技術、または１つのアプリケーションから出力を受信し、その出力を第２のアプリケーションに適した入力に変換し、その入力を第２のアプリケーションに供給するアダプタアプリケーションを単に提供することを含み得る。
企業が変化するビジネスニーズに各アプリケーションを適合させる別の方法には、企業が有するアプリケーションへのカスタマイズを含む。新規購入であろうと、付加的な購入であろうと、上記のニーズを満たすために新しいアプリケーションを調達したときに、しばしばカスタマイズが適用される。ビジネスソフトウェアベンダが直面する問題は、カスタマイズ可能なアプリケーションに関するこのエンドカスタマの要件に対応することである。所与のシステムをカスタマイズできるようにするために従来使用されている異なるいくつかの技術がある。これらにはソースコードカスタマイズ手法、統合ツールベース手法などがあり、これらによってエンドカスタマはフィールドをテーブルおよびフォーム自体に追加することができる。上記の各技術では、一般に、まず第一にアプリケーションの開発コストを増加させる、またはカスタマイズ開発の負担をエンドカスタマにかけることによって全システムコストが増加する。一例のソースコード変更では、顧客に製品のソースコードのコピーを提供することを伴う。したがって、よく訓練されている専門家は、アプリケーションのかなりの部分を変更することができる。こうした変更は、実質的に変更されたソースコード製品の一部であるため、まるで製品の一部であるかのように見えるようにすることができる。
しかし、ソースコード変更には、かなりの欠点が伴う。例えば、ソースコード変更は、製品を使用する前に多額の金額がかかる。というのは、ユーザまたは顧客は、しばしば製品をどのように構築するかのニュアンスを特に学んだ費用のかかるコンサルタントおよび開発者を雇う必要があるからである。次いでユーザは、問題を予測するリスクに耐える必要がある。これは非常に困難で不正確なタスクである。これらの問題を克服し、これらに耐えた場合でさえ、結局はソースコードが変更されることになる。変更されたアプリケーションの元のソースコードの製造元がこうしたバグ修正、更新、および新しいバージョンなど追加のソフトウェアを出荷したとき、顧客は、これらの変更を製造元によって出荷された新しいソースコードにマージするために、再度訓練された（かつ望ましくは元の変更を加えたのと同じ）エンジニアまたは開発者を雇うこと、および新しく変更されたソースコードに問題が生じたときに問題を１つずつ解決することを余儀なくされる。あるいは、ユーザは単に、ユーザの業務に利益をもたらし得るバグ修正および新しい機能なしで済ませる可能性がある。
ミドルウェアとともに動作して個別のビジネスソフトウェアソリューションの仲介をする個々のソフトウェアアダプタの作成に関しても、ソースコード変更に関して上述したすべての問題が同様に存在している。アダプタは一般に、顧客ＩＤ番号など第１のソフトウェアシステムからの所与の出力を第２のシステムで使用可能な入力に変換するように構成されている。例えば、１つのシステムの顧客ＩＤフィールドは、データを第２のシステムにインポートするために文字列から長整数型に変更する必要がある。顧客ＩＤ番号文字列を１文字の接頭語で埋めるというほど簡単な第１のシステムへの変更では、接頭語は変換できないため、アプリケーション統合アダプタが機能しなくなるおそれがある。
データ変換結果に基づいているほとんどの形態のミドルウェアおよび／またはアダプタは、相対的に不安定なコードおよび／または連携したソフトウェア構成要素の組をもたらす。アダプタベースの統合手法の脆弱な性質によって、重要なソフトウェアの更新を統合された１組のソフトウェアの任意の構成要素に適用するという決定が複雑になる。ミドルウェアおよびアダプタに基づいた統合戦略は、個々の任意のシステムへの更新が行われたときはいつでも、固有の脆弱性およびシステム全体の再統合の費用のために失敗する。
拡張可能で安定した自動的なやり方で個別のスタンドアロンビジネスソリューションを自動的に統合するための新しいシステムが必要である。こうしたシステムによって、競合（および連携）するソフトウェアベンダは、最低限のカスタマイズコストでビジネスソリューションに容易に統合でき、同様にシステムの安定性に悪影響を与えない構成要素を設計し、提供できるようになる。最後に、こうしたシステムは、修正プログラムおよび更新を容易に受け入れ、その結果個々の製品の改良を容易に適用でき、将来発見され得る問題、欠点、および／または脆弱性に対処できるようになる。
自動ビジネスソフトウェアアプリケーションを提供する。オブジェクトおよびアクティビティを含むビジネスの特徴は、包括的な標準のやり方で分類され、記述される。ビジネスソフトウェア構成要素をインストールすると、探索マネージャは、標準的な分類に従ってソフトウェアを記述した情報に基づいてソフトウェアの機能および要件を識別する。ソフトウェア構成要素は、モデル対応バスの１つまたは複数の役割に選択的にバインドされる。一部の態様では、標準的なソフトウェアアダプタによって、従来技術のソフトウェアシステムとともに本発明の実施形態を容易に使用することが可能になる。追加のソフトウェア層およびオーバーヘッドによって、複数のソフトウェア構成要素の管理および操作が容易になる。
本発明は、ビジネスアプリケーションをサポートするためのフレームワークを含む。しかし、本発明をより詳しく説明する前に、本発明が存在し得るコンピューティング環境の一例について説明する。
図１は、本発明を実施できる適したコンピューティングシステム環境１００の例を示している。コンピューティングシステム環境１００は、適したコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に関する限定を示唆するものではない。また、コンピューティング環境１００を、動作環境１００の例に示した構成要素のいずれか１つ、またはその組合せに関連する依存性または必要条件を有しているものと解釈すべきではない。
本発明は、他の多くの汎用または専用コンピューティングシステム環境または構成で動作可能である。本発明との使用に適したよく知られているコンピューティングシステム、環境、および／または構成の例には、それだけには限定されないが、パーソナルコンピュータ、サーバーコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記の任意のシステムまたは装置を含む分散コンピューティング環境などがある。
本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。本発明は、タスクが通信ネットワークによってリンクされているリモート処理装置によって実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含むローカルおよびリモートのコンピュータ記憶媒体に置くことができる。
図１を参照すると、本発明を実施するシステムの例は、汎用コンピューティング装置をコンピュータ１１０の形で含んでいる。コンピュータ１１０の構成要素は、それだけには限定されないが、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素を処理ユニット１２０に連結するシステムバス１２１を含む。システムバス１２１は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。こうしたアーキテクチャには、それだけには限定されないが一例として、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子装置規格化協会（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られている周辺部品相互接続（ＰＣＩ）バスなどがある。
コンピュータ１１０は、一般に様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０からアクセスできる使用可能な任意の媒体とすることができ、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体を含む。コンピュータ可読媒体は、それだけには限定されないが一例として、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性および不揮発性のリムーバブルおよび非リムーバブル媒体がある。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、または所望の情報の格納に使用でき、コンピュータ１１０からアクセスできる他の任意の媒体などがある。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを搬送波または他の移送機構などの変調されたデータ信号に組み込む。これには任意の情報配送媒体がある。「変調されたデータ信号」という用語は、信号内の情報を符号化するなどのやり方で設定または変更されたその特徴のうちの１つまたは複数を有する信号を意味する。通信媒体には、それだけには限定されないが一例として、有線ネットワーク、直接配線された接続などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体がある。また、上記のどんな組合せでもコンピュータ可読媒体の範囲内に含まれるものとする。
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、例えば起動中など、コンピュータ１１０内の要素間での情報の転送を助ける基本ルーチンを含み、一般にＲＯＭ１３１に格納されている。ＲＡＭ１３２は一般に、処理ユニット１２０から直接アクセス可能な、かつ／または処理ユニット１２０が現在処理しているデータおよび／またはプログラムモジュールを含む。図１は、それだけには限定されないが一例として、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。
コンピュータ１１０は、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。一例にすぎないが、図１は、非リムーバブル不揮発性磁気媒体から読み取り、あるいはそこに書き込むハードディスクドライブ１４１、リムーバブル不揮発性磁気ディスク１５２から読み取り、あるいはそこに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭや他の光媒体など、リムーバブル不揮発性光ディスク１５６から読み取り、あるいはそこに書き込む光ディスクドライブ１５５を示している。動作環境の例で使用できる他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがある。ハードディスクドライブ１４１は一般に、インターフェイス１４０などの非リムーバブルメモリインターフェイスを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インターフェイス１５０などのリムーバブルメモリインターフェイスによってシステムバス１２１に接続される。
上述し、図１に示したドライブおよびその関連のコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ１１０の他のデータの記憶を提供する。図１では例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、異なっていてもよいことに注意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は少なくとも異なるコピーであることを示すために、ここではそれらに異なる番号を付している。
ユーザは、キーボード１６２、マイクロフォン１６３、およびマウス、トラックボール、タッチパッドなどのポインティング装置１６１などの入力装置を介してコマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどがある。これらおよび他の入力装置は、しばしばシステムバスに連結されているユーザ入力インターフェイス１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインターフェイスおよびバス構造で接続してもよい。モニタ１９１または他のタイプの表示装置もまた、ビデオインターフェイス１９０などのインターフェイスを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、出力周辺インターフェイス１９５などを介して接続できるスピーカー１９７、プリンタ１９６などの他の周辺出力装置を含むこともできる。
コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク式環境で操作される。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルド装置、サーバー、ルーター、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般にコンピュータ１１０に関連して上述した多くまたはすべての要素を含む。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域エリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含んでいてもよい。こうしたネットワーキング環境は、オフィス、全社規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。
ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０は、ネットワークインターフェイスまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は一般に、モデム１７２、またはインターネットなどＷＡＮ１７３を介して通信を確立する他の手段を含む。モデム１７２は、内蔵のものでも外付けのものでもよく、ユーザ入力インターフェイス１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク式環境では、コンピュータ１１０に関連して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に格納することができる。図１は、それだけには限定されないが一例として、リモートアプリケーションプログラム１８５をメモリコンピュータ１８０上に存在するものとして示している。図示したネットワーク接続は例であり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。
図２は、従来技術による１対のビジネスソフトウェアソリューションシステムの相互運用を示す略図である。システムＡコントローラ２００は、画面２０２およびデータベース２０４に連結されており、またそれらを含んでいてもよい。また、コントローラ２００は、システムＡ ＡＰＩ２０６に連結されているそれ自体のビジネスアプリケーション論理も含んでおり、その結果ユーザは、例えば矢印２０８で示すように注文を追加することができる。図示したように、システムＢは、１対のアダプタ２１０、２１２を使用してシステムＡと一体化されている。アダプタ２１０および２１２は、特に、アダプタ２１０および２１２が設計されたときのシステムＡおよびシステムＢの正確な状態に基づいてシステムＡとシステムＢの間の相互運用を提供するように設計されている。したがって、システムＡまたはＢの一方がたとえマイナーなやり方ででもアップグレードまたは変更された場合、アダプタ２１０および２１２は、使用できなくなることはないにしても、その効率が激減する可能性がある。
図２で、通信したい業務がシステムＡを稼働させていることがわかっているエンティティは、ライン２０８に示すようにシステムＡ ＡＰＩ２０６を介してＡｄｄ．Ｏｒｄｅｒ要求をシステムＡに送信する。この注文はシステムＡコントローラ２００を通過し、データベース２０４に書き込まれていた。注文は、画面２０２上に表示され、次いでアダプタ２１０を介してＳａｌｅｓ．ＯｒｄｅｒとしてシステムＢに送信される。Ｓａｌｅｓ．Ｏｒｄｅｒ要求に応答して、システムＢの注文状況出力は、ライン２１４で示すように、アダプタ２１２によって変換されてＯｒｄｅｒ．ＳｔａｔｕｓとしてシステムＡに入る。図２に関して説明した動作は、個別の２つのビジネスソフトウェアソリューションシステムが相互に通信し、相互運用できるように働くミドルウェア（具体的にはアダプタ２１０、２１２）の標準的な例である。将来、システムＢをシステムＣと取り替える場合、またはシステムＢ’のバージョンにアップグレードする場合でさえ、アダプタ２１０および２１２を書き換える必要がある。
図３は、配置されたビジネスソフトウェアシステムの数が増加するにつれて従来技術の問題の複雑さがどのように増すかを示す従来技術の別のビジネスソリューションを示す略図である。図３では、システムＡコントローラ２００がシステムＡ ＡＰＩ２０６およびデータベース２０４に連結されている。システムＡは、特にシステムＡとシステムＣの間の対話を容易にするように設計されているカスタマイズされたアダプタ２１８を介してシステムＣ ＡＰＩ２１６と対話する。また、システムＡは、カスタマイズされたアダプタ２２０を介してシステムＢと対話することもできる。システムＢは、それぞれアダプタ２２２、２２４を介してシステムＡおよびＣと対話することができる。最後に、システムＣは、それぞれアダプタ２２６および２２８を介してシステムＢおよびＡと対話することができる。図３は、複数のビジネスソフトウェアシステムが配置されているときは使用する必要のあるカスタマイズされたアダプタの数が激増するということだけではなく、３システムソリューションと対話するようソフトウェアを設計したい独立したソフトウェアベンダはどのＡＰＩのために新しいソフトウェアを設計すべきかがわからないことを示している。この不明確さを疑問符付のライン２３０によって示している。
図４は、本発明の一実施形態によるビジネスソフトウェアソリューションを示す略図である。図４では、システムＡ、Ｂ、およびＤ（それぞれ２００、２３２、および２３４）は、サードパーティアプリケーション２４０と対話するために、１対のアプリケーションプログラミングインターフェイス（粗粒度ＡＰＩ（ｃｏａｒｓｅ−ｇｒａｉｎ ＡＰＩ）２３６および細粒度ＡＰＩ（ｆｉｎｅ−ｇｒａｉｎ ＡＰＩ）２３８）の間で動作している。図４に示した実施形態の重要な概念の１つは、これはビジネスアプリケーションの大規模で包括的な分類を表すことである。具体的には、ビジネスアプリケーションのデータ型、オブジェクトラベル、イベントタイプなどは標準的な分類の対象となる。そうした例には、出荷通知の送信または確認通知の送信のアクションを説明するための標準の方法がある。粗粒度ＡＰＩ２３６および細粒度ＡＰＩ２３８の定義、および標準的なアダプタ２４２、２４４、２４６、および２４８の設計および実装を可能にするのがこの包括的なビジネス分類である。
これらのアダプタは、ＡＰＩ２３６および２３８に組み込まれる包括的な分類の承認を表すという意味で標準化されている。特に、標準的な各アダプタは、スタンドアロンビジネスソフトウェアシステムによってサポートされていないビジネスオブジェクトおよび／またはプロセス用に少なくとも表記法またはスタブを含み得る。こうした項目がサポートされていない場合、標準的なアダプタは、単にそのようなものを示す。したがって、本明細書で使用する場合、標準的なアダプタとは、標準的なアダプタが包括的なビジネス分類に従って設計される総合包括型ビジネスソフトウェアソリューションにスタンドアロンビジネスソフトウェアシステムを連結するソフトウェアアダプタを意味するものである。説明上、各アダプタ２４２、２４４、および２４６でのサポートしていない項目の適用を縦縞２５０として示しており、標準的なアダプタ２４２、２４４、２４６、および２４８は、本明細書では隙間の広いアダプタ（ｇａｐ−ｔｏｏｔｈ ａｄａｐｔｅｒ）と呼ぶこともある。図４に示した実施形態によって、独立したソフトウェアベンダは、（ＡＰＩ２３６および２３８を介して）標準的な耐久性のあるインターフェイスと対話することができる。このインターフェイスは、インターフェイスと対話するように設計されている機能およびオブジェクトが常に機能するという意味ではインターフェイス契約とみなされるので、耐久性があると見なされる。したがって、ＡＰＩ２３６および２３８を備えるインターフェイスは、決して小さくならず、もっぱら大きくなり、それによって後方互換性が保証される。これによって、独立したソフトウェアプロバイダは、各自の製品から今日現存する様々なＡＰＩおよび／またはアダプタへのインターフェイスを生成するために多量の資源を費やすのではなく、より多くの資源を各自の製品の設計に集中することができる。
複数のシステム２００、２３２、および２３４がパブリッシャ／サブスクライバモデル（ｐｕｂｌｉｓｈｅｒ／ｓｕｂｓｃｒｉｂｅｒ ｍｏｄｅｌ）の形でモデル対応バスと対話することが好ましい。したがって、スタンドアロンビジネスソフトウェアアプリケーションは、インストールされると、それが処理できるビジネスアクションまたはイベントに加入し、それ自体の機能に基づいていくつかのタイプのデータおよび／またはイベントのパブリッシャであることを示す。一例として、図４では、各システム２００および２３２は、接続２５２および粗粒度ＡＰＩ２３６を介してＩＳＶ Ａｐｐ２４０に接続されている。各システム２００および２３２は、あるタイプのイベント（例えば注文の予約）に応答することができ、したがってＢｏｏｋ．Ｏｒｄｅｒイベントに加入している。このイベントは、例えばビジネスイベント３．１．１．５として数値的にエンコードすることができる。アプリケーション２４０は、このイベントの情報のソースとして働き、粗粒度ＡＰＩを介してバスにイベントを送信する。バスはイベントを受信して、それが連結されているスタンドアロンシステムのいずれかがそのイベントのサブスクライバであるかどうかを決定する。この場合、システム２００および２３２はいずれもサブスクライバであり、したがってこのイベントはバスによってそれらに渡される。別個に注文が満たされると、システム２３２が標準的なアダプタ２４６およびＡＰＩ２３８を介して注文の詳細を要求し、次いで出荷通知（３．１．３．１とエンコードされたイベント）を送信する間に、システム２００は更新注文状況イベントを送信する必要がある。粗粒度ＡＰＩ２３６は、システムＢから出荷通知を送信するために使用され、矢印２５４で示すように適切な通知を送信する。さらに、システムＤがインストールされ、注文明細のソースとして構成されたと仮定すると、ＡＰＩ２３８を使用して、細粒度ＡＰＩ２３８を介して応答するシステムＤ（２３４）に要求注文明細メッセージが送信される。
図４に１対のアプリケーションプログラミングインターフェイス２３６および２３８を示しているが、こうした両方のインターフェイスを含む単一のＡＰＩを提供することができることを明白に企図している。さらに、標準的なアダプタは、既知のスタンドアロンビジネスソフトウェアアプリケーション間の対話を容易にするように設計されているが、標準的な包括的インターフェイスと対話するために、アダプタの少なくとも半分、例えばアダプタ２４２の半分部分２５６が生成されるので、こうした標準的なアダプタの開発は簡素化される。スタンドアロンソフトウェアアプリケーションに基づいて変わるのは、アダプタ２４２の半分部分２５８のみである。さらに、ソフトウェアプロバイダは包括的なインターフェイスおよび本発明の他の態様を採用し始めているので、標準的なアダプタを使用することなくＡＰＩ２３６および２３８と自動的に対話するスタンドアロンソフトウェアシステムが提供されるようになる。システムＤ（２３４）は、こうした例の１つである。
システム間通信を容易にするために、細粒度ＡＰＩ２３８は、複製インターフェイスとして機能するようにも構成される。本質的に、インターフェイス２３８は、一般にソフトウェアのトリガを介して、各スタンドアロンソフトウェアシステムからイベントを受信する。次いでＡＰＩ２３８は、上記のパブリッシャ／サブスクライバモデルに基づいて必要な命令および／またはメッセージを適切なシステムに提供する。
ＡＰＩ２３６および２３８から成る包括的なインターフェイスは、２つ以上のインストールされたソフトウェアアプリケーションの役割が重複する場合のソフトウェアの役割の選択および／または管理を可能にする管理用ＡＰＩの機能を含むこともできる。したがって、１つのアプリケーションにはこうした役割を行わないよう命令し、他方にはその役割を行うよう命令することができる。
したがって、本発明の一実施形態によって作成されたインターフェイスは、同一の自動化機能の基礎を提供する１つまたは複数の共通のＡＰＩを提供する。インターフェイスは、共有論理データモデルに基づいている。さらに、インターフェイスは、バージョンに対して安定したやり方でフィールドおよび追加機能の追加をサポートしている。さらに、安定したインターフェイスは、インターフェイスのバージョンの変更に伴い安定性を維持するように構築される。さらに、データモデル、ＡＰＩ、および分類は、インストール可能とし、その結果、基礎となるソフトウェアバスを使用した複数のアプリケーションドメインモデルのサポートが可能になり、バスは、安定した管理およびマネジメント用ツールセットを提供しながら、異なる複数の、しかし標準的なビジネス分類をサポートすることができる。異なるアプリケーションドメインモデルは、異なるドメイン固有の分類を駆動することができる。例えば、あるドメイン固有の包括的なビジネス分類は銀行業に提供し、別のドメイン固有の包括的なビジネス分類は、医療産業に提供することができる。本発明の実施形態は、包括的なビジネス分類の様々なバージョンまたはインスタンスに適応するようにモデル対応バスを構成できることを含む。
図５は、本発明の一実施形態による統合ビジネスソフトウェアソリューションを示す略図である。上述したように、本発明の実施形態の一態様は、実質的に１つのビジネスのすべての特徴を標準的な方法で分類でき、類別できる標準的なビジネス分類を提供することである。このプロセスは、１つのビジネスソフトウェアが人間関係管理や顧客関係管理（ＣＲＭ）などの高レベルビジネス機能の一部であることを示すなど、高レベル分類を含む多くのレベルで行うことができる。分類のビジネスへの適用は、標準的なビジネスオブジェクトの個々のデータ型の仕様にまで及ぶ。これは、例えば、所与のドメインモデルにおいて、とりわけ２０文字列未満のファーストネームを有するオブジェクトとなるように「顧客」が標準化されることを意味し得る。本発明の実施形態に従ってこれらの標準化のすべてが定義され、インストールされると、開発者は、分類の組によって定義されるこのソフトウェアの設計図に従って統合できるビジネスソフトウェアを提供することができる。これに関して、設計図は、事前定義された戦略に従って、および現在の有効なビジネス分類によって定義される安定したインターフェイスに従ってビジネスソフトウェアを統合できることを意味する。
図５は、標準的な分類によって実行可能となるこの統合の一例を示す。こうした１つのビジネス分類の内の１つの標準的なプロセスをリードクオリフィケーション（ｌｅａｄ ｑｕａｌｉｆｉｃａｔｉｏｎ）とすることができる。この標準的なビジネスプロセスをブロック３００で示している。標準化によって、リードクオリフィケーションは、いくつかの内部特徴を有することができ、１つまたは複数の入力を受信し、１つまたは複数の出力を提供するように要求され得る。ビジネスソフトウェアアプリケーションは、こうした情報を提供し、かつ／またはこうした情報を受信する役割にバインドする。本発明の実施形態は、構成の変更に反応し、複数の構成をサポートできるという点で、モデル対応バスを使用すると考えることができる。このバスは、統合／相互運用性管理に関してアプリケーションドメイン外に、ランタイムサービスのために提供される連携する多層のインフラストラクチャを含む。
本発明の実施形態は、一般に６つ、また任意選択で７つの異なる形の分類を使用する。これらの分類には、モジュール機能、プロセス機能、プロセスロール（ｐｒｏｃｅｓｓ ｒｏｌｅ）、参照データ、依存関係、イベントデータ、および任意選択でキーパフォーマンスインジケータがある。
モジュール機能分類の例は、本質的にビジネスモジュール機能のグループ分けを記述する。この説明の例では、１つのモジュールを、例えば人事システムの一部またはすべて、またはカスタマリレーションシップマネジメントシステムのすべてまたは一部として記述する。
プロセス機能分類は、所与のソフトウェアアプリケーションモジュールによって実行できるプロセスの記述に使用する。この記述の一例は、モジュールが例えば図５に関連して示したリードクオリフィケーションプロセスに参加できることの表示である。
プロセスロール分類は、ビジネスプロセスにおいてモジュールが果たす役割を記述する。以前のリードクオリフィケーション例を拡張することによって、特定のアプリケーションモジュールが申請者または承認者の役割を果たすことになる。
参照データ分類は、アプリケーションにとって使用可能な、またはアプリケーションが必要とする参照データのタイプを記述する。
依存関係分類は、アプリケーションまたはプロセスと所与の参照データまたはイベントデータソースの間の共通部分を記述する。これには、共通部分が記述した関係のソースであるか、シンクであるかも記述する。この依存関係分類の例には、所与のアプリケーションまたはプロセスが例えば顧客データに依存し、使用可能な顧客データのソースがあることに依存するモジュールの部分が機能するかどうかを決定するために使用する表示がある。顧客データのソースがない場合、インストールされたアプリケーションの部分を使用可能にすること、または使用不可にすることを管理する本発明の実施形態の一部では、アプリケーションのこうした依存部分が動作するのを防ぐ。所与のモジュールが全面的に所与のプロセス、デ―タ型、またはビジネス分類からの他の項目に依存しており、それらの項目が存在していない場合、アプリケーションは、こうした依存関係が満たされるまで使用不可になる。このより限定的な依存関係の挙動の例には、アプリケーションまたはプロセスは動作できるようになる前にアカウントの図が必要であることの表示がある。
イベントデータ分類は、所与のアプリケーションによる消費または作成に可能なイベントのタイプを記述する。イベントデータ分類の一例には、例えば、このイベントを介して顧客データに変更が加えられたときはいつでもアプリケーションが変更顧客データイベントのコピーを必要とすることの表示がある。
最後に、任意選択のキーパフォーマンスインジケータ（ＫＰＩ）分類は、システムから使用可能なキーパフォーマンスインジケータのタイプを記述する。キーパフォーマンスインジケータの例には、注文の実行を完了するための全経過時間、定時引渡しなどの項目がある。これらのタイプのＫＰＩは、アプリケーション構成要素の統合スイート内の個々のモジュールから容易に見ることはできない。
これらの分類のいくつかは、モジュールマップにおいてモデル化される。図６は、本発明の実施形態によるモジュールマップの一部を示す略図である。モジュールマップ３１０は、ビジネスにおいて可能なすべての項目の網羅的なリストを単に含む。図６は、モジュールマップ３１０全体の異なる部分をそれぞれ実行する１対のビジネスソフトウェアアプリケーション３１２、３１４を示している。具体的に、アプリケーション３１２は、注文管理、販売管理、価格設定、契約管理、およびリードクオリフィケーションの機能を実行するように設計されている。インストール中、または他の任意の適した探索プロセスの間、アプリケーション３１２は、その機能を決定するよう尋ねられる。次いでこれらの機能は、適切な決定を容易にするように、モジュールマップに基づく分類による構成に基づいて、本発明の実施形態によって適切な宛先にバインドされる。また図６は、アプリケーション３１２がモジュールマップ３１０の異なる部分を実行することも示す。具体的に、アプリケーション３１４は、需要計画および供給計画を提供するように設計されている。ビジネスソフトウェア機能を管理するこの技術は、例えば、独立したソフトウェアベンダが追加の、またはより適切なビジネスソフトウェアをビジネスに提供する機会を識別し、それに対処できるようにするために、モジュールマップ３１０とともに動作するよう設計された適切な管理用ツールを使用することによってビジネス全体のソフトウェアを迅速かつ効率的に分析できる方法を提供する。
図７は、本発明の一実施形態によるビジネスソフトウェアソリューションに配置されたビジネスソフトウェアアプリケーション３２０、３２２、３２４を示す略図である。各アプリケーション３２０、３２２、および３２４は、システム探索マネージャ（モデル対応バスの一構成要素）３２６と対話し、その結果各ソフトウェアアプリケーションの機能（チェックボックス付きの四角として図示）および機能外（空の四角として図示）を決定することができる。連携するソフトウェアアプリケーションのインストールの認識によって相互作用が可能になる。例えば、図７に示すように、販売注文管理モジュール３２２および配送モジュール３２４がインストールされると、点線の四角３２８で示す２つのモジュールの間の直接操作が可能になる。全体計画モジュール３２０と配送モジュール３２４の間の点線ボックス３３０では別の相互作用が明らかである。
ある意味では、本発明の実施形態とともに使用するモデル対応バスは、いくつかの層に有利な機能を提供する。１つの層は、メッセージルーティングの管理に使用する。ルーティング層は、発呼側からの要求を構成されたプロバイダにルーティングする責任を負う。要求は、非同期または同期（呼出し／応答または一方向呼出し）の形をとることができる。ルーティング層は、モデルで定義された構成されたビジネスプロセス記述に基づいて要求を引き渡す。発呼側は、宛先を知らず、また、サービスプロバイダに直接リンクされることもない。ルーティング層は、構成要素とモジュールの間の要求の引渡しを決定する最後のプロキシ／エージェントとして働く。
パターン適合層（ｐａｔｔｅｒｎ ｆｉｔｎｅｓｓ ｌａｙｅｒ）は、インストール時に構成要素によって提供されたメタデータ記述がアクティブモデルで定義された要件と一致することをチェックする責任を負う。適合チェックは、アクティブモデルのプロセス記述のプロパティに基づいて呼び出される。細部にわたる詳細なプロセス記述は、要求のルーティングがアクティブモデルによって要求されるフローから逸脱するのを防ぐ。
別の層は、運用／管理層である。この層は、エンドカスタマの営業所の運用スタッフに、稼働するプラグアンドプレイアプリケーションを管理するための手段を提供する。この層によって、アプリケーションの部品の地理的分散に依存せずアプリケーションの健全性への可視性が提供される。インストールされている構成要素とインストールされる構成要素との間であろうと、インストールされる新しい構成要素とアクティブモデルで定義されているプロセス／役割／メッセージ記述との間であろうと、競合が起こると、インストールを行うオペレータに通知される。運用／管理層によって提供される別の機能の例には、ビジネスソフトウェアシステムに大幅な変更が加えられたときにチェックポイントをマークすることがある。
別の層は、複製／マスタ層である。この層は、ステップ（新しいレプリカの設定など）、一括インポート、および同期化された情報の共通のビューを共有する分散されたデータストアの組の管理に必要な進行中のフローの提供中の一括データフローを管理する。
別の層は、追跡／監査層である。この層によって、フローを監査し、追跡し、デバッグすることができる。各モジュールまたは構成要素は、最終的にはテストまたは追跡モードにすることができなければならず、テスト結果および追跡データは、この層を介して中央追跡／監査機能に書き込まれる。
最後に、もう１つの層は、キーパフォーマンスインジケータを提供することができる。この層は、アプリケーション構成要素間のフローを業務の健全性および他のＫＰＩデータの捕捉に重要な情報のソースとして監視できるようにするデータの観察および推測機能として働く。モデルは、モデル間のプロセス対話を定義するため、モジュール間を流れるイベントのタイミングは、重要なビジネスレベルパフォーマンスデータを表す。この層は、プロセスのブラックボックスレベルおよびホワイトボックスレベルでのＫＰＩの定義を可能にし、アプリケーションモジュールにわたって捕捉および報告アクセスを提供する。
図８は、本発明の一実施形態によるルーティング層の一部を示す略図である。各ソフトウェアアプリケーション４００、４０２、４０４は、上記の包括的なビジネス分類に従って構築されている。したがって、追加のミドルウェアおよびアダプタは不要である。ルーティング層は、モデル対応バスの下層の１つである。これによって基本的に、情報が確実に異なるビジネスソフトウェアアプリケーション間を適切に流れるようになる。
ソフトウェアアプリケーション４００は、インストールされると、図８に示すように、例えばリードクオリフィケーションの役割に参加することができることを示すメタデータを提供する。この機能のために、ソフトウェアアプリケーション４００の適切なポートが適切なプロセスロール（図８のプロセスロールＡ）にバインドされる。メタデータは本質的に、ビジネスソフトウェアアプリケーションをモジュールとして識別する。メタデータは、バインドに使用可能なポート、および使用可能なそれらのポートが参加できる適切なビジネスプロセスをさらに識別する。例えば、リードクオリフィケーションプロセスにバインドされているビジネスソフトウェアアプリケーション４００のポートは、１．３．４．１として識別されているプロセスを開始するのに必要な情報を提供することができることを示す役割Ａのソース責任を提供することができる。
また、アプリケーション４００のメタデータは、ビジネスプロセス１．３．４．４の情報をソースし、ビジネスプロセス１．３．４．３および１．３．４．５の情報をシンクすることができることを示すこともできる。ソフトウェアアプリケーション４００のポートは、ポートへのバインドに対してルーティング層の役割にバインドされていることを当分野の技術者であれば理解されよう。システム４０２がインストールされると、システム４０２によって提供されるメタデータは、モデル対応バスに、役割Ｂをプロセス１．３．４にバインドするのにシステム４０２が適していることを知らせる。メタデータは、アプリケーション４０２が１．３．４．１の情報をシンクし、１．３．４．２の情報をソースし、１．３．４．４の情報をシンクし、１．３．４．５の情報をソースできることを知らせることができる。アプリケーション４０４がインストールされると、そのメタデータは、アプリケーション４０４が図８に示したプロセスにおける役割（役割Ｃ）へのバインドにも適していることを示す。これらのバインドが行われると、プロセスは、アクティブ化され得る。例えば、リードの送信を望むアプリケーション４００は、モデル対応バスに対してクエリを行い、リードクオリフィケーションプロセスが使用可能かどうかを確認することができる。バス４０６は、その問合せに応答して、リードの送信のための宛先が存在していることを示すことができる。それに応答して、アプリケーション４００は、リードをバス４０６に送信することができる。アプリケーション４００は、リード送信情報の最終的な宛先を知る必要はない。というのは、そのルーティング情報は、モデル対応バスのルーティング層内に格納されているからである。
図９は、パターン層４１０に関連して図８に関して説明した動的ルーティング層４０６を示す略図である。システムがパターン層４１０を使用して、ビジネスプロセス（この例ではリードクオリフィケーション）が使用可能かどうかが決定される。パターン４１０は、ビジネスプロセスが必要に応じて機能することができるかどうかを決定するために、個々のモジュールによって提供されたメタデータと比較することができるデータであらかじめ構成されている。層４１０は本質的に、ソースおよびシンクに関してプロセスが何であるべきかの層である。層４１０は、層４０６と比較されて、役割を果たしているかどうかが決定される。個別の層４１０を有することの利点の１つは、役割のタイプをより十分に定義できることである。例えば、パターン４１０は、例えば役割Ｃは、絶対に必要であり、１回だけ実行することができるという情報を含み得る。役割の仕様の別の形は、役割は任意選択であり、ゼロ回からｎ回実行することができるということである。役割の仕様のさらに別のタイプは、役割は任意選択であり、しかしゼロ回または１回しか実行できないことである。追加のタイプの役割仕様を使用することができる。
運用／管理層は、一般に（図９に関して示し説明した）前の２つの層のメタデータを使用して、ソフトウェアソリューション全体が動作の準備ができているかどうかなどの高レベル機能を提供する。さらに、この層を使用して、定義され、インストールされたプロセス定義を列挙することができる。さらに、この層を使用してフラグを立てる、そうでなければ完全には実行されていないプロセスを識別することができる。次いで識別されたこうしたプロセスに管理ユーザの注意を引き付けることができ、次いで管理ユーザは、こうしたプロセスを現在の状態で使用可能にすることを試みるか、是正措置を取ってプロセスを完了するかを手動で決定することができる。
運用層は、ソフトウェアの構成、提供、テスト、チェックポイント、および場合によってはロールバックさえ容易にする。これによって、管理者は、ソフトウェアのインストール、パッチ、アップグレード、交換、修復、リタイア、および／または復元を比較的容易に行うことができるようになる。
「モデル対応バス」は、特定のアクティブモデルで定義されるシステムの挙動を実施する連携する１組のランタイムサービスである。モデル対応バスは、モデルで定義されたランタイム挙動を制御するための一般的な機構を提供する。特定のモデルがインストールされ、アクティブモデルインスタンスとしてマークされると、アプリケーションモジュールおよび個々の構成要素およびサービスをインストールすることができる。
インストール中、所与の構成要素によって提供されるメタデータがモデルと比較される。ローカル管理者の設定に応じて、モデルからの逸脱が許容され、または逸脱としてマークすることができ、さらに管理アクションが講じられるまで使用不可にすることができる。
ランタイム時、構成要素間のフローは、モデルが記述するフローに基づいて生じる。送信側、例えば役割ベースのバスへのバインドを確立したアプリケーションは、バスへの要求を行い、所与の構成要素に関連するバインドに基づいて、情報フローが計画されたパス上に生じる。計画されていないフローは、管理上使用可能にする、またはまったく禁止することができる。
上記のモデル対応バスの設計仕様は、ランタイム時にソフトウェア構成要素をモデル対応バスにバインドする技術上の対話を提供する。そのようにバインドすることによって、ある構成要素は、他の構成要素、バス自体、管理者、およびデータサービスとの対話を開始することができる。構成要素がバインドされると、モジュールインターフェイス設計は、許可されるビジネスプロセスおよびデータ対話を管理する。
バスのインスタンスの構成に使用した分類によって定義されたモジュールインターフェイスは、本質的に他のモジュールとのプラグアンドプレイ対話を達成するとともに、システム自体を任意の所与のモジュールと対話できるようにするために、すべての構成要素が従う規定を提供する。モジュールインターフェイス自体もサービス、ユーザインターフェイス要素、およびプロセス対話機能の形でモジュール固有の１組の機能を公開する。これらのそれぞれは、ドメイン固有のモデル設計者によって定義された予想される挙動を反映する。
次のセクションでは、プラグアンドプレイ機能を容易にするために、一般にすべてのモジュールに共通する設計要素に焦点を置く。
本発明の実施形態の１つの重要な態様は、探索プロセスおよび初期設定対話である。これには、構成要素またはモジュールをインストールし、構成し、アクティブにし、または非アクティブにしたときに構成要素またはモジュールがモデル対応バスと関与する方法を含む。最初の対話は、１つまたは複数の構成要素から成る新しいモジュールがランタイム環境に導入されたときに行われる。セットアップ中、各構成要素のビジネスの目的、機能、依存関係、役割などを記述するメタデータがインストールされる各構成要素から読み取られ、次いでモデル対応バスによって管理されるインストールされた項目のマニフェスト、およびバスモデルストア内に存在するモデル情報と比較される。
セットアップ中、モデル対応バスのランタイムの特徴は、インストールされる構成要素がモデルにはわかっているかどうかを決定する。いくつかのケースが考えられ、簡単な説明をそれぞれ以下に示す。新しいモジュールがインストールされ、そのモジュールのメタデータが目的のランタイム環境を制御しているモデルのメタデータと一致するときに、ある状況が起こる。この状況で、モジュールおよびその構成要素は、「稼働待ち」状態になる。この状態からモジュールおよびその構成要素を、管理アクションによってアクティブ状態に促進することができる。
新しいモジュールがモデル化された要素に対する予想と一致しないときに別の状況が起こる。新しいモジュールがインストールされ、そのモジュールのメタデータが現在のモデルで説明されている要件を満たさないとき、モジュールおよびその構成要素は「使用不可−不一致」状態になる。管理アクションは、不一致状態から、不安定な構成要素をアンインストールする、または予定のモードからの逸脱を許可する（それによって特例の拡張機能を作成する）ことが要求される。モジュールがモデル全体との調整からずれる度合いは、逸脱許可がどの程度成功するかにおいてある役割を果たす。ランタイムアーキテクチャは、ある程度の逸脱に対応し、モデル設計者および管理者に、要素がどの程度厳密にランタイム記述と一致する必要があるかについての何らかの制御を提供する必要がある。
新しいモジュールがモデル化されていない機能を記述しているときに別の状況が生じる。新しいモジュールがインストールされ、そのモジュールのメタデータがランタイムを制御している特定のターゲットモデルへの拡張を定義したとき、モジュールは、「承認待ち」状態になる。管理アクションによって、新しいモジュールは、モデル拡張がランタイム環境に追加された後、「稼働待ち状態」に移動することができる。
プロセスのバインドおよび検査は、本発明の実施形態において重要な役割を果たす。自動的に構成可能な１組のソフトウェアモジュールの原理の１つは、特定のモジュールを構成する構成要素は、うまく定義された、またはモデル化されたビジネスプロセス対話を介して他の構成要素と対話することである。簡単な場合では、１つの構成要素は別のものと１対１の関係で対話し、各構成要素は特定のサービス要求に応じて役割を果たす（発呼側および被呼側など）。
別の場合では、２つの構成要素が、長時間稼働するトランザクションシーケンスまたはプロセスの一部として要求／応答アクションの複雑なシーケンスで対話するようになる。対話している各構成要素は、上記のようなプロセスにおいて特定の役割にバインドされることに注意されたい。このバインド要件は、各構成要素がセットアップ中に提供するメタデータの一部としてバスに伝達される。構成要素の対がアクティブ状態になると、モデルからのプロセス記述は、アクティブ化ステップにおいてある役割を果たす。各モデルの予想を記述するメタデータがアクティブモデルでのプロセスを定義するメタデータと一致していると仮定すると、アクティブ化が成功し、２つのモジュールは計画されたように通信することができる。
リモート構成要素の代わりにプロセスにおける役割にバインドするこの手法の利点には、連結解除およびより良いランタイム管理がある。
連結解除は、発呼側が相手の構成要素の位置およびそこへの経路に関する情報をもはや維持していないために達成される。モジュールは、特定の対話が可能かどうかについてのみ注意する。プロセス自体は、（ランタイムを介してこれを追跡することによって）どの役割がアクティブであるかを知っているため、発呼側は、やみくもに要求を行う前にサービス要求を行うことができるかどうかを決定することができる。
より良いランタイム管理は、構成要素がプロセスロールにバインドされるために達成される。特定のプロセスロールにバインドされている構成要素がランタイム時に使用不可状態になった場合、あるいはアンインストールされた可能性がある場合、そのプロセスにおける役割の記述に応じてプロセスを使用不可状態にすることができる。オプションの役割は、プロセスに影響を及ぼすことなくアクティブまたは非アクティブにすることができる。
本発明の実施形態は、プロセスの監視も容易にする。プロセスフローをアクティブに管理する中間のルーティング層を通過することによって、個々のフローは、監視および測定論理を個々のモジュールに入れる必要なく、装備、監視、測定することができる。より一貫性のある運用監視環境は、この手法から生じる。
本発明の実施形態では、個々の構成要素はプロセスにおいてそれぞれが果たす役割についてのみを知っているため、プロセスの柔軟性も向上する。したがって、個々の構成要素に中断条件またはコード変更要求を導入することなく、（アクティブモデルにおける管理者の設定が許す範囲で）プロセス自体を変更し、新しい役割によって拡張することができる。この手法では、それ自体を、複数の役割、および他の応答パターン（一方向、通知、サブスクリプション、同報通信、非同期要求／応答、およびｎ方向戻り経路）を伴うより複雑なプロセスに容易に拡張する。
上述したように、本発明の実施形態は、一般にメタデータを使用して、モジュールの機能および要件を記述する。本質的にプラグアンドプレイ機能のためにモジュールまたは構成要素が信号で知らせる必要があるメタデータの１つは、所与のモジュールが機能するために存在していなければならない、または任意選択である機能のリストである。別のメタデータは、所与の構成要素またはモジュールによって提供される機能の表示である。メタデータは、依存関係メタデータも含んでおり、これは、インストール中にモジュールによって提供される必要のある依存関係メタデータのタイプを略述する。このデータは、依存関係のクエリインターフェイス（ｑｕｅｒｙ−ｉｎｔｅｒｆａｃｅ−ｆｏｒ−ｄｅｐｅｎｄｅｎｃｙ）タイプのインターフェイスによって、またはランタイム時において様々な構成状態を反映する共有探索機能を検査することによって発見可能であるはずである。本発明の実施形態は、発見の手法を含む。このインターフェイスに関して考慮すべき依存関係メタデータのタイプは、ドキュメントソース／データ依存関係、モデルバージョンターゲット、アクティブモデルにおけるプロセスの存在、プロセスロールの存在、プロセスロールの相互依存性、および構成要素またはサービスの存在を含む。
ドキュメント、イベント、およびデータの依存関係は、モジュールまたは構成要素が適切に機能するために存在すべきデータおよびドキュメントソースのタイプを定義する。依存関係が必要であるか任意選択であるかも示す必要がある。
本発明の実施形態の別の態様は、特定のモデルターゲットに従って個々のモジュールが構築されるという仮定である。つまり、本発明の実施形態の構成に使用できる所与のアプリケーションドメインモデルについて、所与のモジュールの開発者は、ソフトウェアが適切に機能するためにはランタイム時にモデルの特定のバージョンが存在しなければならないという仮定に従ってソフトウェアを事前に構築する。モデルバージョンターゲットメタデータは、ソフトウェアアプリケーションまたはモジュールの「所望の」モデルバージョンターゲットを指定し、バインドのための第２の選択肢および優先順位を指定することができなければならない。特定のモデルバージョンが必要な場合、これを示す必要がある。
プロセスの存在とは、インストール中またはランタイム時に、プロセス分類に見られる識別子によって定義される特定のプロセスのステータスについて、モデル対応バスに対してクエリを行うことができるようにモジュールが開発される機能である。このメタデータは、モジュールが１つまたは複数のプロセス定義をバインドすることができるかどうかを制御する。モジュールまたは構成要素をアクティブにしたとき、システム構成ステップを案内するのにこの情報が使用される。プロセスの存在が必要であるか任意選択であるかを示す必要がある。
プロセスロールの存在のメタデータは、モジュールが望んで引き受けることができるプロセスロールを指定する。
プロセスロールの相互依存性のメタデータは、バインドロールの割当（ｂｉｎｄｉｎｇ ｒｏｌｅ ａｓｓｉｇｎｍｅｎｔ）の間の関係を指定する。この情報によって、個々のプラグアンドプレイ構成要素が意味をなさないようなやり方で混合されないように、「全面的または皆無の」バインド関係を指定することができる。
構成要素またはサービスの存在のメタデータは、特定の構成要素の実装またはサービスの存在が必要かどうかを指定する。このデータは、契約定義に基づいて論理能力の点で説明することが好ましい。
メタデータの記述は、本発明の実施形態において、モジュールの機能および要件の一般的な説明を提供する１つの方法である。各モジュールとバスの間、および異なるモジュール間の一般的な通信をしやすくするのを助ける別の重要な機能は、メッセージング層である。本質的にプラグアンドプレイ操作の目的を満たすために、モデル駆動式のアプリケーションは、モジュールおよび構成要素の通信、エラー管理、２相コミットトランザクション管理、および操作制御をカバーする共通の信号方式とともに動作する必要がある。メッセージ構造自体は、異なる地域の異なる開発チームが、一貫性をもって動くモデル駆動式アプリケーション構成要素を開発できるように、規範的な設計に従う必要がある。
以下の説明は、本発明の一実施形態によるメッセージング仕様の例である。モデル対応バスによって接続されるプラグアンドプレイアプリケーションモジュールのためのメッセージの組の設計は、アプリケーションドメインおよび制御構造の安定したコアデータモデルに依存する。コアデータモデルは、個々のアプリケーションデータ型の共通のドメイン間定義を提供する。データモデル安定性に関する要件は、ビジネスアプリケーションの様々な性質に対応する。個々のアプリケーションは専門化され、各アプリケーションがそれ自体のサーバーの組にインストールされることが普通である。営業所、工場、本社は、めったに同じ場所に配置されておらず、いくつかの市に分散している。
地理的に分散したこうしたインストールは、同期待ち時間、およびネットワークまたはサーバーがダウンしたときに引き続き稼働する必要性をもたらすだけではなく、個別の予算サイクルをもたらし、新しいバージョンのソフトウェアでシステム全体が同時に更新されることさえめったにないことが確実になる。
モジュール設計者は、アプリケーションドメイン内の中核概念ごとにスキーマ要素定義を定義することによって、コアデータモデルを、ＸＭＬなどの標準的なやり方で表す。こうしたスキーマ定義は、後でメッセージドメインモデルの基礎として使用される。
メッセージドメインモデルは、特定のモデルドメイン内のモデル定義されたモジュールを構成する構成要素間で共有されるメッセージ構造を定義する。これらのメッセージドメインモデルは、ＸＭＬスキーマでそれぞれ表すことが好ましい個々のメッセージ定義の集まりである。これらのスキーマのそれぞれは、ｍｏｄｕｌｅＭｅｓｓａｇｅと呼ばれるモデル構成体から継承される。ｍｏｄｕｌｅＭｅｓｓａｇｅ定義は、すべてのドメインメッセージに共通の構造を定義するフレームワークを提供する。ｍｏｄｕｌｅＭｅｓｓａｇｅ定義は、次の共通のメッセージ機能、つまり制御ヘッダー、忠実度階層化（ｆｉｄｅｌｉｔｙ ｌａｙｅｒｉｎｇ）、配置後メッセージ拡張（ｐｏｓｔ ｄｅｐｌｏｙｍｅｎｔ ｍｅｓｓａｇｅ ｅｘｔｅｎｓｉｏｎ）、およびマルチパートメッセージ処理（ｍｕｌｔｉｐａｒｔ ｍｅｓｓａｇｅ ｈａｎｄｌｉｎｇ）を提供する。制御ヘッダーは、識別、べき等挙動（ｉｄｅｍｐｏｔｅｎｔ ｂｅｈａｖｉｏｒ）、同時実行、データバージョン管理、相関性、ｎ方向対話、およびトランザクションの関与を管理するメッセージの要素を定義する。忠実度階層化は、所与のメッセージまたはドキュメントタイプに対して定義された中核要素へのエリア固有の拡張における階層化の必要性に対処する。これは、中核ドキュメントの階層化された拡張を識別し、拡張される中核を識別し、バージョン管理するための手法を定義する。配置後メッセージ拡張は、メッセージがどのように「フィールドの追加」のシナリオをサポートするかを定義する。最後に、マルチパートメッセージセクションは、特定のメッセージインスタンスがｍ個の関連メッセージのｎ部目であることを知らせるためにメッセージがどのようにマークされるかを定義する。このタイプのメッセージ部分は、アプリケーションによって管理される。
以下の説明では、各メッセージに存在する制御要素でサポートすべきメッセージング機能に関する詳細をさらに提供する。説明上、提案した設計をＸＭＬとして表す。メッセージ制御要素は、「制御ヘッダー」の論理概念にグループ化される。これは、簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）などの標準プロトコルに従って送信されるペイロードに含まれるＸＭＬ要素であることが好ましい。これがＳＯＡＰ：Ｈｅａｄｅｒ内ではなくペイロード内にある理由は、現在はほとんどのＳＯＡＰ処理インスタンスが行うように、アプリケーションレベルの制御要素がＳＯＡＰメッセージから取り除かれるのを防ぐためである。
以下に定義する要素は、すべてｃｏｎｔｒｏｌＨｅａｄｅｒと呼ばれる共通制御ヘッダー要素内に含まれていることが好ましい。
例：
<ch:controlHeader・xmlns:ch="urn:schemas_microsoft_com:controlHeader:vl"/>
ｃｏｎｔｒｏｌＨｅａｄｅｒは、メッセージ要素ｍｅｓｓａｇｅＴｙｐｅおよびｍｅｓｓａｇｅＩｎｓｔａｎｃｅＩｄｅｎｔｉｔｙを有する。メッセージのルーティングを促進するために、制御ヘッダーは、メッセージタイプの明示的インジケータを有する。メッセージタイプは、メッセージ自体を識別し、経路指定するためにモデル駆動式バスによって使用される。メッセージタイプ情報は、ｍｅｓｓａｇｅＴｙｐｅと呼ばれる必須属性に配置される。
例：
<ch:controlHeader・xmlns:ch="urn:schemas_microsoft_com:controlHeader:vl"・messageType="messageURI">
・・・
</ch:controlHeader>
ＭｅｓｓａｇｅＩｎｓｔａｎｃｅＩｄｅｎｔｉｔｙは、アプリケーション側の一意の「送信」のインスタンスを定義し、個々の送信の試行は表さない。アプリケーション層は、一意の識別子を各メッセージに割り当てる責任を負う。メッセージインスタンスは、ｍｅｓｓａｇｅＩＤと呼ばれる要素で定義される。
例：
<ch:controlHeader・xmlns:ch="urn:schemas_microsoft_com:controlHeader:vl"・messageType="messageURI">
<ch:messageID・context="senderContextlD">uniqueID</ch:MessagelD>
・・・
</ch:controlHeader>
ｓｅｎｄｅｒＣｏｎｔｅｘｔと呼ばれる必須属性は、送信側アプリケーションおよび／またはモジュールコンテキストを指定するために使用される。コンテキストフィールドの値は、ランタイム時にモジュール対応バスからわかる登録された送信側コンテキストの１つでなければならない。これは一般に、モジュールがインストールされたときに作成されたモジュールインスタンス識別子である。この属性の値、およびｍｅｓｓａｇｅＩＤ要素の一意の識別子の値は、ともに一意のメッセージインスタンス識別を構成する。
組となる２つのモジュールまたは構成要素にわたるべき等送信（ｉｄｅｍｐｏｔｅｎｔ ｔｒａｎｓｍｉｓｓｉｏｎ）は、メッセージインスタンス識別で渡された情報によって実行可能になる。ランタイム時は、再生状況によって所与のメッセージの二重処理が行われないようにするようにメッセージの再生の可能性を知っておくことは、受信側の責任である。
メッセージのスレッドの追跡、ソート、および順序付けを容易にするために、ある種の順序付け機構を確立することが必要である。好ましい機構は、元の要求の送信時間である。送信のタイムスタンピングは、送信側によって行われる機能である。タイムスタンプ要素を使用して、送信時間を表す。粒度は、秒単位まで細かくすることが好ましい。
例：
<ch:controlHeader
xmlns:ch="urn:schemas_microsoft_com:controlHeader:vl"・messageType
="messageURI">
<ch:messageID
context="senderContextlD">uniqueID</ch:MessageID>
<ch:timestamp・instant="2003-06-13T14:21:OOZ/>
タイムスタンプ要素は、ＸＭＬ日時表記法でフォーマットされた必須ｉｎｓｔａｎｔ属性を有する。送信側アプリケーションは、Ｚｕｌｕ時表記法を使用して、つまりグリニッジ標準時（ＧＴＭ）に変換されたタイムゾーン構成要素でタイムスタンプを表すことが好ましい。
要求および応答の意味の調和は、一般のビジネスアクティビティである。メッセージを直接論理子孫としてマークするために、ｐｅｒｔａｉｎｓＴｏＩＤと呼ばれる任意選択の要素が提供されて要求と応答の照合が行われる。
例：
<ch:controlHeader
xmlns:ch="urn:schemas_microsoft_com:controlHeader:vl"・messageType
="messageURI">
<ch:messageID
context="responderContextlD">uniqueID</ch:MessageID>・<ch:timestamp・instant="2003-06-13T14:21:30Z/>
<ch:pertainsToID
context="originalContextlD">uniqueID</ch:parentID>
・・・
</ch:controlHeader>
この例は、以前の要求に対する応答の制御ヘッダーの内容を示している。応答メッセージは、依然としてメッセージであるため、それ自体の一意のメッセージインスタンス識別子を有している。これは直接応答であるため、ｐａｒｅｎｔｌＤ要素は、制御ヘッダーに追加される。このｐａｒｅｎｔｌＤ要素は、もともと要求メッセージのｍｅｓｓａｇｅｌＤフィールドで渡された値で埋められる。ドメインモデルで定義された要件に基づいて、モジュールによって送信されるメッセージが直接応答でない場合、ｐａｒｅｎｔＩＤ要素は存在しない。
本発明の実施形態によって、全スタンドアロンビジネスソフトウェアシステムおよび／またはその構成要素を自動的にインストールし、管理できるようになる。この意味では、こうしたソフトウェアのインストールおよび操作は、プラグアンドプレイと考えることができる。本発明の実施形態によって提供される統合および操作の容易さによって、こうしたソフトウェアが使用可能になるにつれて、新しい、また向上されたビジネスソフトウェアの取得および配置が容易になる。
本発明は、特定の実施形態との関連で説明してきたが、本発明の意図および範囲から逸脱することなく、形態および詳細に変更を加えることができることを当分野の技術者であれば理解されよう。
本発明を実施できる適したコンピューティングシステム環境１００の一例を示す図である。 従来技術による１対のビジネスソフトウェアソリューションシステムの相互運用を示す略図である。 配置されたビジネスソフトウェアシステムの数が増加するにつれて従来技術の問題の複雑さがどのように増すかを示す従来技術の別のビジネスソリューションを示す略図である。 本発明の一実施形態によるビジネスソフトウェアソリューションを示す略図である。 本発明の一実施形態による統合ビジネスソフトウェアソリューションを示す略図である。 本発明の実施形態によるモジュールマップの一部を示す略図である。 本発明の一実施形態によるビジネスソフトウェアソリューションに配置されたビジネスソフトウェアアプリケーションを示す略図である。 本発明の一実施形態によるルーティング層の一部を示す略図である。 パターン層４１０に関連して図８に関して説明した動的ルーティング層４０６を示す略図である。
符号の説明
１００ コンピューティングシステム環境
１１０ コンピュータ
１２０ 処理ユニット
１２１ システムバス
１３０ システムメモリ
１３１ 読取り専用メモリ（ＲＯＭ）
１３２ ランダムアクセスメモリ（ＲＡＭ）
１３３ 基本入出力システム（ＢＩＯＳ）
１３４、１４４ オペレーティングシステム
１３５、１４５ アプリケーションプログラム
１３６、１４６ 他のプログラムモジュール
１３７、１４７ プログラムデータ
１４０、１５０ インターフェイス
１４１ ハードディスクドライブ
１５１ 磁気ディスクドライブ
１５２ リムーバブル不揮発性磁気ディスク
１５５ 光ディスクドライブ
１５６ リムーバブル不揮発性光ディスク
１６０ ユーザ入力インターフェイス
１６１ ポインティング装置
１６２ キーボード
１６３ マイクロフォン
１７０ ネットワークインターフェイスまたはアダプタ
１７１ ローカルエリアネットワーク（ＬＡＮ）
１７２ モデム
１７３ 広域エリアネットワーク（ＷＡＮ）
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインターフェイス
１９１ モニタ
１９５ 出力周辺インターフェイス
１９６ プリンタ
１９７ スピーカー
２００ システムＡコントローラ
２０２ 画面
２０４ データベース
２０６ システムＡ ＡＰＩ
２１０、２１２、２１８、２２０、２２２、２２４、２２６、２２８、２４２ アダプタ
２１６ システムＣ ＡＰＩ
２３２ システムＢ
２３４ システムＤ
２３６ 粗粒度ＡＰＩ
２３８ 細粒度ＡＰＩ
２４０ サードパーティアプリケーション
２５２ 接続
２５６、２５８ 半分部分
３１０ モジュールマップ
３１２、３１４ ビジネスソフトウェアアプリケーション
３２０ 全体計画モジュール
３２２ 販売注文管理モジュール
３２４ 配送モジュール
３２６ システム探索マネージャ
４００、４０２、４０４ ソフトウェアアプリケーション
４０６ 動的ルーティング層
４１０ パターン層

Claims (22)

  1. 少なくとも１つの第１の構成要素機能または第１の構成要素要件を有する第１のビジネスソフトウェア構成要素に関する情報を見つけることと、
    前記少なくとも１つの第１の構成要素機能または第１の構成要素要件をモデル駆動式バスの第１の役割にバインドすることと、
    少なくとも１つの第２の構成要素機能または第２の構成要素要件を有する第２のビジネスソフトウェア構成要素に関する情報を見つけることと、
    前記少なくとも１つの第２の構成要素機能または第２の構成要素要件をモデル駆動式バスの第２の役割にバインドすることと、
    を含むことを特徴とする複数のビジネスソフトウェア構成要素を操作する方法。
  2. 前記第１のビジネス構成要素に関する情報を見つけるステップは探索マネージャによって実行されることを特徴とする請求項１に記載の方法。
  3. 前記第２のビジネス構成要素に関する情報を見つけるステップは探索マネージャによって実行されることを特徴とする請求項２に記載の方法。
  4. 前記第１のビジネス構成要素に関する情報を見つけるステップは自動的に行われることを特徴とする請求項１に記載の方法。
  5. 前記第２のビジネス構成要素に関する情報を見つけるステップは自動的に行われることを特徴とする請求項４に記載の方法。
  6. 前記自動発見は前記第１のビジネスソフトウェア構成要素のインストールの一環として行われることを特徴とする請求項４に記載の方法。
  7. 前記第１のビジネスソフトウェア構成要素の少なくとも１つの機能は前記第２のビジネスソフトウェア構成要素の少なくとも１つの機能と重複し、前記モデル駆動式バスは、前記第１および第２のビジネスソフトウェア構成要素のうちの一方のみが重複する機能を提供するように調停を行うことを特徴とする請求項１に記載の方法。
  8. 前記第１および第２のビジネスソフトウェア構成要素の間に標準的なメッセージングを提供すること
    をさらに含むことを特徴とする請求項１に記載の方法。
  9. ビジネスプロセスを実行可能にすることができるかどうかを決定するために役割のバインドを検査すること
    をさらに含むことを特徴とする請求項１に記載の方法。
  10. 検査することはプロセスロールのバインドを事前定義されたプロセスパターン情報と比較することを含むことを特徴とする請求項９に記載の方法。
  11. 前記事前定義されたプロセスパターン情報はパターン適合層の一部であることを特徴とする請求項１０に記載の方法。
  12. 包括的なビジネス分類に従って設計された一時的に安定したインターフェイスを有するソフトウェアバスと、
    前記ソフトウェアバスの第１の部分にバインドされ、それを実行する第１のビジネスソフトウェア構成要素と、
    前記ソフトウェアバスの第２の部分にバインドされ、それを実行する第２のビジネスソフトウェア構成要素と
    を含むことを特徴とするビジネスソフトウェアシステム。
  13. 前記ソフトウェアバスは、前記ソフトウェア構成要素のそれぞれと通信するためのメッセージルーティング層を含むことを特徴とする請求項１２に記載のシステム。
  14. 前記ソフトウェアバスは、前記第１および第２のソフトウェア構成要素に関連して情報をチェックするためのパターン適合層を含むことを特徴とする請求項１２に記載のシステム。
  15. 前記ソフトウェアバスは前記構成要素のユーザ管理を容易にするための管理層を含むことを特徴とする請求項１２に記載のシステム。
  16. 前記ソフトウェアバスは複製層を含むことを特徴とする請求項１２に記載のシステム。
  17. 前記ソフトウェアバスは監査層を含むことを特徴とする請求項１２に記載のシステム。
  18. 前記ソフトウェアバスはキーパフォーマンスインジケータ層を含むことを特徴とする請求項１２に記載のシステム。
  19. 前記ソフトウェアバスは異なる包括的なビジネス分類とともに使用可能であることを特徴とする請求項１２に記載のシステム。
  20. 前記異なる包括的なビジネス分類のそれぞれはドメイン固有であることを特徴とする請求項１９に記載のシステム。
  21. 特定のビジネスソフトウェア構成要素と対話するようにカスタム構成されたソフトウェア構成要素側と、
    前記ソフトウェア構成要素側に連結され、標準的な耐久性のあるアプリケーションプログラミングインターフェイスと対話するように構成され、前記ソフトウェア構成要素によってサポートされない少なくとも１つのビジネスプロセスに関連するデータを含む標準化側と
    を含むことを特徴とする標準的なアダプタを定義する命令を格納するコンピュータ可読媒体。
  22. 前記スタンドアロンビジネスソフトウェア構成要素の機能をメタデータで記述することと、
    前記スタンドアロンビジネスソフトウェア構成要素の要件をメタデータで記述することと、
    標準的なソフトウェアアダプタを生成して、前記スタンドアロンビジネスソフトウェア構成要素を前記統合ビジネスソフトウェアシステムにインターフェイスすることと
    を含むことを特徴とする自動化統合ビジネスソフトウェアシステムで使用するためにスタンドアロンビジネスソフトウェア構成要素を改良する方法。

JP2004052375A 2003-03-12 2004-02-26 自動化されたビジネスソフトウェアアプリケーション統合 Pending JP2004280809A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US45453703P 2003-03-12 2003-03-12
US10/726,879 US7395540B2 (en) 2003-03-12 2003-12-03 Automated business software application integration

Publications (1)

Publication Number Publication Date
JP2004280809A true JP2004280809A (ja) 2004-10-07

Family

ID=32965748

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004052375A Pending JP2004280809A (ja) 2003-03-12 2004-02-26 自動化されたビジネスソフトウェアアプリケーション統合

Country Status (3)

Country Link
US (1) US7395540B2 (ja)
EP (1) EP1475700A3 (ja)
JP (1) JP2004280809A (ja)

Families Citing this family (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7424702B1 (en) 2002-08-19 2008-09-09 Sprint Communications Company L.P. Data integration techniques for use in enterprise architecture modeling
GB0315190D0 (en) * 2003-06-28 2003-08-06 Ibm Methods, apparatus and computer programs for visualization and management of data organisation within a data processing system
US7707255B2 (en) 2003-07-01 2010-04-27 Microsoft Corporation Automatic grouping of electronic mail
US8060553B2 (en) 2003-08-27 2011-11-15 International Business Machines Corporation Service oriented architecture for a transformation function in a data integration platform
US7814142B2 (en) * 2003-08-27 2010-10-12 International Business Machines Corporation User interface service for a services oriented architecture in a data integration platform
US8041760B2 (en) * 2003-08-27 2011-10-18 International Business Machines Corporation Service oriented architecture for a loading function in a data integration platform
WO2005022417A2 (en) * 2003-08-27 2005-03-10 Ascential Software Corporation Methods and systems for real time integration services
US7698383B2 (en) * 2004-02-27 2010-04-13 Research In Motion Limited System and method for building component applications using metadata defined mapping between message and data domains
US7283986B2 (en) * 2004-04-08 2007-10-16 International Business Machines Corporation End-to-end business integration testing tool
US7849438B1 (en) * 2004-05-27 2010-12-07 Sprint Communications Company L.P. Enterprise software development process for outsourced developers
US8255828B2 (en) 2004-08-16 2012-08-28 Microsoft Corporation Command user interface for displaying selectable software functionality controls
US8146016B2 (en) 2004-08-16 2012-03-27 Microsoft Corporation User interface for displaying a gallery of formatting options applicable to a selected object
US7703036B2 (en) 2004-08-16 2010-04-20 Microsoft Corporation User interface for displaying selectable software functionality controls that are relevant to a selected object
US20060064335A1 (en) * 2004-08-17 2006-03-23 International Business Machines Corporation Method, system, and storage medium for performing business process modeling
US7890484B1 (en) * 2004-11-10 2011-02-15 At&T Intellectual Property Ii, L.P. Method and apparatus for selecting services based on behavior models
US20060112122A1 (en) * 2004-11-23 2006-05-25 International Business Machines Corporation Method, system, and storage medium for implementing business process modules
US20070005461A1 (en) * 2005-06-10 2007-01-04 Lenz Kenneth R Business tax organizing method and system
US8484065B1 (en) 2005-07-14 2013-07-09 Sprint Communications Company L.P. Small enhancement process workflow manager
US7895572B2 (en) * 2005-08-15 2011-02-22 Sap Aktiengesellschaft Systems and methods for enterprise software management
US8239882B2 (en) 2005-08-30 2012-08-07 Microsoft Corporation Markup based extensibility for user interfaces
US8627222B2 (en) 2005-09-12 2014-01-07 Microsoft Corporation Expanded search and find user interface
US9251497B2 (en) * 2005-09-29 2016-02-02 International Business Machines Corporation Dynamic binding of process patterns in a method architecture
US7698685B2 (en) * 2005-10-12 2010-04-13 Microsoft Corporation Discovery, qualification, and activation of software add-in components
US7599861B2 (en) 2006-03-02 2009-10-06 Convergys Customer Management Group, Inc. System and method for closed loop decisionmaking in an automated care system
US7882058B1 (en) * 2006-04-20 2011-02-01 Xfi Corporation Method and apparatus for business resource automation
US8379830B1 (en) 2006-05-22 2013-02-19 Convergys Customer Management Delaware Llc System and method for automated customer service with contingent live interaction
US7809663B1 (en) 2006-05-22 2010-10-05 Convergys Cmg Utah, Inc. System and method for supporting the utilization of machine language
US9727989B2 (en) 2006-06-01 2017-08-08 Microsoft Technology Licensing, Llc Modifying and formatting a chart using pictorially provided chart elements
US7809703B2 (en) * 2006-12-22 2010-10-05 International Business Machines Corporation Usage of development context in search operations
US20080172276A1 (en) * 2007-01-12 2008-07-17 Burton Mary C Apparatus, system, and method for assessing information technology environment needs
US20080183514A1 (en) * 2007-01-29 2008-07-31 International Business Machines Corporation System and Methods for Using Solution Building Blocks
US8762880B2 (en) 2007-06-29 2014-06-24 Microsoft Corporation Exposing non-authoring features through document status information in an out-space user interface
US8484578B2 (en) 2007-06-29 2013-07-09 Microsoft Corporation Communication between a document editor in-space user interface and a document editor out-space user interface
US8706667B2 (en) * 2007-07-26 2014-04-22 Ab Initio Technology Llc Transactional graph-based computation with error handling
US8209211B2 (en) * 2008-03-18 2012-06-26 International Business Machines Corporation Apparatus and methods for requirements decomposition and management
US9588781B2 (en) 2008-03-31 2017-03-07 Microsoft Technology Licensing, Llc Associating command surfaces with multiple active components
US8266189B2 (en) * 2008-06-02 2012-09-11 Microsoft Corporation Adapting between coupled and decoupled provider interfaces
US9665850B2 (en) 2008-06-20 2017-05-30 Microsoft Technology Licensing, Llc Synchronized conversation-centric message list and message reading pane
CN101651669A (zh) * 2008-08-15 2010-02-17 国际商业机器公司 业务箱集成服务器和业务箱集成方法
US8799353B2 (en) 2009-03-30 2014-08-05 Josef Larsson Scope-based extensibility for control surfaces
US20100262557A1 (en) * 2009-04-14 2010-10-14 Ferreira Rodrigo C Systems, methods, and apparatus for guiding users in process-driven environments
US8019839B2 (en) 2009-05-11 2011-09-13 Accenture Global Services Limited Enhanced network adapter framework
US8412797B2 (en) * 2009-08-27 2013-04-02 Vmware, Inc. Platform for development and deployment of system administration solutions
US8302014B2 (en) * 2010-06-11 2012-10-30 Microsoft Corporation Merging modifications to user interface components while preserving user customizations
US9183124B2 (en) * 2011-04-18 2015-11-10 Accenture Global Services Limited Automation controller for next generation testing system
WO2013049542A1 (en) * 2011-09-30 2013-04-04 Competitive Insights Llc Method, apparatus and computer program product for providing a supply chain performance management tool
US9639898B2 (en) * 2012-03-28 2017-05-02 Oracle International Corporation Tax analysis tool
IN2013MU03381A (ja) * 2013-10-25 2015-07-17 Tata Consultancy Services Ltd
US9870203B2 (en) 2013-12-05 2018-01-16 Sap Se Consumption layer for business entities
US9612889B2 (en) 2015-02-27 2017-04-04 Wal-Mart Stores, Inc. Integrating applications
WO2016206047A1 (en) * 2015-06-25 2016-12-29 Intel Corporation Techniques for reliable primary and secondary containers
US10078497B2 (en) 2015-07-24 2018-09-18 Oracle International Corporation Bridging a module system and a non-module system
US9626171B2 (en) 2015-07-24 2017-04-18 Oracle International Corporation Composing a module system and a non-module system
US10104090B2 (en) 2015-08-25 2018-10-16 Oracle International Corporation Restrictive access control for modular reflection
US10394528B2 (en) 2016-03-30 2019-08-27 Oracle International Corporation Returning a runtime type loaded from an archive in a module system
US10191753B2 (en) 2016-03-30 2019-01-29 Oracle International Corporation Generating verification metadata and verifying a runtime type based on verification metadata
US10387142B2 (en) 2016-09-16 2019-08-20 Oracle International Corporation Using annotation processors defined by modules with annotation processors defined by non-module code
US10360008B2 (en) 2016-09-16 2019-07-23 Oracle International Corporation Metadata application constraints within a module system based on modular encapsulation
US10848410B2 (en) 2017-03-29 2020-11-24 Oracle International Corporation Ranking service implementations for a service interface
CN111770009B (zh) * 2020-06-29 2022-05-20 深圳市金蝶天燕云计算股份有限公司 一种数据传输方法及相关设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6295571B1 (en) * 1999-03-19 2001-09-25 Times N Systems, Inc. Shared memory apparatus and method for multiprocessor systems
US6996500B2 (en) * 2002-10-30 2006-02-07 Hewlett-Packard Development Company, L.P. Method for communicating diagnostic data
US7188155B2 (en) * 2002-12-17 2007-03-06 International Business Machines Corporation Apparatus and method for selecting a web service in response to a request from a client device
US8538840B2 (en) * 2002-12-20 2013-09-17 Siebel Systems, Inc. Financial services data model

Also Published As

Publication number Publication date
EP1475700A3 (en) 2006-01-04
US20040181471A1 (en) 2004-09-16
US7395540B2 (en) 2008-07-01
EP1475700A2 (en) 2004-11-10

Similar Documents

Publication Publication Date Title
JP2004280809A (ja) 自動化されたビジネスソフトウェアアプリケーション統合
US7093247B2 (en) Installation of a data processing solution
KR101087439B1 (ko) 소프트웨어 컴포넌트화
JP5541830B2 (ja) コンピューティング環境においてオブジェクトを記述するメタデータのカスタマイズのための方法
US7712085B2 (en) Use of attribution to describe management information
US7406483B2 (en) Provisioning of software components via workflow management systems
US8549514B2 (en) Distributing customized software products
US9020881B2 (en) Public solution model in an enterprise service architecture
US6820118B1 (en) Method and system for providing a linkage between systems management systems and applications
US20060229994A1 (en) Automatic generation of license package for solution components
US20110320574A1 (en) Method and system for performing application server configuration using configuration groups
US20040025157A1 (en) Installation of a data processing solution
US20060293911A1 (en) Methods, systems and computer program products for integrating carrier services into an enterprise
WO2003102722A2 (en) Collaborative business plug-in framework
US20050050320A1 (en) Branding framework
JP2004272908A (ja) システムの設計、展開、管理のフェーズを統合する方法
JP2008181536A (ja) ウェブ・サービスで構成された、インタネット・ホスティング・ビジネス・アプリケーションの開発システム
Capilla et al. An enhanced architectural knowledge metamodel linking architectural design decisions to other artifacts in the software engineering lifecycle
US20080288918A1 (en) Web service tool based on business object layer
US20040093580A1 (en) System and methodology for mobile e-services
Lindquist et al. IBM service management architecture
Juric et al. WS-BPEL extensions for versioning
Baird et al. Self-adapting workflow reconfiguration
Dunphy et al. Pro BizTalk 2006
Akram et al. A Data centric approach for Workflows

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070115

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100402

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100702

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100723