クライアント/サーバー管理
組み込みクライアント/サーバーアプリケーションまたはリモートプロジェクトの形で、4Dデスクトップアプリケーションをクライアント/サーバー構成で運用することができます。
-
組み込みクライアント/サーバーアプリケーション は アプリケーションビルダー を使って生成します。 これらは、アプリケーションの運用に使います。
-
リモートプロジェクト とは、4D Server 上で開いた .4DProject ファイルのことで、リモートモードの 4D を使って接続します。 4D Server は、プロジェクトの 圧縮形式 である .4dz ファイルをリモートの 4D に送信します。つまり、ストラクチャーファイルは読み取り専用です。 この構成は通常、アプリケーションのテストに使います。
ただし、4D Server と同じマシン から接続している場合には、プロジェクトファイルの変更が可能です。 この 特殊機能 により、クライアント/サーバーアプリケーションを運用時と同じコンテキストで開発することができます。
組み込みクライアント/サーバーアプリケーションを開く
ビルドされたクライアント/サーバーアプリケーションは起動や接続処理が簡易です:
- サーバーを起動するには、サーバーアプリケーションをダブルクリックします。 プロジェクトファイルを選択する必要はありません。
- クライアントを起動するにも、同様にクライアントアプリケーションをダブルクリックします。すると、サーバーアプリケーションへの接続が直接おこなわれるため、
詳細については アプリケーションビルド ページを参照ください。
リモートプロジェクトを開く
4D Server 上で動いているプロジェクトに初めて接続する場合は、通常は標準の接続ダイアログを使います。 以降は、最近使用したプロジェクトを開く メニューや、4DLink ショートカットファイルを使って直接接続できるようになります。
4D Server で実行されているプロジェクトに接続するには:
- 次のいずれかの方法をおこないます:
- Welcome ウィザードにて 4D Serverに接続 を選択します。
- ファイル メニューより **開く ＞ リモートプロジェクト...**を選択するか、開く ツールバーボタンより同様に選択します。
4D Server に接続するためのダイアログが表示されます。 ダイアログには 最近使用、利用可、および カスタム という、3つのタブがあります。
リモートの 4D と同じサブネットワークに 4D Server が接続されている場合は 利用可 タブを選択します。 4D Server には組み込みのブロードキャストシステムがあり、デフォルトで、ネットワーク上に利用可能な 4D Server データベースの名前を公開します。 このリストは、名前が見つかった順に表示され、動的に更新されます。
このリストからサーバーに接続するには、名前上でダブルクリックするか、名前を選択して OK ボタンをクリックします。
公開されているプロジェクトが 利用可 タブに見つからない場合には、カスタム タブを開きます。 カスタムページでは、IPアドレスでネットワーク上のサーバーを指定し、それに任意の名前をつけられます。
- プロジェクト名: 4D Server プロジェクトのローカル名を指定できます。 この名前は 最近使用 ページでプロジェクトを参照する際に使用されます。
- ネットワークアドレス: 4D Server が起動されたマシンの IPアドレスを指定します。
- 2つのサーバーが同じマシン上で同時に起動されているときは、IPアドレスの後にコロンとポート番号を続けます。例:
192.168.92.104:19820。 - デフォルトで、4D Server の公開ポートは 19813 です。 この番号は、プロジェクト設定で変更できます。
- 2つのサーバーが同じマシン上で同時に起動されているときは、IPアドレスの後にコロンとポート番号を続けます。例:
開発モードを有効化する オプションは、特別な読み取り/書き込みモードでリモート接続を開きます。このモードでは、リモート4D からプロジェクトフォルダーへのアクセスが確保されている必要があります。
このページでサーバーを指定したら、OK ボタンをクリックしてサーバーに接続できます。
サーバーとの接続が確立されると、そのリモートプロジェクトは 最近使用 タブのリストに加えられます。
サーバー上のプロジェクトファイルの更新
インタープリターモードの場合、4D Server は .4DProject プロジェクトファイル (非圧縮) の .4dz ファイルを自動的に作成し、リモートマシンに送信します。
- プロジェクトが編集され 4D Server にリロードされた場合など、必要に応じてプロジェクトの .4dzファイルは自動的に更新されます。 プロジェクトは次の場合にリロードされます:
- 4D Server アプリケーションウィンドウが OS の最前面に来たり、同じマシン上の 4D アプリケーションが編集を保存した場合 (後述参照) に自動でリロードされます。
RELOAD PROJECTコマンドが実行されたとき。 プロジェクトの新しいバージョンをソース管理システムよりプルしたときなどに、このコマンドを呼び出す必要があります。
リモートマシンのプロジェクトファイルの更新
4D Server 上で .4dz ファイルの更新版が生成された場合、その更新版を利用するには、接続中のリモート 4D マシンは一度ログアウトし、4D Server に再接続する必要があります。
4D と 4D Server の同じマシン上での使用
同じマシン上で 4D が 4D Server に接続すると、アプリケーションはシングルユーザーモードの 4D のようにふるまい、デザイン環境にてプロジェクトファイルの編集が可能です。 この機能により、クライアント/サーバーアプリケーションを運用時と同じコンテキストで開発することができます。
同じマシン上で 4D Server に 4D を接続する場合には、 開発モード オプションの設定にかかわらず 開発モード が自動的に有効化されます。
デザイン環境にて 4D が すべてを保存 アクションを (ファイル メニューを使って明示的に、または、アプリケーションモードへの移行により暗示的に) おこなうと、4D Server は同期的にプロジェクトファイルをリロードします。 4D Server によるプロジェクトファイルのリロードが完了するのを待って、4D は続行します。
ただし、標準のプロジェクトアーキテクチャー とは次のふるまいにおいて異なりますので、注意が必要です:
- 4D が使用する userPreferences.{username} フォルダーは、4D Server が使用するプロジェクトフォルダー内のものと同一ではありません。 4D が使用する userPreferences.{username} フォルダーは、4D Server が使用するプロジェクトフォルダー内のものと同一ではありません。
- 4D が使用する DerivedData フォルダーは、4D Server が使用するプロジェクトフォルダー内のものと同一ではありません。 この専用の "DerivedDataRemote" フォルダーはプロジェクトのシステムフォルダー内に格納されます。
- catalog.4DCatalog ファイルは 4D ではなく 4D Server によって編集されます。 catalog の情報はクライアント/サーバーリクエストによって同期されます。
- directory.json ファイルは 4D ではなく 4D Server によって編集されます。 directory の情報はクライアント/サーバーリクエストによって同期されます。
- 4D は、4D Server 上のものではなく、独自の内部的なコンポーネントやプラグインを使用します。
プラグインやコンポーネントを 4D あるいは 4D Server アプリケーションレベルにインストールすることは、推奨されません。
開発モード
4D Server における 開発モード とは、接続したリモート4D アプリケーションに読み/書きアクセスが許可されるプロジェクトを開くときの特別なモードです。 プロジェクトはインタープリタ モード でなければなりません。
このモードでは、同じプロジェクトに対して複数のデベロッパーがデザイン環境で同時に作業することができます。 プロジェクトが開発モードで開かれている場合、以下のような特徴があります:
- プロジェクトファイルは読み/書きが可能な状態なので、メソッドやフォームなどを編集することができます。
- 複数のリモート4D が、同じインタープリタ版のプロジェクトファイルを同時に開いて、それを編集することができます。 この場合、自動ロックシステムが同じリソースへの同時アクセスを防止します。
- 編集は全てのリモートデベロッパーに対して利用可能になります。 ただし、このときリモートデベロッパーに対しては自動的なプッシュは起こらなず、最新のバージョンのファイルを取得するためには更新を行う必要があります(更新は、デベロッパーがデザインモードからアプリケーションモードへと切り替えるか、あるいは ファイル メニューから 全て保存 を選択したときに毎回起こります)。
このモードを使用するには、リモート4D から接続ダイアログボックス から開発モードを有効化する を選択する必要があります。 次に4D プロジェクトファイルを選択してくださいと表示されます: 4D Server が開いている .project ファイル を選択する必要があります。 異なるファイルを選択した場合、開発モードが利用できないことを警告するアラートダイアログボックスが表示されます。 これは、リモート4D がプロジェクトフォルダに対してネットワーク越しでもアクセス権を持っていなければならないことを意味します(例えばプロジェクトのroot フォルダが共有されているなど、プロジェクトファイル全体が共有されている必要があります)。
この設定においてはパフォーマンス上の理由から、プロジェクトフォルダがローカルネットワーク上の専用のファイルサーバー上(例: NAS など)に保存することが強く推奨されています。
サーバーとリモート4D が同じマシン上にある場合、追加のルールが適用されます。
開発モードアーキテクチャーの概要は以下のようになります:
この機能は、バイナリーデータベースで作業するのに慣れていて、現在の構成を維持したままプロジェクトモードでの機能を利用したいような、小規模な開発チーム向けに設計されています。 しかしながら、4D プロジェクト上でのマルチユーザー開発については、デベロッパーがそれぞれのマシン上で開発を行い、その作業をソース管理レポジトリツール(Git、SVN など)で管理する標準のアーキテクチャーを使用することが強く推奨されます。 この構成であれば、デベロッパーが異なるブランチで作業をしたり、行った編集の比較、マージ、差し戻しなどが可能になり、大きな柔軟性を持ちます。
コードの実行場所
クライアント/サーバーアプリケーションにおいては、コードが実際に実行される場所を知っておくことが重要です: サーバー側 あるいは クライアント側 のどちらかです。 実行場所を知っておくことは、ユーザーセッション関連のコードの実装、プロセス間での情報の共有、またはデータのアクセスなどの際に非常に重要となります。
以下の表は、デフォルトでのコードの実行場所と、その実行場所を切り替えるための方法(許可されていれば)をまとめたものです。 この表での ローカル とは、コードはそれが実際に呼ばれたマシン上で実行されることを意味するという点に注意してください。
| コード | デフォルトの実行場所 | 切り替え方法 |
|---|---|---|
| ORDA データモデル関数 | server | 関数定義内で local キーワードを使用 |
ORDA 計算属性関数のうち get()、 set() | server | 関数定義内で local キーワードを使用 |
ORDA 計算属性関数のうち query()、 orderBy() | server | n/a |
| ORDA イベント関数 (全般) | server | n/a |
ORDA イベント関数 constructor() | local | n/a |
ORDA イベント関数 event touched() | server | 関数定義内で local キーワードを使用 |
| ユーザークラス関数 | local | n/a |
| 共有シングルトンまたは施ッションシングルトンの関数 | local | 関数定義内で server キーワードを使用 |
| トリガ | server | n/a |
| クライアントから呼び出されたプロジェクトメソッド | client | サーバー上で実行する オプション をチェックする。 コードは、ユーザーセッションプロセス のツインプロセス内で実行されます。 |
Execute on server コマンドを呼び出す。 コードはストアドプロシージャセッション 内で実行されます。 | ||
| サーバー上のストアドプロシージャから呼び出されたプロジェクトメソッド | server | EXECUTE ON CLIENT コマンドを呼び出す。 ターゲットとなるクライアントは 登録されている 必要があります。 |
| オブジェクトメソッド | local | n/a |
以下のデータベースメソッド:
| server | n/a |
以下のデータベースメソッド:
| client | n/a |
スリープしたクライアントセッションの管理
4D Server は、サーバーマシンへの接続がアクティブである間にスリープモードへと切り替わってしまった 4Dリモートアプリケーションを実行しているマシンについて、特別な管理をします。
この場合、リモートアプリケーションはスリープする前に4D Server へと自動的に知らせます。 対応するクライアントセッションはステータスはSleeping へと変更されます。
このステータスはセッションのコンテキストを保持しつつ、サーバー側のリソースを一部解放します。
リモートマシンがスリープモードから復帰した時、アプリケーションは再接続し、既存のセッションを復元します。
スリープ状態のクライアントセッションは、48時間活動がなかった場合には自動的にドロップされます。
この\タイムアウトを変更するには、SET DATABASE PARAMETER コマンドの Remote connection sleep timeout セレクターを使用します。
到達不能なピアの管理
QUIC ネットワークレイヤーが使用されている 場合、クライアント/サーバーせションでは予期せぬ接続切断の場合に 自動再接続機能 の恩恵を受けることができます。 予期せぬ接続切断とは、例えば以下の様な場合を含みます:
- LAN ケーブルの抜き差し
- モバイル接続の移行
- スイッチの再起動
- 小さなネットワークエラー。
この機能はピアとの接続が切断された場合の、サーバー側とクライアント側との両方をサポートしており、また設定可能なタイムアウトとリアルタイム情報も含みます。
到達不能イベント
QUIC ネットワークレイヤーは、リモート4D が予期せず対応できない状態になったときには、自動的に"到達不能"イベントを4D Server に送信します。逆に、4D Server が予期せず対応できない状態になったときには、リモート4D に"到達不能"イベントを自動的に送信します。 どちらか側で"到達不能" イベントが受信されると、その情報はインターフェース内とマシンのSession オブジェクト内にて即座に反映されます。
リモート4D側が応答を停止した場合
リモート4D が予期せず応答を停止した場合、サーバー管理ウィンドウ 上では、リモートセッションのステータス が到達不能 に設定されます。
サーバーが応答を停止した場合
4D Server が予期せず応答を停止した場合、リモートマシン上では再接続ダイアログボックスが表示されます:
セッションオブジェクトの更新
どちらかで"Unreachable" イベントが受信された時、イベントを受信したマシン上のセッション内にてinfo.unreachableSince プロパティが作成され(サーバー上ではこれはProcess activity.sessions プロパティを通して読み出し可能です)、また最後の通信からの秒数をカウントし始めます。 このプロパティを使用して独自の接続解除インターフェースを実装することができます。
接続の復元または解除
QUIC セッションのタイムアウトはデフォとでは900 秒(15分) となっており、これはSET DATABASE PARAMETER コマンドのQUIC session timeout セレクターを使用することで変更することができます。
QUIC セッションタイムアウトは、接続解除をモニターするために以下の様に自動的に使用されます:
- 接続がQUIC セッションタイムアウトに達する前に復元された場合、
info.unreachableSinceプロパティはセッションオブジェクトから自動的に削除されます。 - 接続がQUIC セッションタイムアウトに達するまでに復元されなかった場合、セッションは閉じられます。
- サーバーマシン上でリモートセッションが閉じられた場合、警告エントリーが診断ログ 内に書き込まれます。
- リモートマシンにおいてサーバーセッションが閉じられた場合、警告ダイアログが表示され、ユーザーはリモートアプリケーションを再起動するか終了するかを選択することができます:
