KR20050007901A - 무선인터넷플랫폼이 탑재된 이동통신단말기에서실행가능한 바이너리코드를 생성하는 방법 및 시스템 - Google Patents

Abstract

본 발명은 Java를 컴파일해 무선인터넷플랫폼이 탑재된 이동통신단말기에서 직접 실행가능한 실행 바이너리로 만드는 방법 및 그 시스템에 관한 것으로, COD 시스템은 개발자가 제공하는 자바 클래스 파일을 입력으로 일련의 과정을 거쳐 단말기 사용자에게 프로그램 바이너리 이미지 파일을 제공한다. COD 내부에서는 입력된 자바 바이트코드를 분석해 해당 분석 정보를 기반으로 이와 동일한 기능을 갖는 C/C++ 프로그램으로 번역한다. 또한 이렇게 만들어진 소스를 자동으로 컴파일할 수 있는 Makefile도 같이 만들어 컴파일러를 구동한다.

Description

무선인터넷플랫폼이 탑재된 이동통신단말기에서 실행가능한 바이너리코드를 생성하는 방법 및 시스템{Method and system for generating binary code executable in mobile terminal embedding mobile internet platform}

본 발명은 Java를 컴파일해 무선인터넷플랫폼이 탑재된 이동통신단말기에서 직접 실행가능한 실행 바이너리로 만드는 방법 및 그 시스템에 관한 것이다.

본 발명이 이루고자 하는 기술적 과제는 Java를 컴파일해 무선인터넷플랫폼이 탑재된 이동통신단말기에서 직접 실행가능한 실행 바이너리로 만드는 방법 및 그 시스템을 제공하는 것이다.

도 1은 COD 시스템의 처리 과정을 표시한 도면이다.

도 2는 COD의 구성을 나타내는 도면이다.

도 3은 COD 서비스 구조를 설명하는 도면이다.

도 4는 본 발명의 세부수행내용을 나타내는 도면이다.

이하에서, 도면을 참조하여 본 발명의 실시예에 대하여 상세히 설명하기로 한다.

WIPI 플랫폼은 자바 언어의 장점을 수용하며 네이티브 바이너리의 실행 성능을 갖도록 개발됐다. C/C++ 언어는 네이티브 바이너리를 생성하는 데 아무런 문제가 없으나, 자바 언어는 기본적으로 가상 기계를 대상으로 하기 때문에 자바를 컴파일해 단말기에서 직접 실행가능한 실행 바이너리를 어디선가 만들어야 한다. 이러한 기능을 수행하는 WIPI 구성요소가 바로 COD다.

기존의 무선인터넷 플랫폼은 VM 기술과 네이티브 바이너리 기술로 구별된다. 두 가지 기술은 상호배타적인 특성을 가지고 있다. 즉 한쪽 기술의 장점이 다른 기술의 단점이 되고, 한쪽 기술의 단점이 다른 기술의 장점이 되는 것이다. VM 기술은 말 그대로 가상 기계를 사용해 프로그램을 동작시키는 것이다. 작성된 프로그램을 소프트웨어 CPU에서 동작할 수 있는 중간 코드로 변환하면 가상 기계가 해당 코드를 실제 CPU용 기계어로 번역해 실행시키는 방식이다. 이러한 기술은 자바를 통해 일반화돼 있으며 자바 가상머신은 무선인터넷 플랫폼에도 이미 적용되어 있다. 국내에서는 SK텔레콤의 SK-VM, LGT의 자바 스테이션이 JVM을 탑재한 무선인터넷 플랫폼을 통해 서비스를 제공하고 있다. 또한 C 언어의 축소판인 Mini-C를 이용한 GVM 기술이 국내에서 개발돼 SK텔레콤을 통해 서비스되고 있다.

