(57)【要約】  本発明は、送り状を作るデータアイテムを見つけるための手段を具備し、少なくとも１つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステムに関する。本発明に係るトランザクションシステムは、記憶された送り状データを含むデータ記憶と共に提供される、少なくとも１つのトランザクション処理モジュール（ＶＧＡ）を備え、前記トランザクション処理モジュール（ＶＧＡ）は、少なくとも１つのデータモジュールにインターフェースを介して接続されることを特徴とする。
2008530665.tif 000002
【特許請求の範囲】
【請求項１】
送り状を作るデータを得るための手段を具備し、少なくとも１つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステムであって、
前記トランザクションシステムは少なくとも１つのトランザクション処理モジュールを備え、
前記トランザクション処理モジュールは送り状を作るデータが記憶されるデータコンテナを備えるとともに、
少なくとも１つのデータモジュールにインターフェースを介して接続されることを特徴とする、トランザクションシステム。
【請求項２】
前記データモジュールは生データモジュールであることを特徴とする、請求項１に記載のトランザクションシステム。
【請求項３】
前記データモジュールはデータコンポーネントを備えることを特徴とする、請求項１又は請求項２のうちいずれか一方、又は両方に記載のトランザクションシステム。
【請求項４】
前記トランザクションシステムは、データコンテナを、始動、及び／又は、終了できるように構成される制御モジュールを備えていることを特徴とする、請求項１〜請求項３のうち１項以上に記載のトランザクションシステム。
【請求項５】
前記トランザクションシステムは、トランザクション処理モジュールを、始動、及び／又は、終了できるように構成されるコンテキストマネージャを備えていることを特徴とする、請求項１〜請求項４のうち１項以上に記載のトランザクションシステム。
【請求項６】
前記コンテキストマネージャは、互いに関係なく複数のトランザクション処理モジュールを、始動、及び／又は、終了できるように構成されることを特徴とする、請求項５に記載のトランザクションシステム。
【請求項７】
前記コンテキストマネージャは、制御モジュールとして構成されることを特徴とする、請求項４〜請求項６のうち１項以上に記載のトランザクションシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送り状を作るデータを得るための手段を具備し、少なくとも１つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステムに関する。
【０００２】
本発明はまた、トランザクションを遂行する方法にも関する。
【背景技術】
【０００３】
従来のトランザクションシステムならびに方法は、特許文献１及び前記特許文献１のドイツ語の翻訳文である特許文献２によって公知となっている。
【特許文献１】欧州特許第９３８７１５号明細書
【特許文献２】独国特許第６９７０７００９号明細書
【０００４】
従来のトランザクションシステムは複数の差出人と輸送会社とに、トランザクション情報を処理するための環境を提供している。該トランザクションシステムは、トランザクション情報を処理し、認証プロフィール基準を記憶し、前記トランザクション情報が該認証プロフィール基準と一致するか否かを確認する中央演算処理装置を有することで、前記認証プロフィール基準は許可されたユーザーについての情報を具備するものである。
【０００５】
可能な限り少数の条件を含み、提供されるサービスのために素早くタイムリーに送り状を作ることを可能にするトランザクションシステムを提供することが望まれる。
【０００６】
ここで「サービス」とは、決して限定的な方法を意味するわけではなく、販売、貸出、貸与にわたる商品の提供や、提供されるサービスのみならず例えばコミュニケーションシステム及び情報へのアクセスといった仮想空間上のサービスからなる。
【０００７】
ここで「サービスプロバイダ」とは、一般的に意味するところと同様であり、前記サービスを提供することのできるユニットを具備する。特に、前記サービスプロバイダは例えば商品若しくはサービスを提供する自動販売機のような物理的な装置であっても良いし、例えばサービスプロバイダ会社若しくは会社の支店、好ましくは複数の支店のような組織的なユニットであっても良い。
【発明の開示】
【０００８】
本発明の解決しようとする課題は以上の如くであり、次にこの課題を解決するための手段を説明する。
【０００９】
本発明の特に望ましい実施形態としては、送り状を作るデータを得るための手段を具備し、少なくとも１つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステムであって、前記トランザクションシステムが少なくとも１つのトランザクション処理モジュールを備えるように形成され、前記トランザクション処理モジュールはコンテキストマネージャに接続され、前記コンテキストマネージャは少なくとも一つのトランザクション処理モジュールと複数の各構成要素に接続されるものである。
【００１０】
本発明は、トランザクションを実行する方法も含む。
【００１１】
本発明は、あらゆる所望のトランザクションでの使用に適している。本発明に係るトランザクションは、当該トランザクションにおいては一連の演算が完全に実行される又は全く実行されない従来のトランザクションだけでなく、情報のみが提供される、及び／又は、関数だけが実行される、新規のトランザクションをも含む。本発明に係るトランザクションシステムは、従来のトランザクションだけでなく新規のトランザクションに対しても使用可能である点で優れている。
【００１２】
トランザクションの完全性を確保する必要がある場合は、従来のトランザクションに対して本発明を適用することが好ましい。この場合、データストックでのトランザクションの変更はトランザクションが完全に実行された時点で恒久的に記憶される。
【００１３】
さらに、本発明に係るトランザクションシステムは、本発明に応じて具備され、かつ、シェアされた処理シークエンスが不要である新しいトランザクションに対して使用可能である。この一例は、データストック内で変更のないアカウントバランスクエリである。特に、本発明に係るトランザクションは、情報の、及び、データを変更する関数並びにトランザクションの、及びデータを変更しない関数並びにトランザクションのあらゆる種類のプレゼンテーションを具備する。さらに、状態を維持しないトランザクションだけでなく、状態を維持するトランザクションをも具備する。
【００１４】
請求項２から７に記載のトランザクションシステムの有効な改良点を以下に記述する。
【００１５】
本発明はトランザクションシステムの多数の構成を可能にする。分散させていたデータ記憶装置を用いる具体例は、汎用性とフェ-ルセーフを向上させるために特に好適である。
【００１６】
トランザクション処理モジュールにおけるデータ記憶装置によって、トランザクションを処理するプロセッサーが、トランザクションを処理するために必要なデータのそれぞれに直接アクセスできることが保障される。
【００１７】
本発明の特に好ましい実施形態は、データオブジェクトを記憶するためのデータコンテナがトランザクション処理モジュール内で生成されるものである。
【００１８】
特に、データオブジェクトがデータの値を含んでいることが好ましい。
【００１９】
さらに、取得、及び／又は、処理のための1つ以上のコンポーネントは別として、トランザクション処理モジュールは、特にデータの値を含んでいるデータオブジェクトを記憶するためのデータコンテナを備えていることが望ましい。データオブジェクトの形式であるトランザクション処理モジュールのデータストックは、例えば、システム・クラッシュの後で容易に記憶され、修復することができる。
【００２０】
本発明の特に好ましい実施形態では、特に広範囲のデータバックアップは、特に簡単で信頼できるデータ修復と同様、トランザクション処理モジュールによって得られ、または処理される各データ要素がデータオブジェクトと関連付けられることを達成することができる。
【００２１】
データについての記述は、個々のデータ要素にもまた適用する。単語「データ」は複数形または単数形で使用されているかどうかに関わらず、1つの個々のデータ要素が意味される場合を明確に含んでいる。
【００２２】
データコンテナはこうしてトランザクションの全体の「状態」を含んでいる。全体のトランザクションはこうして特に単純にバックアップされ、必要ならば、修復することができる。データセキュリティの安全性を増すため、許容値の限界を示すデータ自体と共にプロパティデータのプロパティを含んでいることは、データオブジェクトにとって好ましい。これは数フォーマットのデータである場合もあり、例えば、値の範囲、又は規定された分散数値、さもなくば規定された文字列の最小長、及び／又は、最大長を示すことができる。
【００２３】
データ処理モジュールはこうして、データオブジェクトに記憶されるプロパティが適合プロパティ条件の変化にすぐに、かつ、単純に適合される。
【００２４】
データコンテナに含まれているデータオブジェクトに基づいて、トランザクションの挙動はまた規定することができる。挙動の構成はこうして主として、大部分は、機能ユニットが処理の大多数のために行われる標準操作にアクセスできるように、トランザクション処理モジュールの機能ユニットの設定から連結を解かれる。
【００２５】
既存のデータオブジェクトの値が変わるトランザクション処理モジュール内で、データの獲得を達成することができる。しかし同じように新しいデータオブジェクトを構築し、それらに値を入れることもまた可能である。データを表示するためには、データコンテナの値にアクセスすることも同様に可能である。
【００２６】
複数の各構成要素へ接続されるのと同様、少なくとも1つのトランザクション処理モジュールに接続されるように、トランザクション処理モジュールがコンテキストマネージャに接続することができ、そしてコンテキストマネージャが構成されるという方法が複数のトランザクション処理モジュールから成り立つネットワークで起こることが特に望ましい。
【００２７】
発明の特に好ましい実施形態は、コンテキストマネージャがトランザクション処理モジュールのための中央制御の方法として、かつ、トランザクション処理モジュールのための中央サービスプロバイダとして修正される。
【００２８】
さらにそれが接続された各構成要素の存在に関して問い合わせを可能にするように、コンテキストマネージャと、形成されるべきインターフェースがＩＳｕｐｐｏｒｔＳｅｒｖｉｃｅインターフェースに接続されることが望ましい。
【００２９】
発明の特に好ましい実施形態はデータ送信が通知コンポーネントによって遂行されることを特徴とする。
【００３０】
ここに、通知コンポーネントが、通知を送信するためのルートを選ぶためのセレクションモジュールを備えていることが特に望ましい。
【００３１】
トランザクション処理モジュールのシーケンスプランが、トランザクション処理モジュールが始まるとき読取られる構成ファイルで記憶されるように方法を遂行することが特に望ましい。
【００３２】
トランザクション処理モジュールのデータとの直接的な結合によって、新しいモジュールが加えられることも、他のトランザクション処理モジュールの操作能力を損なわないで、個々のトランザクション処理モジュールが取除かれることもまた可能である。
【００３３】
発明の特に好ましい実施形態では、トランザクション処理モジュールは少なくとも1つの付加的なデータモジュールに接続される。
【００３４】
付加的なデータモジュールは、複数のトランザクション処理モジュールにおいて、データ処理に使用することができる種類のデータを含んでいることが望ましい。
【００３５】
生データコンポーネントを使用して、トランザクションタイプは生データの記録を発生させる。コンテキストマネージャは媒介として役立ち、ＩＲＤＳＭａｎａｇｅｒインターフェースによってトランザクションタイプに生データコンポーネントのサービスを転送する。
【００３６】
生データの記録は複数、特に２つの部分から成っていることが望ましい。これらは、一方は、いわゆる固定フレームワークであり、他方は、ビジネストランザクションである。フレームワークは構造の点でスタティックである。この部分はすべての生データ記録の点から見て関連している技術的、及び手続き的データが記憶されるところである。ビジネストランザクションの要素はフレームワークにある。ビジネストランザクションは1つのタイプのビジネストランザクションから別のものに変わる手続き型データを含んでいる。
【００３７】
データコンポーネントは他のコンポーネントによって使用することができるフレームワークのコンポーネントであることが望ましい。例えば、データコンポーネントは、生データのリストの形でデータ材料の最初の獲得を処理する生データコンポーネントによって使用することができる。
【００３８】
さらに、トランザクションシステムがデータコンテナを活動化、及び／又は、非活動化をできるように形成される制御モジュールを備えていることが望ましい。
【００３９】
トランザクション処理モジュールは発明に従って、データコンテナがデータの可変値そして規定されたプロパティを含んでいるデータオブジェクトから成り立つというデータコンテナと同様、データを取得、及び／又は、処理するための少なくとも1つのコンポーネントを有するように形成される。
【００４０】
トランザクション処理モジュールはプロセス、例えばビジネスプロセスのマップするトランザクションを処理するのに使用されているモジュールと定義される。データ処理モジュールは、例えば1つ以上のプロセスを処理するためのコンピュータプログラムの要素として、または自立型コンピュータプログラムとして実行されることができる。
【００４１】
取得、及び／又は、処理のための1つ以上のコンポーネントは別として、トランザクション処理モジュールは特にデータの値を含んでいるデータオブジェクトを記憶するためのデータコンテナを備えていることが望ましい。データオブジェクトの形であるトランザクション処理モジュールのデータストックは、プロセシングシステム・クラッシュの後でこうして容易に、例えば、記憶され、修復することができる。
【００４２】
発明の好ましい実施形態では、表示方法のグラフィック・ユーザ・インタフェース内で描写することができるデータフィールドとデータオブジェクトがそれぞれ関連付けられる。
【００４３】
発明に係るトランザクションシステムの別の好ましい実施形態は、通知コンポーネントが通知当該通知を送信するために送信パスを選ぶためのセレクションモジュールを備えていることを特徴とする。
【００４４】
このトランザクションシステムの特に好ましい実施形態は、結合された生データレコードを管理するためのモジュールを備えたセッションマネージャを備えていることを特徴とする。
【００４５】
さらに、セッションマネージャが生データコンポーネントに接続されることが望ましい。
【００４６】
発明の特に好ましい実施形態は、コンテキストマネージャがトランザクション処理モジュールのための中央制御方法として、そしてまたトランザクション処理モジュールのための中央サービスプロバイダとして形成されることを特徴とする。特に、コンテキストマネージャは、トランザクション処理モジュールを始動し、停止し、終了させる。
【００４７】
前記トランザクションシステムは接続された各構成要素の存在の問い合わせを可能にするようにインターフェースが形成されるというコンテキストマネージャがＩＳｕｐｐｏｒｔＳｅｒｖｉｃｅＩＳｕｐｐｏｒｔＳｅｒｖｉｃｅインターフェース(ＩＳＳ)に接続されるように形成されることが望ましい。
【００４８】
さらに、前記トランザクションシステムは、データ送信を可能とする通知コンポーネント(ＫＩＳＳ)を具備することが好ましい。
【００４９】
本発明の特に好ましい実施形態は、前記通知コンポーネントは、通知を送信するための送信パスを選択するセレクションモジュールを具備することを特徴とする。
【００５０】
このように、異なる種類の通知を異なる送信パスに関連付けるとともに、送信容量を特に効率的に利用することが可能である。
【００５１】
さらに、セッションマネージャと生データコンポーネント間のデータ送信を制御できるように、コンテキストマネージャが形成されることが好ましい。
【００５２】
本発明のその他の効果、技術的特徴、及び実用的な改良については、以下の、従属項の請求項、及び図面を参照した好ましい実施形態の説明のとおりである。
【発明を実施するための最良の形態】
【００５３】
各図は以下を示す。
図１は本発明に係るトランザクションシステムを示す概略図である。
図２は本発明に係るトランザクションシステムの特に好ましい構成を示す概略図である。
図３は情報技術システムのブロックダイヤグラムを示す図である。
図４はトランザクションの論理的順序を説明するブロックダイヤグラムを示す図である。
図５は情報技術システムにおける論理的コンポーネント間の生データの交換を説明するブロックダイヤグラムを示す図である。
【００５４】
本発明に係るトランザクションシステムは、トランザクション処理の特に効果的な実行を可能とするように、複数の相互に関連するコンポーネントを備えている。
【００５５】
図では、複雑なデータベースシステムのデータの生成、管理及び送信が示されている。データ処理システムは、それぞれが（好ましくは個別に）データを受信及び／又は送信する複数のトランザクション処理モジュールを具備する。
【００５６】
ここで、異なる属性を伴う処理すべきデータ容量が特に大きいので、複雑なシステムにおいて本発明を使用することは有効であり、本発明の積極的効果により優位な結果を得ることができる。
【００５７】
しかし、同様に本発明をより複雑でないシステムにも使用することができ、同様により効果的なネットワーク資源の利用という効果を得ることができる。
【００５８】
本発明は、特に、一つ以上のサーバを具備するネットワークでの使用に好適である。最初に、クライアントはアプリケーションのフレームワークを初期化する。これにより、クライアントは、例えば、データベースや支払のモジュールといった他のフレームワークのコンポーネントを伴うプラットフォームを使用することができる。本発明の好ましい実施形態では、ＣＡＲＢＯＮ（Ｃｏｍｐｏｎｅｎｔ  ＡＲｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  Ｂｕｓｉｎｅｓｓ  ＯｐｔｉｍｉｚａｔｉｏＮ）プラットフォームと呼ばれるプラットフォームを使用することができる。このＣＡＲＢＯＮプラットフォームは適当なハードウェア装置（例えば、プログラム可能な電気的要素に基づく装置）のみならず、ソフトウェアを使用することによって実行され、データ処理システムにインストールされている。
ここで、前記フレームワークは、ＣＬＲ（Ｃｏｍｍｏｎ  Ｌａｎｇｕａｇｅ  Ｒｕｎｔｉｍｅ）と呼ばれる前記プラットフォームの作動時間ライブラリを具備する。前記クライアントによるアプリケーションのフレームワークの初期化後、該クライアントがフレームワークのカーネルを初期化して始動することが好ましい。前記カーネルの初期化の前に、例えばプログラムの完全性に関連するテストが実行される。さらに、始動か、もしくは、トランザクションの中断によって生まれた修復の場合か、をチェックすることが可能となる。
【００５９】
データコンポーネントを伴うトランザクション処理モジュールは、クライアント側に配置されることが好ましい。ここで、特に、使用されているフレームワークに関する付加的なコンポーネント又は機能ユニットは、データコンポーネントとトランザクション処理モジュールとの間にインストールされることによって、間接的な接続が可能となる。前記データコンポーネントはコンピュータシステムの入力側に配置されることが好ましいが、システムの構成によっては、出力側にも接続可能である。前記トランザクション処理モジュールは電気的に該トランザクション処理モジュールによって処理される、トランザクション若しくはビジネスプロセスをマップする。これらのトランザクションは、例えば保険、金融または物流部門において使用される小売システムに関するトランザクションである。さらに、複数の異なるトランザクション処理モジュールのバージョンがクライアント側にインストールされている。トランザクション処理モジュールが始動されたとき、最も高いバージョン番号を有するバージョンが自動的に選択される。これを可能にするため、トランザクション処理モジュールは、特定の順序でトランザクション処理モジュールディレクトリに格納されていることが好ましい。
【００６０】
入力側は従業者がタスクを遂行するワークプレースを特に示す。例えば、ブランチの従業者は顧客の要求を受け取り、完全にすべての必要な情報を入れることで従業者を助けるグラフィック・ユーザ・インタフェースを使用して、例えば、顧客のデータ、顧客の要求等を得る。
【００６１】
出力側はバックグラウンドシステムを特に示す。バックグラウンドシステムでは、トランザクションは記録され、顧客データは記憶される。さらに、バックグラウンドシステムで、データは特に適切なアカウント原則に応じるために、ミラーリングされ、アーカイブされる。
【００６２】
特に好ましい実施形態において、それらをつなぐのに使用されている入力側、出力側及びコンポーネントはブランチシステムを形成する。
【００６３】
本発明の好ましい実施形態では、トランザクション処理モジュールは同様にフレームワークに接続されており、該フレームワークはオブジェクト指向及びコンポーネント指向で構成されていることが好ましい。前記フレームワークはＡＰＩ（アプリケーションプログラミングインターフェース）であり、該ＡＰＩは多様なサポートを基礎としたトランザクションのために生成するクライアントの機能を提供する。前記フレームワークによって提供される機能性は、例えば、クライアントもしくはトランザクション処理モジュールの始動／終了を行うカーネルの機能を具備する。
前記フレームワークは、トランザクション処理モジュールを始動するための共有の始動モジュールを具備する。さらに、前記フレームワークは、データ管理及びシーケンス制御においてトランザクション処理モジュールを支援し、データにアクセスするための、又は印刷するためのコンポーネントを具備する。さらに、記録すること若しくはエラー処理することのような基礎的な機能が提供される。
【００６４】
Ｃ＃は、例えば完全に前記フレームワークにおいてオブジェクト指向のプログラミング言語として使用され得るものである。オブジェクト指向プログラミングはオブジェクト−クラスの関係を要求する。ここで、クラスは共有された構造及び／又は共通の振る舞いを有するオブジェクトに対する抽象的な一般名称である。ここで、オブジェクトはクラスのインスタンスであり、前記クラスのために記憶領域が用意され、前記クラスはプログラムの実行時間中に存在するものである。一つのオブジェクトは一つのクラスのインスタンスである。このように、一つのクラス及び該クラスのオブジェクトは、属性、操作性、信頼性、関連性によって特徴付けられており、前記クラスは前記属性及びメソッドを統合してユニットとするものである。標準的な特徴として、前記属性は前記クラスのメソッドを使用してのみアクセスすることができるので、カプセル化又はアクセス制限を実現するものである。さらに、一つのクラスは明示のインターフェース若しくは一つ以上の明示のインターフェースを有することができず、前記カプセル化によって前記インターフェースから実装環境を別離することとなる。
【００６５】
本発明の特に好ましい実施形態では、前記トランザクション処理モジュールは、自立型プログラムではなく、むしろ実行されるためのクライアントの基盤を要求する。しかし、前記トランザクション処理モジュールは、例えばトランザクション処理モジュール自身の停止及び／又は他のトランザクション処理モジュールの始動を引き起こす能動的なコンポーネントである。ワークプレースのスタックにおける停止は別のレイヤーを適用することによってより好ましい効果を与えられる。
【００６６】
さらに、個々のトランザクション処理モジュールは前記クライアント側の入力側に配置されることが可能となり、別の領域が出力側に、つまり、中央サーバアプリケーションに、又はサードパーティシステムに位置することが可能となる。
【００６７】
好ましくは、いくつかのトランザクション処理モジュールが、それぞれがトランザクションをマップする計算手段にインストールされていることが好ましい。この場合、前記トランザクション処理モジュールは、コンピュータシステムの入力側又は出力側に配置される。前記データコンポーネントのような前記トランザクション処理モジュールは入力側に配置されることが好ましい。さらに、コンピュータシステムが、いくつかのコンポーネントによって構成されるのは好ましい。
【００６８】
本発明の特に好ましい実施形態では、トランザクション処理モジュールが統合されているトータルシステムは、トランザクションが最も小さい機能ユニットに分解された高度にモジュール化された方式である。従って、トランザクション処理モジュールは特に他の、複数のトランザクション処理モジュールの要素であるプロセスをマップすることができる。例えば、トランザクション処理モジュールはバー・コードのスキャン、個人的なアイデンティティデータの獲得または値の計算をマップすることができる。これらの個々のプロセスは、ただ一度実行されなければならないように、他のトランザクション処理モジュールによってモジュールとして呼ぶことができる。
【００６９】
コンピュータシステムは少なくとも２つのデータソースかデータ受信端末から成り立つ。データソースはデータが供給される起源の場所である。データ受信端末はデータ及びこうして受け取るサイトの行先である。データの受け取りは普通、標準化されたインターフェースによって起こる。データソース及びデータ受信端末は、例えば、ローカルデータベース、サーバに支援されたデータベース、アプリケーションサーバまたはサードパーティシステムいずれの場合もある。以下、簡単に、そのようなデータソース及びデータ受信端末を一般にデータシステムと呼ぶ。データシステムは出力側と同様、入力側に置くことができる。図１で示されている具体例では、最初のデータシステムは２つの付加的なデータシステムが入力側ＦＥと関連付けられるべきである一方、出力側ＢＥと関連付けられるべきである。
【００７０】
生データの発送はＣＡＲＢＯＮフレームワークＣＦを使用することが望ましい。入力側で得られるすべてのデータは、生データの記録の形でＣＡＲＢＯＮフレームワークによって出力側に送られることが望ましい。
【００７１】
さらに、例えば、切手の自動販売機のような自動販売機を制御するコンピュータは、自動販売機が同様に、記憶ユニット及びプロセッサーユニットが装備されているコンピュータに接続されて表示し、入力する手段を備えるというデータ処理システムとして使用することができることが望ましい。
【００７２】
ＣＡＲＢＯＮプラットフォームに基づいて、トランザクションはまたネットワークのような、例えば、ローカルネットワークまたはインターネットによって扱うことができる。プラットフォームは、ネットワーク上でサーバ・コンピュータに接続されるクライアントコンピュータを介して、当業者に公知の方法で操作される、サーバ・コンピュータに設けられている。
【００７３】
処理を実行するため又は遂行するために、ＣＡＲＢＯＮプラットフォームは、様々なデータ資源及びデータシンクへのアクセスを制御し、かつ、例えば、トランザクションの実行に必要な、顧客データのようなデータを提供する、データコンポーネントと、例えば、印刷サービス、又は、手持ちスキャナ若しくはＩＣカードリーダのような基礎的なサービスを提供する、所謂ＣＡＲＢＯＮホストＣＨと、トランザクションの処理中に要求され、かつ、処理される、ダウンストリームデータを、アカウンティングシステム又はデータ管理システムなどのシステムに送信する、コンポーネントと、を具備する。
【００７４】
プロセスは、トランザクションを実行するためのトランザクション処理モジュールとそれぞれ関連付けられるトランザクションによって、ＣＡＲＢＯＮプラットフォーム内でマップされる。モジュール構造は、多数のプロセスの要素である部分的なプロセスにまでプロセスを分解することを可能にする。技術者に知られているこの原則のために、部分的なプロセスはトランザクションとしてだけ一度実行されなければならず、総プロセスの処理の間に各々の総プロセスを実施する必要なしに呼び出すことができる。
【００７５】
従って、プロセスの実行で、一般に、部分的なプロセスをマップする複数のトランザクションは、それぞれトランザクション処理モジュールによって扱われ、遂行される。様々なトランザクション処理モジュールを処理するために、ＣＡＲＢＯＮプラットフォームは、トランザクション処理モジュールを初期設定するためにも特に使用されているコンテキストマネージャを備える。
【００７６】
発明に係るコンポーネントは、複数の組み合わせが特に望ましいが、個々のコンポーネントは既に有効な効果を有する。
【００７７】
本発明の特に好ましい実施形態を以下に示す。
【００７８】
［アダプタコンポーネント］
前記インターフェースのようなアダプタコンポーネントは、アクセスコンポーネントと多様なデータシステムの間の接続を構築する。前記アダプタコンポーネントは、前記アクセスを、サポートされたデータシステムのネイティブインターフェースにカプセル化し、特にオンライン及びオフラインによるデータシステムの接続を許可する。前記アダプタコンポーネントは、好ましくは直接データシステム又は使用されるミドルウェアによって構築されるものであれば好ましい。
【００７９】
例えば、多種のデータベースに接続するための適切なアダプタが具備される。使用されるフレームワークによって、例えば、ＯＬＥＤＢ（Ｏｐｅｎ  ＤａｔａＢａｓｅ  Ｃｏｎｎｅｃｔｉｖｉｔｙ）アダプタ、ＳＱＬ（Ｓｔａｎｄａｒｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）アダプタ、及びＥＤＢＣ（Ｅｎｈａｎｃｅｄ  ＤａｔａＢａｓｅ  Ｃｏｎｔａｉｎｅｒ）アダプタは、ローカルデータベースアクセスのためのアダプタとして使用される。好ましくは、適切なデータ動作がそれぞれのアダプタに具備されるべきである。
【００８０】
前記アダプタコンポーネントは、また、オンライン及びオフラインによるデータシステムへの接続のための適切なアダプタも具備している。例えば、もしデータシステムがオンラインで接続可能な場合は、適切なアダプタが提供される。逆に、データシステムがオフラインで接続されている場合は、アダプタはオフラインに接続できることが必要となる。データ接続のために、例えば、ミドルウェアは、前記アダプタが直接前記ミドルウェア上で構築されるように使用される。図１に示すように、出力側のデータシステムは通知コンポーネントＫＩＳＳを経由して、入力側に接続されており、専用のアダプタが前記データシステムに接続するためのアダプタコンポーネントに具備されている。ここでは、ミドルウェアも同様に使用されている。
【００８１】
［アプリケーションマネージャ  ＡＭ］
システム始動の間、前記アプリケーションマネージャはＣＡＲＢＯＮの操作に必要な全てのオブジェクトを生成及び初期化する。さらに、前記アプリケーションマネージャは、付随する制御メカニズムを伴ってメインウィンドウという形式でグラフィックアプリケーションフレームワークを提供する。
【００８２】
［承認モジュール  ＢＭ］
承認モジュールは様々な承認（例えば、承認の機能として表われたメニュー構造の制御）を制御する。但し、承認の概念は提供された記述に基づいて他の要素に従って拡大されなければならない。
【００８３】
［ライブラリ］
ライブラリはＣＡＲＢＯＮフレームワークの基礎的な機能を具備する。前記基礎的な機能は、例えば、記録すること、エラーを処理すること、システム情報へのアクセスなどの機能である。
【００８４】
ライブラリの機能は、クライアント側の通信基盤を必要としない。特に、それぞれ適切に構築されたプログラムは、ライブラリの機能にアクセスすることができる。ライブラリはユーザーへの直接のダイアログではなく、確実にユーザ・インタフェースと関連付けられるコンポーネントを具備することが好ましい。前記コンポーネントはＣＡＲＢＯＮフレームワーク、クライアント、又はトランザクション処理モジュールによって使用される補助機能（メッセージ表示）である。
【００８５】
［ＣＡＲＢＯＮ］
ＣＡＲＢＯＮは、好適に次の構成要素を具備するプラットフォームに関するものである。
（１）クライアント
（２）トランザクションタイプ
（３）コンポーネント
（４）ライブラリ
【００８６】
［ＣＡＲＢＯＮクライアント］
ＣＡＲＢＯＮクライアントは、個別の機能／アプリケーションを始動する。いくつかのＣＡＲＢＯＮクライアントはお互いに隣接して存在する。
【００８７】
基本的に、全てのプログラムは、ＣＡＲＢＯＮネットワーク全体、又はＣＡＲＢＯＮネットワークの一部のどちらかを使用するクライアントとして参照することができる。大部分において、前記プログラムはいくつかのトランザクションを実行することを目的とするプログラムである。しかし、ＣＡＲＢＯＮホストのような、他のＣＡＲＢＯＮクライアントにサービスを提供する他のプログラムもまたクライアントとして参照することができる。
【００８８】
［ＣＡＲＢＯＮフレームワーク  ＣＦ］
ＣＡＲＢＯＮフレームワークは、いくつかのモジュールをまとめて有することが好ましい。ＣＡＲＢＯＮフレームワークは、アシスタントを基礎とするトランザクションタイプのためのクライアントを生成する機能を具備するＡＰＩであることが好ましい。
【００８９】
ＣＡＲＢＯＮフレームワークの範囲において提供される前記機能は四つの作業エリアにグループ化されることが好ましい。
（１）コア機能−前記クライアントの始動／終了、トランザクションの始動／終了、又は管理
（２）トランザクション補助（マスク、データ管理、シーケンス制御等）
（３）コンポーネント（データへのアクセス、印刷等）
（４）基礎的機能の供給（記録すること、エラー処理等）
【００９０】
［ＣＲＡＢＯＮホストＣＨ］
ＣＡＲＢＯＮホストは、他のモジュール若しくはサービスを起動、終了、若しくは停止することができるホストモジュールである。
【００９１】
［ＣＡＲＢＯＮカーネル］
ＣＡＲＢＯＮカーネルの機能が実装された領域は、ＣＡＲＢＯＮカーネルと呼ばれる。
【００９２】
ＣＡＲＢＯＮカーネルは複数のコンポーネントで構成することが好ましい。前記コンポーネントの一例を以下に示す：
すなわち、Ｅｐｏｓ．アプリケーション、ＣＡＲＢＯＮ．コンテキスト、ＣＡＲＢＯＮ．リカバリー、及びＣＡＲＢＯＮ．セッションである。
特に、前記コンポーネントは次の機能を実行するために構成されることが好ましい。
（１）Ｅｐｏｓ．アプリケーション−アプリケーションの始動、アプリケーションフレームワークの初期化及び管理、
（２）ＣＡＲＢＯＮ．コンテキスト−トランザクションタイプの始動、停止、管理、ホスティングサービス、バックアップ、修復の制御、
（３）ＣＡＲＢＯＮ．リカバリー−バックアップ、修復のためのデータ記録、管理、
（４）ＣＡＲＢＯＮ．セッション−セッションの管理。
【００９３】
このように、前記カーネルは、ＣＡＲＢＯＮフレームワーク及びクライアントの基礎的機能を構成する。前記フレームワークは多数の受動的アセンブリから構成されていることが好ましいので、前記フレームワークを読み込んでインスタンス化する中央エントリーポイントが存在する。
【００９４】
この作業は、クライアントによって実行されることが好ましい。
【００９５】
Ｅｐｏｓ．ｅｘｅは、ＥＰＯＳクライアント（ＥＰＯＳ．ＥｎｔｒｙＰｏｉｎｔクラス）への前記エントリーポイントを定義する。前記アプリケーションマネージャはインスタンス化され、フレームワークの始動が始動され、更なる処理進行の間に始動トランザクションが読み込まれる。
【００９６】
［ＣＡＲＢＯＮカーネルの構造］
図２は、ＥＰＯＳクライアントの基礎的な構造を示す図である。中段は前記フレームワークのカーネルで構成されている。
【００９７】
［ＣＡＲＢＯＮフレームワーク］
図２で見られるように、アプリケーションマネージャ、コンテキストマネージャ、リカバリーマネージャ及びセッションマネージャのクラスはフレームワークの中央切換えポイントであることが特に望ましい。
【００９８】
［ＣＡＲＢＯＮトランザクションタイプ］
トランザクションタイプは、処理手順についてのシステム技術的マップを構成する。ＣＡＲＢＯＮフレームワークでは、境界条件や規則がトランザクションタイプの指定及び生成と効果的にリンクしている。
【００９９】
トランザクションタイプはビジネスプロセスの電子演算子である。いくつかのマスクから成り立つユーザ・インタフェースの部分に加えて、トランザクションタイプはまたマップされたビジネスプロセスのビジネス・ロジックを具備する。
【０１００】
トランザクションタイプは自立型プログラムでなく、クライアントの下部組織が実行されることを必要とする。それらはこのようなユーザーとの直接ダイアログである要素から成り立ち、この要素はユーザ・インタフェース(マスク)と関連付けられる。
【０１０１】
トランザクションタイプの実施形態は、以下の特徴の1つ以上があることを特徴とすることが特に好ましい。
【０１０２】
トランザクションタイプは使用可能なＣＡＲＢＯＮコンポーネント(例えばトランザクションタイプ制御)を使用するべきである。
【０１０３】
トランザクションタイプの複数の異なったバージョンは1人のクライアントに存在する場合もある。ＣＡＲＢＯＮフレームワークはもっとも数の高いバージョンを常に選択する。
【０１０４】
ユーザ・インタフェースはトランザクションタイプのビジネス・ロジックから厳密に分離されている。このために、既に最新式から知られているＭＶＣモデルはＣＡＲＢＯＮフレームワークで使用されることが望ましい。
【０１０５】
ＭＶＣモデルは特にプログラムプロパティを分けるための設計パターンである。設計パターンはプログラムを複数のユニットに、特にデータモデル、プレゼンテーション及びプログラム制御の３つのユニットに分けるのに役立つ。言葉モジュール、視界及びコントローラーはユニットのために明瞭な指定として使用される。
【０１０６】
適用範囲が広いプログラム・デザインはＭＶＣモデルの使用によって達成することができる。これは簡単な修正か拡張を可能にする。さらに、それは個々のコンポーネントが再使用されるようにする。
【０１０７】
原則として、グラフィック描画のためのトランザクションタイプは複数のマスクから構成される。前記マスク間のナビゲーションは線形及び非線形である。
【０１０８】
ＣＡＲＢＯＮフレームワークからのＧＵＩ制御は、ユーザー側のインターフェースを構成することを目的として、トランザクションタイププログラマーにより取得できる。
【０１０９】
トランザクションタイプは、他のトランザクションタイプから呼び出されることも可能である。双方向でのデータ交換はトランザクションタイプ間で行うことができる。
【０１１０】
ＣＡＲＢＯＮフレームワークのバックアップ／修復システムがバックアップできるように、前記トランザクションタイプを直列化できる。
【０１１１】
前記トランザクションタイプは基礎サービスに利用できる。
【０１１２】
［コンテキストマネージャ  ＣＭ］
コンテキストマネージャはトランザクションタイプのための中央制御の要素そして中央サービスのプロバイダである。利用できるサービスの決定は、リンクされたコンポーネントをただすことによるコンテキストマネージャによって、ＩＳｕｐｐｏｒｔＳｅｒｖｉｃｅsインターフェースを通してなされる。
【０１１３】
［データコンテナＤＣ］
前記データコンテナは、実行される処理手順のコンポーネントを具備する。換言すれば、トランザクション処理モジュールＶＧＡの状態が前記データコンテナＤＣのコンポーネント上の具体的な値に影響される。データコンテナＤＣはフィールドコンテンツの変化がＧＵＩにおいて発生した場合に、ビジネスオブジェクトへの修正及びフィードバックを許可する。前記データコンテナＤＣは、更なる値が好ましいために、該更なる値に常に占められる。
【０１１４】
この発明はデータコンテナＤＣの要素で小売りのクライアントユーザーの入力データを記憶することを提供する。
【０１１５】
発明に係るデータ記憶装置はシステムの汎用性及びシステムの失敗に対する安全性を高める。
【０１１６】
［データコンポーネントＤＫ］
前記データコンポーネントは、構成ファイルに接続されるデータレコードを参照する。前記構成ファイルは局所的に記憶されたデータへの中央アクセスを許可する。
【０１１７】
特に好ましい実施形態では、前記データコンポーネントは、ビジネスレイヤー、技術管理レイヤー、技術適用レイヤーによって構成されている。データコンポーネントは局所的であって、出力側に位置するデータ資源への接続を制御する。この目的のために、ＫＩＳＳへのインターフェースが存在する。
【０１１８】
本発明によるデータコンポーネントＤＫは、少なくとも一つの機能コンポーネントＦＫ、一つの接続コンポーネントＺＫ及び一つのアダプタコンポーネントＡＫを具備することが好ましい。
【０１１９】
［ＫＩＳＳ］
通知コンポーネントＫＩＳＳ（コンポーネント基礎構造サービス）
前記通知コンポーネントは、送受信通知の送信パスの選択を許可する。
【０１２０】
さらに、通知コンポーネントＫＩＳＳは出力側と入力側をつなぐのに使用することができる。このために、出力側と同様、入力側は適したインターフェースで形成される。通知コンポーネント内のデータ通信はＸＭＬかＳＯＡＰに基づくことが望ましい。発明の特に好ましい実施形態では、入力側及び出力側のコンピュータ平均の連結は、異なった速度を持っているコミュニケーションパスで確立することができる。例えば、ミドルウェアはコミュニケーションパスに使用することができる。
【０１２１】
通知コンポーネントの特に好ましい実施形態は、データを送る複数の(例えば、リモート、オフラインパス、オンライン要求の３つの)可能性があり、そのＫＩＳＳは送信経路の最適化を行うことを特徴とする。かなりの送信費用がこの方法で節約される。オンライン要求の間に、オフラインパスのための特定データの「移動」が達成される。
【０１２２】
通知コンポーネントは、問い合わせの伝達目的に適切なデータ転送速度で通信チャネルを選ぶための選択方法を備えるように形成されることが望ましい。
【０１２３】
通知コンポーネントＫＩＳＳの効果的な改良は、送信チャンネルが既に比較的重要度の高いデータの送信のために空けられているときに比較的重要度の低いデータを「移動する」ことにある。
【０１２４】
前記通知コンポーネントＫＩＳＳの特に有効な点は、他の目標となるアーキテクチャのコンポーネントが、ＫＩＳＳの操作についての内的モードから独立して、ＫＩＳＳの機能を使用できることである。
【０１２５】
［コンポーネント］
コンポーネントは、好ましくは分割されたプログラムユニットとしてセットアップされる、機能の集合である。コンポーネントは、ある作業（例えば、顧客データの管理）を実行するために、ＣＡＲＢＯＮカーネル、トランザクションタイプ、及び他のコンポーネントによって使用されるものである。コンポーネント使用の目的は、複数のトランザクションタイプが同一のコンポーネントにアクセスできる機能の冗長な開発を避けることにある。
【０１２６】
コンポーネントは、自立型のプログラムでは無く、実行されるためのクライアント側の基礎的構造である必要がある。好ましくは、コンポーネントは、ユーザ・インタフェースと接続されるコンポーネントを全く持っていないものである。さらに好ましくは、コンポーネントは、直接にはユーザーのダイアログ内にはなく、むしろトランザクションタイプもしくは他のコンポーネントを介して呼び出されるものである。
【０１２７】
ＣＡＲＢＯＮコンポーネントは実際の機能性に加え、コンポーネントファクトリを具備するユニットでもある。このファクトリは、
（１）コンポーネントについての情報を提供する
（２）一貫性及び必要な点検を遂行することを可能にする
（３）要求されたタイプの目的の例を提供する。
【０１２８】
この構造は、一定の方法でオブジェクトインスタンスを生成することを可能とする。原則として、インターフェースはファクトリによって要求されることから、インスタンスによって生成されたクラスは全く問題なく改良若しくは交換され得る。
【０１２９】
コンポーネントはトランザクション処理モジュール、ＣＡＲＢＯＮカーネルまたは他のコンポーネントによって使用される。ライブラリはコンポーネントを使用しないことが望ましい。
【０１３０】
ＣＡＲＢＯＮが出力側で有効であることを保障するため、ＣＡＲＢＯＮコンポーネントは状態を維持せずにおくべきである。それらは中央データ記憶装置でファイルすることができるが、その必要はない。
【０１３１】
前記ファクトリは、コンポーネントのクラスについてのインスタンスを生成せずにコンポーネントを使用するための必要条件をチェックすることを可能とする。この目的のために、一貫性及び必要条件のチェックメソッドを実装する。
【０１３２】
［構成ファイル］
本発明によれば、構成ファイルは、機能コンポーネントに読み込まれ、これにより、前記構成ファイルはデータシステムへのアクセスのためのプロシージャの情報を具備する。前記構成ファイルは、ＸＭＬフォーマットの形で存在することが好ましく、全てのデータ・アクセスをカプセル化するためのＤａｔａＳｅｒｖｉｃｅクラスを初期化する。機能コンポーネントは、トランザクション処理モジュールのプロシージャのコンテンツを形成し、これにより、例えば、情報は、トランザクション処理モジュールによって必要とされるデータが蓄積されているデータ資源、又は、トランザクション処理モジュールによって取得されるデータがファイルされているデータシンクを示す構成ファイルにファイリングされる。さらに、入力値及び出力値の妥当性の検討は、機能コンポーネントによって実行される。複数のデータシステムからのデータの合併は、機能コンポーネントによって実行される。データシステムへのアクセスの技術的詳細は、機能コンポーネントには含まれないことが好ましい。
【０１３３】
［ミドルウェア］
ミドルウェアは、アプリケーションの間を仲介するためのサービスを提供するアプリケーション独立コンポーネントである。ミドルウェアは複雑なソフトウェアシステムにおける水準であり、更なる他の離間したソフトウェアコンポーネントのサービスプロバイダとして、相互間の通信を許可する。
【０１３４】
［モデルビューコントローラ］
前記モデルビューコントローラは、ユーザ・インタフェースと、データと、処理とを確実に分割するものである。
【０１３５】
［周辺コンポーネント］
周辺コンポーネントを介して、ＣＡＲＢＯＮは周辺を直接制御する。特別にプログラムされたインターフェースは、ＣＡＲＢＯＮによって規定されたプロパティを具備するいかなる装置への接続も許可する。
【０１３６】
［リカバリーマネージャＲＭ］
リカバリーマネージャは、一定の間隔を置いてクライアントの状態を記憶し、必要ならば再びもとに戻す。
【０１３７】
［生データコンポーネント］
生データコンポーネントを使用することにより、トランザクションタイプは生データレコードを生成する。前記コンテキストマネージャは、仲介手段としての役割を果たす、つまり、生データコンポーネントのサービスを、インターフェースを介してトランザクションタイプに転送するものである。
【０１３８】
［アクセスコンポーネント］
データコンポーネントのアクセスコンポーネントは、データシステムの動作についての技術情報を備え、技術的な処理層を構成する。それはデータシステムへの技術的なアクセスを発生させ、パラメータで表すための論理を備えるが、手続き型論理は備えないことが望ましい。データシステムへのアクセスはインターフェースと技術的なアダプタのクラスによってＤａｔａＡｃｔｉｏｎｓの形で達成されることが望ましい。
【０１３９】
アクセスコンポーネントはＤａｔａＳｅｒｖｉｃｅの抽象的なクラスとして形成されることが望ましい。それはすべてのＤａｔａＡｃｔｉｏｎｓのためのファクトリとして作用する。ＤａｔａＡｃｔｉｏｎはＩＤａｔａＡｃｔｉｏｎインターフェースを実行するクラスによって実行される。ＤａｔａＡｃｔｉｏｎとして機能する各クラスはＩＤａｔａＡｃｔｉｏｎインターフェースを実行しなければならない。すべての部門及びサーバに支えられたデータ・アクセスは、このＩＤａｔａＡｃｔｉｏｎインターフェースによって実行される。ＩＤａｔａＡｃｔｉｏｎインターフェースは読み込み、書き出し及び処理のようなすべての一般データ操作を行うことが望ましい。最初のＩＤａｔａＡｃｔｉｏｎはサーバーアクセスのために、及びデータベース・アクセスのための第２ＩＤａｔａＡｃｔｉｏｎのために提供されることが望ましい。
【０１４０】
図３は情報技術トランザクションシステムのブロックダイヤグラムを示す図である。明瞭性のため、この構造は1つの単一トランザクションサイトに限られるが、技術者は多くのトランザクションサイトが付いているシステムに容易にこれを適用できる。トランザクションサイトでは、プログラムされた通信がＩＴシステムで提供されるトランザクションタイプは、トランザクションサイトで提供されるひとつひとつのサービスと関連付けられる。そのようなトランザクションサイトの例はブランチシステムの支店である。
【０１４１】
本発明は、例えば、個別の条件に基づいて、そして同様に使用される他の区域において特に考慮に入れられなければならない生産技術のプロパティの大多数を含む、車や他の生産商品の、ジャスト・イン・タイム製造のような複雑なプロダクションシステムでの使用に適している。
【０１４２】
以下、例を用いて、広く細分化されたブランチシステムの発明の使用を記述する。ブランチシステムは顧客に会社が提供する商品またはサービスへの広範囲のアクセスを与える。ここでは例を用いて、多数の駅及び空港で顧客に彼らのサービスを提供する運送業者について述べる。これらは例えば列車や航空券の購入、手荷物の点検、または車の賃借などが含まれる。別の例として、彼等の顧客に、国内におけるほとんどあらゆる町中でなされる、例えば、手紙及び小包の受け取り、切手の販売、銀行業務全般、特に口座からの現金の出金、現金払いの承諾及びその他多くを含むような郵便業務の広範な選択を提供する郵便業務の提供者に関連する。
【０１４３】
これらの例は、販売の広い選択及び助言的なサービスが多数の支店のそれぞれで使用できるようにされることを示す。但し、ここで同様に類似して示される、他のトランザクションシステムの例を使用することも可能である。以下、本発明を郵便業務の提供者の例に関して記述するが、本発明における概要の適用の可能性はこれに限定して解釈されるべきではない。具体的には、例えば、顧客が郵便局の支店で口座からの現金を出金するとき、データが顧客カードから読取られて顧客が識別され、同時に、彼の口座の残高が点検されることを意味する。郵便局の支店の従業者はその際、情報技術システム(ＩＴシステム)によって、彼が預金を支払ってもいいかどうか通知される。上記の他の例、即ち列車または航空券の販売では、顧客は彼の顧客カードによって同様に識別され、販売された列車または航空券には既に、一定量のボーナスポイントが販売の時に加えられる、当該会社のボーナスポイントプログラムで登録されている。これらの少数の例はまさに、ブランチシステムのトランザクションをマップすることがかなり高い情報技術の条件を伴うことを既に示している。一般に、比較的簡単なビジネストランザクションでは、複数の異なったタイプのデータを支店及び中央データベースまたは中央コンピュータの間で交換することが求められる。
【０１４４】
本発明はコンピュータによる一般的なブランチシステムと同様、自動システムで使用することができる。
【０１４５】
本発明は主として自動化されたシステムで使用されるとき、自動化された処理ルーチンを遂行できるソフトウェアエージェントを使用することが特に望ましい。
【０１４６】
但し、本発明はこのような特に選ばれた十分に自動化された実施形態に限られず、むしろ、ソフトウェアエージェントがなく、個々の自動化されたプロセスを遂行する全面的な環境においても、また同様に実行することができる。
【０１４７】
特に部門に支えられた実施例を以下に記述する。
【０１４８】
トランザクションサイトの従業者は顧客の要求を受け取り、完全にすべての必要な情報を与えることで従業者を助けるグラフィック・ユーザ・インタフェースを使用して、例えば、付加的な顧客データを得る。従業者がこれらの仕事を遂行するワークプレースは入力側である。このように得られるクライアントの要求及びクライアントデータは、より深いコンポーネント、ＩＴシステムの下部組織の層１２に進む。下部組織の層１２は、従業者が操作の順序に介入しなくとも、自立的に周辺コンポーネントの制御の処理をする。例えば、印刷ジョブは自動的に切符またはレシートのプリンターに送られ、若しくは自動出納機はある特定の金額を出金するように指示される。これらのトランザクションすべてはバックグラウンドシステム１３にログインされ、顧客データは記憶される。さらに、また出力側部門であるバックグラウンドシステム１３で、データは適切なアカウント原則に則って反映され、アーカイブされる。入力側１１、下部組織の層１２及び部門出力側１３がトランザクションシステムを形成する。
【０１４９】
最終的に、いくつかのトランザクションにとっては、顧客が要求する現金を引出すために口座で十分な資金が実際に利用可能か、または要求された製品を渡すことができるかどうか、を確認するために、例えば、銀行コンピュータのデータベースによる他のシステムとのデータの交換が、トランザクションシステムに必要であるトランザクションサイトの外のそのようなシステムはまた、サードパーティシステム１４と言われる。そのような問い合わせのトランザクションは、従業者側の介入なしで部門出力側の１３によって同様に自立的に遂行される。データがサードパーティシステム１４から返信されれば、このデータは従業者がデータの内容に基づいて処置を行えるように、部門出力側１３の下部組織の層１２から従業者の入力側１１に送信される。よって、この実施例では、従業者は望みの金融合計を支払ったり、又は支払わなかったりする。ブランチシステムの個々の層とサードパーティシステム１４間のデータ交換は図３における矢印で示される。
【０１５０】
図４はトランザクションの論理構造を示す。トランザクションは、トランザクションサイトにおけるトランザクション処理の間に、データの入力又はトランザクションシステムに既に存在するデータを通して一歩ずつ増加される親データレコード２１から始まる。このプロセスでは、データ交換はブロック２２として記載したトランザクションと、ブロック２３として記載したトランザクションシステムの間で絶えず起こっている。トランザクションとトランザクションシステム間のデータレコードの交換はブロック２４ａ、２４ｂ及び２４ｃによって図４に示される。すべてのデータは、トランザクションの最終段階で、構造を以下さらに詳しく記述する、生データの記録２５ａ、２５ｂ、２５ｃに一緒に結合される。図４はまた矢印によって示されるようにデータの流れも示す。
【０１５１】
図式的なブロックダイヤグラムにより、図５に総合システムにおける、個々の層間の生データ交換についての論理的順序を示す。図５では、４つのデータブロック３１ａ、３１ｂ、３１ｃ及び３１ｄは例を用いて示される。データブロック３１ａから３１ｄのそれぞれは生データのための基礎としてアプリケーション特有のデータ構造を備える。但しこれらのデータ構造が生データでないことが、示されるべきである。生データは、生データモジュール３２が、一度アプリケーション特有のデータ構造をデータブロック３１ｃから生データに変形させたときのみ得られる。よって、生データモジュール３２はデータ変形プロセスを遂行する。２つの矢印３３ａ及び３３ｂによって示されるトランザクションのステップでは、生データサービスコンポーネント３５と同様、アーカイブの記憶３４で記憶されるところで、生データの記録は入力側１１から部門出力側１２に送信される。与えられたトランザクションに必要であれば、生データサービスコンポーネント３５はサードパーティシステム１４に生データを送信する。適切なアカウントの原則に従うために、トランザクションのアプリケーション特有のデータはまた記憶される。データブロック３１ａ及び３１ｂは、生データに変えられない相互作用データ及びプロセスデータを表すが、むしろこのために特に提供されるサービスコンポーネント３６及び３７で変わらずに送信される。サービスコンポーネント３６及び３７は、部門出力側１３とサードパーティシステム１４間の相互作用データ及びプロセスデータの交換もまた保障する。
【０１５２】
均一な生データの構造の範囲内で、個々のトランザクションに関連しているデータの均一な獲得と処理は、両立性が均一データ構造によって保障されるので新しいトランザクションタイプが非常に容易に現在の下部組織に統合されるという利点がある。
【０１５３】
図４で示されている生データモデルを形成するスキームは、リッチスキームと言われる。それらは、生データの記録が発生するかどうかの、入力側の特定のプロパティを含んでいない。リッチスキームは、異なった入力側で発生する、すべての可能な生データのスーパーセットを形成する。システムの発生及び/または処理は、リッチスキームの特殊化を定義し、使用できる。リッチスキームの特殊化はリッチスキームと比較してもっと特殊化された、自身のデータ条件をマップすることに有用な場合もあり、これらはプア−スキームと言われる。この概念の利点は、プアースキームが、結びついたリッチスキームに基づいて自動的に点検し、特殊化と定義されることができるという事実にある。このため、プアースキームがリッチスキームと明瞭に関連付けられなければならないことは、考慮に入れられなければならない。リッチスキームにおけるすべての必須要素は、またプアースキームの要素でなければならない。但し、プアースキームはリッチスキームと比較して、少ない基礎、少ない要素などを有することが可能である。プアースキームは結びついたリッチスキームと比較して、長さ及び特徴による要素の制限を有することもできる。しかし、逆にこれは問題ではない。
【０１５４】
生データ記録の構造の設計で、生データの要素の記録が、最も小さい手続き上の論理的なトランザクションの単位を形成することが考慮された。最も小さい手続き上の単位は、手続き上一緒に属し、含まれるすべてのシステム、即ち、入力側１１、部門出力側の１３、及びサードパーティシステム１４で、有用な処理を許可する、トランザクションの要素の全量である。但し、複数の生データの記録が手続き型単位と一緒にマップすることもまた可能である。この場合、すべての生データ記録の全体だけが、ある特定のトランザクションを完全にマップする。この場合、必要なデータ容積をできるだけ小さく保つため、生データの記録間のリダンダンシーはない。これは生データの記録が分離していることを意味する。
【０１５５】
ＩＴシステムの構造と同じように、トランザクションシステムのデータ・ストリームは、生データ及び非生データに分解することができる。非生データは、例えば、プロセスサービスのコミュニケーション間に関連しているデータである。図５に示すように、例えば、生データ及び非生データは、互いとは別にアーカイブされる。
【図面の簡単な説明】
【０１５６】
【図１】本発明に係るトランザクションシステムを示す概略図。
【図２】本発明に係るトランザクションシステムの特に好ましい構成を示す概略図。
【図３】情報技術システムのブロックダイヤグラムを示す図。
【図４】トランザクションの論理的順序を説明するブロックダイヤグラムを示す図。
【図５】情報技術システムにおける論理的なコンポーネント間の生データの交換を説明するブロックダイヤグラムを示す図。
【符号の説明】
【０１５７】
ＡＢＫ     注文処理コンポーネント
ＡＭ       アプリケーションマネージャ
ＢＭ      承認モジュール
ＣＦ       ＣＡＲＢＯＮフレームワーク
ＣＨ       ＣＡＲＢＯＮホスト
ＣＭ      コンテキストマネージャ
ＤＣ       データコンテナ
ＤＫ      データコンポーネント
ＤＫＭ    データコンポーネントモジュール
ＫＩＳＳ  通知コンポーネント
ＩＳＳ    ＩＳｕｐｐｏｒｔサービス
ＲＤＭ    生データモジュール
ＲＫＭ    生データコンポーネントモジュール
ＲＭ       リカバリーマネージャ
ＳＭ      セッションマネージャ
ＶＧＡ    トランザクション処理モジュール
【図１】
2008530665.tif 000003
【図２】
2008530665.tif 000004
【図３】
2008530665.tif 000005
【図４】
2008530665.tif 000006
【図５】
2008530665.tif 000007
【国際調査報告】
2008530665.tif 000008
2008530665.tif 000009
2008530665.tif 000010
2008530665.tif 000011
2008530665.tif 000012
2008530665.tif 000013