S1A – Spring Dynamic Modules Updates : Costin Leau

스프링 DM 기본 설명

스프링 애플리케이션에서 추가 코드 없이 OSGi를 사용할 수 있다.
=> 스프링 철학과 일맥상통한다. non-invasive

스프링 DM
– 오라클(/BEA)와 함꼐 협업하고 있다.
=> 스프링 DM이 OSGi 스펙을 주도 하고 있다.

Raw OSGi
=> 다이나믹스를 다루기 위한 반복적인 코드가 필요하다.
=> OSGi 번들은 일반 JAR 파일로 무엇을 사용하고공개할지 정의한 파일을 가지고 있다.
=> 손수 해야 할 일이 많다.

OSGi에서 스프링 사용하기
=> OSGi 서비스를 룩업하지 말고 DI하기

POJO developement in OSGi

기능 살펴보기

번들 == ApplicationContext
=> 하나의 번들은 하나의 application context를 가지고 있다. 직접 만들 필요는 없다. 모듈을 정의하고 설정을 만들고 배포하면 되지.. 스프링을 이용하려고 뭔가를 하지 않아도 된다.

OSGi-aware Contexxt
=> OSGi 환경에 대해 알고 싶다면(예를 들어, BundleContextAware)같은 인터페이스를 사용할 수 있다.
=> bundle 스코프 제공
=> 여러 모듈에 걸친 application context 설정파일 사용가능

애플리케이션 == 모듈 집합

OSGi 서비스 == 스프링 빈

=> 서비스 레지스트리는 loose coupling을 실현해준다.

서비스 공개하기(export)
=> 보통 인터페이스를 기준으로 공개한다.
=>  auto-export 속성

서비스 참조하기(import)
=> 서비스 다이나믹스를 내부에서 다뤄준다.

데모
1. STS에서 dm 서버 실행한다.
2. localhost 2401로 telnet한다.
3. osgi> 콘솔 확인 help로 기본 명령어 확인
4. ss로 설치된 번들 확인
5. bundle 번들id로 번들 정보 확인

1. 간단한 서비스 공개(하나는 all-classses, 하는 interface)
2. 번들을 dm 서버에 설치하고 공개된 서비스 확인

1.  shape 번들 만들고 서비스 세 개 공개
2. MF 파일 고칠 거 없다.
3. dm 서버에 배포하고 공개된 서비스 확인

1. painter manager 번들 만들고 painter와 packageAdmin 서비스 레퍼런스 가져온다.
2. osgi:list로 여러 서비스를 참조할 수 있다.
3. BundleLogger에  packageAdmin 주입.

서비스 다이나믹(dynamics)
=> dynamic은 서비스가 언제든지 새로 추가되거나 없어질 수 있다는 거다.
Dependency resilience

만약
– 대응하는 서비스가 없다면
– 대응하는 서브시가 여러 개라면
– 대응하는 서비스가 사용 도중 없어지면
– 더 잘 매칭하는 새로운 서비스가 배포 되면

import cardinality
– 1..X: 애플리케이션 시작할 때 필요하다
=> X .. 1 일 때 서비스가 사라지면 다른 서비스 참조한다.
=> X .. N 일 때 서비스가 사라지면 컬렉션에서 빼준다.

데모

1. 쓰레드로 2초마다 그림그리는 메소드 실행하는 번들 만듬
2. painterManager 번들 stop
3. 다시 start
4. 로깅을 stop(등록한 서비스를 제거한다.)
=> 없어지면 대체제를 찾고 대체제가 없으면 기다린다.
5. 로깅 다시 start

리스닝
=> 메소드 매개 변수에서 서비스를 필터링할 수 있다.

통합 테스트 데모
1. AbsractConfigurableBundleCreatorTests 상속 받기
2. bundleContext.getBundles() 사용하기
3. getPlatformName으로 테스트할 플랫폼 선택가능. Platform.EQUINOX

1.2.0은 Compendium Services Integration
– Configuration Admin 속성을 참조하라.
– osgix 네임스페이스 공부할 것…

OSGi 4.2 계획
– Spring DM은 OSGi 4.2를 기준으로 한다.
RFC 124의 RI가 된다.
– 2009년 5/6월을 배포를 목표로..
=> 스프링 네임스페이스랑 OSGi 네임스페이스가 거의 비슷한 형태로..

로드맵
– 1.2.0은 2009년 1/2월
– 2.0(Spring, 3.0, JDK 5.0, RFC 124 RI) 2009년 5/6월

S1A – OSGi best practive by 코스틴 리우

자바 애플리케이션 모듈화는 어렵다. 하지만 해결책은 있다.

개요
– 모듈성 개요
– 클래스 & 리소스 로딩
– 서비스 다아나믹스

모듈화 목적
=> 차 사고 났을 때 헤드라이트 나가면 거기만 갈아 낄 수 있도록.
=>

모듈성이 없는 app
– web/facade/repository 한 덩어리

모듈성이 있는 app
– ADao, BDao, CService

OSGi
– 1999년부터 사용 가능
– JDK 1.2 호환

모듈화 대안 – JSR277/JAM
– JAva Module
– “Opaque” 스펙 진행중
=> 어떻게 되가고 있는지 모르겠다.
– JDK 7.0 호환
=> 왜냐면 새로운 키워드를 사용해야 해서…
– OSGi 호환

모듈화 대안 – HK2
=> glassfish 팀이 사용하고 있다.
– 2007년 말에 밸표됨
– 애노테이션 기반 간단 IoC
– 정적인 시스템

OSGi/JSR 277 비교
– http://www.osgi.org/blog/
– http://underlap.blogspot.com/

클래스로딩
– 모듈은 자기 내부 패키지와 다른 모듈에서 가져온 패키지만 로딩할 수 있다.
– 모든 패키지는 버전을 가지고 있다.

Type Leakage
  – 공개한 클래스 계층 구조에서 내부 클래스
  – 공개한 시그너쳐에 있는 내부 클래스
=> 이런 일이 발생하면 안 돼. 그럼 어떻게 해야 할까?
– 내부 패키지를 공개해(
– ‘연결’ 인터페이스를 축출해
– Generic public 타입을 사용해
– 검증 도구(bnd)를 사용해

추이적인 의존성
– A -> C1, B ->C2 => 이렇게 여러 버전 배포 가능하다. 이럴 때 X -> A, B 이렇게 되면.. C 패키지는 어떤 버전 사용하게 되는거야?? => A나 B가 사용하고 X가 직접 사용 안 하면 상관없겠지만 X가 직접 해당 패키지를 사용하게 되면 타입 캐스팅 충돌 발생할꺼다 그래서 바운더리를 만들어줘야 한다. X -> A, B, C1 이런식으로..
또는
=> A, B, X -> C2 이런식으로 한 버전을 참조하도록 한다.
– uses 지시어를 사용해서 둘 사이의 관계를 기술하라.

AOP
– 동적 클래스 확장
– 기존 모듈 경계를 깨트린다.
=> AOP의 아름다움은 바로 transparent하게  로깅이나 트랜잭션 등을 처리해 준다는 것이다.

(과거) 컴파일-타임 위빙
– Imports를 수정해야 한다.
– provisioning 을 통해서 한다.

로드 타임 위빙
=> 이미 리졸브 된 상태에서 추가로 필요한 패키지가 있으면 못 가져온다.
– Synthetic 클래스로더 하나가 Proxy Creator Module, Advoce Module, Target Module을 모두 관리해야 한다.

동적인 로드 타임 위빙
=> 위에서 설치한 모듈이 중간에 없어지면 어떡하냐.. 프록시를 없앴다가 다시 만들어야 돼.
– 의존하는 모듈을 update 해줘야 돼
=> SpringSource DM 서버에서는 알아서 해준다.

영속화/리모팅
– 클래스 로더 사용과 연관이 많다. => 해결책은 synthetic classloader

DynamicImport-Package
– 이 건 사용을 권장하지 않아.
=> 일관성이 없이 매번 실행할 때마다 문제가 있을 수도 있고 없을 수도 있다. 여러 버전을 사용할 수 있을 경우에 완전 운에 달린 게임이다.
– 프로토타입에서나 사용하고 제품에선 사용하지 말아라.

리소스 로딩
=> 클래스 로딩과 비슷한데 silent error가 발생한다.
– 리소르를 클래스와 동일한 곳에 둔다. 클래스에서 사용할 수 있도록 -> portable cnofig 자동으로 export 된다.

공유 자원
– META-INF/services
– 버저닝이 문제가 딜 수 있다.
=> 헤결 책은 extender

Externder 패턴
=> 번들 내부 리소스를 OSGi 서비스에서 사용가능하게 해준다.

웹 애플리케이션

오너쉽 문제 누가 로딩을 주도하는가?
– OSGi 플랫폼이?
– 웹 컨테이너가?
옵션
– HttpService
– Servlet Bridge
– ClassLoader bridge(스프링 DM 서버)

웹 애플리케이션에서 클래스 로딩
– WAR는 미리 정의되어 있는 클래스패스가 있다.
– OSGi에서는 뭔가가 필요하다. => 번들 처리 도구를 사용하거나, dm 서버가 해준다.

리소스 로딩
=> 스프링DM/dm 서버가 알아서 해준다.

서비스 Dynamics

OSGi 서비스
– 간적접인 계층
– 객체를 서비스 registry에 추가하거나 제거할 수 있다.
– 타입 필터링이 자동으로 적용된다.
– 서비스는 동적이다.(언제든 사라지고 나타날 수 있다.)
– OSGi 서비스는 싱글톤이다.

OSGi 서비스와 스프링 DM
– 그림
=> decoupling

서비스 Dynamics
– org.osgi.util.ServiceTracker
– Tracking Proxy(Spring DM) => 참조하던 서비스 없어지면 대체 가능한 다른 걸로 update 해준다.

다른 이슈
– 쓰레드 Context 클래스로더
– TCCL을 사용하지 말거나 스프링 DM/dm 서버처럼 관리하라.
– 쓰레딩
– 번들/애플리케이션 관리

결론
– STS, Spring DM, dm 서버를 사용하라. @.@

오호.. 스프링소스 manifest 헤더가 OSGi에 추가되는군요

참조: http://blog.springsource.com/2008/11/27/springsource-manifest-headers-registered-with-osgi/

OSGi 진영에서 public registry에 밴더별 헤더를 등록해서 중복하는 헤더를 방지하고자 하는 것 같습니다.

추가된 스프링소스의 헤더 7개
– Import-Bundle
– Import-Library
– Module-Scope
– Modeul-Type
– Web-Contextpath
– Web-DispatcherServletUrlPatterns
– Web-FilterMappings

추가된 bnd 헤더 2개
– Include-Resource
– Private-Package

오호~~ 귿~~ 다시 한 번 스프링 DM 공부를 하고 가야겠습니다. S1A에 가서 스프링 DM과 DM 서버 관련 세션을 집중적으로 듣고 올 계획입니다. 이틀 남았네 빡쎄게 공부해야겠군..

OSGi uses 충돌 감지하기

참조 및 번역: Diagnosing OSGi uses conflicts

Glyn은 최근에 “OSGi “uses” 지시어 이해하기”를 제공했다. 나(Rob Harrop)는 uses 제약 위반 원인을 좀 더 자세히 살펴보고 여러분 애플리케이션에서 발생하는 uses 문제 해결에 유용한 몇 가지 팁을 제공하고자 한다.

나는 대부분의 예제에서 dm Server 보다는 이퀴녹스를 사용하려고 한다. 그 이유는 uses 제약사항이 dm Server에 한정적인 것이 아니고 모든 OSGi 사용자와 관련된 것이기 때문이다. 이 블로그 마지막에는, dm Server에 구축된 매우 똑똑한 제약 사항 실패 진단 몇 가지를 보여줄 것이다.

의존적인 제약 불일치(Dependent Constraint Mismatch)


가장 흔한 uses 위반은 한 개 이상의 의존적인 제약 사항끼리의 불일치 때문이다. 예제로 다음 세 개의 manifest를 살펴보자.

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version=”2.5.5″;uses:=”eclipselink”
Import-Package: eclipselink;version=”[1.0, 2.0)”

Manifest-Version: 1.0
Bundle-Name: EclipseLink 1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 1
Export-Package: eclipselink;version=”1.0.0″

Manifest-Version: 1.0
Bundle-Name: EclipseLink 2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 2
Export-Package: eclipselink;version=”2.0.0″

스프링 번들 한 개와 두개의 eclipselink 번들이 있다. 물론 실제 번들은 아니다. spring 번들은 [1.0, 2.0) 버전 번위의 eclipselink 패키지를 사용한다. 분명히 오직 eclipselink_1 번들만이 이 제약 사항을 만족한다. 이제 다른 두 개의 애플리케이션 manifest를 살펴보자.

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version=”[1.0, 1.0]”

Manifest-Version: 1.0
Bundle-Name: App2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app2
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version=”[2.0, 2.0]”

app1은 exlicpselink [1.0, 1.0] 범위를 참조하고, app2는 eclispelink [2.0, 2.0] 범위를 참조한다. 만약 이 두 개의 번들을 이퀴녹스에 설치하고 app 번들들을 start 시도하면, 콘솔에서 다음과 같은 결과를 확인할 수 있다.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
2       RESOLVED    spring_2.5.5
3       RESOLVED    eclipselink_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app1_1.0.0
6       INSTALLED   app2_1.0.0

sprig과 eclipselink 번들들은 모두 잘 리졸브 된 걸 볼 수 있다. app1 번들은 시작(start)했지만, app2 번들은 시작하지 못했다. 이유를 알아보기 위해 diag 커맨드를 사용할 수 있다.

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [6]
  Package uses conflict: Import-Package: spring.orm.hibernate; version=”0.0.0″

여기서 우리는 spring.orm.hibernate 패키지를 임포트하는 부분에서 uses 충돌로 인해 해당 번들을 리졸브 할 수 없다는 것을 알 수 있다. 이것은 app2에서 spring.orm.hibernate를 임포트하는 것을 안 된다는 것이다. 그 이유는 다른 import로 인해 spring.orm.hibernate를 제공하는 번들의 uses 제약 사항이 깨질 수 있기 때문이다.

이를 진단하는 과정 처음으로 할 일은 spring.orm.hibernate 번들의 가용한 공급자를 찾아내는 것이다. 우리는 이미 해당 공급자가 spring 번들이라는 걸 알고 있지만, 만약 공급자를 모른다면 packages 커맨드를 사용할 수 있다.

osgi> packages spring.orm.hibernate
spring.orm.hibernate; version=”2.5.5″<file:/Users/robharrop/dev/resdiag/uses/spring/bin [2]>
  file:/Users/robharrop/dev/resdiag/uses/app1/bin [5] imports

여기서 spring.orm.hibernate 패키지를 번들 2에서 공급(export)했다는 것을 알 수 있다. 이 정보를 가지고 번들 2의 spring.orm.hibernate에서 uses 지시어에 어떤 패키지가 등록되어 있는지 확인할 수 있다.

osgi> headers 2
Bundle headers:
 Bundle-ManifestVersion = 2
 Bundle-Name = Spring Bundle
 Bundle-SymbolicName = spring
 Bundle-Version = 2.5.5
 Export-Package = spring.orm.hibernate;version=”2.5.5″;uses:=”eclipselink”
 Import-Package = eclipselink;version=”[1.0, 2.0)”
 Manifest-Version = 1.0

여기서 우리는 uses에 있는 유일한 패키지 eclipselink 패키지가 범인이라는 걸 알 수 있다. 사실, 스프링 번들은 eclipselink [1.0, 2.0) 범위를 참조하는 반면 app2는 eclipselink [2.0, 2.0] 범위를 참조하는 걸 확인할 수 있다. 이 두 범위는 상충한다. app2는 스프링 번들이 사용하는 eclipselink와 동일한 버전을 연결할 수 없다.

uses 목록이 긴 경우는, 어떤 패키지의 제공자가 둘 이상인지를 확인하여 위반을 한 패키지 범위를 좁혀볼 수 있다. uses 제약을 위반 패키지를 제공하는 공급자는 반드시 둘 이상이다.

버전 불일치는 의존 제약 불일치의 유일한 원인이 아니다. 속성도 버전처럼 제약 문제를 발생 시킬 수 있다.

설치 순서 문제


앞선 예제를 다시 살펴보자. spring 번들의 manifest를 변경하여 eclipselink 2.0 패키지를 참조하도록 변경하고 app1은 1.0 이상의 모든 버전을 허용하도록 수정하여 문제를 수정해보자.

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version=”2.5.5″;uses:=”eclipselink”
Import-Package: eclipselink;version=”[1.0, 2.0]”

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version=”1.0″

번들들을 설치하고 app 번들을 시작하면 큰 변화가 생긴걸 볼 수 있다.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       RESOLVED    eclipselink_2.0.0
4       ACTIVE      app1_1.0.0
5       ACTIVE      app2_1.0.0

이제 두 개의 app 번들 모두 시작 할 수 있다. 불행히도 좀 더 교묘한 이슈가 우리를 기다리고 있다. 설치 순서에 따라, 이 번들 집합체는 같이 실행되지 않을 수도 있다. 이를 실험해보기 위해서, spring, eclipselink_1과 app1을 한 묶음으로 설치하고 app1을 실행한다.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0

자 이제 eclipselink_2와 app2를 설치한다.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       INSTALLED   app2_1.0.0

app2 번들은 시작되지 않는다. diag 통해 왜 그런지 살펴보자.

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [5]
  Package uses conflict: Import-Package: spring.orm.hibernate; version=”0.0.0″

uses 충돌이 다시 발생했다. 이번에는 앞선 진단 과정이 아무런 도움이 되지 않느다. 의존성 제약 불일치가 없기 때문이다. 첫 번째에 모두 잘 리졸브 됐기 때문에 이건 이미 알고 있다.

이슈는 리졸루션 순서에 있다. 번들들은 두 덩어리로 나눠서 설치하고 리졸브 했다. 첫 번째 덩어리는 spring, eclipselink_1, app1 이고 두 번째 덩어리는 eclipselink_@와 app2다. (app1 번들을 시작(start)한 결과로..)첫 번째 덩어리가 리졸브 될 때, spring 번들은 esclipselink 패키지를 가져올 때 eclipselink_1 번들에 묶이게 된다. 이것을 콘솔에서 확인해보자.

osgi> bundle app1
file:/Users/robharrop/dev/resdiag/uses/app1/bin [3]
  Id=3, Status=ACTIVE      Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/3/data
  No registered services.
  No services in use.
  No exported packages
  Imported packages
    spring.orm.hibernate; version=”2.5.5″<file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]>
    eclipselink; version=”1.0.0″<file:/Users/robharrop/dev/resdiag/uses/eclipselink1/bin [2]>
  No fragment bundles
  Named class space
    app1; bundle-version=”1.0.0″[provided]
  No required bundles