또 다른 기술인 네이티브 바이너리 기술은 일반적으로 우리가 프로그램을 작성하고 컴파일해 실행시키는 방법과 동일한 과정을 밟는다. 즉, 개발된 프로그램을 프로그램이 실행될 CPU에서 동작되는 기계어로 만들어 실행시키는 것이다. 이 기술을 이용한 무선인터넷 플랫폼이 퀄컴의 브루 플랫폼이다. VM 기반의 무선인터넷 플랫폼은 소프트웨어 CPU를 이용해 중간 코드를 실행 과정에 번역(Interpreting)하는 부담을 안고 있으며 이는 CPU 성능과 자원이 제한된 휴대전화기에서 사용자가 상대적으로 매우 느린 속도를 경험하게 된다. 그러나 VM 기술은 상대적인 시스템 안정성을 제공하며 완벽한 보안을 제공하는 장점을 가지고 있다.

반면 네이티브 바이너리를 이용하는 플랫폼은 VM 기술과 달리 탑재된 CPU의 성능을 100% 활용할 수 있으므로 VM에 비해 매우 빠른 실행속도를 제공한다. 그러나 지금의 네이티브 바이너리를 사용하는 기술은 개발언어로 C/C++를 사용하고 있어 프로그램 개발자에 의해 악의적인 메모리 접근 등을 통한 시스템 안정성을 위해할 수 있는 요소를 갖고 있다.WIPI 플랫폼은 이러한 대조되는 두 가지 기술의 장점을 갖는 플랫폼으로 계획되고 개발됐다. 즉, 자바 언어의 장점을 수용하며 네이티브 바이너리의 실행 성능을 갖도록 하는 것이다.

따라서 WIPI 플랫폼은 C/C++와 자바를 기본 언어로 채택해 프로그램 개발이 가능하고, 단말기에 탑재되는 애플리케이션은 네이티브 바이너리로 만들어져 실행 성능을 보장받는다. 여기서 C/C++ 언어는 네이티브 바이너리를 생성하는 데 아무런 문제가 없으나, 자바 언어는 기본적으로 가상 기계를 대상으로 하기 때문에 자바를 컴파일해 단말기에서 직접 실행가능한 실행 바이너리를 어디선가 만들어야 한다. 이러한 기능을 수행하는 WIPI 구성요소가 바로 COD(Compile On Demand)다.

이하에서는 COD/ATOC에 대해 설명한다. COD는 AOTC(Ahead Of Time Compile) 기술이 포함된 일종의 서비스 프레임워크를 표현하는 말이다. COD란 단어가 표현하고 있는 것을 대부분의 사람들은 사용자 요구에 의한 프로그램 컴파일 이라고 생각한다. 즉, 사용자가 어떤 프로그램을 자기 단말기로 다운받기를 원하면 자바 프로그램은 시스템에 의해 컴파일되고, 해당 단말기에서 실행되는 바이너리로 생성되어 다운로드될 것이라는 것이다. 물론 이러한 시스템 구성도 가능하다. 이런 경우라면 동일한 종류의 단말기에 동일한 프로그램을 탑재시키기 위해 시스템에서 동일한 바이너리를 생성하기 위한 반복적인 작업으로 많은 자원을 낭비하는 결과를 초래할 것이다.

하지만 요구(Demand)의 주체가 사용자가 아닌 프로그램 개발자 또는 시스템 관리자라고 생각하면 어떨까. 이렇게 되면 프로그램 개발자는 COD 시스템에 자신이 개발한 프로그램을 제공하고 단말기에 탑재할 수 있는 실행 바이너리를 생성해 관리한다. 만일 사용자가 다운로드를 요구하면 이미 컴파일된 실행 바이너리를 선택해 다운로드하면 된다. 현재 COD 시스템은 후자와 같은 서비스 흐름을 갖는 시스템으로 구현되어 있다.

그러면 AOTC는 어떤 기술인가. 앞서 언급된 바와 같이 자바로 작성된 프로그램이 단말 환경에서 빠른 실행 속도를 보장받기 위해 가상 기계를 이용하지 않고 단말에서 직접 실행되는 바이너리 형태를 가져야 한다.

