AP処理方式¶
AP基盤機能一覧¶
Web・バッチアプリケーションを設計・実装を行う場合、AP処理方式・AP基盤機能として、 以下の事項を検討する必要がある。プロジェクト要件に応じて、各項目の検討の要否を決定すること。
No | 検討事項 | 詳細 | 処理方式概要(例) | 備考 |
---|---|---|---|---|
1 | 業務ロジック実行方式 | 業務ロジックの実行方式及びトランザクション境界、各コンポーネントの責務を検討する。 | コンポーネントの責務やトランザクション境界の設定は TERASOLUNA FW5ドメイン層の実装に従い、イベントごとにServiceを実装する。 | ビジネスロジックの業務例外発生時のリトライ等要件があれば別途方式を検討。 |
2 | 業務ロジック入出力データマッピング方式 | リクエストパラメータから業務ロジックインプットデータ、アプトプットデータからレスポンスへのデータマッピング方式を検討する。 | Controllerクラス内で Dozerをベースとしたマッピング処理にて行う。必要に応じてマッピング設定ファイルを作成する。 | その他、ModelMapperやCommonsBeanUtilsなども検討 |
3 | 純バッチ実行方式 | 時刻起動やイベント契機で起動するジョブ及びシェルスクリプト、バッチ処理プログラムの実行方式を検討する。 | コンポーネントの責務やトランザクション境界の設定は TERASOLUNA FW5のアーキテクチャに従い、実装する。 | バッチ実行時の業務例外発生時のリトライ・リラン等要件があれば別途方式を検討。 |
4 | 非同期実行方式(ディレードバッチ処理) | オンラインから非同期で別処理(別スレッド)を実行する方式を検討する。 | TERASOLUNA Batch5 におけるDBポーリング型のディレードバッチ実行方式に準ずる。バッチ実行完了の通知は要件に応じてプッシュ型もしくはポーリング型か処理方式を検討し、決定する。 | 通知をプッシュ型にするのであれば、WebSocketsやCometの採用を検討 |
5 | データベースアクセス方式 | データベースへアクセスし、 データの参照、更新、挿入、削除を行う方式を検討する。 | FW5におけるデータベースアクセス(JPA)に準拠し、SpringDataJPAを利用して実装する。 | 各ユースケースの例は、を参照のこと。 |
6 | 入力チェック方式 | 単項目、相関項目、業務処理チェック行う方式を検討する。 | 単項目、相関項目チェック方式に関しては、TERASOLUNA FW5における入力チェックに準拠し、Bean Validation及びSpringValidatorを用いて実装する。 DBアクセスを伴う業務チェック処理については、フィルタもしくは、Serviceにて実装するロジック内で業務個別に実装する。 | 外字が含まれる文字列をチェックする場合はコードポイントを利用したチェックロジック部品の作成を検討。 |
7 |
ログ出力方式 - 業務ログ - 操作(監査ログ) - トレース(デバッグログ) |
システムとしてのログ要件を決定し、出力ログの項目、出力方式、出力場所、出力タイミングを検討する | 一般的なログ要件と出力フォーマット仕様はこちらを参照のこと。 画面遷移の情報を含むログについてはSpringのAOPを用いて、Controller実行時にAP基盤機能が出力する。 | アプリケーションサーバで物理サーバ数が多くなる場合やMicroService構成で複数のサービスを跨ぐ場合はMDCの利用を検討 |
8 | 排他制御機能 (ACIDトランザクション) | データベースアクセス時の排他制御の方式を検討する | 排他制御はDBMSの排他制御機能を利用する。 制御レベルはSpringのデフォルトに従う。 | オンライン時間帯にバッチが実行される場合など、1トランザクション内での複数テーブル更新時のデッドロック回避のため、更新テーブルの更新順序を検討すること。 |
9 | 排他制御機能 (ロングトランザクション) | 画面を跨ぐ業務トランザクションの排他制御 (楽観ロック、悲観ロック)の方式を検討する。 | 楽観ロック方式で制御する。JPAのデフォルトに従い、DBの各テーブルにバージョンカラムを設け、 データ挿入・更新・削除時にカラムバージョンを比較し、 異なれば業務エラーとする。 | |
10 | 例外ハンドリング方式 | 業務例外やシステム例外、入力値例外に関する方式を検討する。 | 基本的な考え方はTERASOLUNA FW5 標準の例外ハンドリング方式に従う。Spring Frameworkの例外ハンドリング機能を利用して処理する。 非同期通信による入力値エラーはExceptionHandlerにて共通的に例外処理を行いBadRequestを返却する方針とする | |
11 | セッション管理方式 | セッションに格納する対象のデータ選定や ステートフル・スレートレス処理に関する内容を検討する | 詳細はこちらを参照すること。 ユーザ情報以外のデータはセッションに保持せず、業務データは基本リクエストパラメータで持ちまわる(ステートレス)方針とする。 | |
12 | メッセージ管理方式 | 業務メッセージ、画面メッセージ、 エラーメッセージを保持・利用する方式について検討する。 | プロパティファイルにて管理する。 | メッセージのオン中変更を実現するのであれば、DBテーブル管理を検討すること。 |
13 | プロパティ管理方式 | プロパティとして保持する対象について選定、 管理方式について検討する。 | Springのプロパティファイル管理機能を用いる | |
14 | 定数・列挙型管理方式 | 列挙型・定数として保持する対象について選定、 管理方式について検討する。 | 列挙型クラス、定数クラスを共通ライブラリとして作成し、保存する。 | |
15 | 文字コード・ロケール | 文字コードとロケールについて検討する | 文字コードを参照のこと、サーバ側はデフォルトUTF8で対応。ロケールはja_JP前提で実装を行う | 国際化対応が必要な場合、ロケールに依存しない実装を行うこと。 |
16 | 国際化機能 | 他言語表示の方式について検討する | TERASOLUNA FW5の国際化方式に従う。 | 国際化対応が必要な場合、静的文言はメッセージプロパティで切り替え、 コードリストは他言語表示でも問題ない内容を検討すること。 |
17 | ページネーション機能 | ページネーションの方式について検討する | TERASSOLUNA FW5のガイドライン「ページネーション」に従い、 Pagableオブジェクトを利用する形で実装する。 | |
18 | 2重送信防止 | 2度押し防止のための方式を決定する。 | 更新系処理については、JavaScriptでボタンの2度押しを抑止することに加えて、TERASOLUNA FW5のガイドライン「2重送信防止」の実装に従い、 トランザクショントークンの実装を行うことで実現する。 なお、更新系処理はPRGパターンに沿って、画面遷移を設定する。 | |
19 | コードリスト機能 | 静的・動的コードリスト対象選定・実装方式について検討する | TERASOLUNA FW5のガイドライン「コードリスト」 に従い、利用する。 | |
20 | 非同期通信(Ajax)機能 | 非同期通信要件の有無について確認、通信処理方式などの検討を行う。 | TERASOLUNA FW5のガイドライン Ajax に添う形で実装する。 | |
21 | ファイルアップロード機能 | ファイルアップロード処理方式に関する検討を行う。 | TERASOLUNA FW5のファイルアップロード に従う形で実装する。 | |
22 | ファイルダウンロード機能 | ファイルダウンロード処理方式に関する検討を行う。 | TERASOLUNA FW5のファイルダウンロード に従う形で実装する。 | |
23 |
リクエストフィルタリング - エンコーディング機能 - IPアクセス制御機能 - サニタイズ機能 |
リクエストフィルタリング対象の機能要件を確定し、方式を検討する。 | サーブレットフィルタを利用してAP基盤部品として実装する。 | |
24 | サーバ閉塞チェック機能 | サーバが停止している場合のアクセス制御についてを検討する。 | Sorryサーバにて対応するため、APの考慮は不要 | ビジネスロジックの業務例外発生時のリトライ等要件があれば別途方式を検討。 |
25 | 業務閉塞チェック機能 | 一部業務や、機能を停止する場合のアクセス制御についてを検討する。 | 機能ごとの時間制御情報テーブルをデータベースに作成し、 サーブレットフィルタにてチェックを行うAP基盤処理を追加する | |
26 | 日付・時刻制御機能 | システム日付や時刻、業務日付や時刻の概念を整理し、 業務・機能の時刻制御方式有無を確認。取得や制御方式を検討する。 | 営業日日付テーブル等をデータベースに作成し、チェック処理など必要に応じてAP基盤部品として実装する。 | 営業日やサマータイムなどシステム時間とは別の業務概念の日付・時刻について留意。TERASOLUNA FW5のガイドライン「システム時刻」も合わせて参照すること。 |
27 | 帳票出力方式 | 帳票の形式や要件を整理し、帳票作成・出力のオンライン処理・バッチ処理方式を検討する。 | ||
28 | メール送信機能 | メール送信の要件有無を確認し、実装方式を検討する。 | TERASOLUNA FW5のガイドライン「Email送信」に従い、実装を行う。 | |
29 | ヘルスチェック機能 | サーバの死活状況監視の要件の必要性を確認し、方式について検討する | TERASOLUNA FW5のガイドライン「ヘルスチェック」 に従い、 AP基盤部品として実装する。 | |
30 | XMLマーシャル・アンマーシャル機能 | XMLとJavaオブジェクトのマーシャル、アンマーシャルの処理要件の有無を確認し、方式について検討する。 | JAXB、SAX、StAX等のXML処理を Java標準クラスライブラリのものを利用するか、 オープンソースのライブラリを使用するか、 XML処理内容・性能に応じて適切な方法を検討すること。 | |
31 | ワークフロー機能 | ビジネスユースケースにおいて、システム処理でワークフロー制御が必要な場合、処理方式を検討する。 | DBテーブルにステータス管理テーブルを作成し、業務チェックの中で制御する。 | ワークフロー機能をもつミドルウェアの採用も必要に応じて検討する。 |
32 | ファイル転送機能 | 外部システムへのファイル転送有無に関する要件を確認し、処理方式を検討する | HULFTといったミドルウェア、FTP、rsyncなどのファイル転送処理方式を検討すること。 | |
33 | 共有ファイル・キャッシュ接続方式 | NFSや、キャッシュ、共用ストレージの利用有無を確認し、処理方式を検討する | ||
34 |
メッセージ通信方式 - MQ - CORBA - RPC |
外部システムとのメッセージ通信(メッセージキュー)や、CORBA通信、RPC利用有無を確認し、処理方式を検討する | MQの通信については、TERASOLUNA FW5ガイドライン「JMS 」に準拠した実装を行う。 | |
35 |
WebServeice - JAX-RS - JAX-WS - JSON-HTTP |
外部システムとのXML、JSON形式のHTTP通信やSOAPプロトコルの利用有無を確認し、処理方式を検討する | TERASOLUNA FW5ガイドライン「Restクライアント」、TERASOLUNA FW5ガイドライン「RESTful WebService」、TERASOLUNA FW5ガイドライン「SOAP WebService」に準拠する。 | |
36 | 文字列操作機能 | 文字列を操作するユーティリティの要否について確認し、処理方式を検討する。 | 部品の実装は TERASOLUNA FW5のガイドライン 「文字列操作」 も参考のこと。 | |
37 | 日付操作機能 | 日付を操作するユーティリティの要否について確認し、処理方式を検討する。 | 部品の実装はTERASOLUNA FW5のガイドライン 「日付操作(JSR-310 Date and Time API)」 、TERASOLUNA FW5のガイドライン 「日付操作(JODA Time)」 も参考のこと。 | |
38 | 集合演算機能 | 演算処理ユーティリティの要否について確認し、処理方式を検討する。 | ||
39 | ZIP圧縮・解凍機能 | ZIP圧縮・解凍を行うユーティリティの要否について確認し、処理方式を検討する。 | ||
40 | ファイル生成機能 | CSVやテキスト、PDFといったファイル生成機能の要否を検討し、処理方式を検討する。 | ||
41 | BASE64エンコード機能 | BASE64エンコード処理方式を検討する。 | ||
42 | 暗号化・複合化機能 | 個人情報データなど暗号化処理する必要のあるデータの有無について確認し、 暗号化・複合化の処理方式を検討する | ||
43 | 認証機能 | リクエスト認証処理方式について検討する | TERASOLUNA FW5のガイドライン 「認証」 に記載されている内容に基づき、リクエスト認証はSpring Securityを使用する。 | |
44 | 認可機能 | リクエスト認可処理方式について検討する | TERASOLUNA FW5のガイドライン 「認可」 に記載されている内容に基づき、認可はSpring Securityで実現する。 | 画面コンテンツの表示制御はNo39を参照。 |
45 | 画面遷移制御方式 | 画面遷移に関するアクセス制御が必要な場合、方式について検討する | トークンによる画面アクセス制御をAP基盤機能として実装する。 | |
46 | 画面表示制御方式 | 画面コンテンツの表示制御方式について検討する | ||
47 |
セキュアパスワード機能 セキュアパスワード生成 パスワードチェック パスワードハッシュ化方式 |
パスワード要件を整理し、生成・チェック機能の要否、処理方式を検討する。 | TERASOLUNA FW5ガイドライン 「認証」に記載されている内容に基づき、Spring Securityの拡張として実装する。 | |
48 |
パスワード変更通知 強制変更機能 |
パスワード要件を整理し、変更通知、強制変更機能の要否、処理方式を検討する。 | ||
49 | マスキング機能 | 画面にマスキングして表示する要件について確認し、処理方式について検討する | ||
50 | セキュアコマンド実行機能 | ディレクトリトラバーサル・OSコマンドインジェクションに対する防止策の要否について確認し、処理方式を検討する | ||
51 |
なりすまし防止機能 - セキュアセッションID生成 - セキュアCookie発行 |
なりすましに対する防止策の要否について確認し、処理方式を検討する。 | ||
52 | プロジェクト・パッケージ構成の検討 | アプリケーションのプロジェクト・パッケージ構成を検討する。 | ||
クラウドネイティブアプリケーションの処理方式¶
クラウド環境でアプリケーションを構築した場合、主な処理方式で差分が発生しやすい処理方式・機能は以下の通りである。 また、処理方式概要には、AWSを利用した場合の処理方式概要例を記載する。
No | 検討事項 | 詳細 | 処理方式概要(例) | 備考 |
---|---|---|---|---|
3 | 純バッチ実行方式 | コンテナ上で実行した場合のジョブ・バッチLaunch方式、多重実行処理や、リラン・リスタートなどの方式について検討する必要がある。 | ||
5 | データベースアクセス方式 | AWS DynamoDBやMongoDB、Apache Cassandraといった、NoSQL型のデータストアを利用するケースが増え、RDBと方式が異なるデータベースアクセス方式が必要になる。また、サーバスケールを想定したシャーディングなどの方式を検討する必要がある。 | ||
8 | 排他制御機能 (ACIDトランザクション) | NoSQL DBの多くは完全な一貫性や原子性が担保されないため。排他制御に関するポリシーを決定しておく必要がある。 | ||
10 | 例外ハンドリング方式 | クラウドベンダが提供するサービス(AmazonS3やAmazonLambda、AmazonSQSなど)を利用した場合の例外ハンドリング方法を検討しておく必要がある。 | ||
11 | セッション管理方式 | クラウド環境下でスケールアウト・スケールインする環境下でセッション情報を共有し、サーバ間で擬似的なステートレス方式を実現する必要がある。 | Macchinettaガイドライン「セッション外部管理」に従い、セッション情報をElasticCacheへ委譲する方式とする。 | |
15 | 文字コード・ロケール | クラウド環境下では実行されるアプリケーションのロケールが異なる場合があるので、ロケーションを考慮したアプリケーション設計を検討する必要がある。 | ||
21 | ファイルアップロード機能 | アプリケーションサーバ環境がスケーラブルであり、また、揮発性(いったん再起動するとストレージのデータが初期化される可能性)があるため、 ファイルアップロード時のデータ保存のポリシーや共有ストレージへの直接クライアントからのアクセスする方式を検討しておく必要がある。 | Macchinettaのガイドライン「ファイルアップロード管理」に基づき、 AmazonS3へファイルをアプリケーションサーバ及びクライアントからダイレクトアクセスする方式とする。 | |
22 | ファイルダウンロード機能 | アプリケーションサーバ環境がスケーラブルであり、また、揮発性(いったん再起動するとストレージのデータが初期化される可能性)があるため、 共有ストレージへのクライアントからのダイレクトアクセス方式を検討しておく必要がある。 | Macchinettaのガイドライン「ダウンロードファイル管理」に基づき、 AmazonS3からファイルを取得及びクライアントからダイレクトアクセスする方式とする。 | |
24 | サーバ閉塞チェック機能 | サーバが停止している場合のアクセス制御についてを検討する。 ブルーグリーンデプロイメントなどのクラウドが推奨する方式に基づき、サーバ閉塞ポリシーを決定する必要がある。 | ||
28 | メール送信機能 | クラウドベンダが提供するメール配信サービスを利用した方が効率的な場合があるため、その点を考慮したアプリケーション設計が必要となる。 | Machinettaガイドライン「メール送信」に従い、SESを使用したメール送信処理を実装する。 | |
29 | ヘルスチェック機能 | クラウドベンダが提供するヘルスチェックサービスを利用した方が効率的な場合があるため、その点を考慮したアプリケーション設計が必要となる。 | Machinettaガイドライン「ヘルスチェック」に従い、ヘルスチェック処理を実装する。 | |
32 | ファイル転送機能 | クラウドベンダが提供するサービスを利用した方が効率的な場合があるため、その点を考慮したアプリケーション設計が必要となる。 | ||
33 | 共有ファイルシステム・キャッシュ接続方式 | アプリケーションサーバ環境がスケーラブルであり、また、揮発性(いったん再起動するとストレージのデータが初期化される可能性)があるため、 共有ストレージ(AamazonS3やElasticCache)へのアクセス方式を検討しておく必要がある。 | Macchinettaガイドライン「ファイルアップロード」に従い、AmazonS3へデータを保存する。 | |
34 |
メッセージ通信方式 - MQ - CORBA - RPC |
クラウドベンダが提供するサービス(AmazonSQSなど)を利用した方が効率的な場合があるため、その点を考慮したアプリケーション設計が必要となる。 | Machinettaガイドライン「キューイング活用」に従い、AmazonSQSを利用する。 | |
50 | プロジェクト・パッケージ構成の検討 | クラウド環境やサービスへの依存が小さい疎結合なプロジェクト構成を検討する必要がある。 | Machinettaガイドライン「AWS向け開発プロジェクトの作成」に従い、プロジェクトを作成する。 |