1 / 50

WebSphere Application Server Upgrade from V3.5, V4.0 to V5

WebSphere Application Server Upgrade from V3.5, V4.0 to V5. 작성자 : 차의중 / 한국 IBM / 전문 과장 / ejcha@kr.ibm.com 작성일 : 2004.3.17. 목 차. 필요성 및 기대 효과 버전간 비교 Overall migration steps Web component migration steps EJB component migration steps WAS configuration migration steps Other useful tools.

raanan
Télécharger la présentation

WebSphere Application Server Upgrade from V3.5, V4.0 to V5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WebSphere Application Server Upgradefrom V3.5, V4.0 to V5 작성자 : 차의중 / 한국 IBM / 전문 과장 / ejcha@kr.ibm.com 작성일 : 2004.3.17

  2. 목 차 필요성 및 기대 효과버전간 비교Overall migration stepsWeb component migration stepsEJB component migration stepsWAS configuration migration stepsOther useful tools

  3. 필요성 및 기대 효과

  4. WAS Upgrade의 필요성 성공적인 인프라 구축 WebSphere v5 Upgrade 비즈니스 요건변화에 탄력적 대응 급변하는 시장환경에 대응 신속하고 안정적인 환경제공 유지보수 및 기술지원 용이 J2EE Spec 준수 장애진단 및 복구 / 관리의용이성 보다 안정적이고 탄력적인 시스템 필요 WebSphere v3.5 환경

  5. WAS Upgrade후 기대효과-1/4 J2EE Spec준수 유지보수 및 기술 지원 용이 J2EE Server로서의 WebSphere는 J2EE 표준 스펙을 준수하는 Web Application Server입니다. 그러나 WAS v3.5는 표준 Spec 이전에 제공된 서버로, 기본적인 Web 환경 지원을 모두 제공하나, 표준을 준수한다고는 할 수 없습니다. 따라서 WAS v3.5는 표준 Spec의 변화로 개선/추가되는 기능에 대한 지원을 기대하기 어려울 뿐만 아니라, 사용자/개발자/운영자에게 보다 편리하고 안정적인 시스템 제공하는 데는 한계가 있습니다. => WAS v5는 최신 J2EE Spec 1.3을 준수하며, 그 외 확장된 기능의 제공으로 보다 탄력적인 시스템을 제공합니다. WAS v3.5의 공식적인 IBM의 서비스(EOS)는 2003.11월까지 입니다. 그러므로 그 이후에는 새로운 기술 및 기능상의 보완을 기대할 수 없습니다. 즉 계속 변화하는 IT환경에서 요구하는 기술에 대한 지원을 더 이상 받을 수가 없습니다. => 지속적인 서비스 지원을 받기 위해서는 WAS v5 로 upgrade가 필연적입니다.

  6. WAS Upgrade후 기대효과-2/4 비즈니스 요건 변화에 탄력적 대응 급변하는 시장 환경에 대응 비즈니스 요건 변화에 의한 새로운 Application 적용 및 수정 보완 시 보다 빠른 개발 생산성과 보다 안정적인 시스템 구현을 위한 시스템 및 탄력적인 대응이 반드시 필요합니다. WAS v3.5는 이러한 비즈니스 요건 변화에 대해 개발에서 적용, 안정화 단계까지 지원해 줄 수 있는 제반 환경 및 Tool이 제공되지 않습니다. 이러한 상황은 많은 위험 요소를 가지고 있습니다. => WAS v5는 개발에서 적용, 안정화 단계까지 각종 Tool을 제공함으로써 빠른 기일 내에 최소한의 인적 자원의 사용으로 탄력적인 시스템 구현을 가능하게 하며, 안정적인 시스템 환경을 구현합니다. WAS는 단순 Web Application Server 에서 Transaction을 처리하는 OLTP 및 Web Service의 구현을 위한 환경, 더 나가서는 EAI 기능까지 수행하는 시스템으로서 변화하고 있습니다. 뿐만 아니라 변화하는 시장 환경에 지속적으로 대응하기 위한 유연한 구조를 가지고 있어야 합니다. WAS v3.5는 이러한 흐름을 기본적으로 반영하고 있는 J2EE Spec을 100% 준수하지 못하며, 이러한 환경에 유연하게 대처할 수가 없습니다. => WAS v5 는 최신 J2EE Spec을 준수하며, 시장 환경에 유연하게 대처할 수 있는 기본 Infra를 제공하고 있으며, 새로운 변화에도 대응하도록 지속적인 지원을 할 것입니다. 또 현재 사용하는 시스템을 단순 유지하기 위한 계획이 아니라면 더욱 더 Upgrade가 필요합니다.

  7. WAS Upgrade후 기대효과-3/4 신속하고 안정적인 환경 제공 장애진단 및 복구 / 관리의 용이성 – 1/2 Network 및 IT의 환경의 변화로 인해 사용자는 더 빠른 서비스와 다양한 서비스를 제공받기를 원합니다. 이런 기대에 부응하기 위해서는 시스템, Network등의 자원의 효율성을 극대화하여 더 많은 사용자에게 더 빠른 서비스 제공하여야 하며, 또 시스템 확장이 용이하여야 하며 사용자의 편의성을 고려해야 합니다. WAS v3.5는 이러한 기능 및 환경을 제공하기 위해서 v5보다 많은 기능적 제약이 있으며 한계가 있습니다.. => WAS v5는 Dynacache 등의 기능 제공으로 보다 빠른 성능을 제공하며, 또 성능에 영향을 주는 요인들을 추적/분석해 낼 수 있는 Tivoli Performance Viewer, Performance Tuning Advisor, Request Metrics 등을 이용하여 성능에 영향을 주는 요인들을 제거 할 수 있습니다. 시스템 Resource 부족, 새로운 Application 적용 인한 영향, 사용자 및 사용량 증가 등으로 발생할 수 있는 시스템에 대한 장애에 대해 사전 감지 기능 및 자동 복구 기능이 제공되지 않아, 사전에 장애 예방을 할 수 없으며, 장애가 발생한 후에도 복구에 많은 인력과 시간이 필요합니다. 기존에 발생했던 DB Connection에 대한 장애 경험으로 장애에 대한 예방 및 빠른 복구가 절실히 필요함을 인지하고 계시리라 생각됩니다. => WAS v5는 모니터링 기능이 추가된 Log Analyzer, Tivoli Performance Viewer, DB Connection Manager에 대한 Trace, FFDC, IVT 등으로 장애에 대한 사전 예방 및 신속한 복구를 지원합니다.

  8. WAS Upgrade후 기대효과-4/4 장애진단 및 복구 / 관리의 용이성 – 2/2 Repository DB를 사용함으로써 추가적인 DB에 대한 사용 및 관리가 필요하며, Application Server가 반드시 Administrator Server에 의해 관리되어야 하므로 Administrator Server 장애 발생시 Application 서버에 대한 시작/중지/Deploy 등의 모든 작업을 할 수 없으므로 추가적인 Application Server의 장애 발생 요인이 됩니다. 또 관리를 위해 반드시 Admin Tool이 install되어야 하므로 관리 환경에 제약이 있고, Node당 개별적인 관리화면을 통해 분리된 관리가 이루어집니다. 그리고 서버에 대한 관리 환경 설정은 전적으로 관리자의 판단에 의해 좌우되므로 숙련된 전문가가 필수입니다. => WAS v5는 Repository로 XML File을 사용하므로 DB에 대한 사용이 필요 없으며, 어디서나 Web Browser를 통해 모든 Node를 하나의 화면에서 관리하므로 중앙 집중적인 통합환경의 관리가 이루어집니다. 또 Performance Tuning Advisor나 Tivoli Performance Viewer등의 Tool들이 제공하는 값들에 의해 관리 환경을 설정할 수 있으므로, 관리자의 지식에만 의존되는 또는 실수로 인해 발생할 수 있는 위험을 줄일 수 있습니다.

  9. 버전간 비교

  10. Product Roadmap

  11. 최신 산업 표준 기술에 대한 지원 • 웹 서비스 지원 IBM은 SOAP, WSDLUDDI, 등의 표준 spec을 정의하는데 주도적인 역할을 하고 있고, WSIF, Web Services Gateway등 웹 서비스의 첨단 기술을 업계 최초로 제품화하여 제공합니다 • => WebSphere위에서 Java와 웹 서비스를 비롯한 최신 산업 표준 기술을 가장 빠르고 안정적으로 사용함으로써 IT Trend를 앞서 갈 수 있음

  12. 관리 방식 • 서버를 신속하고 간편하고 관리하고, • 강력한 모니터링 기능을 통해서 서버를 최적화 시키고 장애를 사전에 예방할 수 있음

  13. 장애 진단 • 사용자에게 보다 빠른 서비스를 제공

  14. 확장성 • 더 많은 사용자에게 적절하고 안정적인 서비스를 제공

  15. 기타

  16. 성능 • 보다 빠른 서비스 제공

  17. 수행성능 비교 그래프 : From 3.02 to 5.1 5.1 4.0 5.0 3.0 3.5 JDK1.4.1 JDK1.3.1 JDK1.3.1 JDK1.3.1 JDK1.3.1 JDK1.3.1 JDK1.3.1 JDK1.2 Note: Performance delta between two releases was used for the above graph.

  18. 수행성능 비교 그래프: WAS 4.0 5.0 14% 24%

  19. 수행 성능 비교 그래프: WAS 5.0.2 5.1 30% 32% 41% 60% Trade Application On Windows Primitives

  20. Trade3 Results, EJBs on 4-way Systems 5.02 5.1 +25% +35% +46% 400 295 287 +35% +38% 265 230 218 300 181 reqs/second 127 200 106 94 77 100 0 HPUX Solaris Windows AIX Linux CPU% 97 95 97 95 99 99 99 99 94 95 R/T ms 635 470 530 391 274 185 213 172 227 168 System configuration Driver: WPT on IBM IntelliStation, 930 MHz PIII, Red Hat Linux 7.3, 50 clients HPUX SUT: HP/UX RISC rp5470, 4 x 750 MHz pa-RISC Processor, HP/UX 11i Solaris SUT: Sun Fire v880, 4 x 900 MHz SPARC Processor, Sun Solaris Release 5.9 (Solaris 9) Windows SUT: xSeries 440, 4 x 2.0 GHz Xeon, Windows 2003 Server Enterprise Edition AIX SUT: pSeries 660 6M1, 4 x 750 MHz, AIX 5L ML2 Linux SUT: xSeries 440, 4 x 2.0 GHz Xeon, Red Hat Advanced Server v 2.1 Database: xSeries 440, 4 x 2.0 GHz Xeon, Windows 2003 Server Enterprise Edition, 수행 성능 비교 그래프 : WAS 5.0.2 5.1

  21. Overall Migration Steps

  22. WebSphere Migration Process Features • Co-existenceable • 기존 버전이 설치되어 있는 머신에 추가로 V5 설치 가능 • Migration Tool 제공 • WASPreUpgrade, WASPostUpgrade, EJBDeploy, migrateWC, CACT, clientupgrade, earconvert, mb2mdb • 필요에 따라 선택 사용 • Migration Guide 제공 • redbook : http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246910.html?Open • InfoCenter => 자동화된 tool을 사용해서 수 작업을 최소화하고, 빠른 시간 안에 V5로 migration 가능

  23. Migration Steps (V3.5 to V5) • Install Target Machine에 이전 버전 WAS가 존재할 경우, Installation Wizard가 Migration 여부를 물어봄 • 4번과 10번 단계는 수작업 필요.

  24. Migration Steps (V4.0 to V5) • Install Target Machine에 이전 버전 WAS가 존재할 경우, Installation Wizard가 Migration 여부를 물어봄 • 필요에 따라 자동 / 수동 및 반복 적용을 통해 Migration 수행 • Application packaing을 다시 할 필요가 없음. • 4번과 7번 단계는 수작업 필요

  25. Web ComponentMigration Steps

  26. V3.5->V5 • Code Conversion (Required) • WAS 3.5 에서 지원되던 Web Module API중 JSP 0.91 과 Servlet 2.1이 WAS 4.0 이후로더이상 지원되지 않음에 따라 API의 변경이 필요 • JSP 0.91 -> JSP 1.0 / 1.1 • Servlet 2.1 -> Servlet 2.2 • Tool(migrateWC) 을 이용하여 자동화 가능 • Redeploy (Required) V4.0->V5 • WAS 4가 지원하는 JSP 1.1 과 Servlet 2.2 는 WAS 5가 지원하는 JSP 1.2 및 JSP 2.3의 subset이므로 Code Conversion 불필요 • Redeploy (Required)

  27. Code translation table (JSP 0.91 tags to JSP 1.0/1.1 tags )

  28. Code translation table (Servlet 2.1 to Servlet 2.2 API)

  29. Migration assistant tools (migrateWCutility) • migrateWC • download from http://www-1.ibm.com/support/docview.wss?uid=swg24001150 • 자동으로 API Translation을 수행하는 command line tool • JSP 0.91 -> JSP 1.0 / 1.1 • Servlet 2.1 -> Servlet 2.2 • Web Component 단위뿐 아니라 Directory 단위로도 수행 가능 • Ex) migratewc SessionServlet.java if(session.getValue( "msg" )==null){ session.setValue( "msg", msg ); } SessionServlet.java.new if(session.getAttribute( "msg" )<<:>Made code changes!->==null){ session.setAttribute( "msg", msg )<<:>Made code changes!->; }

  30. EJB ComponentMigration Steps

  31. V3.5->V5 • Code Conversion (Optional) • EJB 1.0 -> EJB 1.1 • EJB 1.0 -> EJB 2.0 • 툴을 이용하여 Conversion이 권장되는 Code를 알아낼 수 있음 : ejbdeploy, AAT • Redeploy (Required) • 툴을 이용하여 자동화 가능 : ejbdeploy , AAT V4.0->V5 • Code Conversion (Optional) • EJB 1.1 -> EJB 2.0 • Message Bean -> EJB 2.0 Message Driven Bean • Redeploy (Required) • 툴을 이용하여 자동화 가능 : ejbdeploy, AAT

  32. Code conversion rules (EJB 1.0 -> EJB 1.1) • An enterprise bean cannot use the javax.jts.UserTransaction interface. Use the new javax.transaction.UserTransaction interface instead. • An entity bean cannot use the UserTransaction interface. This is not allowed in 1.1. • An entity bean must define FinderException in their throws clause of finder methods. • An enterprise bean cannot throw a java.rmi.RemoteException. It can throw a javax.ejb.EJBException instead. But RemoteException must still be defined in EJB home and remote interfaces (as required by RMI). • You cannot use the finalize method. • java.security.Identity is deprecated. • Enterprise bean methods getCallerIdentity() and isCallerInRole(Identity) are deprecated. Use getCallerPrincipal() and isCallerinRole(String roleName) instead.

  33. Code conversion rules (EJB 1.0 -> EJB 1.1) • getEnvironment is deprecated. Open ejb_jar.xml with EJB deployment • descriptor, Beans tab, and view environment variables (such as • TARGET_HOME_NAME) String homeName=aLink.getEntityContext().getEnvironment().getProperty("TARG ET_HOME_NAME"); if (homeName == null) homeName = "TARGET_HOME_NAME"; becomes: Context env = (Context)(new InitialContext()).lookup("java:comp/env"); String homeName = (String)env.lookup("ejb10- properties/TARGET_HOME_NAME"); • CMP enterprise beans ejbCreate(...) methods should return the bean's primary key class (instead of void). • New HomeHandle interface, and EJBHome interface requires new getHomeHandle() method: public javax.ejb.HomeHandle getHomeHandle() { return null; }

  34. Code conversion rules (EJB 1.0 -> EJB 1.1) • Entity bean primary keys can now be java.lang.String objects. • Entity bean finder methods should define FinderException in their throws clause. • Entity bean finder methods return java.util.Collection. • Check the format of your JNDI names (and local namespaces are now supported). • There are now security roles, and isolation levels are now defined at the method level (they were defined at the EJB level for EJB 1.0).

  35. Code conversion rules (EJB 1.1 -> EJB 2.0) • For any CMP 1.x bean, replace each CMP field with abstract getXXX and setXXX methods. (Then the bean class needs to be abstract.) • For any CMP 1.x bean, change all occurrences of this.field = value to setField(value) in ejbCreate() and elsewhere throughout the code. • For any CMP, create an abstract getXXX and setXXX method for the primary key. • For any CMP 1.x finder, create an EJBQL (EJB Query Language) for each finder. • For any CMP 1.x finder, return java.util.Collection instead of java.util.Enumeration.

  36. Code conversion rules (EJB 1.1 -> EJB 2.0) • Update your exception handling (rollback behavior) for non-application exceptions: • Throw javax.ejb.EJBException instead of java.rmi.RemoteException to report non-application exceptions. • In EJB 2.0 and 1.1, all non-application exceptions thrown by the instance result in the rollback of the transaction in which the instance executed, and in discarding the instance. • In EJB 1.0, the container would not roll back a transaction and discard the • instance if the instance threw the java.rmi.RemoteException.

  37. Code conversion rules (EJB 1.1 -> EJB 2.0) • Update your Exception handling (rollback behavior) for application exceptions: • In EJB 2.0 and 1.1, an application exception does not cause the container to automatically roll back a transaction. • In EJB 1.1, the container performs the rollback only if the instance have invoked the setRollbackOnly() method on its EJBContext object. • In EJB 1.0, the container was required to roll back a transaction when an application exception was passed through a transaction boundary started by the container.

  38. Migration assitant tools • ejbdeploy • Located at $WAS_HOME/bin • EJB Deployment 및 Redeployment 를 위한 command line tool • Code conversion recommandation • EJB 1.0 컴포넌트를 EJB 1.1 컴포넌트로 변경시키고자 할 때, 변경되어야 할 부분들을 지적해 줌 Ex)

  39. Migration assitant tools • AAT (Application Assembly Tool) • Located in $WAS_HOME/bin • WAR,EJB-jar, EAR Deployment 및 Redeployment를 위한 GUI tool • 내부적으로, ejbdeployment를 호출할 수 있게 되어있음

  40. WebSphere on iSeries • 다양한 edition 제공으로 필요에 따라 선택할 수 있습니다 • WebSphere Express, Base, Network Deployment • Manual & Guide • Redbook, InfoCenter, iSeries Engineer community

  41. WAS Configuration Migration

  42. V3.5 또는 V4.0->V5 • Reconfiguration (Required) • 툴을 이용하여 자동 수행 가능 : WASPreUpgrade, WASPostUpgrade

  43. migration assistant tools • WASPreUpgrade • Located in $WAS_HOME/bin • V3.5 및 V4.0 의 Server Configuration 내용을 백업하는 Command line tool • 백업되는 내용들은 다음과 같다. • For Version 3.5 • bin • classes • deployableEJBs (Advanced Edition only) • deployedEJBs (Advanced Edition only) • hosts • properties • servlets • For Version 4.0 • bin • classes • config (Version 4.0.x Advanced Single Server Edition only) • installableApps • installedApps • installedConnectors (Version 4.x Advanced Edition only) • properties

  44. migration assistant tools • WASPostUpgrade • Located in $WAS_HOME/bin • WASPreUpgrade 에 의해 백업된, V3.5 및 V4.0 의 Server Configuration 을 V5.0으로 변경/적용시키는 Command line tool • Configuration 은 V5.0이 가진 기존 Configuration에 추가됨(대체가 아님) • V5.0의 기존 Configuration은 백업되어 필요시 복구 가능

  45. migration assistant tools • CACT • ex) • WASPostUpgrade • ex)

  46. Other useful tools

  47. Class API Checker tool • CACT • Download from http://www-106.ibm.com/developerworks/websphere/library/techarticles/0208_cocasse/0208_cocasse.html#Part%203.%20Downloading,%20installing%20and%20using%20CACT • V 3.5를 위한 어플리케이션 바이너리 파일(.class 또는 .jar)을 분석하여 V 4.0 또는 V 5.0에서 deprecated 된 API 를 출력해 주는 command line tool • Web Component 및 EJB Component 모두에 사용 가능 • Ex)

  48. EAR conversion tool (J2EE 1.2 ear to J2EE 1.3 ear) • earconvert • Located in $WAS_HOME/bin • J2EE 1.2 기반 어플리케이션의 EAR 파일을 J2EE 1.3 기반 EAR 파일로 변경해주는 command line tool • J2EE 1.2 기반 어플리케이션을 J2EE 1.3 기반으로 Migration하고자 할 때 필요 (J2EE 1.3 의 새로운 기능이나/ API를 사용하기 위해) • 물론, J2EE 1.2 기반 EAR은 J2EE 1.3 기반으로 변경하지 않고도 V 5에서 구동시킬 수 있다. • Deployment 정보만 J2EE 1.3 용으로 변경되며, Source code는 변경되지 않는다.

  49. Message Bean conversion tool • mb2mdb • Located in $WAS_HOME/bin • ejb-jar 또는 ear 속에 들어있는, V4.0 의 Message Bean 을 V5.0 의 EJB 2.0 기반 Message Driven Bean으로 변경해주는 command line tool

  50. client upgrade • clientupgrade • V4.0용 EAR 속의 client Jar 파일에 J2EE resource가 정의되어 있을 경우, 이 Resource를 V 5.0용 Resource로 변경해주는 command line tool

More Related