読書会(Java EE 7徹底入門)第6回議事録
[ 戻る ]
読書会(Java EE 7徹底入門)第6回議事録
=================================================
Java読書会BOF 「Java EE 7徹底入門」を読む会 第6回
=================================================
.. csv-table:: 開催概要
"日時", "2016年6月18日 10:00 - 17:00"
"場所", "川崎市教育文化会館 第３会議室"
"出席者(敬称略)", "伊藤、井上(2名)、今井、岩室、遠藤、小川、加藤、高橋(徹)、高橋(智)、平山、村山、吉本、川内(書記)"
議事
====
8.3.3 制約
---------
"精度とスケール、長さ"セクション
----------------------------
* precision(精度=全体の桁数)とscale(整数部分の桁数)は分かりにくい。
整数部分の桁数と小数部分の桁数で指定できればよいのに。
- 科学的表記(指数表記, 1.23e4等)に合わせているのだろう。
* JPAのエンティティを基にデータベースのスキーマを生成する場合は、
precisionとscaleの定義が必要なのは分かるが、
既存のスキーマが先にあって、それに合わせてJPAのエンティティを定義する場合、
precisionとscaleの定義が必要？
- 既存のスキーマと不整合時の挙動が予測できないため、スキーマに合わせて定義する必要あり。
"一意性制約"セクション
-------------------
* 既存のスキーマに一意性制約が定義されている場合は、それに合わせてJPAエンティティ側も定義が必要
"データベースの方言"コラム
-----------------------
図8.9のデータベースの図が2つとも、MySQLとなっているが、下側はOracleの誤り
"データベースとソースコードの修正に対する考察"コラム
---------------------------------------------
* 採り上げられた、名前の変更とデータ型の変更の例では、JDBC直接利用と比べJPAに軍配があがるが、
項目の追加/削除/他のテーブルへの移動の場合はどうか？
- データベースのスキーマからエンティティのソースコードを生成して、
コンパイルエラーが発生する箇所を潰していけばよい。
ただし、再生成するとJPQL等、追加した手書き部分のコードが消えるため、簡単に復元できる手立ては必要
8.4 トランザクション
------------------
* EJBコンテナ内でトランザクションの開始／コミットを手動でしてもよいのか？
- EJBを使用していても、IDの採番等、伝播されるトランザクションとは別のトランザクションを開始/コミット
する場合があるので、問題なし。
8.5 キャッシュ
------------
8.5.1 これまでのデータアクセス
--------------------------
* 図8.13は本文から参照されていない
8.5.2 キャッシュを使用したデータアクセス
-----------------------------------
8.5.3 JPAのキャッシュ
-------------------
* 本には記載されていないが、キャッシュ機能を利用するには、データベースを更新する
アプリケーションは1つにする必要あり。
- 複数のアプリケーションが同一のデータベースを更新する必要がある場合は、
データベース更新部分をマイクロサービス化して、各アプリケーションは、
そのマイクロサービス経由でデータベースを更新するアーキテクチャとする必要あり。
8.5.4 キャッシュとヒープ
---------------------
* テーブルの全データをキャッシュしても、JPQLの実行は早くなる？
データベース製品はクエリの実行速度を上げるためにあらゆることをしているが、
JPA実装も、キャッシュにあるデータに対するクエリの実行速度を上げるための工夫をしている？
- どちらが早いかはユースケース(=クエリの内容)次第だが、ネットワーク遅延の影響はやはり大きいと考えられる。
8.5.5 プリロード
--------------
8.5.6 EclipseLink
-----------------
8.6 永続化ユニット
----------------
8.7 環境構築手順
--------------
* JPAは設定が大変
- 気軽にデータベースプログラミングを行うというのは難しそう
- JPAだけでなく、JNDI等、バックエンドの知識も必要となってくる
8.8 アプリケーションの開発手順
--------------------------
8.8.1 エンティティの作成
---------------------
* 図8.40でファイル・タイプ(F):のリストボックスに表示されている、
”データベースからのエンティティ・クラス”を選択すると、NetBeansで、
既存のデータベーススキーマからエンティティクラスを自動生成できる。
- 図には表示されていないが、生成したエンティティクラスをもとに、
Session Beanや、JAX-RSのリソースクラスも生成可能。
8.8.2 JPQLの開発
---------------
8.9 まとめ
---------
9 RESTful Webサービスの開発
-------------------------
9.1 Webサービスの基礎
-------------------
9.1.1 Webサービスとは
-------------------
"Webサービスの例"コラム
---------------------------------------------
* 標題はWebサービスの例となっているが、記載のURLは各社が実施するWebサービスの案内のURLとなっている。
* TwitterのWebサービスの利用経験があるが、OAuthによる認証が必要で、認証周りはとにかく面倒
9.1.2 RESTful Webサービスとは
---------------------------
* 企業内の環境では、PUT/DELETEメソッドのHTTPリクエストを制限しているケースがあり、
RESTful Webサービス構築/利用時には、注意が必要
* SOAPの方が信頼性が高く、企業間のWebサービス向けとあるが、バージョンの混在等により、繋がらない経験があり
- WSDLもバージョンアップで巨大になり、ソース生成ツールにかけても、ツールが異常終了し、生成できないケースあり
9.1.3 RESTとHTTP
----------------
* 図9.3に"レスポンスライン"とあるが、正式な用語は"ステータスライン"
* Locationヘッダはどのような時に使う?
- POSTメソッドでリソースを生成した場合に、生成したリソースにアクセスするためのURIをLocationヘッダで示す
- リダイレクトの際、リダイレクト先のURIを示す
* マトリクスパラメータはどのような時に使う?
- 地図上の緯度と経度を表す際の使用例を見たことがある
* よく利用するステータスコードで採り上げられていないものに、以下がある
- 304 Not Modified
9.2 JAX-RSの基本
---------------
9.2.1 JAX-RSとは
---------------
9.2.2 サンプルアプリケーションにおけるJAX-RSの機能
--------------------------------------------
* "RESTful Webサービス"と"RESTサービス”と2種類の表記があるが、使い分けているのか?
- RESTful Webサービス一般のこと表す場合は"RESTful Webサービス"、
特定のサービスを表す場合は"RESTサービス”と使い分けているように思われる
9.3 RESTful Webサービス作成のための事前準備
---------------------------------------
9.3.1 RESTful Webサービスの認証方式
--------------------------------
9.3.2 データクラス(DTO)
---------------------
9.3.3 Applicationクラス
----------------------
* web.xmlの設定に関する記載がないが、web.xmlの設定は不要ということか?
- Applicationのサブクラスを定義した場合は、web.xmlの設定は不要
- Applicationの寒クラスを定義せず、web.xmlの設定だけで済ませる方法もあり
9.4 RESTサービスクラス(サーバー側)の作成
------------------------------------
9.4.1 リソースクラスの構成要素
--------------------------
9.4.2 ①エンドポイントURIの設定
----------------------------
9.4.3 ②HTTPメソッドとリソースメソッドのバインド
------------------------------------------
9.4.4 ③メッセージボディのデータ形式指定
-----------------------------------
9.4.5 ④リクエスト情報のインジェクション
-----------------------------------
* @MatrixParamの利用例から見ると、複数の階層で同一の名前のマトリクスパラメータは利用できないということか?
* @FormParamは便利そうだが、フォームのメソッドをPOSTからGETに変更すると、
@FormParamはそのままでよいのか? それとも、@QueryParamに変更する必要があるのか
* Cookieや@Contextでインジェクションするパラメータは、メソッドのパラメータでは受け渡したくないが、
フィールド/setterインジェクションも可能?
- 可能(9.4.5の冒頭に説明あり)
* ここで、「JavaのAPIもServletの頃と比較すると格段に進歩した」との感慨あり。
- ServletはServletのサブクラス化が必要で、リクエストの受け渡しはHttpRequestクラス
- JAX-RSでは、必要な部分のみ、インジェクションで受け取り可能で、メソッドシグニチャも自由
9.4.6 ⑤リクエストのメッセージボディの受け取り
----------------------------------------
9.4.7 ⑥入力チェック
------------------
9.4.8 ⑦レスポンスの定義
---------------------
9.5 HTTPメソッドに応じた処理
-------------------------
9.5.1 ナレッジの検索(GETメソッドによる操作)
--------------------------------------
* JSON返却時のHTTPレスポンスのサンプルでは、Content-Typeヘッダに文字コードの指定がないが、
どうやって文字コードを判定するの?
- JSONはユニコードでエンコーディングする決まりとなっている
9.5.2 ナレッジの登録(POSTメソッドによる操作)
---------------------------------------
.. note:: 次回は、P.437「9.5.3 ナレッジの更新(PUTメソッドによる操作)」から。
[ 戻る ]