Migrating traditional Java EE
applications to mobile
Serge Pagop
Sr. Channel MW Solution Architect, Red Hat
spagop@redhat.com
Burr Sutter
Product Management Director, Red Hat
bsutter@redhat.com
2014-04-16
2
Agenda
•Migration motivations
•Traditional Java (2) EE technologies usage
•Migration approaches
•Migration of layers
•Modernize to Java EE 6 technologies – Plan for mobile
•REST fits well with the mobile strategy
•Which Mobile application model to choose?
•Mobile Gateway architecture – Mobile + JBoss EAP Runtime
•Demo and Q&A
3
Motivations
•Innovation, integration, cost reduction, modernization
•Market Demand, Time to market, Go-To Market strategy
•Complexity, performance, stability, security
•Vendor lock-in, lack of functionalities, standards compliance
•Multi-tenancy, Ready for the Cloud
•Penetrate New Market Segment
•Increase developer productivity
4
Motivations – MOBILE VS. DESKTOP - Projection
Source: visual.ly
5
Traditional Java (2) EE technologies usage
Current situation
6
Traditional Java (2) EE technologies usage
Current situation
•Persistence layer
•Standards are JDBC, CMP, BMP, JPA, JDO
•Non-Standards are Hibernate, iBatis, ...
•Business layer
•Standards are Enterprise JavaBeans 2.x / 3.0
•Non-Standards are Spring Framework, JBoss Seam, Google Guice, ...
•Communication layer
•Standards are JAX-WS, JAX-RPC, RMI
•Non-Standards are legacy Web Service Frameworks
7
Traditional Java (2) EE technologies usage – Cont.
Current situation
•Presentation layer
•Standards are JSP+Servlets, JSF 1.2/2.0
•Non-Standards are: Struts, Tapestry, GWT, Wicket, ...
8
Migration approaches
•Complete migration
•Layer-oriented migration
•Module-oriented migration
First Action Item: Migration Assessment
9
Migration assessment
•Looks at all facets of applications and infrastructure
•Helps to understand the risks, savings, and anticipated costs
•Enables stakeholders to scope the engineering time and effort
required to migrate applications
● Free open source tool for Java EE migration assessment
● Analyzes code and generates report with known issues
● Provides an estimate of effort required to make changes
● Offers suggestions for replacement code
● Highlights vendor specific implementations
10,000 Foot View Report
http://www.jboss.org/migration
10
Complete migration – Big Bang style
•Unique new development
•Migration of the entire application in a new system
•High Complexity because of new development
11
Layer-oriented migration
•Based on layer oriented approach: each layer needs a specific
handling
•Complexity is defined through
•Multiple migration with associated test and acceptance processes
•Migration of a layer affects overlying layers
12
Module-oriented migration
•Defined as Migration On Demand
•Migration of technical modules will be taken in consideration
•Complexity is defined through
•A mix of technologies of new and old ones
•Delimitation of technical modules
13
Persistence layer migration
Current-Situation Future-Situation
SQL/JDBC Data Access JPA 2.0 Challenges
● SQL Queries
● DAO / Repository Pattern
● Providing Value Objects
● Domain model introduction with relationship
● Detached entity objects handling
● Adaption of entity objects with unique identity
EJB 2.x Data Access JPA 2.0 Challenges
● CMP 2.x - Entity classes and XML descriptors
● BMP 2.x - CRUD callback methods
● Domain model introduction with relationship
● Detached entity objects handling
● Adaption of entity objects with unique identity
● Data Access Objects introduction
Hibernate Data Access JPA 2.0 Challenges
● O/R Mapping via XML
● Using Hibernate APIs
● No challenges (Hibernate is JPA provider in JBoss EAP)
● May be some challenges with proprietary Hibernate
features
JDO Data Access JPA 2.0 Challenges
● Domain model approach similar to JPA (based on
annotation or configuration)
● JDO and JPA have similarities
14
Business layer migration
Current-Situation Future-Situation
EJB 2.x components EJB 3.1 Challenges
● Stateless and Stateful Session Beans
● EJB 2.x Pattern and communication
● No challenges
● Eliminate J2EE Pattern
● Eliminate proprietary infrastructure code
EJB 2.x components CDI 1.0 Challenges
● Stateless and Stateful Session Beans
● EJB 2.x Pattern and communication
● No challenges
● Eliminate J2EE Pattern
● Eliminate proprietary infrastructure code
Spring – lightweight DI Framework CDI 1.0 Challenges
● Based on XML or annotation
● Strong integration support (JDBC template, Tx template,
JMS template, Mail template)
● Supports other annotations (@Resource, @Inject)
● No challenges
● May be some challenges with Spring Add-On
● Different semantics in the field of scopes
15
Communication layer migration
Future-Situation – Introduction of a new communication interface
JAX-RS - Challenges
●New fresh start
●Provide distinct URI for each resource you wish to expose
●Expose REST services by injecting EJBs into JAX-RS annotated POJOs
●Use nouns in the URIs
●Use links in your responses
●Make service stateless
●Define what actions should be able to perform on each resource
●Map the actions to an appropriate HTTP verbs (@DELETE, @GET, @POST, @PUT,
@HEAD)
●Use JSON via JAXB as interchange data format
16
Presentation layer migration
Standard like JSP with Servlet or
JSF 2.0/2.1 and non-standard
web frameworks like Struts,
Tapestry, GWT, … do not have a
migration path in a mobile
strategy
Client side needs a clean / fresh
start
Mobile-First strategy
creating pages, UI components
that address the constraints of
mobile, then progressively
enhances the experience to other
screen spaces, features, and
more
17
Modernize to Java EE 6 technologies
Future situation to enable mobile capabilities
18
REST fits well with mobile strategy
•REST is flexible and adequate for Client-Server communication
•Communication happens over HTTP using REST styles
•JSON over HTTP/HTTPs should be used for data-interchange
•Stateless, Cacheable, Lightweight, Scalable
•Using HTTP verbs (DELETE, GET, POST, PUT)
•Using Web technologies and security standards
•Fully supported in JBoss EAP (Java EE 6 compliant environment)
by a JAX-RS implementation (RESTEasy)
19
REST fits well with mobile strategy
Securing endpoints - Possibilities
•JBoss EAP 6.2 – Basic Auth
•RealmUsersRoles with *-users.properties and *-roles.properties files
•Database login module - users and roles from a database system
•LDAP login module – users and roles from a LDAP server
•JBoss EAP 6.3 – PicketLink
•Identity Management (IDM)
Which Mobile application model to choose?
Mobile Web
<html>
<body>
<div id=”name”/>
<script src=”x.js”/>
</body>
</html>
Native Shell Native App
Native Code
Apple apple apple
Android android
Windows windows
IOS ios ios
Jave
Objectve c
<html>
<body>
<div id=”name”/>
<script src=”x.js”/>
</body>
</html>
HTML5HTML5
Device Browser Apache Cordova Objective-C / Android Java
Pros:
Instant Deployment
Reuse of Web Talents
No App Stores
Cons:
Limited Device Features
Limited Offline Capabilities
No Push
No App Stores
Pros:
Cross-Platform
Native Device Features
Push
App Stores
Cons:
HTML/JS-based UI
Non-native look & feel
App Stores
Pros:
Limitless capability
Cons:
Unique Codebases
Unique skill-sets
Addressing multiple screen dimensions
App Stores
20
Internet
DBDB
JAX-RSJAX-RS
Unified
Push
Server
LDAPLDAP
Fuse
or
FSW
Fuse
or
FSW
Firewall
REST
APNS
GCM
push
notification
Internal
System A
Internal
System A
Internal
System B
Internal
System B
SalesForceSalesForce
SAPSAP
JBoss
Enterprise
Application
Platform
DBDB
MSSQLMSSQL
DB/2DB/2
OracleOracle
Mobile Gateway architecture
Mobile + JBoss EAP Server Runtime
21
22
Demo Time!
Questions?
Serge Pagop
Email: spagop@redhat.com
Burr Sutter
Email: bsutter@redhat.com

