XFS インターフェースを使用する利点は、デバイス (ピンパッド、カードリーダー) と相互運用するプログラムを 1 回だけ作成できることであるというのは、一般的に正しいのでしょうか? その結果 (理想的には)、デバイスを変更でき、ソフトウェアを変更する必要はありません。これが可能なのは、ユニバーサル XFS インターフェースを使用しているからです。私は正しいですか？
そこで、いくつかのビジネス ロジックを実装するプログラムを作成します。それは XFS インターフェースの操作を呼び出します。XFS ライブラリは、XFS からのクエリとコマンドを理解するサービス プロバイダ ライブラリを検索し、そのライブラリと連携します。デバイスを直接。私はそれについて正しいですか？
たとえば、デバイスを操作するためのドキュメントと (デバイス ベンダーからの) DLL があります。XFSインフラストラクチャで使用できるかどうかをどのように理解できますか? ドキュメントで、この dll が C 関数を公開してデバイスで動作することを確認しました。
CEN / XFS の主な目的は、銀行システム (ATM、キオスキーなどで実行される) がハードウェアの複雑さを抽象化できるようにすることです (例: 各メーカーには、紙幣ディスペンサーがどのように動作する必要があるかについてのソリューションがあります)。実際、標準の XFS は解釈の違いに対して非常にオープンであるため、この目標が常に完全に達成されるとは限りません。このため、銀行 (銀行など) が XFS の独自の解釈を作成し、そのサプライヤーにそれに従うよう要求することは非常に一般的です。これは、大規模な銀行 (ブラジルの Bradesco など) について話している場合に可能です。しかし、大量の ATM やその他の端末を購入しない小規模な銀行事業体の場合、システム内の XFS レイヤーの上に抽象化レイヤーを追加するなど、別の代替手段が可能です。
また、次の記事を読むことをお勧めします。
WOSA/XFS アプリケーションを開発する予定です。次に、以下を含む開発環境を作成する必要があります。 a) FI 市場で既に使用されているマシン (ブランドの ATM やキオスク モデルなど) 用のソフトウェアを開発している場合は、ハードウェア メーカーからの XFS インストール b) または、構成にいくつかの XFS デバイス (カードリーダー、バーコードリーダーなど) を含む独自のハードウェアを作成する場合、 CEN XFS 標準の独自のポートを実装する必要があるため、これはより複雑で実装が非常に困難です。これには、独自の XFS マネージャーに必要なすべてのコード (dll、lib、およびヘッダー ファイル) と、一般的な XFS 機能を担当する API SPI を含むすべてのデバイス SPI (サービス プロバイダー インターフェイス) のビルドが含まれます。これは、新しいハードウェア FI ユニットを大量に (少なくとも数百または数千単位で) 販売できない場合、時間とお金の投資として合理的とは言えません。ただし、さまざまなベンダー (NCR、Wincor、Diebold、Glory Solutions など) から既製の XFS インストールを購入できます。
これは、開発環境とテスト環境の両方に適切な XFS インストール (開発マシン用の開発バージョン、テスト マシン用のランタイム バージョン) を提供する最初のステップです。2 つ目は、アプリケーション開発のニーズに合わせて、お気に入りの C++ 環境を開発マシンにインストールし、デバッグ環境をテスト ハードウェアにインストールすることです。
セットアップが完了したら、キャッシュ/クレジット カード マシンに適したソフトウェアを作成するために、コードにヘッダー ファイルを含め、実行可能ファイルをビルドするときにライブラリをリンクするだけです。
おっしゃる通り、XFS は Java の「一度書けば、どこでも実行できる」に似ているため、たとえば、廃止されたカードリーダーや現金預金ユニットを別のものに変更した場合など、将来的にソフトウェアを保守および採用する必要はありません。たとえ別のベンダーからのものであっても。