Migrating traditional Java EE applications to mobile Serge Pagop Sr. Channel MW Solution Architect, Red Hat [email protected] Burr Sutter Product Management Director, Red Hat [email protected] 2014-04-16 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 2 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 3 Motivations – MOBILE VS. DESKTOP - Projection Source: visual.ly 4 Traditional Java (2) EE technologies usage Current situation 5 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 6 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, ... 7 Migration approaches • Complete migration • Layer-oriented migration • Module-oriented migration First Action Item: Migration Assessment 8 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 10,000 Foot View Report ● Offers suggestions for replacement code http://www.jboss.org/migration ● Highlights vendor specific implementations 9 Complete migration – Big Bang style • Unique new development • Migration of the entire application in a new system • High Complexity because of new development 10 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 11 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 12 Persistence layer migration Current-Situation Future-Situation SQL/JDBC Data Access JPA 2.0 Challenges ● SQL Queries ● Domain model introduction with relationship ● DAO / Repository Pattern ● Detached entity objects handling ● Providing Value Objects ● Adaption of entity objects with unique identity EJB 2.x Data Access JPA 2.0 Challenges ● CMP 2.x - Entity classes and XML descriptors ● Domain model introduction with relationship ● BMP 2.x - CRUD callback methods ● 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 ● No challenges (Hibernate is JPA provider in JBoss EAP) ● Using Hibernate APIs ● May be some challenges with proprietary Hibernate features JDO Data Access JPA 2.0 Challenges ● Domain model approach similar to JPA (based on ● JDO and JPA have similarities annotation or configuration) 13 Business layer migration Current-Situation Future-Situation EJB 2.x components EJB 3.1 Challenges ● Stateless and Stateful Session Beans ● No challenges ● EJB 2.x Pattern and communication ● Eliminate J2EE Pattern ● Eliminate proprietary infrastructure code EJB 2.x components CDI 1.0 Challenges ● Stateless and Stateful Session Beans ● No challenges ● EJB 2.x Pattern and communication ● Eliminate J2EE Pattern ● Eliminate proprietary infrastructure code Spring – lightweight DI Framework CDI 1.0 Challenges ● Based on XML or annotation ● No challenges ● Strong integration support (JDBC template, Tx template, ● May be some challenges with Spring Add-On JMS template, Mail template) ● Different semantics in the field of scopes ● Supports other annotations (@Resource, @Inject) 14 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 15 Presentation layer migration Standard like JSP with Servlet or JSF 2.0/2.1 and non-standard web frameworks like Struts, Mobile-First strategy Tapestry, GWT, … do not have a creating pages, UI components migration path in a mobile that address the constraints of strategy mobile, then progressively enhances the experience to other screen spaces, features, and more Client side needs a clean / fresh start 16 Modernize to Java EE 6 technologies Future situation to enable mobile capabilities 17 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) 18 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) 19 Which Mobile application model to choose? Mobile Web Native Shell Native App Native Code HTML5 HTML5 <html> <html> Apple apple apple <body> <body> Android android <div id=”name”/> <div id=”name”/> Windows windows <script src=”x.js”/> <script src=”x.js”/> IOS ios ios </body> </body> Jave </html> </html> Objectve c Device Browser Apache Cordova Objective-C / Android Java Pros: Pros: Pros: Instant Deployment Cross-Platform Limitless capability Reuse of Web Talents Native Device Features No App Stores Push Cons: App Stores Unique Codebases Cons: Unique skill-sets Limited Device Features Cons: Addressing multiple screen dimensions Limited Offline Capabilities HTML/JS-based UI App Stores No Push Non-native look & feel No App Stores App Stores 20 Mobile Gateway architecture Mobile + JBoss EAP Server Runtime JBoss Enterprise Application LDAPLDAP Platform InternalInternal DB SystemSystem AA DB APNS JAX-RSJAX-RS InternalInternal Internet REST FuseFuse SystemSystem BB oror MSSQLMSSQL Unified FSWFSW Push push GCM Server notification SalesForceSalesForce DB/2DB/2 DBDB SAPSAP OracleOracle Firewall 21 Demo Time! 22 Questions? Serge Pagop Burr Sutter Email: [email protected] Email: [email protected].