3.1.6 アプリケーションプログラムインタフェースの実装仕様
3.1.6.1 APl要件
APIに対して以下の要件が求められ、これらを満たす必要がある。
1)プログラム言語とアプリケーション開発環境に依存しないプラットフォームが前提であること。
2)OSへの依存性がないこと。
3)色々なネットワークヘの接続性が良いこと。
4)分散型オブジェクトシステムに対する透過性がある(少なくとも共存できる)こと。
5)ユーザアプリケーションとの間に平易なインターフェースを持つこと。
6)局間の情報伝達方法(プロトコル及びデータ構造)が汎用化されたものであること。
3.1.6.2 APIの概念
APIの動作概念を図3.5に示す。
図3.5 APIの動作概念
1)LITP搭載局におけるAPI
本実装仕様ではLITP搭載局においてクライアントのみの実装を前提とする。
図3.4に示したように、CORBAを使用したクライアント〜サーバ間の通信はサーバ側で定義されるオペレーション単位で行われるが、前述のAPI要件を満たすためにAPIからユーザアプリケーションに対して平易なインターフェースを提供する必要がある。
即ちユーザアプリケーションからの要求を各オペレーション単位の個別要求へ展開することがクライアントLITP搭載局におけるAPI部の主要機能である。
2)SITP搭載局におけるAPI
本実装仕様においてLITP搭載局から発せられる各種オペレーション要求は、船上または船社側ネットワーク上に位置するデータベースサーバヘのアクセス要求に該当する。
データベースサーバそのものの構造や配置はシステムによって異なる可能性があるため、 LITP搭載局から船上または船社側デ一夕ベースサーバへ直接アクセスするのではなく、SITP搭載局を窓口としてアクセスすることを前提とする。
従ってSITP搭載局における主業務は、LITP搭載局から受信したデ一夕ベースサーバヘのオペレーション要求を中継することであり、図3.4に示すサーバプログラム、同クライアントプログラム、及び両者間のインタフェースプログラムがAPI部の内容となる。
3)データベースサーバ搭載局におけるAPI
データベースサーバ搭載局では自己が管理するデ一夕ベースヘの他からのアクセス要求に応えることが主業務のため、サーバ機能のみを搭載する。
ただしデータベースそのものの仕様については本実装仕様のスコープ外であるため、直接データベースにアクセスする部分はユーザアプリケーションにてシステム毎に定義する必要がある。
3.1.6.3 ソフトウエア構成
3.1.6.3.1. LlTP搭載局
LITP搭載局のソフトウェア構成を図3.6に示す。
図3.6 LITP搭載システムのソフトウェア構成
局間でのデータ送受単位となるCORBAオペレーションとして、データベースサーバより1個のデータを読み出す「データ読出」、データベースサーバに1個のデータを書き込む「データ書込」、データベースサーバに格納されたFMSデータの一覧を読み出す「データー覧取得」、1隻の船舶に関するFMSデータがどのデータベースサーバに格納されているかという情報(船舶情報と呼ぶ)を取得する「船舶情報取得」の4種を定義し、実装する。
APIブロックにはこれらのオペレーションを要求する処理、及びユーザアプリケーションからの要求をオペレーション単位に展開するユーザアプリケーションインタフェース、更にFMSN上で通信相手となる局のオブジェクト名を指定してその通信先を得るためのCORBA共通サービスであるネーミングサービスを利用する際に動作するネーミングサービスI/Fを持つ。
IDLスタブには上記4種のオペレーションをサーバ局に要求する処理が実装される。
3.1.6.3.2. SITP搭載局
図3.7 SITP搭載システムのソフトウェア構成
SITP搭載局のソフトウェア構成を図3.7に示す。
API部はサーバプログラムとクライアントプログラムからなり、サーバプログラムでFMSNより受信した各オペレーションの要求をクライアントプログラムを介してデータベースサーバへ転送する。
3.1.6.3.3. データベースサーバ
図3.8 データベースサーバのソフトウェア構成
データベースサーバのソフトウェア構成を図3.8に示す。
データベースとして汎用のものを使用することを前提としている(ORDBS:Object Relational Data Base System を想定している。)ため、実際にデ一夕ベースヘアクセスする処理は本実装仕様のスコープ外とし、ユーザアプリケーションにて実現する。
3.2 実装仕様の検証と評価
APIを評価するために実施した実験の内容と結果について述べる。
3.2.1実験システムの構成
（拡大画面： 100 KB）
図3.9 実験システム構成図
実験時に使用したシステム構成を図3.9に示す。
破線部は、実験用として図3.1のシステム構成から省略した部分を表している(HUBは追加)。 また、図中に示すようにPSCデータ管理PC、PSCレポート作成PC、および船隊・各船舶管理PCを1台のPCに統合した。
3.2.2 検証項目と結果
表3.1の各項目についてテストを行い良好な結果を得た。
| No |
項目 |
チェック内容 |
| 1 |
全体動作
(PSCビューアによるPSCレポートフォーム作成からレポート完成までの一連動作) |
本文3.1.2節に示す動作手順通りに各局が動作することを確認する。 |
| 2 |
DBからの読出 |
[1]DB内にあるデータが読めるか |
| 3 |
DBへの書込 |
[1]DBにデータを書き込めるか(該当データが既存の場合は上書きされるか) |
| 4 |
ネットワーク構成
(ネットワーク構成に依存しないことを確認) |
以下のケースでネットワーク上のデータ授受に支障がないことを確認する。 |
| [1]各局のLAN設定(IPアト'レス)を変えてみる。 |
| [2]PSCビューア用PCにDBを内蔵する実装形態、および陸上用のDBと船上用DBを同一PCにまとめる実装形態を作成する。 |
表3.1 実験システムにおける試験項目一覧
3.2.3 API実装仕様および検証作業についての評価と課題
3.2.3.1 総合評価
3.1.6.1節に示す6項目のAPI要件に幾つかの評価ポイントを加え、API実装仕様について評価した。その結果を表3.2に示す。
また実験を行うことにより、CORBAを使用することでネットワークの存在を意識せずにAPIおよびユーザアプリケーションプログラムの作成が可能であること、CORBAを使用することで相手先オブジェクトがネットワーク上のどこにあるか全く意識しなくとも通信を行えることが確認された。
これらにより、FMSN用APIを標準化するためにCORBAのような分散オブジェクトシステム用標準が不可欠であることが確認されたが、一方で次節に示すような課題も確認できた。
表3.2 実装仕様への評価結果
| No. |
評価のポイント |
評価 |
| 1 APIに求められる要件 |
| 1-1 |
プログラム言語、アプリケーション開発環境に依存しないプラットフォーム |
OK |
| 1-2 |
OSへ非依存 |
OK |
| 1-3 |
外部ネットワークヘの接続性 |
OK |
| 1-4 |
分散オブジェクトシステムヘの透過性 |
OK |
| 1-5 |
平易な1/F |
OK |
| 1-6 |
汎用化された情報伝達方法およびデータ構造 |
OK |
| 2 ユーザの立場からのマクロ的評価ポイント |
| 2-1-1 |
ユーザ業務に対するカスタマイズ性 |
OK |
| 2-1-2 |
汎用ソフトとのデータ交換の容易性(ITの進展をフォローしやすく、進展対応作業をユーザ自身で行えるか) |
OK |
| 2-2 |
コスト |
(※1) |
| 2-3 |
システムの維持向上容易性 |
OK |
(※1船陸間通信のコスト等、今後変化が予想されるため現状不明。)
3.2.3.2 課題・問題点
［1］ 実験システムで使用したPCは全て同じOS、同じ開発環境・言語を使用したため、プラットフォームやOSに依存しないということ実証はできなかった。
［2］ LANや船陸通信を介さないシステム構成であったため、それらへの適合性や通信速度に関する検証ができなかった。
［3］ 各局からの通信先を特定するためにAPIでネーミングサービスを使用することが前提となるが、その場合、ネームサーバと呼ばれる局(「アドレス帳」に該当する局)の通信先を各局が知っている必要がある。
このネームサーバをネットワーク上のどこへ、どのような形で設けるかについて検討が必要である。
