Copyright © 2016 NTT DATA Corporation
株式会社NTTデータ 技術革新統括本部ソフトウェア工学推進センタ
Application Re-Architecture Technology
~ StrutsからSpring MVCへ ~
2Copyright © 2016 NTT DATA Corporation
自己紹介
池谷 智行
NTTデータ社内標準アプリケーションフレームワークであるTERASOLUNA Frameworkの整備、展開を担当している。Spring信者で、Spring MVCやSpring Batchを用いた実務開発経験あり。「Spring徹底入門」を執筆。
倉元 貴一
長年、某金融機関のミッションクリティカルシステム向けJavaフレームワーク開発を担当していた。現在はTERASOLUNAチームでバッチフレームワークに携わりつつ、社内の様々なプロジェクトのサポートをしている。「Spring徹底入門」を執筆。
3Copyright © 2016 NTT DATA Corporation
TERASOLUNAとは
Process
Environment
Support
数多くのシステム開発で培ったノウハウを盛り込んだ標準開発手順・管理手順
ソフトウェアを開発する際の雛形になるフレームワークと開発を支援するツール
蓄積されたノウハウを展開するための研修や教育サービス
標準手順
サポート
開発環境
数多くのシステム開発実績をもとにした「標準手順」「開発環境」「サポート」をトータルで提供しており、TERASOLUNAを活用することで、高品質なシステム開発が実現できます。
TERASOLUNAとは、NTTデータのシステム開発を支えるオープン系システム開発のための総合ソリューション
4Copyright © 2016 NTT DATA Corporation
TERASOLUNAフレームワークのコンセプト
業務アプリケーション
エンタープライズ利用における当社知見をベースに、Springを最大限活用したフレームワークへ
iBATIS
独自フレームワーク層
業務アプリケーション
Spring IO Platform
Spring Security
SpringMVC JPA
MyBatis
1. 各種OSSをベースとしつつも、独自フレームワークの開発に注力
2. 機能説明書を提供
1. OSSを組み合わせ、独自部分を極小化2. OSSの機能を最大限に活かして開発するため
のベストプラクティスを提供することに注力
開発ガイドライン開発ガイドライン
5Copyright © 2016 NTT DATA Corporation
TERASOLUNA Frameworkの構成要素
•Spring, MyBatisなどのOSSフレームワークソフトウェアフレームワーク
•エンタープライズ向けに必要な汎用的な部品共通ライブラリ
•OSSを利用したエンタープライズ向けアプリ開発に
おけるベストプラクティスドキュメントガイドライン
•基本的な開発方法を学ぶ学習教材チュートリアル
•基本的な機能を実装したサンプルアプリサンプルAP
•プロジェクト構成のひな形ブランクプロジェクト
6Copyright © 2016 NTT DATA Corporation
公開資材の一例
http://terasolunaorg.github.io/開発ガイドライン
ポータルサイト
資材提供
7Copyright © 2016 NTT DATA Corporation
ニュースリリース
2016/02/24 本格運用開始のニュースリリースhttp://www.nttdata.com/jp/ja/news/release/2016/022400.html
エンドースメント頂いた会社様(敬称略)• Pivotal• 株式会社NTTデータ イントラマート• 日本アイ・ビー・エム株式会社• 日本オラクル株式会社• 日本電気株式会社• 株式会社日立製作所• 富士通株式会社• Red Hat Inc.
Copyright © 2015 NTT DATA Corporation 8
TERASOLUNA Frameworkの狙い
コモディティ化しつつある領域では仲間を増やし、業界貢献することが重要
お客様 競合他社 開発者 OSSコミュニティ
9Copyright © 2016 NTT DATA Corporation
(参考)ガイドラインへのアクセス数
公開から33万ユーザ以上にアクセスされ毎日4000ページビュー以上閲覧されている
10Copyright © 2016 NTT DATA Corporation
Springイベントのスポンサーおよび講演
Springの当社プレゼンスを向上するため積極的に講演活動およびイベントスポンサーに取り組む
2015年に引き続き、世界最大のSpringプロジェクトイベント「SpringOne Platform 2016」のシルバースポンサーとして協賛
イベント参加レポートはこちらから
Spring 5.0は来春リリース!クラウドネイティブ開発、マイクロサービス化など最新技術・事例にあふれた4日間
http://codezine.jp/article/detail/9631
11Copyright © 2016 NTT DATA Corporation
Springに関する書籍出版
好評につき増刷決定!!
Spring徹底入門執筆Spring初心者からSpring有識者まで
書籍の詳細はこちらからhttp://www.shoeisha.co.jp/book/detail/9784798142470
Copyright © 2015 NTT DATA Corporation 12
INDEX
1. なぜ今移行なのか
2. 実プロジェクトでの取り組み
3. おわりに
Copyright © 2016 NTT DATA Corporation 13
なぜ今移行なのか
14Copyright © 2016 NTT DATA Corporation
Struts 1 の EOLがもたらしたこと
• 従来、JavaなエンタープライズシステムはStrutsで組まれていた
• Struts 1.x EOL(2013/4) → 脆弱性発覚(2014/4)
http://www.nttdata.com/jp/ja/news/information/2014/2014042801.html
15Copyright © 2016 NTT DATA Corporation
Struts 1 を使い続けるということ
• Struts 1 を使い続けると…
• セキュリティへの対応が困難になる
• 機会損失を産んでしまう
16Copyright © 2016 NTT DATA Corporation
どうしよう?
17Copyright © 2016 NTT DATA Corporation
http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016/
Springのシェアは高い!
18Copyright © 2016 NTT DATA Corporation
Struts 1 から Spring へ
業務アプリケーション
当社もSpringを最大限活用したフレームワークへ舵を切った
iBATIS
独自フレームワーク層
業務アプリケーション
Spring IO Platform
Spring Security
SpringMVC JPA
MyBatis
開発ガイドライン開発ガイドライン
19Copyright © 2016 NTT DATA Corporation
問題は解決したか?
あらゆるプロジェクトがすぐに追従できない
Copyright © 2015 NTT DATA Corporation 20
業務アプリケーション
フレームワーク
ミドルウェア
OS/HW
ミドルウェア
OS/HW
システム更改パターン
開発 運用
開発 運用
開発 運用
2次(基盤更改)
初期
3次(刷新)
5~7 9~12 14~17経過年数
初期開発時に採用したフレームワークは長期間利用される傾向がある
初回更改時は、システム基盤更改(OS/HW/MWのEOL対応)
と簡単な機能追加に留まるケースが多い2回目の更改時は、システム全体の刷新を
前提にした開発予算が計上されやすい
21Copyright © 2016 NTT DATA Corporation
WebAPサーバ
Spring
JavaEEサーバ
EJB
WebAPサーバ
WebAPサーバ
FW移行の難しさ
• 更改周期と合わないが、外的要因で移行しなくてはならない• 手軽に移行するソリューションが欲しくなる
• PRJ特化な手順 -> 汎用手順 -> 汎用ツール とできると理想
• ツール化は可能なのか?• APのアーキテクチャはプロジェクトによりけり。特に、Strutsはフルスタックなフレーム
ワークではないため、ビジネスロジック以降の構成は様々。全てに対応することは困難。
Struts 1
ActionPOJO Logic
JDBCres
req
Struts 1
Action
POJO Logic
JDBCres
req
WebAPサーバ
Struts 1
Action
Session Bean
Entity Beanres
req
Struts 1
Action
POJO Logic
O/R Mapperres
req
①Actionにビジネスロジックをベタ書き
②独自のレイヤリング
③EJB呼び出し
④SSH(Spring + Struts + Hibernate)構成
Copyright © 2015 NTT DATA Corporation 22
移行時に必要となる要素
計画 設計 製造 試験
移行プロセス
移行時の見積もり手法
移行の実施要領
移行ツール
見積もりツール
移行ツールマニュアル等
移行では、効率化のための各種ツール、ツールをベースとしたプロセスや実施要領、
移行案件の見積もり方法など、多岐にわたる
• 必要な物や内容は、プロジェクトごとに事情が異なる。• そっと移行して延命すればいい。機能追加はほとんどない。
• ツール等で極力お金をかけずに処置したいという判断もあり得る。• 移行した後もアクティブに改修/機能追加する。
• それならばいっそ作りなおしたほうが良いという判断もあり得る。
Copyright © 2015 NTT DATA Corporation 23
移行の影響範囲
計画 設計 製造 試験
BP RD ED ID M/UT IT ST
システム基盤設計 システム基盤構築
業務
機能
処理
FW
コンポーネント
FWFW
コンポーネント
処理
機能
業務フロー
移行コストを最小限とするため、プロジェクトに合わせて影響範囲を局所化する方策が必要
FW移行の影響範囲
システム基盤更改の影響範囲
24Copyright © 2016 NTT DATA Corporation
移行作業の流れの一例
No 作業分類 作業対象
1 設定ファイルの移行 web.xmlデータソースロギングプロパティファイル
2 インフラストラクチャ層への移行 DAO関連のI/F, 各種設定ファイル
3 ドメイン層への移行 ビジネスロジック
4 アプリケーション層への移行 アクションフォームStruts設定ファイルアクション
5 設定ファイルの移行 Bean定義ファイル
6 アプリケーション層への移行 JSP入力チェック
7 共通処理の移行 例外処理メッセージ
8 セキュリティ対策 認証/認可XSS対策・CSRF対策等
Struts 1 + Spring から Spring MVCに移行する際の作業の流れ
25Copyright © 2016 NTT DATA Corporation
移行前後のAP資材比較(資材の関連)
Application Layer
Domain Layer
Infrastructure Layer
struts-config.xml
validation.xml
ActionForm
sqlMap.xml
for MyBatis2
sqlMap.xml
for MyBatis3MyBatis2
Business Logic
Struts
MyBatis3
Business Logic
Form Bean(Bean Validation)
ControllerSpring MVC
JSPwith struts.tld
JSPwith JSTL, spling.tld
Struts 1.x(+Spring / MyBatis2) Spring MVC
Action
applicationContext.xml
26Copyright © 2016 NTT DATA Corporation
移行前後のAP資材比較(資材の対応)
Application Layer
Struts 1.x
Domain Layer
Infrastructure Layer
Spring MVC
validation.xml
ActionFormForm Bean
(Bean Validation)
Controller
サービスIF
業務サービス
業務サービス
sqlMap.xmlfor MyBatis2
sqlMap.xmlfor MyBatis3
リポジトリIF
struts-config.xml
JSPwith struts.tld
JSPwith JSTL, spling.tld
概要
validation.xmlで定義する入力チェックを、BeanValidationに移行。
・struts-config.xml等の設定を@RequestMapping に移行。
・Actionの個々の処理をSpringMVCに合わせて移行。
・Controllerに対するI/Fに変更。・DAOのI/FをリポジトリIFに変更。・その他実装は基本そのまま。
sqlMap.xmlのSQL定義をIFメソッドとして移行する。
MyBatis2 からMyBatis3へ記法を移行する。
strutsのタグライブラリを、JSTLやSpringタグライブラリに移行。
Action
サービスIF
applicationContext.xml
27Copyright © 2016 NTT DATA Corporation
Application Layer
Struts 1.x
Domain Layer
Infrastructure Layer
validation.xml
ActionForm
業務サービス
sqlMap.xmlfor MyBatis2
struts-config.xml
JSPwith struts.tld
Action
サービスIF
applicationContext.xml
移行のしやすさ
Spring MVC
Form Bean(Bean Validation)
Controller
サービスIF
業務サービス
sqlMap.xmlfor MyBatis3
リポジトリIF
JSPwith JSTL, spling.tld
概要
○:struts標準は汎用的に対処しやすい。プロジェクト独自作成部分は個別対処。
×:プロジェクト独自の要素が強いことが多く、対処しにくい。設定ファイルの内容を機械的に移植することは可能だが、Action内の独自処理をそのまま移せるかどうかは要検討。
△:元々レイヤリングされている状態ならば対処しやすい。大半のロジックをそのまま流用するような工夫は必要。
○:struts標準タグは汎用的に対処しやすい。プロジェクト独自作成部分は個別対処。
△:移行前後のライブラリによって難易度が変わる。
Copyright © 2016 NTT DATA Corporation 28
実プロジェクトでの取り組み
29Copyright © 2016 NTT DATA Corporation
移行を実施するにあたって
• 基本的な考え方
• strutsにあって、spring mvcにない
• 場合によっては仕様変更を検討しつつ対処する。
• 対処漏れが起きにくい。
• strutsにあって、spring mvcにある
• 完全一致ではなく、微妙に違う仕様/挙動になることが多い。
• Struts と Spring MVC はアーキテクチャは似てるけど異なるもの。
• 両方共ActionベースのWebAPフレームワークではある。
• 差を意識しながら扱う必要がある。
以降、実際に起きた問題の一例を紹介します。
• アーキテクチャの差によるもの
• 機能差によるもの
30Copyright © 2016 NTT DATA Corporation
セッション/リクエスト格納データの取得方法の違い
発生した問題
• 画面表示したかったセッションスコープのデータがリクエストスコープの別のデータに置き換わって表示されてしまった。
• requestスコープの値だけを更新したつもりが、同時にsessionスコープの変数も更新されてしまい不整合なデータが表示されてしまった。
発生条件
• Struts1では、requestスコープとsessionスコープで同じキー名で異なるデータを使用している。
• Spring MVCへActionFormを移行する際に、@ModelAttributes、@SessionAttributesを使用している。
result: fuga
requestスコープ
業務AP
sessionスコープ
result=hoge
result=fuga
画面(JSP->HTML)
画面へ出力期待していなかった、値が表示されてしまった
イメージ
31Copyright © 2016 NTT DATA Corporation
セッション/リクエスト格納データの取得方法の違い
Struts1
• リクエスト
• ActionForm(scope=request)
• セッション
• ActionForm(scope=session)
Spring MVC
• リクエスト
• @ModelAttributes、@QueryParam、@RequestAttribute(Spring 4.3~)、etc...
• セッション
• @SessionAttributes、Session Scoped Bean、@SessionAttribute(Spring 4.3~)
@ModelAttributesや@SessionAttributesを
使用した場合の話
32Copyright © 2016 NTT DATA Corporation
Model
セッション/リクエスト格納データの取得方法の違い
Struts1
Spring MVC
HttpServletRequest
HttpSession
ActionForm1(request版)
HttpServletRequest
HttpSession
Spring MVC
ActionForm1(session版)
リクエスト・セッション格納データの入力フロー
Application2(Action)
Application1(Action)
Application2(Controller)
Application1(Controller)Form
Object1
ActionFormとScopeが明確に分かれており、同名ActionFormでも別物として管理される
FormObjectのScopeの違いはアプリケーションからは透過的な思想なため同名キーのリクエストとセッションのデータが同一FormObjectにマッピングされてしまう
Struts1
Application2で取得したいデータ
33Copyright © 2016 NTT DATA Corporation
セッション/リクエスト格納データの取得方法の違い
Struts1
Spring MVC
リクエスト・セッションへのデータ出力フロー
JSP(request出力)
Struts1Taglibs
JSP(session出力)
Struts1Taglibs
HttpServletRequest
HttpSessionActionForm1(session版)
Application2(Action)
Struts1
ModelHttpServletRequest
HttpSession
Spring MVC
Application2(Controller)
Form Object1
専用のTaglibsを使用することで、同名のActionFormに対しても
scopeを指定してActionFormを選択可能
JSP(request出力)
JSP(session出力)
格納先に問わず、画面表示するデータはリクエストスコープを経由して画面描画に
使用する思想のため、リクエストスコープで画面表示データが競合。
元々存在した、偶然に同名キーのリクエストデータ
セッションへ格納しつつ画面出力したいデータ
34Copyright © 2016 NTT DATA Corporation
Model
セッション/リクエスト格納データの取得方法の違い
Spring MVC
HttpServletRequest
HttpSession
Spring MVC
本問題への解決方法
Application2(Controller)
Application1(Controller)Form
Object1
Application2で取得したいデータ Form Object2
ModelHttpServletRequest
HttpSession
Spring MVC
Application2(Controller)
Form Object2
JSP(request出力)
JSP(session出力)
元々存在した、偶然に同名キーのリクエストデータ
セッションへ格納しつつ画面出力したいデータ
各業務処理で使用するFormObjectを洗い出し、FormObjectの名前(キー名)を、
業務処理毎にユニークな名前に定義しなおす。@ModelAttributes(“formObject2”)
@SessionAttributes(“formObject2”)
各業務処理で使用するFormObjectを洗い出し、FormObjectの名前(キー名)を、ユニークな名前に定義しなおす。
@ModelAttributes -> @ModelAttributes(“formObject2”)@SessionAttributes -> @SessionAttributes(“formObject2”)
35Copyright © 2016 NTT DATA Corporation
リクエストスコープへのデータ反映タイミングの違い
発生した問題:
• 1リクエストで複数のビジネスロジックを呼び出した際、前段のビジネスロジックの処理結果が引き継げない。
発生条件
• Struts1で、複数Actionをチェインし複数ビジネスロジックを実行していた
• Struts1では同じActionFormを複数Action間で共有することができる
イメージ
result1:result2: result3: piyo
Request scope
result2=fuga
result1=hoge
画面(JSP->HTML)
最後にチェインしたビジネスロジックからの出力結果しか画面に表示されない
Action1
result3=piyo
Action2 Action3request
response
36Copyright © 2016 NTT DATA Corporation
リクエストスコープへのデータ反映タイミングの違い
Struts1
• 1リクエストで複数のビジネスロジックを実行させる方法
• Actionを<forward>でチェイン
• リクエストスコープのActionFormに画面表示データを格納
Spring MVC
• 1リクエストで複数のビジネスロジックを実行させる方法
• Controllerをforwardでチェイン
• Modelに画面表示データを格納
今回行っていた方法
<action path="/result1type=“com.example.HogeAction"name=“hogeActionForm"scope="request"><forward name="success" path="/result2"/>
</action>
<action path="/result2 ...
@RequestMapping(“/result1”)public String result1() {
// ...return “forward:/result2”;
}
@RequestMapping(“/result2”)public String result2()...
37Copyright © 2016 NTT DATA Corporation
リクエストスコープへのデータ反映タイミングの違い
Struts1
Spring MVC
リクエストへのデータ出力フロー画面出力したいデータは、Action内で
ActionFormに累積して格納
Action1Struts Action2 Action3
ActionFormreq.setAttribute()
Controller1Spring Controller2 Controller3
リクエストスコープModel
forward
forward
forward
forward
Model
model.addAttribute()
model.addAttribute()
Modelmodel.addAttribute()
forward
req.setAttribute()
JSP
JSP
view resolvereq.setAttribute()
Modelからリクエストスコープへのデータ反映のタイミングはViewの解決時のみ
+ModelがForward毎に初期化されるため、Forwardチェイン時にデータが消失する
(BindingResultも同様)
原因
38Copyright © 2016 NTT DATA Corporation
Model
リクエストスコープへのデータ反映タイミングの違い
Spring MVC
本問題への解決方法
ControllerSpring Module2 Module3
リクエストスコープ
model.addAttribute()
model.addAttribute()
model.addAttribute()
JSP
view resolvereq.setAttribute()
Forwardでチェインさせる方式をやめ、1Controller内でModelやBindingResultを
持回るようにメソッドコールする
Method call
Method call
Module1
Method call
Spring MVCではforwardによるチェインは一般的ではないことを考慮し、複数ビジネスロジックの呼び出し方法を変える必要があった。
39Copyright © 2016 NTT DATA Corporation
その他、個別機能で発生した問題の一例
• Spring MVCではStruts1のTransactionTokenに代わる機能がないため、一部の画面遷移の挙動が変わってしまった。
TERA5で同等の機能を用意したため、現行と同様の遷移を維持した。
http://terasolunaorg.github.io/guideline/5.2.0.RELEASE/ja/ArchitectureInDetail/WebApplicationDetail/DoubleSubmitProtection.html
40Copyright © 2016 NTT DATA Corporation
• 入力チェックがstruts-validator(commons-validator)からSpring Validator(Bean Validator)に変更する際に、対応しにくいチェックルールが見つかった。
• 正規表現
• Struts 1 : mask / Bean Validation : @Pattern• 空文字(“”)はチェックの対象外→対象となってしまう。
• 同じ挙動にするため、正規表現の先頭に |を記載した。 例:@Pattern(regexp = "|^[a-z]+$")
• 日本語用の独自チェックルール
• 各プロジェクトでcommons-validatorの拡張ルールを実装している事が多い
• TERA5が用意した文字列チェックアノテーション(@ConsistOf)を活用し、特定のコードポイント集合に含まれることをチェックするようにした(※1)
• ただし、プロジェクトによってはユーザーから受け付ける値の仕様が変わるため、既存のチェックルールをそのまま流用して、BeanValidation経由でコールするようにしたケースもあった。
※1: 詳細は、以下を参照7.6.2.5.5. Bean Validationと連携した文字列チェックhttp://terasolunaorg.github.io/guideline/5.2.0.RELEASE/ja/ArchitectureInDetail/GeneralFuncDetail/StringProcessing.html#stringprocessinghowtousecodepointsvalidator
Copyright © 2016 NTT DATA Corporation 41
おわりに
42Copyright © 2016 NTT DATA Corporation
まとめ
• 移行プロジェクトでは独特なスキルが必要になる。
• プロジェクト特性に合わせた開発プロセスを考え、影響範囲を局所化できるかどうかがポイントになる。
• ソースの対応を取りながら移していく。移行前後の差を都度検証しながら進めていくことが大事。現行をそのまま再現しようとすると、アーキテクチャや機能の差が出てきて当たり前。
• 小規模な移行案件からナレッジをためていく地道な作業が一番効果的。
43Copyright © 2016 NTT DATA Corporation
最後に
今回の話やTERASOLUNAに興味がある方は下記までご連絡ください
TERASOLUNA窓口E-mail: [email protected]電話: 050-5546-2482(平日10時〜18時)
今後もSpringを中心に各種OSSのベストプラクティスを提供し続けます
Springをエンタープライズシステム開発で積極的に活用し、情報交換やコミュニティ活動を活発化してさらなるSpringの発展、繁栄に向けて共に歩んでいきましょう。
Copyright © 2011 NTT DATA Corporation
Copyright © 2016 NTT DATA Corporation
「TERASOLUNA」及びそのロゴは、日本及びその他の国おける株式会社NTTデータの商標または登録商標です。その他、記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です。