01.JAVA/J2me
1. CLDC 소개
1010
2008. 11. 27. 12:55
반응형
|
1. CLDC 소개 | |||||||||||||||||||||||
 | |||||||||||||||||||||||
 1.1 CLDC 개요 | |||||||||||||||||||||||
CLDC(connected limited device configuration)는 앞서 본 바대로 성능이 제한된 CPU나 메모리가 한정적인 시스템을 대상으로 하는 spec이다. CLDC 관련 library는 시스템에 독립적인 고수준의 API 그리고 네트웍관련 API로 되어 있다. 크게 두 가지로 나눌 수 있는데 J2SE에 포함되어 있는 부분과 CLDC에만 있는 부분이다.
다음은 CLDC에서 주목해야할 몇 가지 특징들이다. | |||||||||||||||||||||||
이러한 특징들은 프로그램밍과 시스템의 설계에 있어서 중요한 항목일 경우가 많다. 따라서 하나하나가 의미하는 바를 잘 알아두어야 한다. | |||||||||||||||||||||||
| 1.2 CDC와 CLDC | |||||||||||||||||||||||
CDC, CLDC가 J2ME에서 configuration이라는 것은 이미 배웠다. 두가지 Configuration의 차이를 아래의 표에서 정리하였다.
[ 표 1 - CLDC와 CDC비교 ] | |||||||||||||||||||||||
아래의 그림은 이러한 차이를 좀더 그래픽하게 표현하였고 Profile종류도 나타나 있다. | |||||||||||||||||||||||
 | |||||||||||||||||||||||
