業務でアプリケーションサーバ(glassfish)で動いているSOAP(JAX-WS)のアプリケーションを新しいサーバへマイグレーションしなくてはいけなくなった。新しいサーバにマイグレーションすると共にアプリケーションサーバをglassfishからtomcatへ変更するために色々調べたのでそのためのリンク集をまとめた。
JAX-WSの実装系
-
metro
https://javaee.github.io/metro-jax-ws/
https://eclipse-ee4j.github.io/metro-jax-ws/ -
Apache Axis2
https://axis.apache.org/axis2/java/core/ -
apache cxf
https://cxf.apache.org/docs/jax-ws.html
metro
glassfishはJAX-WSのリファレンス実装(metro)を使っている。互換性重視のためmetroの古いバージョンで動かせるようにした。
-
sun-jaxws.xml作成
glassfishはjax-wsの参照実装のためsun-jaxws.xmlが不要でjax-wsが動作する。他のアプリケーションサーバーはsun-jaxws.xmlにクラスを登録する必要がある。 -
web.xmlの修正
sun-jaxws.xml同様に他のアプリケーションサーバーではContextListenerとServletを登録する必要がある。以下の公式ドキュメントに詳細は書いてあるので参照してほしい。
https://javaee.github.io/metro-jax-ws/doc/user-guide/ch03.html#the-sun-jaxws-xml-file
DataSource
DBのデータソースの名前の命名規則が異なり、環境によってデータソース名の変更が必要な場合がある。スプリングのフレームワークでは以下のような変更が必要だった
glassfishの場合 "jdbc/sampledb"
tomcatの場合 "java:comp/env/jdbc/sampledb"
今後
マイグレーション作業は、動けば終わりでなく、機能的にデグレがないか、ピークパフォーマンスに問題がないか、ロングランテストで問題がないかを確認する必要がある。
その後
- 開発環境、本番環境でそれぞれ約2週間以上のデグレ試験をして問題がないこと確認。
- ピークパフォーマンスに問題ない事を確認。
- ロングランテスト(1時間)で問題ない事を確認。
上記3つを確認して実際に本番にリリースしてみるとQPSが低い場合にレスポンスタイムのAVEと90%tile,95%tile問題がある事が確認されロールバックする事になった。コネクションプール数、最大接続数などが最適値になっていないため、レスポンスタイムの結果が以前より悪くなった。レスポンスタイムはAVE,MAXの他に90%tile,95%tileの測定するべきで、ユーザーにも予め共有しておく事が好ましい。またロールバック基準をあらかじめ定めてユーザー側に提示しておく必要も重要であると今回の経験より学んだ。