BSA
トランザクション †
トランザクションを定義する †
トランザクションを定義したり、ビジネスモデルの基礎を作る作業は、わかりやすく明白でないといけない。
一回あなたがトランザクションを定義したら、ターキテクチャはそれをサポートすることが可能になり、明白な定まったソフトウェアライセンスとなる。
これは簡単ではないが、とても重要だ。
分散したトランザクションシステムでは、トランザクション内で部分的に関与する方法が定義されないといけなくて、この関与はビジネスモデルの基礎となる。
トランザクションとビジネスモデルの関係を定義する †
概して言えば、ビジネスモデルとトランザクションを管理できれば、それが絶対的に重要な要素となることだ。
通信会社のケースでは、電話をかけるトランザクションのキーデータは、誰からかかって、誰にかけて、どのくらいの長さかけたかだ。
監査証跡を保持する †
多くのトランザクションベースのビジネスモデルでは、特定の料金の証明/非証明のために監査証跡が必要だ。
これは、トランザクションでの関与の区別を調停することを試みるときに極めて重要となる。
トランザクションが明確に一意なものと認識されなければならない。 †
トランザクションは一意なものとならないといけない。
シンプルなデータベースカウンターの心配は、現在の分散環境ではしばしばうまくいかないことだ。
幸運なことにUNIXベースシステムにはUUIDが、WindowsにはGUIDが組み込みのアルゴリズムとしてある。
確かに、それらは多くのスペースを必要とするものの、非常に大きな数字の一意認識情報の代わりとなるものだ。
良いことに、比較的長い認識情報を必要としない場合は、あなたは安全で短い一意認識情報とできるかもしれない。
短い認識情報としてよく機能するものは英数字のコードをベースとするもので、”XR349”や”QPCAXZZ”など。
トランザクションの状態、ライフサイクルと期間への理解 †
何かの買い物の清算しているときに、メインフレームのコンピュータが秒間に何百ものクレジットカードのトランザクションを処理していることをイメージできる
トランザクションライフサイクルの完了は定義されていけなればならない、なぜならそれは、トランザクションのためのアカウント管理するバックオフィスシステムに影響を及ぼすからだ。
例として、トランザクションが直近1年間と長く、顧客への請求を月ごとに行う場合、通常であれば、トランザクションへの請求は、トランザクションが完了した時になるだろう。
しかし、このケースではお金を得るために長い時間待たなければならず、キャッシュフローにネガティブな影響を与えるだろう。
もしトランザクションの80%が正常に完了していることがわかれば、安全にトランザクションが開始された時に請求することができ、システムがトランザクションが失敗もしくはアボートしていることを認識でき、バックオフィスシステムがきちんと調整でき、そうでなければ、顧客の口座を信用できないだろう。
この作業行わないと、会計部門にいかなる収益を確定する規定が侵食されていないかを確認することになる。
Metering †
どうユーザを認証するか †
もしビジネスモデルが多くのお金を一意なユーザ認識情報から得ている場合は、シンプルなユーザネームとパスワードを超えた多くのスキームを利用することを検討しなければならない。
概して言うなら、確立されたユーザを認証するためのインフラ技術（LDAPのような）を機能させなければならないだろう。
ユーザ数はどれくらいか †
同時的なユーザシステムでは、同時にアクセスできるユーザ数のリミットがある。
このユーザ数を定義する方法は、いろいろバリエーションがある。
私が働いていたシステムでは、すべての領域でこの値を管理していた。
ローエンドでは、同時にアクセスするユーザ数をテキストエントリーとしてINIファイルにしていて、完全に不安定だったが、自分たちの要求を許容するものだった。
ハイエンドでは、同時にアクセスするユーザ数をライセンスに明記していて、高度に暗号化を用いハードウェアデバイスに保存されていた。私たちのベストな知見で、このアプローチはクラックされたことがない。
どう使用中のユーザをカウントするか †
可能な限り、すべきことだが、ユーザを認証することはインフラに他の部分を依存するが、ユーザをカウントすることはインフラに依存するべきではないかもしれない。
これはアプリケーションの機能かもしれないし、アプリケーション内に統合されたライセンスマネージャーによって得られるかもしれない。
ユーザが非使用中または非活性かどうか †
セッションマネージメントのキーとなる問題は同時的かつユーザアプリケーションであることだ。
一旦ログインしたら、明白にログアウトしたと仮定できない。
なにかはうまくいかなくなるかもしれない：例えばクライアントマシンの故障や、ログアウトを忘れるなど
一般的な解決方法は、タイムアウトパラメータを関連付け、非活性になるピリオドのあとに、ユーザを強制的にoffまたはdropさせることだ。
不運なことに、この値をセットすることは些細なことではない。
これはどうアプリケーションが確かに使用されるかの基本が調整されなければならない。
大事なことは、多く設定パラメータを提供し、それらの値は管理者によって調整が可能なようにすることだ。
リソースの消費管理はターキテクチャのシビアな制限をうける。
それは第一にある種類の状態を維持しなければならないからだ。
もし、顧客が全利用に100時間を購入したとして、どのくらいの時間ユーザがアプリケーションを利用したか記録する必要がある。
一つのアプローチは、中心となるサーバにこれらのデータを保存する方法で、データが改ざんされないよう、そしてネットワークコネクションが常
に信頼できる場合に機能するだろう。
他のアプローチはローカルマシンに保存することだ。注意深く、しかしながら、これはしばしば以前に保存されたデータを消去するためにリセットすることが容易だ。
ハードウェア †
ハードウェアベースのモデルの最大の問題は、どうハードウェアを構成するかを定義することと、どうビジネスと関連付けて管理していくかだ。
担当者のつぶやき †
みんなの突っ込み †
