アーキテクチャ説明資料

多様化するニーズへの対応とスタンダード確立に向けての新しいアーキテクチャ採用について

平成１４年１月２５日
電子入札コアシステム開発コンソーシアム
仕様検討ワーキンググループ

１．コアシステムのあり方
コアシステムの背景と期待される要件
 電子政府／電子自治体をはじめとする各発注機関業務のＩＴ化は、構想の段階から実施の段階へ。
 電子入札システムとしてのスタンダードを保ちながら、各発注機関の多様な要求に対応。
 国土交通省システムが有する入札関連機能はもとより、高信頼性／安全性を継承。
 今後のインターネット利用環境の変化及び技術革新へ対応。
安全で各発注機関の業務要件に十分対応でき、運用後も長期間にわたる稼働と多くの機能強化に耐えられる次世代入札システムのコアを開発。

2

【電子入札コアシステム開発イメージ】
公団／事業団要件
地方自治体要件

各省庁要件

ＣＡＬＳ/ＥＣ＊
電子入札システム
国土交通省版
電子入札システム

信頼性

入札業務機能安全性

電子入札
コアシステム＜汎用＞＜公共事業用＞

経済産業省版
パイロットシステム＜物品調達用＞

中央省庁入札システム仕様＜物品調達用＞

入札システムのスタンダード•各発注機関の多様な要求に対応•今後のインターネット環境の変化
および技術革新へ対応＊：『CALS/EC電子入札システム』とは平成９年１１月から平成12年８月まで二期にわたって運営されたCALS/EC公共調達コンソーシアム（事務局：JACIC）で開発されたシステム。
現行の国土交通省版電子入札システムは、これを改善したものである。

3

