Enterprise Java Hosting in a Cloud Environment
2 likes557 views
The document outlines the history and evolution of Java and WebLogic at Union Pacific Railroad, detailing key milestones from 1995 to 2010, including the adoption of J2EE and various WebLogic versions. It discusses the transition to a Java hosting environment emphasizing flexibility, standardization, and resource utilization, along with challenges and solutions in web infrastructure. Additionally, it covers the introduction of Spring framework and the strategic goals behind the Java hosting environment's technology stack.
Enterprise Java Hosting in a Cloud Environment
- 2. David A. WebsterChief Architectdawebster@up.com Enterprise Java Hosting in a Cloud Environment Sweta Vajjhala Associate Project Engineer svajjhal@up.com Web Infrastructure Union Pacific Railroad 24 June 2010
- 3. Agenda History of WebLogic and J2EE at Union Pacific (UP) Web Architecture Review Support Systems Move to Spring Framework UP’s Hosting Environment Overview Current Future
- 4. History of Java at Union Pacific 1997 Adoption of J2EE 1995 Java introduced at Union Pacific as a supplement to mainframe systems Groundwork for later distributed system 2000 Introduction of WebLogic 5.1 at UP Java otherwise known as “distributed systems” 2014 Retire Mainframe Systems 2002 UP moves to WebLogic 6.1 All Java processing done inside WebLogic based on full J2EE (EJB) spec 2005 UP moves to WebLogic 8.1 2008 UP moves to WebLogic 10.3 2010 UP moves to WebLogic 10.3 and JBoss 2003 Separate JMS & Tuxedo (Jolt) introduced
- 6. Web Request Trace -SiteMinder
- 7. Supporting Systems Source Code ControlHome-grown solution Change Control •Based on check-out from Subversion •Build/deploy to test •Certify in test and deploy to production Security (SiteMinder & LDAP) •Each application has its own login ID JMS ESB Monitoring Feeds
- 8. From Development to Production Install Desktop Environment Build initially to desktop Deploy to DEV using desktop toolsPass user interface inspection Deploy to TEST using change control Certify TEST build PROD deploy from TEST (no builds)
- 9. WebLogic and the move to 10.3 (Spring) Fall 2007 New applications adopt Spring framework Many apps move to Stand-Alone JVMsFall 2008New Java Policy introducedDeprecated J2EE: No EJBsNo WebLogic-specific dependenciesMove to Java 6Maintain Legacy-EJB domain but at reduced SLA Summer 2009 New Java Hosting initiative launchedDecember 31, 2010WebLogic 8.1 retires
- 11. Current EnvironmentAdvantages & Disadvantages Advantages Disadvantages Multiple deployment options Not isolated at hardwareor application levels Provenplatform Inefficientresource utilization Familiar environment No standard console management tool across development & infrastructure teams Costs of licensing& administration
- 12. Java Hosting Environment (JHE) Overview Stand-Alone JDK 1.6
- 13. Java Hosting Environment Strategic Goals Flexibility Choices for container options and hardware resources Standardization Provide standardized containers, libraries, management and operational consoles, DR strategy, monitoring, logging, etc. Availability Provide better application isolation, both at container and hardware level Cost Avoidance Provide environment that better utilizes resources, provides more efficient supportability, and flatten growth in most expensive containers
- 14. Java Hosting EnvironmentTechnology Stack
- 15. Java Hosting EnvironmentPrivate Cloud Infrastructure as a Service RedHat Clustering & Virtualization Platform as a Service Java Containers JBoss Operation Network
- 16. Java Hosting EnvironmentRedHat Clustering & Virtualization Benefits Increased flexibility for: Administration Capacity Increased availability via: Isolation Clustering
- 17. Java Hosting EnvironmentTechnology Stack
- 18. Java Hosting EnvironmentContainer Choices
- 19. The Linux Side Standard filesystem One ID owns binaries and scripts, second ID owns instances and logs RHQ Agent under software and instance ID In DEV developers use instance ID via “PMRUN” RPM and the Satellite system RedHat binaries
- 20. The “Split Brain” EWS $CATALINA_HOME and $CATALINA_BASE both have standard Tomcat directory structure /lib in $CATALINA_HOME forms system classpath /conf and /webapps in $CATALINA_BASE for each instance EWP run –c <full path to instance> Single set of binaries, multiple instances
- 23. Desktop Development ITL images Custom app servers that are pushed by request “Clone” EWS/EWP and packages of Linux configurations Eclipse Galileo with WTP Use same $CATALINA_HOME/$CATALINA_BASE for EWS Same –c runtime for EWP Dynamic Web projects with Maven facets Allows for step debugging of web apps, including JSP
- 24. Spring Framework support Class Loadtimeweaving (needed for AOP and JPA) EWS–context.xml and Spring ApplicationContext.xml Setenv.sh Context.xml ApplicationContext.xml EWP–Spring ApplicationContext.xml and web.xml ApplicationContext.xml Web.xml
- 25. “Single pane of glass” for all Java processes Web-based GUI for all JHE operations (start/stop/re- deploy) Supplemental monitoring capability JBOSS Operations NetworkOverview
- 29. Winning the political battle Lay the groundwork Establish container-agnostic development standards “Upgrade” the existing container Allow only apps meeting modern standards in new version Shut down old container Keep familiarity Same processes Same domain/cluster hosting model Same development tools Stand-Alone versus container execution of Spring services