EJB構築事例
東京三菱銀行営業店システム

[索引]  背景 |  Java/CORBA導入の狙い |  システム概要 |  技術的課題とコンポーネント適用効果 |  プロジェクト管理上の課題と評価 |  コンポーネント化によるビジネス展開：FBC |  関連情報 

大規模基幹系システムにおける Java/CORBA 技術および Javaコンポーネント の適用事例をご紹介します。このシステムは既に稼働しています。
このプロジェクト発足時には、Javaによる基幹系システム開発の事例はほとんどない中、多くのリスクの上であえて新技術を採用したものです。

背景

このお客様では、

• ビッグバンによる外資系企業の国内市場への参入
• 規制緩和によるサービス拡大、インターネットバンキング開始

といった、顧客獲得競争の激化、新たなビジネスチャンスの到来などに直面していました。

この厳しい状況に早急に対処し、乗り切る為、従来業務の効率化に加え、新サービスの早期提供による業務拡大を行おうと考えました。

お客様の業務上の要件としては、

• 業務の拡大／変更に即時対応できる 「拡張性」
• 営業窓口に加えてインターネットからでもサービスを利用できる 「利便性」
• 「開発・運用費を低く抑える」

といったことがあげられました。

そこで、本店の既存システム（ホスト）はそのままとし、各営業店にアプリケーションサーバを導入し、各営業店と本店をTCP/IP網で接続し、営業窓口サービスの拡大を行うシステムを構築することになりました。

Java/CORBA導入の狙い

プロジェクトに導入する開発技術選定の基準として、以下があげられました。

• 国際的標準技術で、今後10年使える技術であること
• 安く早く
• 既存システムの活用
• 構築後の拡張が容易

検討を重ねた結果、以下の観点を評価してJava/CORBA技術の採用が決定されました。

• 技術の継続性（グローバルスタンダードで、ベンダーに依存せずサービスが受けられる）
  先行きが不透明な時代に、1つのベンダーに依存した技術は、社会システムである銀行業務にふさわしくない。
• 技術の連続性（漸次的に新技術を取り入れておくことで、再構築時の移行負荷低減）
  高い信頼性が必要な基幹系システムでは、こなれた技術を使いたい。 しかし、ここで最新の技術を取り入れておかないと、次の再構築時に技術的ギャップが大きくなり、機能移行をするのが非常に困難になる。
• コンポーネント化による資産活用（他銀行及び他業態への展開ビジネス）
  Thin Client、プラットフォーム非依存の特徴を活かし、ソフトウェア資産をコンポーネントとして開発（コンポーネント指向開発）する。 コンポーネント化することで、開発資産をこのプロジェクトでの利用にとどまらず、系列他銀行や、他業種にまで含めたビジネスに利用する。

また、クライアントアプリケーションについては、以下の観点から、アプレットを選択しました。 現在では、この観点からのアプレットの選択は、inBシステムでは、主流になりつつあります。

• TCO（トータルコスト）削減の観点から、Thin Clientで実現したい。
• 基幹系システムは、性能、操作性に対する要件が非常に厳しい。 C/SのGUI技術も活かしたい。

システム概要

なお、アプリケーションサーバ製品としては、Interstage Application Server、Javaコンポーネント製品として、ComponentAA/Client J を適用しています。

技術的課題とコンポーネントの適用効果

Java/CORBA採用にあたり、性能・操作性について、以下の要求がありました。 これを全てクリアするのが技術的課題でした。

（1） 性能要求（従来同等の性能の実現ができること）

性能面については、

• 3000画面にのぼる全画面を全てサーバ側で集中管理できること
• 勘定系業務のレスポンス確保
  • 画面単体での表示性能
  • 画面遷移速度性能
• 画面数増加に伴う遷移速度の劣化がないこと

（2） 操作性要求（基幹系システムとしての円滑な入力操作性）

• 基幹システムに求められる入力操作
• きめこまかいチェック機能
• 日本語の入力操作

これらの課題の解決にあたって、利用された製品が、Java用クライアントコンポーネント製品である ComponentAA/Client J です。

（1） 画面遷移性能の解決策

ComponentAA/Client J に含まれる「画面制御ライブラリ」を始めとするコンポーネントでは次のような技術を採用しています。（特許出願中）

• 画面とアプレットの分離
  各画面とコントロール部分のアプレットを分離することで、必要な画面のみの読込みなどの制御を可能とし、画面数が増えても性能が劣化しないしくみを提供しています。
• 画面生成タイミングの制御
  画面ごとに、生成や削除のタイミングを変えることができます。
  具体的には、アプレット初期化時、画面遷移時、バックグラウンドなどの指定ができるため、例えば、最初に使う画面だけを初期化時に生成し、その他の画面はバックグラウンドでダウンロードおよび生成を行うこと（画面の先読）が可能となり、大幅な画面遷移の高速化を実現できます。