Migrating traditional Java EE Applications to mobile

  • 1.
    Migrating traditional JavaEE applications to mobile Serge Pagop Sr. Channel MW Solution Architect, Red Hat spagop@redhat.com Burr Sutter Product Management Director, Red Hat bsutter@redhat.com 2014-04-16
  • 2.
    2 Agenda •Migration motivations •Traditional Java(2) EE technologies usage •Migration approaches •Migration of layers •Modernize to Java EE 6 technologies – Plan for mobile •REST fits well with the mobile strategy •Which Mobile application model to choose? •Mobile Gateway architecture – Mobile + JBoss EAP Runtime •Demo and Q&A
  • 3.
    3 Motivations •Innovation, integration, costreduction, modernization •Market Demand, Time to market, Go-To Market strategy •Complexity, performance, stability, security •Vendor lock-in, lack of functionalities, standards compliance •Multi-tenancy, Ready for the Cloud •Penetrate New Market Segment •Increase developer productivity
  • 4.
    4 Motivations – MOBILEVS. DESKTOP - Projection Source: visual.ly
  • 5.
    5 Traditional Java (2)EE technologies usage Current situation
  • 6.
    6 Traditional Java (2)EE technologies usage Current situation •Persistence layer •Standards are JDBC, CMP, BMP, JPA, JDO •Non-Standards are Hibernate, iBatis, ... •Business layer •Standards are Enterprise JavaBeans 2.x / 3.0 •Non-Standards are Spring Framework, JBoss Seam, Google Guice, ... •Communication layer •Standards are JAX-WS, JAX-RPC, RMI •Non-Standards are legacy Web Service Frameworks
  • 7.
    7 Traditional Java (2)EE technologies usage – Cont. Current situation •Presentation layer •Standards are JSP+Servlets, JSF 1.2/2.0 •Non-Standards are: Struts, Tapestry, GWT, Wicket, ...
  • 8.
    8 Migration approaches •Complete migration •Layer-orientedmigration •Module-oriented migration First Action Item: Migration Assessment
  • 9.
    9 Migration assessment •Looks atall facets of applications and infrastructure •Helps to understand the risks, savings, and anticipated costs •Enables stakeholders to scope the engineering time and effort required to migrate applications ● Free open source tool for Java EE migration assessment ● Analyzes code and generates report with known issues ● Provides an estimate of effort required to make changes ● Offers suggestions for replacement code ● Highlights vendor specific implementations 10,000 Foot View Report http://www.jboss.org/migration
  • 10.
    10 Complete migration –Big Bang style •Unique new development •Migration of the entire application in a new system •High Complexity because of new development
  • 11.
    11 Layer-oriented migration •Based onlayer oriented approach: each layer needs a specific handling •Complexity is defined through •Multiple migration with associated test and acceptance processes •Migration of a layer affects overlying layers
  • 12.
    12 Module-oriented migration •Defined asMigration On Demand •Migration of technical modules will be taken in consideration •Complexity is defined through •A mix of technologies of new and old ones •Delimitation of technical modules
  • 13.
    13 Persistence layer migration Current-SituationFuture-Situation SQL/JDBC Data Access JPA 2.0 Challenges ● SQL Queries ● DAO / Repository Pattern ● Providing Value Objects ● Domain model introduction with relationship ● Detached entity objects handling ● Adaption of entity objects with unique identity EJB 2.x Data Access JPA 2.0 Challenges ● CMP 2.x - Entity classes and XML descriptors ● BMP 2.x - CRUD callback methods ● Domain model introduction with relationship ● Detached entity objects handling ● Adaption of entity objects with unique identity ● Data Access Objects introduction Hibernate Data Access JPA 2.0 Challenges ● O/R Mapping via XML ● Using Hibernate APIs ● No challenges (Hibernate is JPA provider in JBoss EAP) ● May be some challenges with proprietary Hibernate features JDO Data Access JPA 2.0 Challenges ● Domain model approach similar to JPA (based on annotation or configuration) ● JDO and JPA have similarities
  • 14.
    14 Business layer migration Current-SituationFuture-Situation EJB 2.x components EJB 3.1 Challenges ● Stateless and Stateful Session Beans ● EJB 2.x Pattern and communication ● No challenges ● Eliminate J2EE Pattern ● Eliminate proprietary infrastructure code EJB 2.x components CDI 1.0 Challenges ● Stateless and Stateful Session Beans ● EJB 2.x Pattern and communication ● No challenges ● Eliminate J2EE Pattern ● Eliminate proprietary infrastructure code Spring – lightweight DI Framework CDI 1.0 Challenges ● Based on XML or annotation ● Strong integration support (JDBC template, Tx template, JMS template, Mail template) ● Supports other annotations (@Resource, @Inject) ● No challenges ● May be some challenges with Spring Add-On ● Different semantics in the field of scopes
  • 15.
    15 Communication layer migration Future-Situation– Introduction of a new communication interface JAX-RS - Challenges ●New fresh start ●Provide distinct URI for each resource you wish to expose ●Expose REST services by injecting EJBs into JAX-RS annotated POJOs ●Use nouns in the URIs ●Use links in your responses ●Make service stateless ●Define what actions should be able to perform on each resource ●Map the actions to an appropriate HTTP verbs (@DELETE, @GET, @POST, @PUT, @HEAD) ●Use JSON via JAXB as interchange data format
  • 16.
    16 Presentation layer migration Standardlike JSP with Servlet or JSF 2.0/2.1 and non-standard web frameworks like Struts, Tapestry, GWT, … do not have a migration path in a mobile strategy Client side needs a clean / fresh start Mobile-First strategy creating pages, UI components that address the constraints of mobile, then progressively enhances the experience to other screen spaces, features, and more
  • 17.
    17 Modernize to JavaEE 6 technologies Future situation to enable mobile capabilities
  • 18.
    18 REST fits wellwith mobile strategy •REST is flexible and adequate for Client-Server communication •Communication happens over HTTP using REST styles •JSON over HTTP/HTTPs should be used for data-interchange •Stateless, Cacheable, Lightweight, Scalable •Using HTTP verbs (DELETE, GET, POST, PUT) •Using Web technologies and security standards •Fully supported in JBoss EAP (Java EE 6 compliant environment) by a JAX-RS implementation (RESTEasy)
  • 19.
    19 REST fits wellwith mobile strategy Securing endpoints - Possibilities •JBoss EAP 6.2 – Basic Auth •RealmUsersRoles with *-users.properties and *-roles.properties files •Database login module - users and roles from a database system •LDAP login module – users and roles from a LDAP server •JBoss EAP 6.3 – PicketLink •Identity Management (IDM)
  • 20.
    Which Mobile applicationmodel to choose? Mobile Web <html> <body> <div id=”name”/> <script src=”x.js”/> </body> </html> Native Shell Native App Native Code Apple apple apple Android android Windows windows IOS ios ios Jave Objectve c <html> <body> <div id=”name”/> <script src=”x.js”/> </body> </html> HTML5HTML5 Device Browser Apache Cordova Objective-C / Android Java Pros: Instant Deployment Reuse of Web Talents No App Stores Cons: Limited Device Features Limited Offline Capabilities No Push No App Stores Pros: Cross-Platform Native Device Features Push App Stores Cons: HTML/JS-based UI Non-native look & feel App Stores Pros: Limitless capability Cons: Unique Codebases Unique skill-sets Addressing multiple screen dimensions App Stores 20
  • 21.
    Internet DBDB JAX-RSJAX-RS Unified Push Server LDAPLDAP Fuse or FSW Fuse or FSW Firewall REST APNS GCM push notification Internal System A Internal System A Internal SystemB Internal System B SalesForceSalesForce SAPSAP JBoss Enterprise Application Platform DBDB MSSQLMSSQL DB/2DB/2 OracleOracle Mobile Gateway architecture Mobile + JBoss EAP Server Runtime 21
  • 22.
  • 23.