import packages 섹션에서 eclipselink 버전 1.0.0이 eclipselink_1 번들에서 가져온 걸 확인할 수 있다. 두 번째 덩어리를 설치하면 app2 번들은 eclipselink 버전 2를 필요로 하는데, spring이 이미 eclipselink 1.0.0 버전에 묶여 있어서 리졸브되지 못한다. 한 덩어리로 모든 번들을 설치하고 리졸브 할 때는, OSGi 리졸버가 spring.orm.hibernate의 uses 제약도 만족하면서도 다른 모든 제약사항을 만족하도록 시도할 것이다.

이 문제를 고치기 위해 우리 번들을 수정할 필요는 없다. 대신, 모든 번들을 한 덩어리로 설치하거나 spring 번들을 리프래쉬 하면 된다. 그렇게 해서 OSGi가 다시 리졸루션 과정을 거치도록 한다. 이제 eclipselink_2 번들이 설치되고 이번에는 다른 결과를 예상할 수 있다.

osgi> refresh spring

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app2_1.0.0

osgi> bundle spring
file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]
  Id=1, Status=RESOLVED    Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/1/data
  No registered services.
  No services in use.
  Exported packages
    spring.orm.hibernate; version=”2.5.5″[exported]
  Imported packages
    eclipselink; version=”2.0.0″<file:/Users/robharrop/dev/resdiag/uses/eclipselink2/bin [4]>
  No fragment bundles
  Named class space
    spring; bundle-version=”2.5.5″[provided]
  No required bundles

spring 번들을 리프래시해서 app2 번들도 리졸브 된 걸 볼 수 있다. spring 번들에서 연결할 eclipselink 패키지가 eclipselink_2 번들의 2.0 버전으로 바꼈다.

dm 서버에서 uses 제약 사항

uses 제약 위반이 dm 서버에서 발생하면, 여러분이 해야할 분석 절차를 알아서 제공해준다. 특히 불일치하는 패키지를 담고 있을 가능성이 있는 의존성 제약을 식별할 때 도움이 된다.

Could not satisfy constraints for bundle ‘app2’ at version ‘1.0.0’.
 Cannot resolve: app2
  Resolver report:
    Bundle: app2_1.0.0 – Uses Conflict: Import-Package: spring.orm.hibernate; version=”0.0.0″
      Possible Supplier: spring_2.5.5 – Export-Package: spring.orm.hibernate; version=”2.5.5″
        Possible Conflicts: eclipselink

uses 제약사항은 엔터프라이즈 라이브러리에서 매우 흔히 사용하며 손수 실패 원인을 분석하는 것은 악몽같은 일이다. 특히, uses를 사용하는 패키지가 10 개 이상 있을 때는, 가용한 충돌을 판별하는 작업은 상당한 시간-낭비를 초래한다. 따라서 자동화 검진은 필수이며, 나는 dm 서버에서 진당 코드가 향상되어 흔히 발생하는 문제가 아무것도 아닌 것처럼 다룰 수 있게 되길 바란다.

다음 배포판에서는, 진단 도구를 dm 서버 이클립스 툴에 바로 포함시켜서 dm 서버에서 이런 문제들을 대부분 자동으로 분석하도록 할 수 있게 할 계획이다.