1. エンタープライズJava開発はこれからが面白い！ 10年の歳月を経て、JavaEEプラットフォームは 実践的な開発プラットフォームへと進化した 2011/8/10 浅井 良

2. 自己紹介 名前 浅井 良 現職 株式会社オージス総研 アドバンストモデリングソリューション部アーキテクトチーム所属 去年から達人プログラマーを目指してのブログを書いています。 http://d.hatena.ne.jp/ryoasai/ TwitterIDryoasai74 Googleアカウント ryoasai74

3. そうです、ワタシが JavaEE おじさんです。

4. 本日のアジェンダ JavaEEの進化の歴史の振り返り（15分） JavaEE6アプリケーション開発で必要な主要開発技術の紹介（25分） JSF2.0 EJB3.1 JPA2.0 CDI 今後のエンタープライズJavaEE開発(10分) 一般的なSIの開発案件で 使えそうな組み合わせ

5. JavaEEの進化の歴史を振り返る

6. エンタープライズアプリケーションの形態の変化 ホストコンピューター＋ダム端末（80年代） C/S構成のシステム（90年代～） Webアプリケーション（90年代後半～） Web2.0、SaaS、クラウド（2000年代～） 80年代 ９０年代 現在

7. エンタープライズシステムの特徴 複雑

8. コンポーネント があれば 幸せになれる！？

9. J2EEの当初の目標は分散コンポーネント開発基盤の標準化 ミドルウェアに対する標準API 関係データベースへのアクセス（JDBC） ネーミング・ディレクトリサービスへのアクセス（JNDI） 分散トランザクション（JTA、JTS） 通信基盤（RMI/IIOP、Webサービス、JMS） 標準プログラミングモデル JSP・サーブレット EJB

10. J2EEの複雑なプログラミングモデル 分散コンポーネントモデル 各機能単位にモジュールが別々のプロセスに分散 現在のSOAの考え方と似ている 状態を持ったオブジェクトがプロセスをまたいでメッセージをやり取りする オブジェクトの位置等価性 重たい 面倒 高コスト

11. 初期のEJBでHelloWorldを作ると ①リモートコンポーネントインターフェースを定義する 決まった親インターフェースを継承 public interface Hello extends EJBObject { String sayHello(String name) throws RemoteException; } 全メソッドでRemoteException送出を宣言

12. ②ホームインターフェースを定義する 決まった親インターフェースを継承 public interface HelloHome extends EJBHome { Hello create() throws CreateException, RemoteException; } 業務と無関係な例外送出を宣言

