SlideShare ist ein Scribd-Unternehmen logo
1 von 41
RHAMT 소개
(Red Hat Application Migration Toolkit)
IT Evolution
Opennaru, Inc. © 2016 | All Rights Reserved.- Confidential -
3티어 아키텍처 – 2000년대
4티어 아키텍처 – 2010년 이후
Linux vs. Unix
Unix To Linux 전환의 필요성
마이그레이션 전환 방법론
IT 인프라 선택의 고민
JDK 및 WAS 업그레이드
마이그레이션 개요
마이그레이션 프로젝트의 핵심은?
• RHAMT(Red Hat Application Migration Toolkit)은 오픈소스 커뮤니티인 Windup의
Red Hat 컨설턴트 팀에 의해 개발
• CLI, Web Console, Eclipse-plugin 3가지 방식을 지원
• Java 애플리케이션을 분석하고 Java Code, JSP, XML들에 대하여 수정이 필요한 부분을
HTML 형식으로 Report 출력
Red Hat Application Migration Toolkit
JBoss Windup is a tool to simplify application migrations.
Running from the command line,
the tool reads EAR, WAR and JAR files.
and produces an HTML report detailing the inner workings
of the Java application to simplify migration efforts.
– Windup ( https://github.com/windup/)
• CLI
• Command Line을 사용하여 마이그레이션이 필요한 소스를 분석이 가능
• Web Console
• WEB 기반으로 되어있으며 Web Console의 통하여 분석이 필요한 소스들을 관리가 가능
• 각각 프로젝트별로 소스를 분리 할 수 있으며 여러 개발자들이 동시에 관리 및 분석 가
• Eclipse-Plugin
• Eclipse와 JBoss Developer Studio에서 사용 가능한 플러그인 을 제공하여 소스 개발 중 변경 해야 할 이슈 부
분을 IDE에서 바로 확인 가능한 것이 장점
RHAMT – Tools
• CLI는 아래 링크에서 다운로드 받을 수 있으며, Linux, Window 두 플랫폼에서 다 실행
이 가능
• Download 링크 : https://developers.redhat.com/download-
manager/file/4.0.0/migrationtoolkit-rhamt-cli-4.0.0.offline.zip
RHAMT – CLI
• 실행 화면
1. 압축 해제
#unzip migrationtoolkit-rhamt-cli-4.0.0.offline.zip
2. 디렉토리 이동
#cd rhamt-cli-4.0.0.Final
3. 스크립트 실행
#./bin/rhamt-cli --input ~/egovframework-all-in-
one.war --output ~/test --source spring -target
eap:7
• Report 화면
• Report 화면에서는 전체적인
summary를 출력
RHAMT – CLI
• 분석된 화면
• 애플리케이션을 선택 하면, 위와
같이 전체 적인 Menu가 나오며
변경 해야 할 가이드 내용을 확인
가능
RHAMT – WEB Console
1. 압축 해제
#unzip migrationtoolkit-rhamt-web-distribution-
4.0.0.with-authentication.zip
2. 디렉토리 이동
#cd rhamt-web-distribution-4.0.0.Final
3. 스크립트 실행
#./run_rhamt.sh
4. WEB Console 접속
http://localhost:8080/rhamt-web
• WEB Console는 아래 링크에서 다운로드 받을수 있으며, Linux, Window 두 플랫폼에
서 다 실행이 가능
• Download 링크: https://developers.redhat.com/download-
manager/file/4.0.0/migrationtoolkit-rhamt-web-distribution-4.0.0.with-
authentication.zip
• 실행 화면
RHAMT – WEB Console
• Project 생성
• Project를 생성하여 해당 프로젝
트에서 등록된 애플리케이션을
관리가 가능
• 애플리케이션 분석
• Project에 등록된 애플리케이션
은 Run Analysis를 클릭하면 바
로 분석을 진행
RHAMT – WEB Console
• 분석 설정
• 어느 애플리케이션을 분석 할지,
어느 JBoss 버전으로 마이그레이
션할지 설정이 가능
• Rules 설정
• 직접 마이그레이션에 대한 Rule
을 정의 하고 싶으면 Rules
Configuration에서 설정이 가능
• Eclipse-plugin은 Eclipse에서 Plugin을 설치 하여 사용
• Plugin 링크 :
http://download.jboss.org/jbosstools/oxygen/development/updates/rhamt/comp
osite/
RHAMT – Eclipse-Plugin
• 설치 화면
• Plugin 설치는 위에 링크를 등록
하면 자동적으로 설치
• RHAMT RUN
• 원하는 애플리케이션을 선택 후
분석 하기 위해 RHAMT를 실행
RHAMT – Eclipse-Plugin
• Issue Explorer
• Issue Explorer에서는 해당 애플리케이션에서 발생된 Issue 리스트를 제
공하며, 해당 이슈에서 더 제사한 내용도 확인 가능
RHAMT – Eclipse-Plugin
• Issue Details
• Issue Details에서는 해당 애플리케이션의 Code나 Config 파일에서 변경 해야
할 부분은 자세히 가이드
• RHAMT에서 식별 대상
• 특정 Application Server에 종속적인 어플리케이션 코드
• Java 코드 중 더 이상 사용할 수 없는 코드 (Deprecated Java code)
• 비표준 -JMS 메시징 코드
• 웹서비스 식별
• EJB 버전 (2 / 3) 식별
• 하이버네이트, 스프링 , 스트럿츠 등에 대한 업그레이드 여부
• 잘못된 XML 코드
• 문제가 되는 애플리케이션 코드에 대한 가이드
RHAMT – 기능
RHAMT – 마이그레이션 점검 샘플
• 스토리 포인트란
• 특정 Application Server에 종속적인 어플리케이션 코드
• 애자일 프로젝트에서 사용자 스토리나 기능 또는 어떤 작업의 규모를 표현하기 위하여 사용
되는 단위
• RHAMT 의 경우 스토리 포인트 1은 기술 숙련도에 따라 1시간 ~ 3시간으로 산정이 가능
• 전자정부프레임워크 • 웹로직 MedRec 샘플
RHAMT – 보고서 내용
• 변경 사항에 대한 상세한 내용
• 변경이 필수 또는 선택적인지 여부
RHAMT – 보고서 내용
• 변경이 복잡하거나 쉬운지 여부(Level of Effort)
• 마이그레이션에 필요한 변경을 위한 팁 및 정보에 대한 링크
CASE 1: WebLogic web application descriptor
(weblogic.xml)
• WebLogic Web application descriptor(weblogic.xml)은 JBoss web
application descriptor(jboss-web.xml)과 다르기 때문에 반드시 규격대로
변경을 해야 함
• WebLogic 에서 JBoss 으로 마이그레이션 작업 시 반드시 해야 함
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<security-role-assignment>
<role-name>WebRunAsRole</role-name>
<principal-name>Admin</principal-name>
</security-role-assignment>
<context-root>jee-example-web</context-root>
</weblogic-web-app>
• weblogic.xml (변경 전)
CASE 1: WebLogic web application descriptor
(weblogic.xml)
<?xml version='1.0' encoding='UTF-8'?>
<jboss-web>
<security-domain>java:/jboss-web-policy</security-domain>
<context-root>jee-example-web</context-root>
</jboss-web>
<security-domains>
<security-domain name="jboss-web-policy" cache-type="default">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
<security-domains>
CASE 1: WebLogic web application descriptor
(weblogic.xml)
• jboss-web.xml (변경 후)
• standalone.xml (security role 추가)
• 참조 링크 : https://access.redhat.com/articles/1327803
• WebLogic EAR application descriptor(weblogic-applicaion.xml)은
Deployment Descriptor file로 WebLogic EAR 아카이브를 설명 하는데 사용
되며, 이러한 Descriptor 요소에 대하여 직접 맵핑은 없지만 이러한 기능 중
많은 부분을 Standard Java EE 파일에 구성 할 수 있음
• JBoss에서 공동적인 요소를 맵핑 하는 방법은 web.xml에 context-param으
로 구성 하는 방법이다.
CASE 2: WebLogic EAR application descriptor
(weblogic-application.xml)
<application-param>
<description>Web application default encoding</description>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<context-param>
<description>Web application default encoding</description>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</context-param>
CASE 2: WebLogic EAR application descriptor
(weblogic-application.xml)
• weblogic-applicaion.xml (변경 전)
• web.xml에 context-param 값으로 설정(변경 후)
• 이 메소드는 JNDI를 사용하여 객체를 검색하며, JNDI 유형에 맞게 Jboss
EAP에서 변경이 필요한지 확인 이후 변경을 해야 한다.
CASE 3: Call of JNDI Lookup
• JAVA EE 플렛폼에 정의된 JNDI context
• Java:comp – 최근 구성요소에 대한 범위
• Java:module – 최근 모듈에 대한 범위
• Java:app – 최근 애플리케이션에 대한 범위
• Java:global – 애플리케이션 서버에 대한 범위
• JBoss에서 제공하는 2개의 global namespace
• Java:jboss/
• Java:/
CASE 3: Call of JNDI Lookup
• Weblogic에서는 T3 프로토콜 이라는 지정된 RMI 를 사용하며, Migration시
에 Source나 Properties에서 Jboss가 사용 할 수 있는 JNDI URL와 Factory
이름으로 변경 해야 함
CASE 4: WebLogic T3 JNDI binding
CASE 4: WebLogic T3 JNDI binding
Properties environment = new Properties();
environment.put("java.naming.factory.initial",
"weblogic.jndi.WLInitialContextFactory");
environment.put("java.naming.provider.url", "t3://localhost:7001");
Context context = new InitialContext(environment);
Properties environment = new Properties();
environment.put("java.naming.factory.initial","org.jboss.naming.remote.cl
ient.InitialContextFactory ");
environment.put("java.naming.provider.url", "remote://localhost:4447 ");
Context context = new InitialContext(environment);
• JNDI Binding (변경 전)
• JNDI Binding (변경 후)
• 참조 링크 : https://access.redhat.com/documentation/en-
us/red_hat_jboss_enterprise_application_platform/6.4/html/development_guide/configuring_a
_remote_jndi_client
CASE 5: WebLogic EJB XML (weblogic-ejb-jar.xml)
• JNDI Binding (변경 전) EJB 2.x 버전에서는 EJB Deployment Descriptor가
필요
• ejb-jar.xml 파일은 표준 EJB Deployment Descriptor 파일이며, 각 WAS 마
다 별도의 Descriptor를 설정 필요
• Weblogic에서 사용하는 ejb 설정 파일을 jboss-ejb 파일로 변경을 해야함
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>ItemLookupBean</ejb-name>
<stateless-session-descriptor>
</stateless-session-descriptor>
<transaction-descriptor>
<trans-timeout-seconds>180</trans-timeout-seconds>
</transaction-descriptor>
<enable-call-by-reference>true</enable-call-by-reference>
<run-as-principal-name>Admin</run-as-principal-name>
<jndi-name>ejb/ItemLookupBean</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
CASE 5: WebLogic EJB XML (weblogic-ejb-jar.xml)
• weblogic-ejb-jar.xml (변경 전)
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar>
<enterprise-beans>
<session>
<ejb-name>ItemLookupBean</ejb-name>
<jndi-name>ejb/ItemLookupBean</jndi-name>
<method-attributes>
<method>
<method-name>*</method-name>
<transaction-timeout>180</transaction-
timeout>
</method>
</session>
</enterprise-beans>
</jboss:ejb-jar>
CASE 5: WebLogic EJB XML (weblogic-ejb-jar.xml)
• jboss-ejb.xml (변경 전)
Opennaru, Inc. © 2016 | All Rights Reserved.- Confidential -
Opennaru, Inc. © 2016 | All Rights Reserved.- Confidential -
제품이나 서비스에 관한 문의
콜 센터 :02-469-5426 ( 휴대폰 : 010-2243-3394 )
전자메일:sales@opennaru.com
Opennaru, Inc. © 2016 | All Rights Reserved.- Confidential -

Weitere ähnliche Inhalte

Ähnlich wie RHAMT 소개

[개방형 클라우드 플랫폼 오픈세미나 오픈클라우드 Pub] 3.open shift 분석
[개방형 클라우드 플랫폼 오픈세미나 오픈클라우드 Pub] 3.open shift 분석[개방형 클라우드 플랫폼 오픈세미나 오픈클라우드 Pub] 3.open shift 분석
[개방형 클라우드 플랫폼 오픈세미나 오픈클라우드 Pub] 3.open shift 분석Tommy Lee
 
HTML5 스펙 소개
HTML5 스펙 소개HTML5 스펙 소개
HTML5 스펙 소개Toby Yun
 
Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos uEngine Solutions
 
[오픈소스컨설팅] OpenShift PaaS Platform How-to
[오픈소스컨설팅] OpenShift PaaS Platform How-to[오픈소스컨설팅] OpenShift PaaS Platform How-to
[오픈소스컨설팅] OpenShift PaaS Platform How-toJi-Woong Choi
 
04.실행환경 교육교재(화면처리)
04.실행환경 교육교재(화면처리)04.실행환경 교육교재(화면처리)
04.실행환경 교육교재(화면처리)Hankyo
 
[웨비나] 클라우드 마이그레이션 수행 시 가장 많이 하는 질문 Top 10!
[웨비나] 클라우드 마이그레이션 수행 시 가장 많이 하는 질문 Top 10![웨비나] 클라우드 마이그레이션 수행 시 가장 많이 하는 질문 Top 10!
[웨비나] 클라우드 마이그레이션 수행 시 가장 많이 하는 질문 Top 10!Open Source Consulting
 
Openshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud NativeOpenshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud Nativerockplace
 
애플리케이션 최적화를 위한 컨테이너 인프라 구축
애플리케이션 최적화를 위한 컨테이너 인프라 구축애플리케이션 최적화를 위한 컨테이너 인프라 구축
애플리케이션 최적화를 위한 컨테이너 인프라 구축rockplace
 
Infra as Code with Packer, Ansible and Terraform
Infra as Code with Packer, Ansible and TerraformInfra as Code with Packer, Ansible and Terraform
Infra as Code with Packer, Ansible and TerraformInho Kang
 
Open standard open cloud engine (3)
Open standard open cloud engine (3)Open standard open cloud engine (3)
Open standard open cloud engine (3)uEngine Solutions
 
마이크로서비스 아키텍처로 개발하기
마이크로서비스 아키텍처로 개발하기마이크로서비스 아키텍처로 개발하기
마이크로서비스 아키텍처로 개발하기Jaewoo Ahn
 
MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?
MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?
MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?VMware Tanzu Korea
 
01.개발환경 교육교재
01.개발환경 교육교재01.개발환경 교육교재
01.개발환경 교육교재Hankyo
 
JBoss RHQ와 Byteman을 이용한 오픈소스 자바 애플리케이션 모니터링
JBoss RHQ와 Byteman을 이용한 오픈소스 자바 애플리케이션 모니터링JBoss RHQ와 Byteman을 이용한 오픈소스 자바 애플리케이션 모니터링
JBoss RHQ와 Byteman을 이용한 오픈소스 자바 애플리케이션 모니터링Ted Won
 
Application Monitoring 신규 기능 소개 (서영일)
Application Monitoring 신규 기능 소개 (서영일)Application Monitoring 신규 기능 소개 (서영일)
Application Monitoring 신규 기능 소개 (서영일)WhaTap Labs
 
멀티클라우드 Service Mesh
멀티클라우드 Service Mesh멀티클라우드 Service Mesh
멀티클라우드 Service MeshJeong-Ho Na
 
01.모바일 프레임워크 이론
01.모바일 프레임워크 이론01.모바일 프레임워크 이론
01.모바일 프레임워크 이론Hankyo
 
Cloud life seminar open shift,이준영(배포용)
Cloud life seminar   open shift,이준영(배포용)Cloud life seminar   open shift,이준영(배포용)
Cloud life seminar open shift,이준영(배포용)Software in Life
 
Meetup tools for-cloud_native_apps_meetup20180510-vs
Meetup tools for-cloud_native_apps_meetup20180510-vsMeetup tools for-cloud_native_apps_meetup20180510-vs
Meetup tools for-cloud_native_apps_meetup20180510-vsminseok kim
 

Ähnlich wie RHAMT 소개 (20)

[개방형 클라우드 플랫폼 오픈세미나 오픈클라우드 Pub] 3.open shift 분석
[개방형 클라우드 플랫폼 오픈세미나 오픈클라우드 Pub] 3.open shift 분석[개방형 클라우드 플랫폼 오픈세미나 오픈클라우드 Pub] 3.open shift 분석
[개방형 클라우드 플랫폼 오픈세미나 오픈클라우드 Pub] 3.open shift 분석
 
HTML5 스펙 소개
HTML5 스펙 소개HTML5 스펙 소개
HTML5 스펙 소개
 
Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos
 
[오픈소스컨설팅] OpenShift PaaS Platform How-to
[오픈소스컨설팅] OpenShift PaaS Platform How-to[오픈소스컨설팅] OpenShift PaaS Platform How-to
[오픈소스컨설팅] OpenShift PaaS Platform How-to
 
04.실행환경 교육교재(화면처리)
04.실행환경 교육교재(화면처리)04.실행환경 교육교재(화면처리)
04.실행환경 교육교재(화면처리)
 
[웨비나] 클라우드 마이그레이션 수행 시 가장 많이 하는 질문 Top 10!
[웨비나] 클라우드 마이그레이션 수행 시 가장 많이 하는 질문 Top 10![웨비나] 클라우드 마이그레이션 수행 시 가장 많이 하는 질문 Top 10!
[웨비나] 클라우드 마이그레이션 수행 시 가장 많이 하는 질문 Top 10!
 
Openshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud NativeOpenshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud Native
 
애플리케이션 최적화를 위한 컨테이너 인프라 구축
애플리케이션 최적화를 위한 컨테이너 인프라 구축애플리케이션 최적화를 위한 컨테이너 인프라 구축
애플리케이션 최적화를 위한 컨테이너 인프라 구축
 
Infra as Code with Packer, Ansible and Terraform
Infra as Code with Packer, Ansible and TerraformInfra as Code with Packer, Ansible and Terraform
Infra as Code with Packer, Ansible and Terraform
 
Open standard open cloud engine (3)
Open standard open cloud engine (3)Open standard open cloud engine (3)
Open standard open cloud engine (3)
 
마이크로서비스 아키텍처로 개발하기
마이크로서비스 아키텍처로 개발하기마이크로서비스 아키텍처로 개발하기
마이크로서비스 아키텍처로 개발하기
 
MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?
MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?
MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?
 
01.개발환경 교육교재
01.개발환경 교육교재01.개발환경 교육교재
01.개발환경 교육교재
 
JBoss RHQ와 Byteman을 이용한 오픈소스 자바 애플리케이션 모니터링
JBoss RHQ와 Byteman을 이용한 오픈소스 자바 애플리케이션 모니터링JBoss RHQ와 Byteman을 이용한 오픈소스 자바 애플리케이션 모니터링
JBoss RHQ와 Byteman을 이용한 오픈소스 자바 애플리케이션 모니터링
 
Application Monitoring 신규 기능 소개 (서영일)
Application Monitoring 신규 기능 소개 (서영일)Application Monitoring 신규 기능 소개 (서영일)
Application Monitoring 신규 기능 소개 (서영일)
 
멀티클라우드 Service Mesh
멀티클라우드 Service Mesh멀티클라우드 Service Mesh
멀티클라우드 Service Mesh
 
2015 oce specification
2015 oce specification2015 oce specification
2015 oce specification
 
01.모바일 프레임워크 이론
01.모바일 프레임워크 이론01.모바일 프레임워크 이론
01.모바일 프레임워크 이론
 
Cloud life seminar open shift,이준영(배포용)
Cloud life seminar   open shift,이준영(배포용)Cloud life seminar   open shift,이준영(배포용)
Cloud life seminar open shift,이준영(배포용)
 
Meetup tools for-cloud_native_apps_meetup20180510-vs
Meetup tools for-cloud_native_apps_meetup20180510-vsMeetup tools for-cloud_native_apps_meetup20180510-vs
Meetup tools for-cloud_native_apps_meetup20180510-vs
 

Mehr von Opennaru, inc.

머신 중심에서 애플리케이션 중심으로 불변의 인프라스트럭처 개념 이해
머신 중심에서 애플리케이션 중심으로 불변의 인프라스트럭처 개념 이해머신 중심에서 애플리케이션 중심으로 불변의 인프라스트럭처 개념 이해
머신 중심에서 애플리케이션 중심으로 불변의 인프라스트럭처 개념 이해Opennaru, inc.
 
쿠버네티스를 이해하려면 반드시 알아야 하는 불변의 인프라스트럭처
쿠버네티스를 이해하려면 반드시 알아야 하는 불변의 인프라스트럭처쿠버네티스를 이해하려면 반드시 알아야 하는 불변의 인프라스트럭처
쿠버네티스를 이해하려면 반드시 알아야 하는 불변의 인프라스트럭처Opennaru, inc.
 
컨테이너 기술의 역사와 발전 단계
컨테이너 기술의 역사와 발전 단계컨테이너 기술의 역사와 발전 단계
컨테이너 기술의 역사와 발전 단계Opennaru, inc.
 
구글은 왜 쿠버네티스를 오픈소스로 공개했을까요?
구글은 왜 쿠버네티스를 오픈소스로 공개했을까요?구글은 왜 쿠버네티스를 오픈소스로 공개했을까요?
구글은 왜 쿠버네티스를 오픈소스로 공개했을까요?Opennaru, inc.
 
컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점Opennaru, inc.
 
컨테이너 개념의 이해 - 물류 분야의 컨테이너와 다른점은?
컨테이너 개념의 이해 - 물류 분야의 컨테이너와 다른점은?컨테이너 개념의 이해 - 물류 분야의 컨테이너와 다른점은?
컨테이너 개념의 이해 - 물류 분야의 컨테이너와 다른점은?Opennaru, inc.
 
VM과 컨테이너 상에서 Apache & Tomcat 설치, 실행 그리고 배포 데모
VM과 컨테이너 상에서 Apache & Tomcat 설치, 실행 그리고 배포 데모VM과 컨테이너 상에서 Apache & Tomcat 설치, 실행 그리고 배포 데모
VM과 컨테이너 상에서 Apache & Tomcat 설치, 실행 그리고 배포 데모Opennaru, inc.
 
가상화 기술 VS 컨테이너의 집적도 비교 데모
가상화 기술 VS 컨테이너의 집적도 비교 데모가상화 기술 VS 컨테이너의 집적도 비교 데모
가상화 기술 VS 컨테이너의 집적도 비교 데모Opennaru, inc.
 
PaaS 환경에서 기업 메신저 서비스 10분 만에 구축하기 데모
PaaS 환경에서 기업 메신저 서비스 10분 만에 구축하기 데모PaaS 환경에서 기업 메신저 서비스 10분 만에 구축하기 데모
PaaS 환경에서 기업 메신저 서비스 10분 만에 구축하기 데모Opennaru, inc.
 
마이크로서비스 아키텍처 (MSA) 데모
마이크로서비스 아키텍처 (MSA) 데모마이크로서비스 아키텍처 (MSA) 데모
마이크로서비스 아키텍처 (MSA) 데모Opennaru, inc.
 
클라우드 환경에서의 모니터링의 특징과 구현 방안 로그통합
클라우드 환경에서의 모니터링의 특징과 구현 방안 로그통합클라우드 환경에서의 모니터링의 특징과 구현 방안 로그통합
클라우드 환경에서의 모니터링의 특징과 구현 방안 로그통합Opennaru, inc.
 
컨테이너 상에서의 서비스 무중단 배포 방법 비교 데모
컨테이너 상에서의 서비스 무중단 배포 방법 비교 데모컨테이너 상에서의 서비스 무중단 배포 방법 비교 데모
컨테이너 상에서의 서비스 무중단 배포 방법 비교 데모Opennaru, inc.
 
자동 확장 자원 풀 – Auto Scaling 데모
자동 확장 자원 풀 – Auto Scaling 데모자동 확장 자원 풀 – Auto Scaling 데모
자동 확장 자원 풀 – Auto Scaling 데모Opennaru, inc.
 
자동 장애 복구 데모 – Auto Healing 데모
자동 장애 복구 데모 – Auto Healing 데모자동 장애 복구 데모 – Auto Healing 데모
자동 장애 복구 데모 – Auto Healing 데모Opennaru, inc.
 
멀티 애플리케이션 환경에서 부하에 따른 자동 자원 할당 데모
멀티 애플리케이션 환경에서 부하에 따른 자동 자원 할당 데모멀티 애플리케이션 환경에서 부하에 따른 자동 자원 할당 데모
멀티 애플리케이션 환경에서 부하에 따른 자동 자원 할당 데모Opennaru, inc.
 
PaaS 환경에서 전자 정부 프레임워크 배포 데모
PaaS 환경에서 전자 정부 프레임워크 배포 데모PaaS 환경에서 전자 정부 프레임워크 배포 데모
PaaS 환경에서 전자 정부 프레임워크 배포 데모Opennaru, inc.
 
PaaS 환경에서 워드프레스 구축하기 데모
PaaS 환경에서 워드프레스 구축하기 데모PaaS 환경에서 워드프레스 구축하기 데모
PaaS 환경에서 워드프레스 구축하기 데모Opennaru, inc.
 
PaaS 환경에서 다중 사용자를 위한 머신 러닝 플랫폼 구축 데모
PaaS 환경에서 다중 사용자를 위한  머신 러닝 플랫폼 구축 데모PaaS 환경에서 다중 사용자를 위한  머신 러닝 플랫폼 구축 데모
PaaS 환경에서 다중 사용자를 위한 머신 러닝 플랫폼 구축 데모Opennaru, inc.
 
16. understanding and implementing msa concepts pub
16. understanding and implementing msa concepts pub16. understanding and implementing msa concepts pub
16. understanding and implementing msa concepts pubOpennaru, inc.
 
개발자가 PaaS 환경에서 반드시 알아야 하는 기술들
개발자가 PaaS 환경에서 반드시 알아야 하는 기술들개발자가 PaaS 환경에서 반드시 알아야 하는 기술들
개발자가 PaaS 환경에서 반드시 알아야 하는 기술들Opennaru, inc.
 

Mehr von Opennaru, inc. (20)

머신 중심에서 애플리케이션 중심으로 불변의 인프라스트럭처 개념 이해
머신 중심에서 애플리케이션 중심으로 불변의 인프라스트럭처 개념 이해머신 중심에서 애플리케이션 중심으로 불변의 인프라스트럭처 개념 이해
머신 중심에서 애플리케이션 중심으로 불변의 인프라스트럭처 개념 이해
 
쿠버네티스를 이해하려면 반드시 알아야 하는 불변의 인프라스트럭처
쿠버네티스를 이해하려면 반드시 알아야 하는 불변의 인프라스트럭처쿠버네티스를 이해하려면 반드시 알아야 하는 불변의 인프라스트럭처
쿠버네티스를 이해하려면 반드시 알아야 하는 불변의 인프라스트럭처
 
컨테이너 기술의 역사와 발전 단계
컨테이너 기술의 역사와 발전 단계컨테이너 기술의 역사와 발전 단계
컨테이너 기술의 역사와 발전 단계
 
구글은 왜 쿠버네티스를 오픈소스로 공개했을까요?
구글은 왜 쿠버네티스를 오픈소스로 공개했을까요?구글은 왜 쿠버네티스를 오픈소스로 공개했을까요?
구글은 왜 쿠버네티스를 오픈소스로 공개했을까요?
 
컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점
 
컨테이너 개념의 이해 - 물류 분야의 컨테이너와 다른점은?
컨테이너 개념의 이해 - 물류 분야의 컨테이너와 다른점은?컨테이너 개념의 이해 - 물류 분야의 컨테이너와 다른점은?
컨테이너 개념의 이해 - 물류 분야의 컨테이너와 다른점은?
 
VM과 컨테이너 상에서 Apache & Tomcat 설치, 실행 그리고 배포 데모
VM과 컨테이너 상에서 Apache & Tomcat 설치, 실행 그리고 배포 데모VM과 컨테이너 상에서 Apache & Tomcat 설치, 실행 그리고 배포 데모
VM과 컨테이너 상에서 Apache & Tomcat 설치, 실행 그리고 배포 데모
 
가상화 기술 VS 컨테이너의 집적도 비교 데모
가상화 기술 VS 컨테이너의 집적도 비교 데모가상화 기술 VS 컨테이너의 집적도 비교 데모
가상화 기술 VS 컨테이너의 집적도 비교 데모
 
PaaS 환경에서 기업 메신저 서비스 10분 만에 구축하기 데모
PaaS 환경에서 기업 메신저 서비스 10분 만에 구축하기 데모PaaS 환경에서 기업 메신저 서비스 10분 만에 구축하기 데모
PaaS 환경에서 기업 메신저 서비스 10분 만에 구축하기 데모
 
마이크로서비스 아키텍처 (MSA) 데모
마이크로서비스 아키텍처 (MSA) 데모마이크로서비스 아키텍처 (MSA) 데모
마이크로서비스 아키텍처 (MSA) 데모
 
클라우드 환경에서의 모니터링의 특징과 구현 방안 로그통합
클라우드 환경에서의 모니터링의 특징과 구현 방안 로그통합클라우드 환경에서의 모니터링의 특징과 구현 방안 로그통합
클라우드 환경에서의 모니터링의 특징과 구현 방안 로그통합
 
컨테이너 상에서의 서비스 무중단 배포 방법 비교 데모
컨테이너 상에서의 서비스 무중단 배포 방법 비교 데모컨테이너 상에서의 서비스 무중단 배포 방법 비교 데모
컨테이너 상에서의 서비스 무중단 배포 방법 비교 데모
 
자동 확장 자원 풀 – Auto Scaling 데모
자동 확장 자원 풀 – Auto Scaling 데모자동 확장 자원 풀 – Auto Scaling 데모
자동 확장 자원 풀 – Auto Scaling 데모
 
자동 장애 복구 데모 – Auto Healing 데모
자동 장애 복구 데모 – Auto Healing 데모자동 장애 복구 데모 – Auto Healing 데모
자동 장애 복구 데모 – Auto Healing 데모
 
멀티 애플리케이션 환경에서 부하에 따른 자동 자원 할당 데모
멀티 애플리케이션 환경에서 부하에 따른 자동 자원 할당 데모멀티 애플리케이션 환경에서 부하에 따른 자동 자원 할당 데모
멀티 애플리케이션 환경에서 부하에 따른 자동 자원 할당 데모
 
PaaS 환경에서 전자 정부 프레임워크 배포 데모
PaaS 환경에서 전자 정부 프레임워크 배포 데모PaaS 환경에서 전자 정부 프레임워크 배포 데모
PaaS 환경에서 전자 정부 프레임워크 배포 데모
 
PaaS 환경에서 워드프레스 구축하기 데모
PaaS 환경에서 워드프레스 구축하기 데모PaaS 환경에서 워드프레스 구축하기 데모
PaaS 환경에서 워드프레스 구축하기 데모
 
PaaS 환경에서 다중 사용자를 위한 머신 러닝 플랫폼 구축 데모
PaaS 환경에서 다중 사용자를 위한  머신 러닝 플랫폼 구축 데모PaaS 환경에서 다중 사용자를 위한  머신 러닝 플랫폼 구축 데모
PaaS 환경에서 다중 사용자를 위한 머신 러닝 플랫폼 구축 데모
 
16. understanding and implementing msa concepts pub
16. understanding and implementing msa concepts pub16. understanding and implementing msa concepts pub
16. understanding and implementing msa concepts pub
 
개발자가 PaaS 환경에서 반드시 알아야 하는 기술들
개발자가 PaaS 환경에서 반드시 알아야 하는 기술들개발자가 PaaS 환경에서 반드시 알아야 하는 기술들
개발자가 PaaS 환경에서 반드시 알아야 하는 기술들
 

RHAMT 소개

  • 1. RHAMT 소개 (Red Hat Application Migration Toolkit)
  • 3. Opennaru, Inc. © 2016 | All Rights Reserved.- Confidential - 3티어 아키텍처 – 2000년대
  • 4. 4티어 아키텍처 – 2010년 이후
  • 6. Unix To Linux 전환의 필요성
  • 9. JDK 및 WAS 업그레이드
  • 12. • RHAMT(Red Hat Application Migration Toolkit)은 오픈소스 커뮤니티인 Windup의 Red Hat 컨설턴트 팀에 의해 개발 • CLI, Web Console, Eclipse-plugin 3가지 방식을 지원 • Java 애플리케이션을 분석하고 Java Code, JSP, XML들에 대하여 수정이 필요한 부분을 HTML 형식으로 Report 출력 Red Hat Application Migration Toolkit JBoss Windup is a tool to simplify application migrations. Running from the command line, the tool reads EAR, WAR and JAR files. and produces an HTML report detailing the inner workings of the Java application to simplify migration efforts. – Windup ( https://github.com/windup/)
  • 13. • CLI • Command Line을 사용하여 마이그레이션이 필요한 소스를 분석이 가능 • Web Console • WEB 기반으로 되어있으며 Web Console의 통하여 분석이 필요한 소스들을 관리가 가능 • 각각 프로젝트별로 소스를 분리 할 수 있으며 여러 개발자들이 동시에 관리 및 분석 가 • Eclipse-Plugin • Eclipse와 JBoss Developer Studio에서 사용 가능한 플러그인 을 제공하여 소스 개발 중 변경 해야 할 이슈 부 분을 IDE에서 바로 확인 가능한 것이 장점 RHAMT – Tools
  • 14. • CLI는 아래 링크에서 다운로드 받을 수 있으며, Linux, Window 두 플랫폼에서 다 실행 이 가능 • Download 링크 : https://developers.redhat.com/download- manager/file/4.0.0/migrationtoolkit-rhamt-cli-4.0.0.offline.zip RHAMT – CLI • 실행 화면 1. 압축 해제 #unzip migrationtoolkit-rhamt-cli-4.0.0.offline.zip 2. 디렉토리 이동 #cd rhamt-cli-4.0.0.Final 3. 스크립트 실행 #./bin/rhamt-cli --input ~/egovframework-all-in- one.war --output ~/test --source spring -target eap:7
  • 15. • Report 화면 • Report 화면에서는 전체적인 summary를 출력 RHAMT – CLI • 분석된 화면 • 애플리케이션을 선택 하면, 위와 같이 전체 적인 Menu가 나오며 변경 해야 할 가이드 내용을 확인 가능
  • 16. RHAMT – WEB Console 1. 압축 해제 #unzip migrationtoolkit-rhamt-web-distribution- 4.0.0.with-authentication.zip 2. 디렉토리 이동 #cd rhamt-web-distribution-4.0.0.Final 3. 스크립트 실행 #./run_rhamt.sh 4. WEB Console 접속 http://localhost:8080/rhamt-web • WEB Console는 아래 링크에서 다운로드 받을수 있으며, Linux, Window 두 플랫폼에 서 다 실행이 가능 • Download 링크: https://developers.redhat.com/download- manager/file/4.0.0/migrationtoolkit-rhamt-web-distribution-4.0.0.with- authentication.zip • 실행 화면
  • 17. RHAMT – WEB Console • Project 생성 • Project를 생성하여 해당 프로젝 트에서 등록된 애플리케이션을 관리가 가능 • 애플리케이션 분석 • Project에 등록된 애플리케이션 은 Run Analysis를 클릭하면 바 로 분석을 진행
  • 18. RHAMT – WEB Console • 분석 설정 • 어느 애플리케이션을 분석 할지, 어느 JBoss 버전으로 마이그레이 션할지 설정이 가능 • Rules 설정 • 직접 마이그레이션에 대한 Rule 을 정의 하고 싶으면 Rules Configuration에서 설정이 가능
  • 19. • Eclipse-plugin은 Eclipse에서 Plugin을 설치 하여 사용 • Plugin 링크 : http://download.jboss.org/jbosstools/oxygen/development/updates/rhamt/comp osite/ RHAMT – Eclipse-Plugin • 설치 화면 • Plugin 설치는 위에 링크를 등록 하면 자동적으로 설치 • RHAMT RUN • 원하는 애플리케이션을 선택 후 분석 하기 위해 RHAMT를 실행
  • 20. RHAMT – Eclipse-Plugin • Issue Explorer • Issue Explorer에서는 해당 애플리케이션에서 발생된 Issue 리스트를 제 공하며, 해당 이슈에서 더 제사한 내용도 확인 가능
  • 21. RHAMT – Eclipse-Plugin • Issue Details • Issue Details에서는 해당 애플리케이션의 Code나 Config 파일에서 변경 해야 할 부분은 자세히 가이드
  • 22. • RHAMT에서 식별 대상 • 특정 Application Server에 종속적인 어플리케이션 코드 • Java 코드 중 더 이상 사용할 수 없는 코드 (Deprecated Java code) • 비표준 -JMS 메시징 코드 • 웹서비스 식별 • EJB 버전 (2 / 3) 식별 • 하이버네이트, 스프링 , 스트럿츠 등에 대한 업그레이드 여부 • 잘못된 XML 코드 • 문제가 되는 애플리케이션 코드에 대한 가이드 RHAMT – 기능
  • 23. RHAMT – 마이그레이션 점검 샘플 • 스토리 포인트란 • 특정 Application Server에 종속적인 어플리케이션 코드 • 애자일 프로젝트에서 사용자 스토리나 기능 또는 어떤 작업의 규모를 표현하기 위하여 사용 되는 단위 • RHAMT 의 경우 스토리 포인트 1은 기술 숙련도에 따라 1시간 ~ 3시간으로 산정이 가능 • 전자정부프레임워크 • 웹로직 MedRec 샘플
  • 24. RHAMT – 보고서 내용 • 변경 사항에 대한 상세한 내용 • 변경이 필수 또는 선택적인지 여부
  • 25. RHAMT – 보고서 내용 • 변경이 복잡하거나 쉬운지 여부(Level of Effort) • 마이그레이션에 필요한 변경을 위한 팁 및 정보에 대한 링크
  • 26.
  • 27. CASE 1: WebLogic web application descriptor (weblogic.xml) • WebLogic Web application descriptor(weblogic.xml)은 JBoss web application descriptor(jboss-web.xml)과 다르기 때문에 반드시 규격대로 변경을 해야 함 • WebLogic 에서 JBoss 으로 마이그레이션 작업 시 반드시 해야 함
  • 28. <?xml version='1.0' encoding='UTF-8'?> <weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <security-role-assignment> <role-name>WebRunAsRole</role-name> <principal-name>Admin</principal-name> </security-role-assignment> <context-root>jee-example-web</context-root> </weblogic-web-app> • weblogic.xml (변경 전) CASE 1: WebLogic web application descriptor (weblogic.xml)
  • 29. <?xml version='1.0' encoding='UTF-8'?> <jboss-web> <security-domain>java:/jboss-web-policy</security-domain> <context-root>jee-example-web</context-root> </jboss-web> <security-domains> <security-domain name="jboss-web-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> <security-domains> CASE 1: WebLogic web application descriptor (weblogic.xml) • jboss-web.xml (변경 후) • standalone.xml (security role 추가) • 참조 링크 : https://access.redhat.com/articles/1327803
  • 30. • WebLogic EAR application descriptor(weblogic-applicaion.xml)은 Deployment Descriptor file로 WebLogic EAR 아카이브를 설명 하는데 사용 되며, 이러한 Descriptor 요소에 대하여 직접 맵핑은 없지만 이러한 기능 중 많은 부분을 Standard Java EE 파일에 구성 할 수 있음 • JBoss에서 공동적인 요소를 맵핑 하는 방법은 web.xml에 context-param으 로 구성 하는 방법이다. CASE 2: WebLogic EAR application descriptor (weblogic-application.xml)
  • 31. <application-param> <description>Web application default encoding</description> <param-name>webapp.encoding.default</param-name> <param-value>UTF-8</param-value> </application-param> <context-param> <description>Web application default encoding</description> <param-name>webapp.encoding.default</param-name> <param-value>UTF-8</param-value> </context-param> CASE 2: WebLogic EAR application descriptor (weblogic-application.xml) • weblogic-applicaion.xml (변경 전) • web.xml에 context-param 값으로 설정(변경 후)
  • 32. • 이 메소드는 JNDI를 사용하여 객체를 검색하며, JNDI 유형에 맞게 Jboss EAP에서 변경이 필요한지 확인 이후 변경을 해야 한다. CASE 3: Call of JNDI Lookup
  • 33. • JAVA EE 플렛폼에 정의된 JNDI context • Java:comp – 최근 구성요소에 대한 범위 • Java:module – 최근 모듈에 대한 범위 • Java:app – 최근 애플리케이션에 대한 범위 • Java:global – 애플리케이션 서버에 대한 범위 • JBoss에서 제공하는 2개의 global namespace • Java:jboss/ • Java:/ CASE 3: Call of JNDI Lookup
  • 34. • Weblogic에서는 T3 프로토콜 이라는 지정된 RMI 를 사용하며, Migration시 에 Source나 Properties에서 Jboss가 사용 할 수 있는 JNDI URL와 Factory 이름으로 변경 해야 함 CASE 4: WebLogic T3 JNDI binding
  • 35. CASE 4: WebLogic T3 JNDI binding Properties environment = new Properties(); environment.put("java.naming.factory.initial", "weblogic.jndi.WLInitialContextFactory"); environment.put("java.naming.provider.url", "t3://localhost:7001"); Context context = new InitialContext(environment); Properties environment = new Properties(); environment.put("java.naming.factory.initial","org.jboss.naming.remote.cl ient.InitialContextFactory "); environment.put("java.naming.provider.url", "remote://localhost:4447 "); Context context = new InitialContext(environment); • JNDI Binding (변경 전) • JNDI Binding (변경 후) • 참조 링크 : https://access.redhat.com/documentation/en- us/red_hat_jboss_enterprise_application_platform/6.4/html/development_guide/configuring_a _remote_jndi_client
  • 36. CASE 5: WebLogic EJB XML (weblogic-ejb-jar.xml) • JNDI Binding (변경 전) EJB 2.x 버전에서는 EJB Deployment Descriptor가 필요 • ejb-jar.xml 파일은 표준 EJB Deployment Descriptor 파일이며, 각 WAS 마 다 별도의 Descriptor를 설정 필요 • Weblogic에서 사용하는 ejb 설정 파일을 jboss-ejb 파일로 변경을 해야함
  • 37. <?xml version="1.0" encoding="UTF-8"?> <weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd"> <weblogic-enterprise-bean> <ejb-name>ItemLookupBean</ejb-name> <stateless-session-descriptor> </stateless-session-descriptor> <transaction-descriptor> <trans-timeout-seconds>180</trans-timeout-seconds> </transaction-descriptor> <enable-call-by-reference>true</enable-call-by-reference> <run-as-principal-name>Admin</run-as-principal-name> <jndi-name>ejb/ItemLookupBean</jndi-name> </weblogic-enterprise-bean> </weblogic-ejb-jar> CASE 5: WebLogic EJB XML (weblogic-ejb-jar.xml) • weblogic-ejb-jar.xml (변경 전)
  • 39. Opennaru, Inc. © 2016 | All Rights Reserved.- Confidential -
  • 40. Opennaru, Inc. © 2016 | All Rights Reserved.- Confidential - 제품이나 서비스에 관한 문의 콜 센터 :02-469-5426 ( 휴대폰 : 010-2243-3394 ) 전자메일:sales@opennaru.com
  • 41. Opennaru, Inc. © 2016 | All Rights Reserved.- Confidential -

Hinweis der Redaktion

  1. 1. 개발방법, 애플리케이션 아키텍처, 배포, 인프라 4가지 프로세스가 있고 위에는 방식 부터 아래 까지 사용 되었었습니다. 그러면 새로운 프로젝트시에 어떤 방식을 사용 하실 건가요?
  2. 2000년대에는 모노리틱 아키텍처를 사용 하였으며, 비싼 Unix box 2대에서 전체 서비스를 올려서 서비스가 죽지 않게 운영하는게 목표였기 때문에 고가용성이 나오지 않음
  3. 3. 2010년 이후 에는 확장이 가능한 아키텍처를 사용하기 위해 작은 x86 여러 대에 여러 인스턴스를 올려서 운영 하며, 멀티 디바이스와 옴니 채널 대응 가능한 REST를 많이 사용하는 방식으로 변경 되어가고 있습니다.
  4. 현재는 Unix와 Linux 기술적 차이를 가리기 힘든 상태 Unix의 경우 해당 밴더의 H/W, S/W 상의 UNIX만 지원 리눅스의 경우 H/W 플랫폼을 지원 리눅스에서는 오픈소스에 대한 제약이 없음
  5. 장비 밴더 종속적으로 고비용 유지보수 비용이 들음 OS가 장비 CPU chip에 의존적이며, 장비가 많이 비쌈
  6. 4개의 프로세스가 있으며 모든분들이 아시는 분석, 구축, 전환 및 성능 최적화, 운영 전환 프로세스로 갑니다.
  7. 현재 구성을 AIX 기반으로 사용 할때에 똑같은 독점 스프트웨어로 가실지 아니면 유상 오픈소스로 가실지 아님 무상 오픈 소스로 가실지 여러분을 선택입니다.
  8. 1.4, 1.5 JDK 버전에서는 최신 아키텍처나 spring boot같은 프레임 워크를 사용 할 수 없습니다. 이러한 기술을 도입 하기 위해서는 JDK 및 WAS가 업그레이드 되어야 합니다.
  9. 마이그레이션에서 가장 중요한것은 운영환경과 애플리케이션 환경을 따로 분리하여 고려해야 합니다. OS/WAS를 마이그레이션을 한다고 해도 애플리케이션이 정상적으로 기동 되는 것이 아니며, 애플리케이션도 환경에 맞게 마이그레이션을 해야지 성공적인 마이그레이션이 될 수 있습니다.
  10. 마이그레이션 프로젝트에서 지금 현재 중요도와 비용를 고려하였을때 비용측면에서는 장비도입/구축이 80%이고 애플리케이션 이관이 20%일때, 중요도 측면에서는 장비도입/구축이 20%이며 애플리케이션이 80%를 차지 합니다. 마이그레이션을 성공적으로 수행하려면 중요도 측면도 고려를 해야합니다.
  11. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  12. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  13. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  14. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  15. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  16. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  17. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  18. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  19. RHAMT 는 3가지 Tools 를 제공 CLI, Web Console, Eclipse-Plugin CLI는 간단히 커맨드 라인을 사용하여 파이그레이션이 필요한 소스를 분석 분석시 Report 형식의 HTML 파일을 제공 Web Console기반은 Web 기반으로 되어 있으며 web console을 통하여 분석이 필요한 소스들을 등록하여 프로젝트별로 소스를 분리 가능하며 여러 사람들이 동시에 관리 및 분석이 가능 Eclipse-Plugin의 경우 소스 개발 중에 변경 해야 할 이슈 부분을 Eclipse에서 바로 확인이 가능.
  20. 식별대상의 경우 따로 Role을 만들어서 편집이 가능하며, 일반적으로 위와 같이 식별하여 변경되어야 할 부분을 가이드 해줍니다.
  21. 마이그레이션 툴을 이미지와 같이 분석하여 어느정도 기술 숙련도가 필요한지 얼마나 시간이 걸리는지 산정 할수 있도록 도움을 줍니다.
  22. 보고서 내용에는 변경해야할 부분에 대한 상세한 내용이 있으며 어떻게 변경을 해야하며 어느 문서를 참조해야할지 링크도 같이 제공 합니다. 또한 변경되어야 할 부분이 필수적인지 아니면 선택적인지 여부도 분리가 되어 확인 가능합니다.
  23. 변경에 대한 복잡도를 가이드 해주며 코드를 변경 해야 할 코드나 설정 부분에 대하여 참조에 도움이 될 가이드 링크를 알려줍니다.
  24. Weblogic 에서 Jboss로 변경시 가장 많이 나오는 이슈를 5가지에 대하여 간단히 설명 드리겠습니다. 이 캐이스는 소스 변경 보단 WAS를 변경 후 반드시 변경 해야 할 사항 위주로 선정하였습니다.
  25. 첫번째 케이스는 Web application descriptor 파일 변경 부분입니다. Weblogic 과 Jboss의 web application descriptor 설정 규격이 다르기 때문에 반드시 변경해야 합니다. 해당 이미지는 RHAMT에서 소스 분석시 가이드를 해주는 내용 입니다. 어떻게 변경하는지는 아래의 링크를 확안하고 수동으로 변경을 하면 됩니다.
  26. 제가 데모에 사용한 애플리케이션은 weblogic의 medrec 애플리케이션 샘플과 레드햇에서 제공해주는 샘플 애플리케이션을 사용하여 만들 었습니다. 해당 설정은 weblogic에서 사용하고 있는 web application descriptor 입니다. 위의 weblogic 파일은 보안을 위한 security-role에 대한 설정이 첨부 되어있습니다.
  27. Weblogic.xml을 jboss 설정으로 맞게 변경하기 위해서는 2개의 파일을 설정해줘야합니다. 하나는 jboss web application descriptor 파일인 jboss-web.xml과 jboss configuration file인 standalone.xml입니다. 먼저 weblogic.xml에서 사용중인 Role을 확인후 standalone.xml에 security-domains에 해당 role을 jboss 규격에 맞게 변경을 한 이후에 Jboss-web.xml 파일에 어느 security-domain role을 사용 할 것인지 정의 해주시면됩니다. 보안 도메인은 인증, 보안 감사, 보안 맵핑을 제어하기 위해 애플리케이션이 사용하는 JAAS(Java Authentication and Authorization Service) 보안 설정들의 집합이다. 여러 개의 보안 도메인을 설정할 수 있다. 보안 도메인에 인증, 권한 부여, 맵핑, 감사 모듈 및 JASPI 인증, JSSE 구성 정보를 포함할 수 있다. 애플리케이션에서 보안 도메인의 이름을 지정하여 보안 설정을 한다
  28. 웹로직 서버 외부에서 동작하는 JSP/서블릿 혹은 엔터프라이즈 빈즈에서 JNDI를 이용할 경우
  29. 웹로직 서버 외부에서 동작하는 JSP/서블릿 혹은 엔터프라이즈 빈즈에서 JNDI를 이용할 경우
  30. 웹로직 서버 외부에서 동작하는 JSP/서블릿 혹은 엔터프라이즈 빈즈에서 JNDI를 이용할 경우
  31. 자바 원격 함수 호출(Java Remote Method Invocation, Java RMI)는 자바 프로그램에서 각 객체간, 컴퓨터간 메서드를 호출할 수 있게 해주는 기술이다.
  32. 자바 원격 함수 호출(Java Remote Method Invocation, Java RMI)는 자바 프로그램에서 각 객체간, 컴퓨터간 메서드를 호출할 수 있게 해주는 기술이다.