(株)における Webベース業務システムの開発 (Takashi Tahara)

Download Report

Transcript (株)における Webベース業務システムの開発 (Takashi Tahara) 

ライカ マイクロシステムズ(株)における
Webベース業務システムの開発
Sep. 7, 1999
Takashi Tahara
Agenda
•
•
•
•
•
•
会社概要
開発のきっかけ
新システムの概要
なぜ、その技術や製品を採用したのか
Webベース システムの開発について
まとめ
会社概要
• 欧米のトップメーカー(ライツ、ウイルド、ケ
ンブリッジ等)の合併により設立された世界
的な企業グループ
• 研究用顕微鏡をはじめ最先端技術をライ
カ ブランドとして全世界に供給
• 販売サービス・ネットワークは、欧米・日本
をはじめ１００カ国以上をカバー
開発のきっかけ
業務フロー
ロジスティクス業務
営業業務
顧客/代理店
ｻｰﾋﾞｽ依頼 見積依頼
引合
貸出依頼
発注
商品受取
案件入力
営業活動の
状況の入力
営業
(サービス含む)
ｻｰﾋﾞｽ受付
見積
ｻｰﾋﾞｽ状況登録
保守部品発注依頼
案件情報を基
に見積書作成
デモ機貸出
在庫照会
貸出申請
受注受付
見積内容確定
リリース
ロジスティクス
BU
仕入先
倉庫
発注
在庫管理
出荷指示
受注情報を基に
国内外仕入先へ発注
入庫管理
返品管理等
受注情報を基に
出荷指示書作成
出荷
入庫
出荷
入庫結果の
入力
出荷状況の
照会・入力
現状の問題点
•
•
•
•
手作業とAS400の混在
データが一元管理されていない
アーキテクチャの陳腐化
Y2K
新システムの開発を決定
• 問題点を解決するためにアーキテクチ
ャの試験を行った後、新システムの開
発を決定
• しかし、多くのSIベンダーがDelphi +
DCOMでの開発に難色を示した
• 有限会社フュージョンが参加すること
で、新システムの開発がスタートでき
た
新システムの概要
システムの目標
•
•
•
•
•
データの一元管理
営業プロセスとモノの流れを把握
一元管理されたデータを戦略に利用
外回り営業のノートパソコンからの操作
TCOの削減
システム構成
HTTP
DCOM
Client (社内)
Net8
Windows98/NT
Internet Explorer
HTTP
DCOM
※RAS経由
Note PC (営業)
Windows98/NT
Internet Explorer
Application Server
Web Server
WindowsNT4.0EE
IIS4.0
COM Object
BDE, Net8
Database Server
WindowsNT4.0EE
Oracle8.05
なぜ、その技術や製品
を採用したのか
新システムで採用した技術と製品
•
•
•
•
•
3層C/S
Webベース
InternetExplorer + ActiveXコントロール
DCOM
Delphi
3層C/S
• 2層C/Sの問題点
– FATクライアント
– ビジネスロジックが共有できない
– スケーラビリティに欠ける
• 3層C/Sのメリット
– Thinクライアント
– ビジネスロジックを共有できる
– スケーラビリティがある
2層C/S：
SQL文
(Network)
Client
UI
BL
Database Server
DBMW
×クライアント台数の増
加により飽和しやすい
×FATクライアント
×BLが共有できない
3層C/S：
○SQLに比べ頻度が
低いためトラフィック
が低い
メソッド呼び出し
(Network)
Client
UI
○Thinクライアント
SQL文
(Network)
Application Server
BL
DBMW
○BLを共有できる
○スケーラビリティがある
Database Server
Webベース
• 2層C/Sの問題点
– 動作するために様々なソフトウェアが必要
– ソフトウェアの配布に手間がかかる
• Webベースのメリット
– Webブラウザがあれば動作する
– ソフトウェアの配布が簡単
2層C/S：
Client
UI
BL
×動作に必要なソフトウェアが多い
×ソフトウェアの配布に手間が掛かる
DBMW
Webベース：
○配布が簡単
UI
ダウンロード
Web Server
Client
IE
メソッド呼び出し
○Webブラウザだけでよい
○ビジネスロジックなどは
配布する必要がない
Application Server
DBMW
BL
Internet Explorer + ActiveXコントロール
• HTMLの問題点
– ＵＩの操作性が悪い
– フォーム送受信によるパフォーマンスの低下
– 生産性があまりよくない
• Internet Explorer+ActiveXコントロール
– Windowsアプリケーション同様の操作性
– 必要なデータのみを送受信できるためパフォ
ーマンスが良い
– 使いなれた開発ツールを利用できる
HTML：
ダウンロード,データの送信
(HTTP)
Client
×データ送受信のパフォー
マンスが悪い
Web Server
Browser HTML
×生産性が悪い
×操作性が悪い
○プラットフォームに依存しない
Internet Explorer + ActiveXコントロー
ル：
ダウンロード(HTTP)
Web Server
Client
IE
ActiveX
データの送信(DCOM)
○パフォーマンスが良い
○操作性が良い
×プラットフォームに依存する
○生産性が良い
Application Server
DCOM
• ソケット通信, VisiBroker, MIDAS
– ソケット通信: スレッド管理やマーシャリングな
どの部分に多くの実装が必要
– VisiBroker: 現状では、Delphiとの親和性に
疑問がある
– MIDAS: ビジネスロジックを実装しにくい
• DCOMのメリット
– ビジネスロジックを実装するだけで良い
• スレッドの管理やマーシャリングなどインフラ部分
はDCOMに実装されている
Delphi
• 開発したプログラムの「抜群の安定性」
• コンポーネントによる「抜群の生産性」
• コンポーネントのソースがあるため、不具
合の原因を完全に追求できる
• ランタイムの配布が不要
• DCOMとDelphiを理解している開発者が
いた
– もしいなければ、Delphiを採用しなかった
採用した技術および製品のまとめ
• 3層C/SとWebベースのいいとこどり
– Thinクライアント
– スケーラビリティ
– UＩの操作性が良い
• プログラムの抜群の安定性
– Delphiで開発したプログラムの抜群の安定性
• プログラムの抜群の生産性
– C/Sで使いなれたDelphiを利用できる
– コンポーネント
3層C/SとWebベースのいいとこどり：
3層C/Sの
長所
Webの長所
Delphiの長
所
Client
Web Server
Application Server
Thinクライアント
ビジネスロジックの共有
操作性が良い
スケーラビリティ
Thinクライアント
ソフトウェアの配布が簡単
抜群の安定性
抜群の生産性
Database Server
Webベース システムの
開発について
プログラムの構成
Client
Web Server
Application Server
Internet Explorer
ActiveForm
ユーザーインタ
ーフェースを表
示
ダウンロード
(HTTP)
メソッドの呼び出し
(DCOM)
Database Server
IIS 4.0
Oracle 8.05
COMオブジェクト
SQL文
BDE, Net8
SQL文
(Net8)
2層C/Sと3層C/Sでの開発の相違点
• クライアントとサーバーの処理の振り分け
– 2層C/S：ほとんどクライアントに実装
• サーバーをＣＯＭオブジェクトとして実装
• クライアントをActiveXコントロールとして実装
– 2層C/S：Windowsアプリケーション
• クライアントとサーバーをDCOMで接続
– 2層C/S：BDEとDBミドルウェア
2層C/S：
Database Server
Client
Windowsアプリケーション
メソッド呼び出し
UI
BL
DBMW
Database
SQL文
3層C/S：
Application Server
Client
COM オブジェクト
ActiveXコントロール
UI
凡例
Database Server
メソッド呼び出し
(DCOM)
2層C/Sと異なる部分
BL
DBMW
SQL文
Database
クライアントとサーバーの処理の振り分け
• サーバー
– ビジネスロジック
– データベースに関連する処理
• クライアント
– UIに関連する処理
– 日付の形式などUIに関連するチェックはクライアントに実装する
• サーバーとクライアント間のI/Oを決める
– オブジェクト、メソッド、パラメータ
– メソッドの呼び出し回数を極力少なくする
– どちらでエラーチェックをするかなど一貫したルールを決めること
COM(Component Object Model)とは？
• 米マイクロソフト社が策定したオブジェクト
間通信規約
• DCOMとは、COMをネットワーク経由で呼
び出せるように拡張したもの
• COM規約に従って実装することで、通信
部分を意識する必要がなくなる
– ビジネスロジックだけを実装すればよい
COMオブジェクトの実装(1)
• TRemoteDataModuleコンポーネント
– COMオブジェクトを表すデータモジュール
– ここにビジネスロジックを実装する
• Single Instance or Multiple Instance
– 別プロセスへの分割が必須でなければMultiple
Instance
• アパートメントスレッドモデル or フリースレッドモデル
– 複数並列実行が必須でなければアパートメントスレッ
ドモデル
• アパートメントスレッドモデル + Multiple Instanceで作
成するのが一般的
TRemoteDataModuleの作成：
Single Instance
or Multiple Instance
アパートメントスレッドモデル
or フリースレッドモデル
TRemoteDataModuleにビジネスロジックを実装：
クラスおよびメソッドを宣言
ビジネスロジックを実装
アパートメントスレッドモデルとフリースレッドモデル：
アパートメントスレッドモデル：
1アパートメントに1スレッド
STA (Single Thread Apartment)
スレッド
COM
Object
COM
Object
COM
Object
STA (Single Thread Apartment)
スレッド
COM
Object
COM
Object
COM
Object
フリースレッドモデル：
アパートメントに複数のスレッド
MTA (Multi Thread Apartment)
スレッド
スレッド
スレッド
COM
Object
COM
Object
COM
Object
COM
Object
COM
Object
Single Instance と Multiple Instance：
Single Instance：
COMクライアント毎にプロセスを作成
Multiple Instance：
１プロセスに複数のCOMオブジェクト
COM Server Process
COM Server Process
COMクライアント
COMクライアント
COM Object
COMクライアント
COM Object
COM Server Process
COMクライアント
COM Object
COMクライアント
COM Object
COM Object
COM Server Process
COMクライアント
COM Object
COMオブジェクトの実装(2)
• DBアクセスの注意点
– フリースレッドモデルでのマルチスレッド アク
セス
• スレッドごとにBDEセッションが必要
– TRemoteDataModuleにTSessionとTDatabaseを配
置し、TSession.AutoSessionName:=Trueに設定
– SQL文を明示的に発行する
• BDEやコンポーネントの挙動に悩まされないよう
にするため
• ※2層C/Sでも同じ
DCOMでの接続
• TDCOMConnectionとTSimpleObjectBroker
で接続
• 配布を単純にするためにレイトバインディングを
採用
– プロキシ/スタブDLL、タイプライブラリを配布・登録し
ないで済む
– この方法のデメリット
• パラメータの型はOLEオートメーション互換型に制限される
• COMオブジェクトの指定は、ProgIDではなく、
CLSID(GUID)でしか指定できない
• TDCOMConnectionをローカルレジストリを参照しないよう
に修正する必要がある
Application Server
Client
サーバー名の取得
DCOMで接続
COM
Object
サーバー名の取得
DCOMで接続
COM
Object
TSimpleObjectBroker:
サーバー名の一元管理
TDCOMConnection:
COMオブジェクトへの接続
ServerGUIDプロパティでCLSIDを指定
アーリーバインディングでは、クライアントにCOMサーバー情報の
配布・登録が必要：
アーリーバインディング
レイトバインディング
Client
Client
UI(ActiveX)
UI(ActiveX)
COMサーバーの
タイプライブラリ
COMサーバーの
プロキシ/スタブDLL
汎用レコードクラス
• クライアント/サーバー間でのレコードセット
の受渡しに利用
• 各プログラムで個別に構造体やクラスを定
義する必要がなくなる
• 汎用レコードクラスのマーシャリング
– OLEオートメーション互換型パラメータに渡す
ために、バイト配列のバリアントにマーシャリ
ングが必要
– TComponentクラスの機能を利用
Application Server
Client
ClientDataSet
格納
など
汎用レコード
オブジェクト
ClientDataSet
格納
など
汎用レコード
オブジェクト
アンパック バリアント型
パック
パック
汎用レコード
オブジェクト
汎用レコード
バリアント型 アンパック
オブジェクト
格納
更新
結果セット
Database
レイトバインディングのため
バリアント型への
マーシャリングが必要
{--------------------------------------コンポーネントをバリアント型にパックする
---------------------------------------}
function ComponentToVariant( Instance: TComponent ): OleVariant;
var
Stream: TMemoryStream;
P: Pointer;
begin
Result := Unassigned;
Stream := TMemoryStream.Create;
try
Stream.WriteComponent( Instance );
Stream.Position := 0;
Result := VarArrayCreate( [0,Stream.Size], varByte );
P := VarArrayLock(Result);
try
Stream.Read( P^, Stream.Size );
finally
VarArrayUnlock(Result);
end;
finally
Stream.Free;
end;
end;
{--------------------------------------バリアント型からコンポーネントにアンパックする
---------------------------------------}
function VariantToComponent( AValue: OleVariant ): TComponent;
var
Stream: TMemoryStream;
P: Pointer;
begin
Stream := TMemoryStream.Create;
try
Stream.Size := VarArrayHighBound(AValue, 1);
P := VarArrayLock(AValue);
try
Stream.Write(P^, Stream.Size);
finally
VarArrayUnlock(AValue);
end;
Stream.Position := 0;
Result := Stream.ReadComponent( nil );
finally
Stream.Free;
end;
end;
COMオブジェクト ラッパー
• COMオブジェクトをカプセル化
– 接続先情報(マシン名、CLSID)
– 汎用レコードクラスのマーシャリングを隠蔽
• 普通のクラスと同様に利用できる
– COMオブジェクト ラッパー利用者は、COMオ
ブジェクトを意識する必要が無い
• データキャッシングやモバイルの不安定な
通信回線への対処にも応用できる
Application Server
Client
COMオブジェクト ラッパー
プログラム
メソッド
呼び出し
COMオブジェクト
への接続情報
DCOM
COMオブジェクト
レコードオブジェクト
のマーシャリング
COMオブジェクトの面倒な部分をカプセル化
普通のObject Pascalのクラスと同様に扱える
クライアントデータセットの利用
• サーバーから受け取ったデータの保存先
として利用
• ActiveForm上のDBGridへの表示・編集
などに利用
データコントロール
コンポーネント
表示
編集
ClientDataSet
格納
汎用レコード
オブジェクト
ActiveFormへのUIの実装
• C/Sと同じテクニックが利用できる
• 複数のフォームを切り替える方法
– ActiveFormを親コントロールに指定する
• 顧客一覧検索など共通に使用する画面は
DLLに実装して共有することも可能
– .infでDLLの転送先を指定すること
• 例：destdir=11
# system32に転送
• ActiveForm間の呼び出しは難しい
– ActiveXコントロールの切り分けに注意が必要
DCOMの注意点
• オブジェクトの実体を渡すことができない
– リスト オブジェクトなどの内容は配列や構造体にしな
いと渡せない
– 独自の例外クラスが定義できないため、例外で伝播
できる情報が少なすぎる
• マーシャリングコードが静的リンクできない
– レイトバインディングにするか、プロキシ/スタブDLLや
タイプライブラリの配布・登録が必要
• セキュリティーが難解
• VisiBrokerに比べ見劣りする
まとめ
まとめ
• 3層C/S + Webベースにすることで、2層
C/Sのさまざまな問題点を解決できる
• 各技術や製品のメリット/デメリットを見極
めてから採用すること
– 技術に振り回されないように注意
• Delphi
– 様々な技術を簡単かつ制限なく利用できる
– 開発したプログラムの抜群の安定性
– コンポーネントによる抜群の生産性
ライカ マイクロシステムズ(株)における
Webベース業務システムの開発
Sep. 7, 1999
Takashi Tahara