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

SpringMVC JPA

MyBatis

1. 各種OSSをベースとしつつも、独自フレームワークの開発に注力

2. 機能説明書を提供

1. OSSを組み合わせ、独自部分を極小化2. OSSの機能を最大限に活かして開発するため

のベストプラクティスを提供することに注力

開発ガイドライン開発ガイドライン


TERASOLUNA Frameworkの構成要素

•Spring, MyBatisなどのOSSフレームワークソフトウェアフレームワーク

•エンタープライズ向けに必要な汎用的な部品共通ライブラリ

•OSSを利用したエンタープライズ向けアプリ開発に

おけるベストプラクティスドキュメントガイドライン

•基本的な開発方法を学ぶ学習教材チュートリアル

•基本的な機能を実装したサンプルアプリサンプルAP

•プロジェクト構成のひな形ブランクプロジェクト


公開資材の一例

http://terasolunaorg.github.io/開発ガイドライン

ポータルサイト

資材提供

http://terasolunaorg.github.io/


ニュースリリース

2016/02/24 本格運用開始のニュースリリースhttp://www.nttdata.com/jp/ja/news/release/2016/022400.html

エンドースメント頂いた会社様(敬称略)• Pivotal• 株式会社NTTデータイントラマート• 日本アイ・ビー・エム株式会社• 日本オラクル株式会社• 日本電気株式会社• 株式会社日立製作所• 富士通株式会社• Red Hat Inc.

http://www.nttdata.com/jp/ja/news/release/2016/022400.html

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

http://codezine.jp/article/detail/9631


Springに関する書籍出版

好評につき増刷決定！！

Spring徹底入門執筆Spring初心者からSpring有識者まで

書籍の詳細はこちらからhttp://www.shoeisha.co.jp/book/detail/9784798142470

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

SpringMVC 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

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)構成


移行時に必要となる要素

計画設計製造試験

移行プロセス

移行時の見積もり手法

移行の実施要領

移行ツール

見積もりツール

移行ツールマニュアル等

移行では、効率化のための各種ツール、ツールをベースとしたプロセスや実施要領、

移行案件の見積もり方法など、多岐にわたる

• 必要な物や内容は、プロジェクトごとに事情が異なる。• そっと移行して延命すればいい。機能追加はほとんどない。

• ツール等で極力お金をかけずに処置したいという判断もあり得る。• 移行した後もアクティブに改修/機能追加する。

• それならばいっそ作りなおしたほうが良いという判断もあり得る。


移行の影響範囲

計画設計製造試験

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 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


移行前後のAP資材比較(資材の対応)

Application Layer

Struts 1.x

Domain Layer


Spring MVC

validation.xml

ActionFormForm Bean

(Bean Validation)

Controller

サービスIF

業務サービス

業務サービス

sqlMap.xmlfor MyBatis2


リポジトリIF

struts-config.xml

JSPwith struts.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



Application Layer

Struts 1.x

Domain Layer


validation.xml

ActionForm

業務サービス


struts-config.xml

JSPwith struts.tld

Action

サービスIF


移行のしやすさ

Spring MVC

Form Bean(Bean Validation)

Controller

サービスIF

業務サービス


リポジトリIF


概要

○：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

HttpServletRequest

HttpSession

ActionForm1(request版)

HttpServletRequest

HttpSession

Spring MVC

ActionForm1(session版)

リクエスト・セッション格納データの入力フロー

Application2(Action)


Application2(Controller)

Application1(Controller)Form

Object1

ActionFormとScopeが明確に分かれており、同名ActionFormでも別物として管理される

FormObjectのScopeの違いはアプリケーションからは透過的な思想なため同名キーのリクエストとセッションのデータが同一FormObjectにマッピングされてしまう

Struts1

Application2で取得したいデータ



Struts1

Spring MVC

リクエスト・セッションへのデータ出力フロー

JSP(request出力)

Struts1Taglibs

JSP(session出力)

Struts1Taglibs

HttpServletRequest

HttpSessionActionForm1(session版)


Struts1

ModelHttpServletRequest

HttpSession

Spring MVC


Form Object1

専用のTaglibsを使用することで、同名のActionFormに対しても

scopeを指定してActionFormを選択可能

JSP(request出力)

JSP(session出力)

格納先に問わず、画面表示するデータはリクエストスコープを経由して画面描画に

使用する思想のため、リクエストスコープで画面表示データが競合。

元々存在した、偶然に同名キーのリクエストデータ

セッションへ格納しつつ画面出力したいデータ


Model


Spring MVC

HttpServletRequest

HttpSession

Spring MVC

本問題への解決方法


Application1(Controller)Form

Object1

Application2で取得したいデータ Form Object2

ModelHttpServletRequest

HttpSession

Spring MVC


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="/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()...



Struts1

Spring MVC

リクエストへのデータ出力フロー画面出力したいデータは、Action内で

ActionFormに累積して格納

Action1Struts Action2 Action3

ActionFormreq.setAttribute()

Controller1Spring Controller2 Controller3

リクエストスコープModel

forward

forward

forward

forward

Model

model.addAttribute()


Modelmodel.addAttribute()

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: [email protected]電話: 050-5546-2482（平日10時〜18時）

今後もSpringを中心に各種OSSのベストプラクティスを提供し続けます

Springをエンタープライズシステム開発で積極的に活用し、情報交換やコミュニティ活動を活発化してさらなるSpringの発展、繁栄に向けて共に歩んでいきましょう。

mailto:[email protected]



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

Engineering

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

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