Application Re-Architecture Technology ～ StrutsからSpring MVCへ～

Copyright © 2016 NTT DATA Corporation
株式会社ＮＴＴデータ技術革新統括本部
ソフトウェア工学推進センタ
Application Re-Architecture Technology
～ StrutsからSpring MVCへ～

2Copyright © 2016 NTT DATA Corporation
自己紹介
池谷智行
NTTデータ社内標準アプリケーションフレームワークであるTERASOLUNA
Frameworkの整備、展開を担当している。
Spring信者で、Spring MVCやSpring Batchを用いた実務開発経験あり。
「Spring徹底入門」を執筆。
倉元貴一
長年、某金融機関のミッションクリティカルシステム向けJavaフレームワーク
開発を担当していた。
現在はTERASOLUNAチームでバッチフレームワークに携わりつつ、社内の
様々なプロジェクトのサポートをしている。
「Spring徹底入門」を執筆。

TERASOLUNAとは
Process
Environment
Support
数多くのシステム開発で
培ったノウハウを盛り込んだ
標準開発手順・管理手順
ソフトウェアを開発する際の
雛形になるフレームワーク
と開発を支援するツール
蓄積されたノウハウ
を展開するための
研修や教育サービス
標準手順
サポート
開発環境
数多くのシステム開発実績をもとにした「標準手順」「開発環境」「サポート」を
トータルで提供しており、TERASOLUNAを活用することで、高品質な
システム開発が実現できます。
TERASOLUNAとは、NTTデータのシステム開発を支える
オープン系システム開発のための総合ソリューション

TERASOLUNAフレームワークのコンセプト
業務アプリケーション
エンタープライズ利用における当社知見をベースに、
Springを最大限活用したフレームワークへ
iBATIS
独自フレームワーク層
Spring IO Platform
Spring
Security
Spring
MVC JPA
MyBatis
1. 各種OSSをベースとしつつも、
独自フレームワークの開発に注力
2. 機能説明書を提供
1. OSSを組み合わせ、独自部分を極小化
2. OSSの機能を最大限に活かして開発するため
のベストプラクティスを提供することに注力
開発ガイドライン開発ガイドライン

TERASOLUNA Frameworkの構成要素
•Spring, MyBatisなどのOSSフレームワークソフトウェアフレームワーク
•エンタープライズ向けに必要な汎用的な部品共通ライブラリ
•OSSを利用したエンタープライズ向けアプリ開発に
おけるベストプラクティスドキュメントガイドライン
•基本的な開発方法を学ぶ学習教材チュートリアル
•基本的な機能を実装したサンプルアプリサンプルAP
•プロジェクト構成のひな形ブランクプロジェクト

公開資材の一例
http://terasolunaorg.github.io/
開発ガイドライン
ポータルサイト
資材提供

ニュースリリース
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コミュニティ

(参考)ガイドラインへのアクセス数
公開から33万ユーザ以上にアクセスされ
毎日4000ページビュー以上閲覧されている

Springイベントのスポンサーおよび講演
Springの当社プレゼンスを向上するため
積極的に講演活動およびイベントスポンサーに取り組む
2015年に引き続き、世界最大のSpringプロジェクトイベント
「SpringOne Platform 2016」のシルバースポンサーとして協賛
イベント参加レポートはこちらから
Spring 5.0は来春リリース！クラウドネイティブ開発、マイクロサービス化など最新技術・事例にあふれた4日間
http://codezine.jp/article/detail/9631

Springに関する書籍出版
好評につき
増刷決定！！
Spring徹底入門執筆
Spring初心者からSpring有識者まで
書籍の詳細はこちらから
http://www.shoeisha.co.jp/book/detail/9784798142470

ＩＮＤＥＸ
1. なぜ今移行なのか
2. 実プロジェクトでの取り組み
3. おわりに

なぜ今移行なのか

Struts 1 の EOLがもたらしたこと
• 従来、JavaなエンタープライズシステムはStrutsで組まれていた
• Struts 1.x EOL(2013/4) → 脆弱性発覚(2014/4)
http://www.nttdata.com/jp/ja/news/information/2014/2014042801.html

Struts 1 を使い続けるということ
• Struts 1 を使い続けると…
• セキュリティへの対応が困難になる
• 機会損失を産んでしまう

どうしよう？

http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016/
Springのシェアは高い！

Struts 1 から Spring へ
当社もSpringを最大限活用したフレームワークへ舵を切った
iBATIS
独自フレームワーク層
Spring IO Platform
Spring
Security
Spring
MVC JPA
MyBatis
開発ガイドライン開発ガイドライン

問題は解決したか？
あらゆるプロジェクトがすぐに追従できない

フレームワーク
ミドルウェア
OS／HW
ミドルウェア
OS／HW
システム更改パターン
開発運用
開発運用
開発運用
２次（基盤更改）
初期
３次（刷新）
5～7 9～12 14～17経過年数
初期開発時に採用したフレームワークは
長期間利用される傾向がある
初回更改時は、システム基盤更改
（OS/HW/MWのEOL対応)
と簡単な機能追加に留まるケースが多い
２回目の更改時は、システム全体の刷新を
前提にした開発予算が計上されやすい

WebAPサーバ
Spring
JavaEEサーバ
EJB
WebAPサーバ
WebAPサーバ
FW移行の難しさ
• 更改周期と合わないが、外的要因で移行しなくてはならない
• 手軽に移行するソリューションが欲しくなる
• PRJ特化な手順 -> 汎用手順 -> 汎用ツールとできると理想
• ツール化は可能なのか？
• APのアーキテクチャはプロジェクトによりけり。特に、Strutsはフルスタックなフレーム
ワークではないため、ビジネスロジック以降の構成は様々。
全てに対応することは困難。
Struts 1
Action
POJO 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)構成

移行時に必要となる要素
計画設計製造試験
移行
プロセス
移行時の
見積もり手法
移行の
実施要領
移行
ツール
見積もり
ツール
移行ツール
マニュアル等
移行では、効率化のための各種ツール、
ツールをベースとしたプロセスや実施要領、
移行案件の見積もり方法など、多岐にわたる
• 必要な物や内容は、プロジェクトごとに事情が異なる。
• そっと移行して延命すればいい。機能追加はほとんどない。
• ツール等で極力お金をかけずに処置したいという判断もあり得る。
• 移行した後もアクティブに改修/機能追加する。
• それならばいっそ作りなおしたほうが良いという判断もあり得る。

移行の影響範囲
計画設計製造試験
BP RD ED ID M/UT IT ST
システム基盤設計システム基盤構築
業務
機能
処理
FW
ｺﾝﾎﾟｰﾈﾝﾄ
FWFW
ｺﾝﾎﾟｰﾈﾝﾄ
処理
機能
業務ﾌﾛｰ
移行コストを最小限とするため、
プロジェクトに合わせて影響範囲を局所化する方策が必要
FW移行の
影響範囲
ｼｽﾃﾑ基盤更改の
影響範囲

移行作業の流れの一例
No 作業分類作業対象
1 設定ファイルの移行 web.xml
データソース
ロギング
プロパティファイル
2 インフラストラクチャ層への移行 DAO関連のI/F, 各種設定ファイル
3 ドメイン層への移行ビジネスロジック
4 アプリケーション層への移行アクションフォーム
Struts設定ファイル
アクション
5 設定ファイルの移行 Bean定義ファイル
6 アプリケーション層への移行 JSP
入力チェック
7 共通処理の移行例外処理
メッセージ
8 セキュリティ対策認証/認可
XSS対策・CSRF対策等
Struts 1 + Spring から Spring MVCに移行する際の作業の流れ

移行前後のAP資材比較(資材の関連)
Application
Layer
Domain Layer
Infrastructure
Layer
struts-config.xml
validation.xml
ActionForm
sqlMap
.xml
for MyBatis2
sqlMap
.xml
for MyBatis3
MyBatis2
Business Logic
Struts
MyBatis3
Business Logic
Form Bean
(Bean
Validation)
Controller
Spring
MVC
JSP
with struts.tld
JSP
with JSTL, spling.tld
Struts 1.x(＋Spring / MyBatis2) Spring MVC
Action
applicationContext.xml

移行前後のAP資材比較(資材の対応)
Application
Layer
Struts 1.x
Domain Layer
Infrastructure
Layer
Spring MVC
validation.xml
ActionForm
Form Bean
(Bean Validation)
Controller
サービスIF
業務
サービス
業務
サービス
sqlMap.xml
for MyBatis2
sqlMap.xml
for MyBatis3
リポジトリIF
struts-config.xml
JSP
with struts.tld
JSP
概要
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

Application
Layer
Struts 1.x
Domain Layer
Infrastructure
Layer
validation.xml
ActionForm
業務
サービス
sqlMap.xml
for MyBatis2
struts-config.xml
JSP
with struts.tld
Action
サービスIF
移行のしやすさ
Spring MVC
Form Bean
(Bean Validation)
Controller
サービスIF
業務
サービス
sqlMap.xml
for MyBatis3
リポジトリIF
JSP
概要
○：
struts標準は汎用的に対処しやすい。
プロジェクト独自作成部分は個別対処。
×：
プロジェクト独自の要素が強いことが多く、
対処しにくい。
設定ファイルの内容を機械的に移植することは可能
だが、Action内の独自処理をそのまま移せるかどう
かは要検討。
△：
元々レイヤリングされている状態ならば対処しやす
い。大半のロジックをそのまま流用するような工夫は
必要。
○：
struts標準タグは汎用的に対処しやすい。
プロジェクト独自作成部分は個別対処。
△：
移行前後のライブラリによって難易度が変わる。

実プロジェクトでの取り組み

移行を実施するにあたって
• 基本的な考え方
• strutsにあって、spring mvcにない
• 場合によっては仕様変更を検討しつつ対処する。
• 対処漏れが起きにくい。
• strutsにあって、spring mvcにある
• 完全一致ではなく、微妙に違う仕様/挙動になることが多い。
• Struts と Spring MVC はアーキテクチャは似てるけど異なるもの。
• 両方共ActionベースのWebAPフレームワークではある。
• 差を意識しながら扱う必要がある。
以降、実際に起きた問題の一例を紹介します。
• アーキテクチャの差によるもの
• 機能差によるもの

セッション/リクエスト格納データの取得方法の違い
発生した問題
• 画面表示したかったセッションスコープのデータがリクエストスコープの別のデータに置
き換わって表示されてしまった。
• requestスコープの値だけを更新したつもりが、同時にsessionスコープの変数も更新さ
れてしまい不整合なデータが表示されてしまった。
発生条件
• Struts1では、requestスコープとsessionスコープで同じキー名で異なるデータを
使用している。
• Spring MVCへActionFormを移行する際に、
@ModelAttributes、@SessionAttributesを使用している。
result: fuga
requestスコープ
業務AP
sessionスコープ
result=hoge
result=fuga
画面(JSP->HTML)
画面へ出力
期待していなかった、
値が表示されてしまった
イメージ

 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を
使用した場合の話

Model
 Struts1
 Spring MVC
HttpServlet
Request
HttpSession
ActionForm1
(request版)
HttpServlet
Request
HttpSession
Spring MVC
ActionForm1
(session版)
リクエスト・セッション格納データの入力フロー
Application2
(Action)
Application1
(Action)
Application2
(Controller)
Application1
(Controller)Form
Object1
ActionFormとScopeが
明確に分かれており、
同名ActionFormでも
別物として管理される
FormObjectのScopeの違いは
アプリケーションからは透過的な思想なため
同名キーのリクエストとセッションのデータが
同一FormObjectにマッピングされてしまう
Struts1
Application2で取得したいデータ

 Struts1
 Spring MVC
リクエスト・セッションへのデータ出力フロー
JSP
(request出力)
Struts1
Taglibs
JSP
(session出力)
Struts1
Taglibs
HttpServlet
Request
HttpSession
ActionForm1
(session版)
Application2
(Action)
Struts1
ModelHttpServlet
Request
HttpSession
Spring MVC
Application2
(Controller)
Form
Object1
専用のTaglibsを使用することで、
同名のActionFormに対しても
scopeを指定してActionFormを選択可能
JSP
(request出力)
JSP
(session出力)
格納先に問わず、画面表示するデータは
リクエストスコープを経由して画面描画に
使用する思想のため、
リクエストスコープで画面表示データが競合。
元々存在した、偶然に同名キーのリクエストデータ
セッションへ格納しつつ
画面出力したいデータ

Model
 Spring MVC
HttpServlet
Request
HttpSession
Spring MVC
本問題への解決方法
Application2
(Controller)
Application1
(Controller)Form
Object1
Application2で取得したいデータ Form
Object2
ModelHttpServlet
Request
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”)