COD 시스템은 크게 두 가지 기능으로 구별할 수 있다. 첫째가 AOTC 부분이며, 두 번째가 AOTC 결과물을 패키징하고 관리하며 단말기에 다운로드하는 과정이다. 도 1은 이러한 일련의 과정을 표시한 것이다.

이를 입출력의 관점에서 보면 COD 시스템은 개발자가 제공하는 자바 클래스파일을 입력으로 일련의 과정을 거쳐 단말기 사용자에게 프로그램 바이너리 이미지 파일을 제공한다. COD 내부에서는 입력된 자바 바이트코드를 분석해 해당 분석 정보를 기반으로 이와 동일한 기능을 갖는 C/C++ 프로그램으로 번역한다. 또한 이렇게 만들어진 소스를 자동으로 컴파일할 수 있는 Makefile도 같이 만들어 컴파일러를 구동한다. 이에 대한 시스템 관점의 흐름을 아래의 "서비스 프레임워크"에서 좀더 자세히 설명한다.

< COD 서비스 프레임워크 >

그렇다면 과연 COD는 실제 어디에 어떻게 위치해 동작하는 것인가. 도 2는 이러한 관점에서 가능한 실제에 가까운 시스템 구성을 표현한 것이다. 여기서 COD는 여러 시스템에 나눠 있으며 매우 다양한 작업을 수행하게 된다. 이 도면을 몇 가지 단계로 나눠 설명하면 다음과 같다.

① 개발자의 프로그램 제공

WIPI 프로그램 개발자는 프로그램을 WIPI SDK 등에서 제공되는 기능을 이용해 프로그램을 개발하고, 자바 컴파일러를 이용해 클래스 파일을 생성한 후 JAR(Java Archive) 형태로 프로그램 정보와 함께 묶어 Content Provider Web Site 를 통해 제출한다. 제출된 프로그램은 검증 과정을 거쳐 프로비져닝(provisioning) 서버에 등록되는 것으로 개발자 프로그램 제공 과정이 마무리된다.

② Compile On Demand

개발자에 의해 제출된 프로그램은 시스템 관리자 또는 개발자 자신에 의해 컴파일을 요청하며, COD 프로세스는 이 요청에 의해 해당 프로그램을 단말기에서작동가능한 바이너리로 생성한다. 정상적으로 생성된 바이너리는 다운로드 형태로 패키징돼 애플리케이션 스토어 데이터베이스에 등록되어 사용자의 다운로드 요청을 기다린다.

③ 애플리케이션 다운로드

사용자는 단말기를 이용해 서버에 접속해 다운로드가 가능한 프로그램을 검색하고 다운로드할 수 있다. 물론, 이 과정도 그리 단순하지만은 않다. 예를 들면, 접속한 단말기의 종류를 확인하고, 사용자가 정상적인 사용자인지 검사하고, 특히 연령제한을 받는 프로그램이라면 이에 대한 확인 작업이 선행되며 각각의 경우에 발생할 수 있는 오류를 적절한 형태로 단말기에 반환해 사용자에게 적합한 메시지를 제공해야 한다. 다운로드를 위한 모든 준비과정이 정상적으로 수행되었을 때 다운로드가 수행된다. 즉, 어디선가 자바 프로그램을 바이너리로 만들어야 한다. AOTC는 이러한 요구를 충족시킬 수 있는 자바 관련 기술이다.

이상과 같은 세 가지 정도의 중요 경로를 설명했으나 실제 서비스에는 훨씬 다양하고 복잡한 과정이 포함되어 있다. 또한 이러한 과정은 서비스 제공자에 따라 약간씩 차이점을 가지고 있다.

그러면, 과연 COD가 개발자에게 제공하는 이점은 무엇인가. 이는 지금까지 지속적으로 언급돼 온 자바 언어를 무선인터넷 플랫폼을 위한 개발언어로 사용해 얻어지는 이익과 거의 동일하다. 또한 AOTC 기술이 사용돼 추가적으로 얻어지는 장점도 있을 것이다.