この他にも

• コンポーネントのライトウェイト化
• ダブルバッファリングによる画面を一括描画

等の技術を取り込み、画面遷移性能課題を開発しています。

これらの技術により、3000画面から成るクライアントアプリケーションの画面遷移性能において、従来のVisual Basicなどによる開発の場合と同等の性能を達成することができました。
これは、Javaアプレットの画面遷移性能としては、世界最高速レベルです。

（2） 基幹システムに求められる操作性の実現

ComponentAA/Client J では入力フィールドや、表形式入力部品などの業務システム用のGUI部品を豊富に提供していますので、開発ツールで効率的に画面を開発することができます。

さらに、それぞれのコンポーネントは、標準のJava開発環境には備わっていない、数字・文字列などの入力属性チェック、カンマ編集、文字の右寄せ・センタリング、入力桁数制限、必須入力指定、全桁入力時のカーソル移動などのきめ細かな制御を、プログラミングなしで実現できます。

また、日本語入力フィールドにカーソルが位置付けられたら日本語IMEを自動的に起動するなど、日本語入力を効率的に行える機能を提供しています。

これらの機能によって、基幹業務システムに求められる操作性を実現することができました。

また、オンラインレスポンスの確保のためには、定評のあるINTERSTAGEのCORBA機能を使うことで、高信頼、高オンラインレスポンスを実現しました。 トランザクション処理に関する機能を最大限に活用することで、銀行の基幹系業務にふさわしい、ハイパフォーマンスを実現できました。

以上のように、世界標準技術であるJava/CORBA技術を利用することで、Thin ClientによるTCO削減と、インターネット利用による利便性の向上を達成でき、同時に、Javaコンポーネント製品（ComponentAA/Client J）を利用することで、基幹系システムとしての性能・操作性の厳しい要件を満たすことができました。

プロジェクト管理上の課題と評価

プロジェクト管理上、最も問題になるのは、開発作業の作業標準の作成です。 特に大規模プロジェクトは、数十人から数百人の開発者が参加しますので、開発標準の標準化は、特に重要です。

オブジェクト指向開発では、一般に、設計と開発・テストを何回か繰り返すようなスパイラル型の開発や、プロジェクト全体では設計・開発・テストの同期をとらずに機能毎に進捗を管理するインクリメンタル型の開発が推奨されています。 しかし、大規模基幹系プロジェクトで、実際にスパイラル型開発が行われたことは極めて少なく、その導入リスクも高いです。 このプロジェクトでも、どのような開発標準でプロジェクトを計画するべきかが課題として、検討されました。

このプロジェクトは一般のアプリケーション開発の中では「超大規模」であり、結果として3000画面、設計時要件定義に関わる技術者数が200人、制御系アプリも1Ms以上の規模を持ちます。

プロトタイプ開発段階で、いくつかの試行錯誤を重ね、以下のような結論になりました。

このことは、他の大規模アプリ事例を通しても、同様のことが言えます。 基幹系大規模では、スパイラル型開発の考え方は一つのプロジェクトの中ではなく、システム全体のライフサイクルとして採用し、一つのプロジェクトの中は、フェーズドアプローチで、というのが一般的になりつつあります。

• スパイラル型開発
  
• フェーズドアプローチ型開発
  
• インクリメンタル型開発
  

コンポーネント化によるビジネス展開：FBC

プロジェクトの目的の一つに、コンポーネント指向開発を行うことで、開発資産を他企業のシステムへ展開するビジネスを立ち上げることがありました。 ここでつくられたコンポーネントの資産は、画面遷移制御に関するものの他に、金融IO制御などがあります。 例えば、照会端末であればブラウザだけで動作可能です。

コンポーネント群の中でも特徴的なのは、伝票処理においてイメージ処理を全面採用している点です。 Java/CORBA環境下でのイメージ処理とワークフローの組み合わせは、技術的な評価はもちろんですが、業務処理面での効果が特に大きいです。 例えば、銀行業務に限らず、流通、公共などの分野でも、業務の中に非定型で専門スキルが必要になる複雑な伝票処理業務が必ず存在します。 それに対応できる高スキルな業務要員を全営業所窓口に配置するのは、業務効率化の流れの中で非常に困難な状況です。 かといって、限られた拠点に紙の伝票を回送していては、時間がかかりサービスの低下を招きます。 このとき、伝票をイメージでネットワークを通じて専門要員に回送できたら、この問題は解決できます。

関連情報

• FBCのプレスリリース