リクエストスコープへのデータ反映タイミングの違い
発生した問題：
• １リクエストで複数のビジネスロジックを呼び出した際、前段のビジネスロジックの処理結果
が引き継げない。
発生条件
• Struts1で、複数Actionをチェインし複数ビジネスロジックを実行していた
• Struts1では同じActionFormを複数Action間で共有することができる
イメージ
result1:
result2:
result3: piyo
Request scope
result2=fuga
result1=hoge
画面(JSP->HTML)
最後にチェインしたビジネスロジックからの
出力結果しか画面に表示されない
Action1
result3=piyo
Action2 Action3request
response

 Struts1
• １リクエストで複数のビジネスロジックを実行させる方法
• Actionを<forward>でチェイン
• リクエストスコープのActionFormに
画面表示データを格納
 Spring MVC
• １リクエストで複数のビジネスロジックを実行させる方法
• Controllerをforwardでチェイン
• Modelに画面表示データを格納
今回行っていた方法
<action path="/result1
type=“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()...

 Struts1
 Spring MVC
リクエストへのデータ出力フロー
画面出力したいデータは、Action内で
ActionFormに累積して格納
Action1Struts Action2 Action3
ActionFormreq.setAttribute()
Controller1Spring Controller2 Controller3
リクエストスコープModel
forward
forward
forward
forward
Model
model.addAttribute()
Model
forward
req.setAttribute()
JSP
JSP
view resolvereq.setAttribute()
Modelからリクエストスコープへのデータ反映
のタイミングはViewの解決時のみ
＋ModelがForward毎に初期化されるため、
Forwardチェイン時にデータが消失する
（BindingResultも同様）
原因

Model
 Spring MVC
本問題への解決方法
ControllerSpring Module2 Module3
リクエスト
スコープ
JSP
view resolvereq.setAttribute()
Forwardでチェインさせる方式をやめ、
1Controller内でModelやBindingResultを
持回るようにメソッドコールする
Method call
Method call
Module1
Method call
Spring MVCではforwardによるチェインは一般的ではないことを考慮し、
複数ビジネスロジックの呼び出し方法を変える必要があった。

その他、個別機能で発生した問題の一例
• Spring MVCではStruts1のTransactionTokenに代わる機能がないため、
一部の画面遷移の挙動が変わってしまった。
 TERA5で同等の機能を用意したため、現行と同様の遷移を維持した。
http://terasolunaorg.github.io/guideline/5.2.0.RELEASE/ja/ArchitectureInDetail/WebApplicationDetail/DoubleSubmitProtection.html

• 入力チェックが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

おわりに

まとめ
• 移行プロジェクトでは独特なスキルが必要になる。
• プロジェクト特性に合わせた開発プロセスを考え、
影響範囲を局所化できるかどうかがポイントになる。
• ソースの対応を取りながら移していく。
移行前後の差を都度検証しながら進めていくことが大事。
現行をそのまま再現しようとすると、
アーキテクチャや機能の差が出てきて当たり前。
• 小規模な移行案件からナレッジをためていく地道な作業が一番効果的。

最後に
今回の話やTERASOLUNAに興味がある方は下記までご連絡ください
TERASOLUNA窓口
E-mail: terasoluna@am.nttdata.co.jp
電話: 050-5546-2482（平日10時〜18時）
今後もSpringを中心に各種OSSの
ベストプラクティスを提供し続けます
Springをエンタープライズシステム開発で積極的に活用し、
情報交換やコミュニティ活動を活発化して
さらなるSpringの発展、繁栄に向けて共に歩んでいきましょう。

「TERASOLUNA」及びそのロゴは、日本及びその他の国おける株式会社NTTデータの商標または登録商標です。
その他、記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です。

Application Re-Architecture Technology ～ StrutsからSpring MVCへ～

Application Re-Architecture Technology ～ StrutsからSpring MVCへ～

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Similar to Application Re-Architecture Technology ～ StrutsからSpring MVCへ～

Similar to Application Re-Architecture Technology ～ StrutsからSpring MVCへ～(20)

More from Yuichi Hasegawa

More from Yuichi Hasegawa(15)

Recently uploaded

Recently uploaded(6)