첫 번째는 자바 언어 수준의 신뢰할 수 있는 안정성을 제공한다. 자바 언어를 사용함으로써 개발자는 개발과정에서 발생할 수 있는 모든 종류의 오류로부터 자유로워질 수 있다. 즉, 자바의 예외 처리 기능을 통해 안정적인 프로그램 작성이 가능하며, 또한 개발자의 실수에 의해 발생하는 시스템 오류 문제를 근본적으로 회피할 수 있다. 많은 독자들이 생각하듯 이동통신 단말기가 구동되고 실행되는 환경은 매우 열악하다. 물론, 시스템의 보호를 위해 많은 보호장치를 하고는 있으나 이는 매우 미미하며 독자들이 일반적으로 사용하고 있는 PC의 운영체제와는 비교도 되지 않을 정도의 초보적인 운영체제를 이용하고 있다.

따라서 단말기에서 실행되는 프로그램이 발생시키는 오류에 의해 단말기 자체의 작동이 불가능한 상태가 발생될 수 있다. 일반적으로 지금까지 바이너리 실행환경의 단말기 플랫폼 개발자는 이러한 오류 발생을 근본적으로 회피할 수 없는 환경이었다. COD에 의해 제공되는 이러한 신뢰할 수 있는 안정성은 프로그램 개발자뿐만 아니라 무선인터넷 서비스를 제공하는 이동통신사에게도 매우 중요한 요소다.

또 다른 장점은 개발자에게 매우 일반적이고 잘 알려진 개발 환경을 제공한다. 자바 프로그램의 개발 환경은 개발자에게 매우 친숙하며 쉬운 사용자 인터페이스를 제공하고 있다. 이러한 개발 환경을 개발자는 동일하게 사용해 개발 작업을 진행할 수 있기 때문에 무선인터넷 플랫폼을 위한 별도의 개발 환경에 적응해야 하는 시간이 필요하지 않다. 또한 WIPI API는 기존의 자바 프로그램 개발자라면 특별한 노력을 들이지 않고도 쉽게 이해할 수 있는 구조를 지원하고 있다. 따라서 날로 확산되고 있는 자바 프로그램 개발자가 쉽게 무선인터넷을 위한 프로그램 개발이 가능해 짧은 기간 내에 많은 개발자의 흡수가 가능하다.

마지막으로 AOTC에 의해 생성된 바이너리는 단말기에서의 빠른 수행속도를 제공하기 때문에 많은 장점을 가질 수 있다. 즉, 가상 기계를 사용하는 구조에 비해 상대적으로 매우 뛰어난 성능을 제공해 멀티미디어 서비스와 같은 고속 처리가 필요한 프로그램 개발과 서비스가 가능하다. AOTC의 결과물은 단말기에 최적화된 실행 바이너리로 단말기에서 최상의 성능을 갖도록 튜닝되어 있다. 이는 지금까지 우리가 일반적으로 생각하는 자바는 느리다 는 인식을 불식시키기에 충분하다. 물론 C 언어로 작성된 프로그램보다 빠르다는 이야기는 아니다. 그렇지만 충분히 이에 근접하는 성능을 AOTC를 통해 제공해 고성능의 프로그램 작성을 위한 기반을 제공한다.

< COD 코드변환기 >

COD의 구성요소에서 가장 중요한 코드변환기에 대해 알아보자. 독자들이 아는 바와 같이 자바와 C++ 언어는 객체지향 언어의 대표주자다. 즉, 두 언어 모두 객체를 다루기 위해 설계된 언어이므로 그 구조나 형태가 매우 유사하다.