２．国土交通省システムのアーキテクチャ
アーキテクチャ採用の経緯
ＣＡＬＳ／ＥＣ電子入札システムは、開発効率、性能、導入コスト、実験効率からサーバシステムをＮＴサーバとＣ／Ｃ＋＋言語で開発。(H9〜12）
国土交通省システムは、信頼性、導入／稼働実績、実験実績からサーバシステムをＣ／Ｃ＋＋言語のままＵＮＩＸ（Solaris）化。(H12〜現在)
いずれのシステムにおいてもクライアントシステムは、入札システムの特殊性（署名、暗号化）から、全てＪＡＶＡアプレットで開発。

国土交通省アーキテクチャの特徴
サーバシステムには、ＣＧＩを利用−今後の技術革新への追従が困難サーバシステムは、国土交通省向けに高度にチューニング。
−より汎用性の高いインタフェースの提供が困難
クライアントシステムのＪＡＶＡアプレットに、入札業務機能を集約。
−クライアントＪＡＶＡアプレットの大型化により、起動時間が増大
4

【従来アーキテクチャの特徴】<クライアント><サーバ>
国土交通省向けに高度にチューニング

Ｊａｖａアプレット

インターネット

受注者
ダウンロードWebﾌﾞﾗｳｻﾞ(Netscape)ＯＳ（MS Windows）

発注者

ウダロン

ＵＮＩＸＣＧＩ

Web
ｻｰﾊﾞ（Ｃ／Ｃ＋＋）ＯＳ（ＳＵＮ）

ドー

ＤＢ
ＯＲＡＣＬＥ
ＯＳ（ＳＵＮ）

ＬＡＮ

Ｊａｖａアプレット《要改善事項》
入札業務機能を集約

Webﾌﾞﾗｳｻﾞ(Netscape)ＯＳ（MS Windows）•今後の技術革新への追従が困難•より汎用性の高いインタフェースの提供が困難•クライアントＪａｖａアプレットの大型化により、起動時間が増大

5

３．新しいアーキテクチャの採用

企業の基幹業務を稼働させるためのサーバシステム向けJava仕様である、
Java 2 Platform, Enterprise Edition (J2EE)をコアシステムの新しいアーキテクチャとして採用し、フレームワークとともにコアシステムを構築。

新しいアーキテクチャのメリット
フレームワークによるシステムの階層化−カスタマイズした部分に影響を与えることなく機能強化が可能

サーバでサポートする処理範囲の拡大−サーバにおける他システム連携ポイントの提供−ＧＵＩのＨＴＭＬ化によるポータビリティ性の確保と汎用化−アプレットプログラムの軽量化

ＪＡＶＡによるマルチプラットフォームへの対応−標準規約（J2EE）に対応した各種製品が選択可能
6

【新しいアーキテクチャの概要】＜サーバ＞＜クライアント＞
受注者
HTML
アプレット
Webﾌﾞﾗｳｻﾞ(Netscape ＆ IE)
ＯＳ（MS Windows）

発注者

ダウン
ロード

HTML
アプレット
Webﾌﾞﾗｳｻﾞ(Netscape ＆ IE)
ＯＳ（MS Windows）

インターネットダウンロード

バウンダリ層

ビジネスロジック層

Web
ｻｰﾊﾞ

フレームワークＤＢ

Ｊ２ＥＥプラットフォーム

ＯＲＡＣＬＥなど

ＯＳ（ＳＵＮなど）

ＯＳ（ＳＵＮなど）

ＬＡＮ《新アーキテクチャの利点》•フレームワークによるシステムの階層化により機能強化が容易•サーバでサポートする処理範囲の拡大により既存システムとの柔軟な連携•ＪＡＶＡによるマルチプラットフォームへの対応
7

【フレームワークによるシステムの階層化】−フレームワークという考え方を取り入れることで、カスタマイズが容易な部分（バウンダリ層）とバウンダリ層に影響を与えることなく機能強化が可能なコア部分（ビジネスロジック層）を提供可能−＜サーバ＞
バウンダリ層（カスタマイズ領域）

カスタマイズ部→←

業 務処 理→←処 理制 御→←コンポーネント
制御→←ＤＢ呼び出し

コア部

インタ
フェース部

画面処 理

画面制御

画面生成

→
←

カプセル化された
プログラム

フレームワーク

セキュアライブラリ
各層の定義付けとその定義に沿ったモジュール設計により高効率開発が可能

エンティティ層︵ＥＪＢ︶

クライアントへ

ビジネスモデル層 コンポーネント化によりコントロール層︵ＥＪＢ ︶

コントロール層︵サーブレット︶

ビュー層
︵ＪＳＰ︶

ビジネスサービス層︵ＥＪＢ︶

アプリケーション層︵ＪＡＶＡ︶

プレゼンテーション層

動的ＨＴＭＬ生成

ビジネスロジック層（コア領域）

8

【サーバでサポートする処理範囲の拡大】

ＧＵＩ部分
カスタマイズロジック部分

ＵＮＩＸ

ＣＧＩ

（Ｃ／Ｃ＋＋）
セキュアライブラリ

調達情報
提供システム

資格審査
システム

従来アーキテクチャ

クライアント処理必須部分

インターネット−従来のクライアントアプレット処理をＧＵＩ部分、カスタマイズロジック部分、クライアント処理必須部分に分類し、このカスタマイズロジック部分を利用した既存システムとの容易な連携が可能−＜クライアント＞＜サーバ＞
Ｊａｖａアプレット

インターネット経由での連携
既存システム
サーバ間の容易な連携

アプレット

＜サーバ＞
バウンダリ層

ビジネスロジック層

カスタマイズロジック

セキュアライブラリ

契約／会計システム

新アーキテクチャ

HTMLインターネット＜クライアント＞

フレームワーク

Ｊ２ＥＥプラットフォーム

9【ＪＡＶＡによるマルチプラットフォームへの対応】−今後、各発注機関の要件に合致したサーバプラットフォームの選択が可能になる上、プログラムコードの一元化が可能となり、開発、保守において大きな効率化が可能−

Ｃ／Ｃ＋＋システムの場合（現行アーキテクチャ）

各プラットフォームにあわせたコアシステムが必要

UNIX 用コアシステム

Windows 用コアシステム

Linux 用コアシステムUNIX(Sun,HP,IBMなど)

Windows(NT,2000など)

Linux(Red Hatなど)

ＪＡＶＡシステムの場合（新しいアーキテクチャ）

プラットフォームに依存しないコアシステムが提供可能

JAVA版
コアシステムJAVA版
コアシステムJAVA版
コアシステムJAVA実行環境

JAVA実行環境

JAVA実行環境

UNIX(Sun,HP,IBMなど)

Windows(NT,2000など)

Linux(Red Hatなど)

標準規約に対応した各種製品が選択可能

10

【電子入札コアシステム全体イメージ】国土交通省 ＣＡＬＳ／ＥＣシステム
ＰＰＩシステム
資格システムＣＣＭＳシステム
電子納品システム
他

電子入札システム

セキュア ＜Javaアプレット＞
ライブラリ

H13追加
要件

提供時期＜Cプログラム、CGI＞
経済産業省版
パイロットシステム＜物品調達用＞
中央省庁入札システム仕様＜物品調達用＞

ＰＰＩシステム

信頼性
安全性
H14上期版
H14下期版 H15版 H16版
電子入札コアシステム
フレーム コアＧＵＩシステム
ワーク （コア国土交通省）
共通 ＜ＨＴML、JSP＞
部品 コアビジネスシステム

上期
開発機能
基本機能
1 ユーザインタフェースの統一○
2 システム競合の回避○
3 既存シス テムとの接続容易性 ○4 マルチプラットフォーム対応
業務機能
5 物品調達対応6 随意契約対応
7 電子契約対応
認証機能
8 複数認証局対応
9 ＧＰＫＩ対応
10 ＬＧＰＫＩ対応
11 クライアントソフトの統一
運用
12 データセンター対応
13 データの長期保存性

平
成
1
5
年
度

平
成
1
4年
度

平
成
1
6年
度

検討課
題

下期

○
○
○
○
○
○
○
○
○
○

＜Ｊａｖａサーブレット＞＜Ｊ２ＥＥサーバ＞
セキュアライブラリ（既存対応）

11