|
[ 그림 1 - CDC와 CLDC 하드웨어 스펙 ] | |||||||||||||||||||||||
| 1.3 CLDC의 제약 | |
| |
| 1) 부동소수점을 지원하지 않는다. | |
| CLDC는 부동소수점을 지원하지 않는다. 이것은 J2SE full spec과 가장 현격한 차이점이기도 하다. 이유는 CLDC 타겟 디바이스가 하드웨어적으로 부동소수점을 지원하지 않기 때문인데, 소프트웨어적으로 부동소수점을 지원하는 것은 너무 큰 부하가 있다. 그래서 언어적인 측면과 가상머신에서 부동소수점은 지원하지 않는다고 명세서에 명시되어 있다. 그러므로, float, double 형과, 부동소수점 리터럴,부동소수점 연산은 사용할 수 없다. 만일 반드시 부동소수점 연산을 해야 한다면 하드웨어 업체가 제공한 OEM spec에서 기능을 찾아보아야 한다. 만일 거기에도 없다면 소프트웨어적으로 처리해야 한다. 다행스럽게도 이러한 Package가 나와 있는데 정수형 타입으로 부동 소수점형 연산을 시뮬레이션 해주는 것이다. MathFP라고 부르는 이 Package는 다음 URL에서 구할 수 있다. SKVM에서는 이 부분을 아예 OEM Spec에 포함하여 출시하고 있다. http://home.rochester.rr.com/ohommes/MathFP | |
2) Finalization과 가비지 컬렉션 | |
| CLDC 라이브러리의 Object 클래스에는 finalize() 메소드가 없다. 그러므로, CLDC 가상머신은 클래스 인스턴스를 가비지 컬렉트할 때 finalization을 수행하지 않는다. KVM은 크기가 작고 메모리를 효율적으로 사용하는 가비지 컬렉터를 위해서, 마크-청소(mark-sweep) 알고리즘을 사용하고, 비복사(non-copying), 비압축(non-compacting) 가비지 컬렉터를 사용한다. | |
3) 에러 처리 | |
| Java에서는 Error 와 Exception 두가지의 예외상황을 처리하는데 Error는 복구할 수 없는 것이고 Exception은 복구가능한 것이다. CLDC는 예외 처리는 지원하지만 에러 처리는 제한적으로 지원한다. 아래와 같이 두가지 Error처리만을 수행하는데 이렇게 대부분의 에러처리가 빠져 버린 이유는 하나는 에러처리가 대부분 하드웨어에서 처리되기 때문이다. 에러 처리가 일관성이 없는 임베디드 환경에서 대부분의 디바이스들은 에러가 발생했을 때, 그냥 리셋을 해 버린다. 다른 하나는 복구할 수 없는 에러를 처리하기 위해서는 매우 힘이 들기 때문이다. 너무 심한 오버헤드를 초래할 가능성이 높다.  java.lang.Error java.lang.VirtualMachineError java.lang.OutOfMemoryError | |
4) JNI(Java Native Interface) | |
| CLDC는 JNI를 지원하지 않는다. 네이티브 함수를 호출하는 방법은 CLDC의 구현에 의존적이다. 즉, CLDC를 구현하는 사람에게 달려있다는 것이다. JNI는 덩치가 크기도 하지만, CLDC의 제한적인 보안 모델로 인해, 네이티브 함수의 호출 자체가 위험할 수 있기 때문에 지원하지 않는다. | |
5) 리플렉션 | |
| 리플렉션은 런타임시에 자바 프로그램이 가상머신 내부의 클래스, 인터페이스, 객체 인스턴스들을 조사할 수 있게 하는 자바가상 머신의 특징이다. CLDC에서는 이러한 리플렉션 기능을 지원하지 않는다. 따라서 리플렉션 기능에 의존적인 여러가지 기능들을 지원할 수 없다. RMI, 객체 직렬화, 디버깅 인터페이스(JVMDI), 프로파일러 인터페이스(JVMPI) 등이 그것이다. 한가지 아쉬운 것은 RMI가 지원되지 않으므로, CLDC/MIDP 플랫폼에 지니를 올릴 수 없다는 것이다. 지니가 핸드폰에 탑재되기를 기대하시던 분들에게는 실망스러운 소식일 것이다. 무선 지니 디바이스에 관심이 있는 분이라면, RMI 프로파일이 포함된 CDC/퍼스널 프로파일 플랫폼을 탑재한 단말기를 기대하셔야 할 것 같다. | |
| 1.4 주요 특징들 | |||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||
| 1) 보안 모델 | |||||||||||||||||||||||||||||||||||
CLDC 타겟 디바이스에는 J2SE 플랫폼의 정책기반(policy-based) 보안 모델을 적용하기 어렵다. 왜냐하면, CLDC 구현보다 보안 모듈이 훨씬 더 큰, ‘배 보다 배꼽이 더 큰’ 형국이 될 것이기 때문이다. CLDC에서 정의된 보안 관련사항은 다음과 같은 두 가지 수준의 보안에 대한 지원이다.
보안에 관한 한 CLDC는 원시적인 자바의 모습으로 퇴화했는데, CLDC 모래상자 보안 모델은 다음과 같은 요구사항을 만족해야 한다.
| |||||||||||||||||||||||||||||||||||
2) 클래스 검증 과정 | |||||||||||||||||||||||||||||||||||
| J2SE의 virtual Machine과 같이, KVM에서도 class file의 수행전에 verify하는 과정을 거쳐야 할 필요가 있다. 하지만 JVM의 class file 검증은 과도한 static / dynamic foot print를 사용하기 때문에 좀 더 단순하고, 효율적인 검증과정이 필요로 하게 되었다. 그 solution으로 제시된 것이 OFF-Line 사전검증 과 ON-Line 검증으로 나누어 검증하는 것이다. J2SE의 Java Virtual Machine에서 일반적으로 검증기(verifier)는 runtime시 50KB의 binary code space와 30~100 KB의 동적 RAM을 필요로 한다. 게다가 CPU역시 실행 시 반복이 많은 data flow 알고리즘을 가지므로 많은 over head를 가지게 된다. 검증(verify)은 프로그램코드의 이동성을 보장하는 Java VM의 제어장치라고 할 수 있을 것이다. 검증기는 프로그램이 검증을 거쳐서 특정한 규칙을 따르고 있으며, 이 어플리케이션이 실행됨으로써 다른 어플리케이션 및 device의 안전을 보장하는 것이다. 반드시 필요한 반면 위에서 설명하다시피 embedded device에서는 과도한 performance를 요구하게 된다.. 그래서 나눈 것이 사전검증(pre-verify)과 실행 시 검증(verify)이다. 즉 OFF-Line 사전검증 과 ON-Line 검증인 것이다. <그림 2>를 보도록 하자. MyApp.java라는 애플리케이션을 작성한 후에 컴파일을 수행하면, MyApp.class라는 클래스 파일을 얻을 수 있다. 이 클래스 파일은 자바 가상머신 명세서에 정의된 클래스 파일 포맷을 따른다. 이 클래스 파일을 사전검증기(preverifier)를 통해 사전검증을 하게 되면, 변경된 MyApp.class 파일을 얻게 된다. 이 때, 이 클래스 파일은 CLDC 명세서에 정의된 클래스 파일 포맷을 따르게 된다. 이렇게 사전검증된 클래스 파일을 디바이스에서 다운로드하여 로딩한 후에는 온-디바이스 검증을 수행한다. | |||||||||||||||||||||||||||||||||||
 [ 그림 2 - 클래스 파일 검증 과정 ] | |||||||||||||||||||||||||||||||||||