코드변환기의 아이디어는 여기에서 시작된 것이다. 물론 자바와 C++ 언어가 구조적인 유사성이 매우 높은 언어이긴 하지만 프로그래밍 언어론 관점의 구문이 일치하지는 않는다. 즉, 매우 미묘한 부분의 차이에 의해 자바 프로그램을 C++ 언어로 변환하는 것은 자동화 과정에 많은 기술적 어려움을 겪을 수밖에 없다. 물론 두 가지 언어를 모두 잘 알고 사용할 수 있는 개발자가 직접 자바로 구현된 내용을 C++로 프로그래밍적으로 구현하는 것은 그리 어려운 일은 아니다.

코드변환기는 자바 클래스 파일(바이트코드)을 이와 동일한 기능을 갖는 C++언어로 변환하는 기능을 수행하며, 또한 생성된 C++ 프로그램을 컴파일하기 위한 Makefile을 자동으로 생성한다. 코드 변환기의 중요 구성요소를 몇가지 정리하면 다음과 같으며, AOTC에 관련된 많은 자료는 인터넷을 통해 얻을 수 있다.

자바 바이트코드 분석기 : 코드변환기에 입력되는 클래스파일을 분석하여 클래스의 구조를 추출하는 기능을 갖는다. 여기에서 생성되는 분석정보를 이용하여 C++ 코드를 생성하게 된다.

C/C++ 코드 생성기 : 바이트코드 분석기와 기타 분석기에 의해 생성된 클래스 분석정보를 기반으로하여 동일한 구조를 사상하는 C++ 소스코드를 생성한다.

Runtime Type Information 분석기 : 클래스에서 사용되는 Java 변수형과 C++로 변환된 경우에 대응하는 변수형 및 이에 대한 기능을 사상하기위한 자료형 정보 분석 기능을 갖는다.

Exception Handler 생성기 : Java 예외처리기능을 C++ 예외처리기능으로 사상하는 기능을 제공한다.

Inline Function 생성기 : 수행속도의 최적화를 위하여 멤버함수의 구성에 따라 Inline 처리가 가능한 함수를 분류하고 C++ 코드 생성시 Inline 함수로 구현하는 기능을 갖는다.

도 3은 COD 서비스 구조를 설명하는 도면이다.

① Java 어플리케이션에 포함된 자바 class file(byte-code)을 클래스 분석기를 통해 분석하고 각 클래스 별로 분석 결과 구조체를 생성한다 (분석 결과 구조체는 자바 클래스내에 선언된 함수와 변수, 상수, 함수내의 예외처리 영역 정보 등과, 해당 클래스내에서 참조된 외부 클래스의 함수 및 필드 등의 정보로 구성).

② 분석 결과에 따라 해당 C++ 헤더파일(*.h)을 생성하고, 각 함수에 포함된 자바의 가상 기계어(byte-code)를 분석하여 C++ 소스파일(*.cpp)을 생성한다.

③ 자바 어플리케이션을 생성하기 위한 Makefile을 생성한다.

④ 필요시, 생성된 C++ 코드를 수정하거나, 새로운 C/C++ 코드나, 라이브러리를 Makefile에 추가한다.

⑤ C/C++ 컴파일러를 구동하여 어플리케이션을 구동할 기기에 적합한 바이너리 이미지를 생성한다.

⑥ 자바 어플리케이션을 변환한 이미지를 단말기에 전송한다.

한편, 컴파일 온 디멘드 서버 운영 방식으로는 다음과 같은 것이 있다.

(1) 개방형 : 단말기의 요청이 있을 때마다, 단말기가 요청한 자바 어플리케이션을 인터넷을 통하여 다운로드받은 후, ①부터 ⑥까지의 절차를 수행한다 (단말기 사용자가 자유로이 임의의 애플리케이션을 다운로드할 수 있음).

(2) 폐쇄형 : 개발자가 애플리케이션을 서버에 등록할 때, ①부터 ⑤까지의 절차를 수행한 후, 단말기의의 요청이 있을 때는 절차 ⑥만 수행한다 (애플리케이션별 보안레벨 설정이 가능하고, 컨텐트의 분류 및 등급화, 과금 시스템과의 연동이 손쉬우며, 서버의 부하를 줄일 수 있음).