13. ③EJB実装クラスを定義する 実装するのはHelloではない！ public class HelloBean implements SessionBean { private SessionContext context; public void setSessionContext( SessionContextaContext) { context = aContext; } public void ejbActivate() {} public void ejbPassivate() {} public void ejbRemove() {} public void ejbCreate() {} public String sayHello(String name) { return “こんにちは " + name; } } 業務的に意味のあるのは この部分だけ

14. ④XMLデプロイメント記述子を作成する <?xml version="1.0" encoding="UTF-8"?> <ejb-jar version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"> <display-name>EJB2App-ejb</display-name> <enterprise-beans> <session> <display-name>HelloBeanSB</display-name> <ejb-name>HelloBean</ejb-name> <home>hello.ejb.HelloHome</home> <remote>hello.ejb.Hello</remote> <ejb-class>hello.ejb.HelloBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> … </ejb-jar>

15. 呼び出し側も大変だった ①JNDIからホームオブジェクトをルックアップ public static HelloHomelookupHelloHome() { Context context = null; try { context = new InitialContext(); return (HelloHome) PortableRemoteObject.narrow( context.lookup("java:global/EJB2App/EJB2App-ejb/HelloBean!hello.ejb.HelloHome"), HelloHome.class); } catch (NamingException ex) { throw new RuntimeException(ex); } finally { if (context != null) { try { context.close(); } catch (NamingException ex) { throw new RuntimeException(ex); } } } }

16. ②ホームオブジェクトから EJBオブジェクトを作成して呼び出す Hello hello = null; try { hello = helloHome.create(); return hello.sayHello(name); } catch (CreateException ex) { throw new RuntimeException(ex); } catch (RemoteException ex) { throw new RuntimeException(ex); } finally { if (hello != null) { try { hello.remove(); } catch (RemoteException ex) { throw new RuntimeException(ex); } catch (RemoveException ex) { throw new RuntimeException(ex); } } } 業務的に意味のあるのは この行だけ

17. 重量Javaのせいで多くのプロジェクトが失敗した

18. J2EE関連のデザインパターンの登場 プロジェクトの失敗は仕様自体の問題ではなく、アプリケーションの設計が不十分なため？ パターンによりJ2EE開発のベストプラクティスを学ぼうという雰囲気があった。 18 EJBデザインパターン Floyd Marinescu (著) J2EEパターン 第2版 Deepak Alur (監修), John Crupi (著), Dan Malks (著)

19. 軽量Javaフレームワークへのパラダイムシフト（2003年～） Springを作ったRodJohnsonの「ハゲ本」 開発生産性で不満のたまった優秀な開発者の間から、J2EE仕様自体の問題点が公に議論されるようになった。 POJO EoD 軽量Java expert one-on-one J2EE Development without EJB Rod Johnson（著）

20. JavaEE5標準に対する軽量Javaの考え方の導入 2006年にようやく登場のJavaEE5標準では開発簡易化（EoD）が重視された EJBをPOJOとして開発 一部にDI・AOPの考え方を導入 アノテーションの利用によるxmlファイルの削減

21. EJB3でHelloWorldを作ると ①ビジネスインターフェースを定義する @Remote public interface Hello { String sayHello(String name) ; }

22. ②ビジネスインターフェースの実装クラスを定義する アノテーションだけでEJBとして登録される。 XMLファイルの設定は不要。 普通にビジネスインターフェースを実装 @Stateless public class HelloBean implements Hello { public String sayHello(String name) { return “こんにちは " + name; } }

23. ③インジェクションして普通に呼び出す @EJB private Hello hello; public void someMethod() { ... String message = hello.sayHello("Test"); ... } アノテーションを使ってインジェクションする。 普通にメソッドを呼び出す。

24. 見かけは簡単になったけど EE5対応のAPサーバは以前よりさらに巨大で重たくなった気がする 動作確認するにはearファイルにパッケージ化する必要がある 結合試験の自動化が意外に困難 DIやAOPが使えるのは一部の重量コンポーネント（EJB、サーブレットなど）に限られる プレゼン層とビジネス層のコンポーネントモデルがまったく異なる 肝心の互換性が少ない 結局JavaEEは 使えないんじゃ？

25. そして、JavaEE6の時代へ EE5から3年半たって2009年12月に策定 開発をさらに簡易化させるアイデアが多数盛り込まれている SeamやFaceletsなどEE5の弱点を補足するフレームワークのしくみを導入 OSSの開発コミュニティが主導で、本当に便利で必要な機能が追加されている 余分な機能の削除によるさらなる軽量化 Webプロファイル Pruning（使われなくなった仕様の間引き）

26. なによりも本当に軽量なJavaEE6サーバーが登場

27. でも、JavaEE6で 本当にまともに 開発できるの？

28. JavaEE6開発の主要技術の紹介

29. JavaEE6だけでWebアプリケーションを作るとどうなるか？ JavaEE6は便利になったと言われるが、フルスタックのサンプルがなかなか見当たらない 画面 ビジネスロジック データアクセス 試験 そこで、JsfScrumToyというJSFのサンプルをリファクタリングしてどこまで簡単にできるかPOCを実施

30. 実際に組み合わせを検証したJavaEE6の技術 Webプレゼンテーション -> JSF2.0 トランザクション管理 -> EJB3.1 データアクセス -> JPA2.0 DI、コンポーネント管理 -> CDI 試験 -> JUnit、埋め込みGlassfish

33. 基本的にステートレスJAX-WS、JAX-RS

34. Webフレームワークの分類 アクションベース VS コンポーネントベース

35. 主要Webフレームワークの位置づけ S2Struts Struts1 設定簡易化 アクション ベース Struts2 SAStruts 会話状態サポート Spring MVC Spring WebFlow Web MVC FW Spring Faces JSF 会話状態サポート コンポーネント ベース Seam Tapestry 設定簡易化 Teeda Wicket Click

36. アクションベースFW HTTPリクエスト HTTPリクエスト解析 アクション 業務ロジック HTTPレスポンス HTTPレスポンス生成

37. UIコンポーネントツリーと管理Bean UIコンポーネントツリー UIViewRoot 管理Bean 管理Bean UIForm 値取得 UIOutputText 値設定 UIInputText 管理Bean UICommandButton アクション起動

38. コンポーネントベースFWの存在意義 リッチな画面部品（カレンダーなど）の再利用が容易 VBのように、部品さえ用意すれば、簡単にロジックを呼び出せる ボタンや入力項目が大量についている画面が大量にあるようなアプリには適する 社内C／Sアプリ のWeb化に適する

39. 以前はいまいちだったけど、 JSF2は前バージョンから大幅に改良されている！

40. 38 Faceletsを使った画面テンプレート化 ほとんどのWeb画面では、メニューバーやサイドバー、フッターなどがパターン化されている 画面が増えてくると、毎回同様のxhtmlファイルを作成するのは面倒 JSF2.0ではFaceletsを採用することで、テンプレート化が簡単に行えるようになった

41. 画面テンプレートの定義例 <html …> <head> … <ui:insert name="head"/> </head> <body> … <div class="body"> <ui:insert name="body"/> </div> </body> </html> template.xhtml

42. 個別画面の定義例 hello.xhtml <html …> <ui:composition template="/layout/template.xhtml"> <ui:define name="body"> <h1>こんにちは世界!</h1> </ui:define> </ui:composition> </html>

43. コンポジットコンポーネント 画面中で繰り返し出現するパターンを抜き出して「タグリブ化」することが可能 部品定義をxtmlで通常の画面と同様に作成し、以下のフォルダに格納するだけでよい Webアプリルート/resources JSP2.0のタグファイルに近い方法で気軽に画面部品を作成できるようになった

44. コンポジットコンポーネントの定義例 link.xhtml <html …> <composite:interface> <composite:attribute name="value“ /> <composite:attribute name="outcome"/> </composite:interface> <composite:implementation> <h:link outcome="#{cc.attrs.outcome}" value="#{cc.attrs.value}"> <f:param name="cid“ value="#{javax.enterprise.context.conversation.id}"/> </h:link> </composite:implementation> </html> パラメーターを宣言 部品の中身を定義

45. コンポジットコンポーネントの利用例 create.xhtml <html ... xmlns:scrum="http://java.sun.com/jsf/composite/components"> ... <scrum:link outcome="/project/show" value="プロジェクト一覧" /> ... </html>

46. JSF1.2までの画面遷移定義 JSF1.2まではすべての画面遷移ルールをxmlで定義する必要があった <navigation-rule> <description> sprint navigation rules </description> <from-view-id>/sprint/show.xhtml</from-view-id> <navigation-case> <from-outcome>showStories</from-outcome> <to-view-id>/story/show.xhtml</to-view-id> </navigation-case> <navigation-case> <from-outcome>showDashboard</from-outcome> <to-view-id>/dashboard/show.xhtml</to-view-id> </navigation-case> </navigation-rule> faces-config.xml

47. 暗黙ナビゲーション JSF2.0ではほとんどの場合遷移先のビュー名を直接記述した方が便利 SprintAction.java public String showSprints(Project project) { selectCurrentEntity(project); return "/sprint/show?faces-redirect=true"; } 拡張子は省略可 ?faces-redirect=trueを付けるとHTTPリダイレクトする

48. BeanValidation（JSR303) public class Task extends AbstractEntity implements Serializable{ … @NotNull @Size(min=0, max=128) private String name; アノテーションを付けるだけで単項目のバリデーションが行われる。

49. Ajax機能を簡単に利用 <h:panelGroup> <h:inputText id=“endDate” value=“#{currentProject.endDate}”> <f:convertDateTime pattern=“yyyy/MM/dd" /> <f:ajax event="blur" render="endDateError" /> </h:inputText> </h:panelGroup> <h:message id="endDateError" for="endDate" styleClass="errorMessage" /> このように書くとblur、 つまり、フォーカスが外れた段階でAjaxリクエストが送信され、結果がエラーメッセージに反映される。

50. その他細かい改良点が多数 Enumのリストを直接選択項目としてバインドできるようになった 以前はわざわざSelectItemのリストに変換する必要あり POJOのリストを直接テーブルに表示できるようになった 以前はDataModelに変換する必要があり 選択行は直接アクションメソッドのパラメータとして簡単に受け取れる

51. EJB3.1＝ちょっと特殊な能力を持ったPOJO 以前はEJB=ビジネスコンポーネント=面倒 最新のEJB3.1はちょっと特殊な能力を持ったPOJOに過ぎない トランザクション リモート呼び出し 同時実行 タイマー実行 非同期実行

52. さらに、EJB3.1では インターフェースはオプション Warファイル中に格納可能 Earファイルは単純な Webアプリでは不要

53. EJB3.1を使った非同期実行 呼び出し側のスレッドをブロックせずに時間のかかる処理を実行 @Stateless public class OrderProcessBean { @Asyncronous public void registerOrder(Order order) { ... } } 戻り値の型はvoidかFuture型

54. EJB3.1を使ったタイマー実行 EJB3.1で新登場の シングルトンBean @Singleton public class LogCleanUpBean { @Schedule(minute="1", hour="*") public void cleanUpOldLogs() { ... } } CRON的な宣言で簡単に定期実行可能

55. JPAを使ったデータアクセス JPA = Java Persistence API O/Rマッピングの標準化

56. JPAを使うと何がよいのか？ 静的なインピーダンスミスマッチの解決 継承などを駆使した複雑なドメインモデルをテーブルにマッピングできる 動的なインピーダンスミスマッチの解決 エンティティの状態変更を適切なタイミングと粒度でテーブル更新に変換してくれる エンティティに複雑な状態変更などの振る舞いを持たせられる DDDと相性がよい！ ※DDD=DomainDrivenDevelopment

57. ドメイン駆動型設計（DDD） 流通、販売など業務固有の処理こそが最も大切で複雑な部分 コアの業務ドメインに優秀な開発者を割り当てて時間をかけてあるべきモデルに進化させていく

58. Story Task ID=null ID=null Task 永続コンテキスト ID=null Story Project ID=3 ID=101 Task Sprint ID=9 Story ID=11 ID=10 Project ID=101 DB 永続コンテキスト中のエンティティの状態はDBと自動的に同期される。

59. JPA2.0の新機能 JPA2では細かい改良と機能追加が行われている キャッシュの標準化 悲観ロックの標準化 クライテリアクエリAPIの標準化 より柔軟なドメインモデルのマッピング Stringなど値コレクションのマッピング Mapを使ったマッピング方式の拡張

60. JavaEEでちょっと複雑な「Bean」について JavaEE仕様の中ではBeanという言葉が様々な仕様で使われている EnterpriseJava Bean(EJB) JSFの管理Bean （@javax.faces.bean.ManagedBeanで定義） JSR250で新たに登場した管理Bean （ @javax.annotation.ManagedBeanで定義） 意味が不統一なだけでなく、お互いに連携させるのも困難

61. 一方で、SpringやSeamでは レイヤーに関係なく、ほぼすべてのPOJOをBeanとしてコンテナに登録できる Bean同士はお互いに統一された方法で連携させることができる やはり、Java EE6はイマイチなのか？

62. JavaEE6でBeanを統一的に扱う切り札となるCDI CDI=Contextsand Dependency Injection beans.xmlファイル（空でもよい）をモジュール内に格納することでCDI機能が有効になる CDIを有効にすると、ほとんどのPOJO・EJBをすべて統一的にBeanとして扱うことができるようになる

63. CDIのBeanの例 Beanの有効 なスコープを定義 JSFのビューから 参照する名前を定義 一定の条件を満たせば自動的にCDIのBean @Named @ConversationScoped public class SprintAction implements Serializable { @Inject ScrumManagerscrumManager; @Inject SprintRepositorysprintRepository; … } 任意のBeanは@Injectで注入

64. CDIのBeanのスコープ CDIのBeanはスコープを持てる @RequestScoped @SessionScoped @ApplicationScoped @ConversationScoped Singleton、Dependent疑似スコープ 独自のスコープを定義して拡張することも可能

65. JavaEE6と試験自動化 Java EE6のコンポーネントは大部分POJO 従って、JUnitとモックオブジェクトを使って容易に単体試験可能 加えて、軽量な埋め込みコンテナを利用することで、トランザクションやDB接続を行う結合試験の自動化もできる JeeUnitやArquillianなどを利用すると、CDIによりいっそう楽になる

66. 今後のエンタープライズJava開発

67. ところで、日本のSI業界では JavaEEの技術（プログラミングモデルの部分）は主に海外で利用され、発展してきた そもそも、日本のSI業界の事情は違うのでは そもそも、コンポーネント化や多層分散アーキテクチャのシステムはほとんどなかったのでは？ 大規模だが、モノリシックなアーキテクチャを強制するフレームワークが蔓延

68. SI業界の残念な実情 FN1002Commandのようなレガシーなクラス名の規約 10000行を超えるクラスがあってもリファクタリングしない（できない） 業務ロジックはexecute()メソッド内に記述、勝手にメソッドを分割できない 今でも新規案件をJDK1.4で開発

69. 海外はオーバーエンジニアリング 海外だと、アーキテクトの権限が強いことが多く、過剰な設計となりがちだった？ 過剰なレイヤ、ティア分割、分散化 面倒だけど頑張ってコンポーネント化、ドメインモデリングしていた？（Sessionファサードパターン）

70. 日本はアーキテクチャ軽視 日本だと、適切なアーキテクチャが施行されていないケースも多い 1機能１クラス（コマンドパターン） Excelから全クラスと設定を自動生成 箱はたくさん分かれているが、論理的なレイヤー構造やコンポーネント構造はなし

71. 開発簡易化（EoD）の真の意味 従来の大変だけれどつまらない単純作業から開発者が解放される 単純な値の詰め替え 冗長な設定ファイルの記述 サービスの粒度などを自由に設計できる ドメイン駆動型設計など複雑な業務ドメインをモデル化 つまり「頭を使う必要がある」ということ

72. EoDと生産性の関係 生産性・保守性 SOA、 TDD、 ドメイン駆動型 アジャイルの開発 日本のSI業界的な 労働集約型、 ウォーターフォール コピペ中心の開発 EoD技術の進化

73. エンタープライズJava開発はこれからが面白い JavaEE6の時代になり、標準仕様ですらEoDがかなり成熟してきたといえる コンポーネント化、DDD、テストファーストなどのメリットが低コストで実現できる仕掛けが標準で得られるようになった 日本のSI開発のやり方も従来の労働集約型のモデルから脱却して、より賢い開発方法を取り入れていかなくてはならない時代

74. 今後はスキルをあるべき方向に発揮できる、 開発者にとって面白い時代になる