LANSAデータサービス層 – 保護とサービス
LANSAリポジトリのアーキテクチャの基本的な考え方は、アプリケーションを依存するデータベースから分離されるようにしておくことです。
どのようなシステムでも、どのような時にアプリケーション・プログラムがデータの作成、読込、更新、削除が許されるのかを決める1セットの規則が存在しています。 これらの規則は、データの品質と一貫性を維持して、マルチユーザの取引環境を保護するために存在しています。規則からの逸脱は、誤ったレポートのレベルからシステムがクラッシュするレベルまでさまざまなことが起こり得ます。
データベースでもアプリケーションでもない
通常、これらの規則はストアードプロシージャ、フィールド妥当性検査、トリガーなどを使っているデータベースレベルでまたはアプリケーションプログラムの中で管理されます。データベースレベルで規則を実施する一つの明らかな利点は、この集中化したモデルで重複を避けらることです。否定的な側面は、すべてのRDBMSベンダがトリガーやストアードプロシージャを実装するための互換性のない独自の方法を持っていることで、これらを使用することで特定のデータベースの使用を強要される点です。この場合、アプリケーション層で規則をコード化することによって特定のデータベースの使用を強要される事態は回避することができるけれども、すべてのプログラムに同じ規則を含む必要が出てきます。このことは開発の生産性を下げるだけでなく、保守を著しく増大させます。
完全に独立したデータサービス層
LANSAはシングルアクセスポイントをすべてのデータに提供して、抽象的な形式、位置、およびコンベンションに役立つデータサービス層を実装しました。特定のプログラム(Object Access Modulesと呼ばれる)はリポジトリに保持されたデータディクショナリから生成されます。これらのOAMはデータベース(フィールドとファイル)の構造を知っていて、作成、読込、更新、削除のトランザクションを制御する規則を含んでいます。例えば、ネットワーク上どんなプログラムでも、人事システムの‘comp_Employee'テーブルに‘Create_New_Employee'したい場合は、適切なOAMを通して処理されることになります。将来に変更が必要になった場合は、その特定のOAMをサーバで再作成されますが、他のいかなるプログラムにも影響を与えません。OAMにデータベースから独立したトリガーをつけたり、フィールドの計算や結合を内蔵の機能を使って更に拡張することができます。
LANSA OAMはさまざまなプログラム、プラットフォームからアクセス可能
LANSAのOAMは、RPG、COBOL、LANSA、Synon、PHPなどの開発言語にかかわらず、IBM iサーバー上で動くどんなプログラムによって実行されます。LANSAのiFusion.net 技術にもまた、LANSAデータサービス層やこれらのOAMへアクセスするためにアプリケーションを.NETフレームワークで構築することが可能なミドルウェアが含まれています。結果的には、あなたのアプリケーション全て-年齢や技術に関係なく-で、基礎となるデータベースへアクセスするために、一般的なデータサービス層を使用しています。