(3) 조합형 : 개방형과 폐쇄형을 조합하여 사용하되, 개방형 서비스의 경우엔 애플리케이션의 보안 레벨을 일정 수준 이하로 한정한다.

도 4는 본 발명의 세부수행내용을 나타내는 도면이다.

COD MoNET 개발에 있어서 단말기와 다운로드서버 시스템간의 통신 방식은 TCP/IP기반의 HTTP 프로토콜을 사용하며, Provisioning 및 프로그램 검색 등은 XML을 기반으로 할 수 있다. MoNET의 Transcoding 대상은 Java Bytecode를 C++로 변환하는 것이며, 기존 VM Contents의 경우 Java MIDP기반으로 작성된 Contents는 Platform에서 MIDP Wrapper를 제공할 경우 별도의 변환작업 없이 적용 가능하다.

아울러 MAP, GVM, BREW Contents의 경우에도 Java MIDP 기반의 Contents 와 같이 Platform 수행업체에서 Wrapper를 지원한다면 같은 방식으로 적용이 가능하다.

C/C++ 언어의 경우 Platform에서 제공하는 C/C++용 Header파일을 사용하여 개발하게 되면 아무런 문제도 발생하지 않으며, H/W Platform에 대한 Independancy 은 Arm7,Arm9,StrongArm 등 각각의 H/W Target 바이너리를 생성하는 것을 고려할 수 있다. 악의적인 memory access의 문제를 검사하기 위하여 application인증이 필요한 것이며, MoNET은 인증이 완료된 Code(Java/C/C++)를 단말기에서 직접 동작 가능한 native binary로 변환하는 과정을 처리하게 된다.

본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플라피디스크, 광데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.

이상 도면과 명세서에서 최적 실시예들이 개시되었다. 여기서 특정한 용어들이 사용되었으나, 이는 단지 본 발명을 설명하기 위한 목적에서 사용된 것이지 의미 한정이나 특허청구범위에 기재된 본 발명의 범위를 제한하기 위하여 사용된 것은 아니다. 그러므로 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 특허청구범위의 기술적 사상에 의해 정해져야 할 것이다.

본 발명에 의하면, 기존의 자바의 안정성을 유지하면서도, 어플리케이션 속도향상의 제한 요소인 VM방식을 탈피하도록 다운로드할 수 있는 요소(Downloadable component)를 제작할 수 있다.

본 발명을 자바 VM방식과의 비교하면, VM방식은 바이트코드(Bytecode)에서 바이너리코드(Binary Code)로 변환하는 과정을 이동 단말기에서 수행하므로, 초기 구동시간이나 속도에 있어 문제점을 내포하고 있는데 반해, 별도의 COD 서버를 이용, Bytecode를 Binary code로 변환하고 변환된 Binary code 만을 이동 단말기로 다운로드 하는 방식은 초기 구동시간이나 속도 문제를 원천적으로 해결하는 대안을 제공한다.

또한, Brew와 비교하면, Brew의 경우에는 C/C++ 언어만 사용이 가능하므로기본적인 Exception Handling이나, Runtime Type Checking이 취약하며 따라서 단말기를 Reset시키거나 하는 문제점이 발생할 수 있는데 반해, COD에서 지원하는 Dynamic Type Checking이나 Exception Handling, Garbage Collection등은 컴포넌트 실행 시의 안정성을 보장하는 좋은 메커니즘이 된다.

본 COD 서버나 Compiler는 기본적으로 Platform에 대한 귀속성이 없으므로, 다른 이동 단말기 (예를 들면, PDA, IMT-2000 단말기 등)에 손쉽게 적용될 수 있다.

Claims (1)

1. Java를 컴파일해 무선인터넷플랫폼이 탑재된 이동통신단말기에서 직접 실행가능한 실행 바이너리로 만드는 방법 및 그 시스템