검증 과정은 프로그램 코드의 네트웍 이동성을 보장하는 자바 가상머신의 안전장치이다. 즉, 검증 과정을 통해서 자바 가상머신은 애플리케이션이 특정한 규칙을 따르고 있음을 확인하고, 이 애플리케이션의 수행이 안전함을 보장할 수 있다. 이것은 애플리케이션이 허락되지 않은 위험한 작업을 수행하지 못하도록 함으로써, 시스템의 안정성을 확보하고, 바이러스 등의 위해한 애플리케이션의 등장을 방지할 수 있게 해 준다. 그러나, 검증 알고리즘을 구현하는 것은 약 50K 정도의 코드 공간이 필요하고, 기존의 검증 과정은 실행시 오버헤드도 크다. 그래서, 사전검증과 실행시 검증이라는 새로운 방법을 CLDC에서 도입한 것이다. 이러한 검증방법을 안전하고 유효하게 만들기 위해서는 몇가지 복잡한 고려를 해야 한다. 그 중에서도 가장 중요한 것은 클래스 파일포맷의 변화이다. 온-디바이스 검증기가 정상적으로 검증을 수행하기 위해서는 사전검증기가 이에 필요한 추가정보를 클래스 파일에 포함시켜야 하고, ‘스택 맵 애트리뷰트’라고 불리는 이러한 추가적인 애트리뷰트를 통해 온-디바이스 검증기는 효율적인 검증을 수행할 수 있다. 추가적인 애트리뷰트로 인해 클래스 파일의 크기는 약 5% 정도 늘어나게 되지만, 온-디바이스 검증기의 크기를 효과적으로 줄일 수 있고, 검증시에 재귀적인 검증을 하지 않고, 1패스 검증을 할 수 있다는 측면에서는 상당한 향상이 있었다고 평가할 수 있다. 다음은 위에서 설명한 사전검증과 실행시 검증으로 분리된 검증방법의 특징들이다.
| |||||||||||||||||||||||||||||||||||
3) 클래스의 로딩과 링킹 | |||||||||||||||||||||||||||||||||||
| CLDC 명세는 JAR(Java ARchive) 파일 포맷을 지원을 강제하고, MIDP 명세는 클래스 파일의 배포를 반드시 JAR(Java ARchive) 파일을 통해서만 이루어 지도록 하고 있다. 이것은 JAR 파일의 사용이 약 30~40% 정도의 대역폭 절감 효과가 있기 때문이다. 물론, 이 때 배포되는 JAR 파일에 포함된 클래스 파일들은 사전검증기에 의해 사전검증이 된 클래스 파일이어야 함은 당연하다. 로딩이란 애플리케이션에서 사용하고자 하는 클래스 파일들을 자바 가상머신으로 전달하는 과정을 말한다. CLDC에서는 JAR 파일의 형태로 네트웍을 통해 전송된 클래스 파일들이 시스템 클래스 로더에 의해 로딩된다. 링킹은 로딩된 클래스 파일, 즉, 바이너리 코드가 자바 가상머신에 의해서 수행될 수 있는 상태로 만드는 과정이다. 이 과정은 로딩된 클래스가 올바른 클래스 포맷을 가지고 있는 지 실행시 검증을 하는 검증(verification) 과정과, 메모리 영역의 할당 등의 예비 과정(preparation), 심볼릭 참조 주소를 직접 참조 주소로 변환하는 결정 과정(resolution) 등으로 세분화할 수 있다. 이 때, 보안상의 이유와 애플리케이션 관리 소프트웨어의 존재로 인해 클래스 파일의 룩업순서가 조금 다르며, 사용자 정의 클래스 로더를 만들 수 없다는 것도 CLDC의 특징이다. 여기서 한가지 강조하고 싶은 문제는 CLDC 디바이스는 대부분 파일시스템이 없다는 것이다. 그러므로, CLDC 명세도 파일시스템에 대한 고려를 하지 않고 있다. 즉, 플래시 메모리를 주 저장장치로 사용하는 CLDC 디바이스의 경우에, 저장공간은 ROM이 아니면 RAM이라는 것이다. 일반적으로 파일 시스템이 보조 기억장치로서 존재하는 PC 시스템의 경우, 자바 가상머신이 수행될 때, 먼저 자바 가상머신이 파일 시스템으로부터 메모리로 올려 진다. 그리고, 클래스 로더가 필요한 시스템 클래스 파일들을 파일시스템으로부터 메모리로 로딩한다. 그리고 나서, 필요한 사용자 정의 클래스 파일들을 파일시스템으로부터 메모리로 로딩한다. 그런데, CLDC 디바이스에서는 가상머신과 시스템 클래스 파일들이 이미 메모리에 존재한다. 그런데, 굳이 로딩과 링킹, 초기화라는 불필요한 절차를 거칠 필요가 있을까? 로마이징(ROMizing)은 이처럼 특정 클래스들을 사전에 미리 로딩하고 링킹해 놓음으로써 애플리케이션의 속도 향상을 가져올 수 있는 기법을 의미한다. CLDC 명세에서는 사전로딩/사전링킹을 통한 로마이징을 구현에 의존적인 기능으로 정의하고 있다. | |||||||||||||||||||||||||||||||||||
4) CLDC 라이브러리 | |||||||||||||||||||||||||||||||||||
자바와 관련한 신기술이 발표될 때 마다, 함께 쏟아져 나오는 API들은 늘 신선함과 함께 부담감으로 작용한다. 필자는 개인적으로 선이 이룩한 가장 기념비적인 업적 중의 하나가 javadoc이라는 문서화 툴의 확산이라고 생각한다. 만일, 그토록 많은 API들의 홍수 속에 살면서, javadoc에 의한 편리하고, 보편적인 문서화가 이루어지지 않았다면, 많은 사람들이 자바를 외면했을 것이라는 생각을 해 본다. 그럼에도 불구하고, 매번 새로운 API를 접하는 것은 상당히 부담스러운 일이다. 그러므로, CLDC에서도 가능하면 모든 API들이 기존의 J2SE API의 서브셋이기를 바라는 것이 자바 개발자들의 공통된 요구일 것이다. 하지만, MIDP를 통해서 더욱 확실히 느끼게 되겠지만, 기존 API와의 호환성은 잊어버리는 게 좋을 정도로 많은 API들이 재정의되었다. 재사용 가능한 API들이라고는 다음 세 가지의 패키지들 중에서도 일부일 뿐이다. 각각의 패키지에 포함된 클래스들은 [표 2]에 정리하였다.
[ 표 2 - CLDC 라이브러리 ] | |||||||||||||||||||||||||||||||||||
5) 프로퍼티 | |||||||||||||||||||||||||||||||||||
[표 2]에서 java.util.Properties를 찾아 보면 찾을 수 없을 것이다. 즉, CLDC에서는 프로퍼티 기능을 지원하지 않는다는 것이다. 다만, System.getProperty(String key) 메소드를 통해서 시스템 프로퍼티에 접근할 수는 있다. 하지만, setProperty() 메소드는 지원되지 않는다는 것을 확인하기 바란다. 그러므로, 애플리케이션 개발자는 시스템 프로퍼티를 변경하거나 새로운 프로퍼티를 생성할 수는 없다. [표 3]은 CLDC에서 정의하는 시스템 프로퍼티들이다. MIDP에서는 지역화를 고려하여 locale 프로퍼티를 추가하였다.
[ 표 3 - 시스템 프로퍼티 ] | |||||||||||||||||||||||||||||||||||
6) 국제화/지역화 | |||||||||||||||||||||||||||||||||||
| 국제화/지역화의 지원은 아직 CLDC/MIDP에서는 제대로 지원을 보장하지 못하고 있다. CLDC에서 유니코드 문자를 바이트로 변환해 주는 변환기를 제한적으로 지원할 뿐이다. 이러한 국제화 지원은 Reader와 Writer를 통해서 이루어지고, 각각에 대해서는 다음과 같은 생성자에서 두 번째 인자로 인코딩 방법을 지정함으로써 코드 변환을 할 수 있다. new InputStreamReader(InputStream is, String name) new OutputStreamWriter(OutputStream os, Striing name) ISO8859_1 이외의 인코딩 방법에 대해서는 기본적으로 CLDC/MIDP 구현자에게 의존적이며, 날짜, 시간, 통화 등의 포맷에 관련한 지역화에 대해서도 MIDP 구현에 의존적이다. 국제화/지역화 문제는 <표 3>에서와 같이 시스템 프로퍼티에 한글 인코딩과 한국의 로캘을 지정하고, 코드 변환기와 포맷 변화기가 완전히 구현되어야 한다. 선 마이크로시스템즈의 CLDC 1.0 베타와 MIDP Early Access 1에서는 한글 및 지역화 지원이 완벽하지 않다고 한다. 그러나 조만간에 이 문제는 해결이 될 것이라 생각된다. | |||||||||||||||||||||||||||||||||||
7) 애플리케이션 관리 메커니즘 | |||||||||||||||||||||||||||||||||||
| 이 글의 서두에서 모바일 솔루션으로서의 자바의 특장점 중의 하나가 애플리케이션의 동적인 다운로드 기능이라고 했다. 자바 애플릿을 떠올린 분들이 많으실텐데, 이것은 커다란 오해다. CLDC/MIDP 플랫폼에서는 완전히 새로운 애플리케이션 모델을 제시하고 있다. ‘애플리케이션 관리 소프트웨어’라고 불리는 새로운 소프트웨어의 등장은 애플릿과 애플리케이션의 혼합, 혹은 자바 플러그-인의 확장이라고 할 수 있는, 새롭지만, 그리 낯설지 않은 애플리케이션의 배포와 관리 메커니즘을 제공하고 있다. CLDC는 단지 이러한 애플리케이션 관리 소프트웨어의 존재에 대해서만 가정하고 있으며, 실질적인 애플리케이션 모델에 대한 정의는 MIDP에서 이루어 지고 있으므로, 나중에 이 부분을 자세히 살펴보도록 하자. | |||||||||||||||||||||||||||||||||||
8) Generic Connection Framework | |||||||||||||||||||||||||||||||||||
| CLDC에서는 확장 패키지에 포함될 클래스를 정의하는 부분이 있다. javax.microedition.io 패키지가 그것인데, 여기에는 Generic Connection Framework(이하, 커넥션 프레임웍)이라고 이름이 붙은 네트워킹과 입출력에 대한 상위 수준의 프레임웍에 대한 인터페이스 정의가 포함되어 있다. 왜 전혀 새로운 네트워킹과 입출력 프레임웍을 정의해야만 했는가? 이에 대한 해답은 다시 메모리의 제약으로 돌아간다. 기존의 java.net 패키지와 java.io 패키지는 덩치가 너무 크다. 100개 이상의 클래스와 200K 이상의 크기를 가진 이 패키지들은 CLDC 디바이스들에는 적합하지 않다. 게다가, TCP/IP, WAP, iMode, IrDA, Bluetooth라는 새로운 통신방법에 대한 지원과, 파일 시스템이 존재하지 않는 입출력 메커니즘을 하나로 통합할 필요성이 존재했다. 그리고, 그 방법으로 새로운 프레임웍의 정의를 선택한 것이다. 다음은 커넥션 프레임웍의 설계목표이다.
CLDC의 커넥션 프레임웍은 네트웍과 입출력을 포함한 모든 연결의 생성에 대해서 다음과 같은 형태의 일관성을 제공한다. Connector.open(“<protocol>:<address>”); 이 일관성의 핵심은 Connector 클래스만으로 모든 연결을 생성할 수 있으며, open() 메소드의 인자를 변경함으로써 연결의 형태를 바꿀 수 있다는 데에 있다. 연결이 성공적이었다면, open() 메소드는 커넥션 프레임웍의 인터페이스들을 구현한 클래스의 인스턴스를 리턴한다. <그림 3>은 커넥션 프레임웍의 계층도에 대해 보여주고 있다. 그리고, <표 5>는 Connector 클래스를 이용해서 여러 프로토콜의 연결을 생성하는 예를 보여주고 있다.
| |||||||||||||||||||||||||||||||||||
|
[ 표 4 - 프로토콜별 연결생성 예 ] | |||||||||||||||||||||||||||||||||||
한 가지 분명히 해 두어야 할 것은 CLDC는 Connector 클래스를 포함해서, 어떠한 실제 구현에 대한 명세도 포함하지 않는다는 점이다. 커넥션 프레임웍은 단지 프레임웍만을 제공할 뿐, 실질적으로 지원할 프로토콜에 대한 정의와 구현은 프로파일의 몫이며, MIDP에서는 HTTP 프로토콜의 지원에 대해서 정의하고 있다. MIDP의 HTTP 지원은 나중에 다시 살펴보도록 하자. | |||||||||||||||||||||||||||||||||||
 | |||||||||||||||||||||||||||||||||||
|
IONETKOREA E&D 연구소 제공 | |||||||||||||||||||||||||||||||||||