본 원고는 마이크로소프트 2008년 5월에 기고한 기사입니다.참조시 출처만 밝히시면 됩니다
Android – OSGi 통합
첫번째로 안드로이드에 OSGi를 탑재하여 구동하는 것은 그렇게 어려운 문제는 아니다. 그것은 이미 OSGi가 다양한 VM에 포팅되어 탑재된 경험이 있기때문이다. OSGi는 기존 JVM이 아닌 Dalvik이라는 VM을 통해서 구동되므로, Dexification이라는 절차를 거쳐서 JAR파일이 Dex 파일로 수행된다는 것을 인식시켜준다. Apache-Felix에서는 큰문제없이 구동되었으나, Equinox에서는 몇가지 사항을 수정해야만 했다. Equinox에서는 어떤 Properties를 수정하기위해서 CodeSource를 사용하는데 반해, Android에서는 ProtectionDomain이 null이기 때문에 아예 CodeSource를 사용할 수가 없다. 따라서 직접 코드에 정해주어야만한다. 또한, ClassLoader.getResource()는 hook된 Configuration Property File의 리스트를 사용하는데 반해 안드로이드는 아예 null 값을 리턴하기에, configuration.ini에 직접 리스트값을 정의해야한다. 이러한 각 OSGi와 안드로이드의 환경설정을 맞추어주면, 안드로이드에서 OSGi Framework를 수행하는 것은 무리가 없다.
마지막으로, 번들의 구성이다. 번들의 개발은 OSGi Framework 구동과는 좀 다른 차원의 문제이다. 가장 큰 문제점들이 자바에서 공식적으로 발표되고 사용하는 API가 Full로 안드로이드에서는 지원되지않는다는것이다. 이 부분은 매우 중요한 부분으로 OSGi Framework에서 번들을 다이나믹하게 로드하고 수행하는데, 표준 API가 필요한데, 안드로이드가 지원하지않게되면, 독자적인 안드로이드 API를 사용하기위해서 직접 개발해주어야하는 문제가 따른다. 그것은 무엇보다 Dalvik VM의 특성을 따르게된다. 일반적인 ClassLoader.defineClass()가 작동하지않고 Dalvik의 android.dalvik.Dexfile을 사용하거나, nested JARs과 directory bundles를 사용할 수가 없다. 또한 간단한 bundle classpath만을 사용할 수가 있는 등, 제약사항들이 있다. 따라서 그에 대한 Exception 처리 또는 코드를 수정해야만 한다. 하지만, 가장 큰 문제점은 역시 수행시간이다. Dexification이라고 불리는 단계에서 바이트코드와 Dex 파일 변환이 동시에 이루어지기가 어룝기 때문에 JIT 기능을 수행하는 성능이 매우 떨어지게 된다. Dexification의 JIT 최적화 문제는 반드시 해결되어야하는 이슈이다. 또한 Full Bundle-ClassPath 지원도 필요하다. 지금은 간단한 bundle-classPath 지원만 가능한데, 이 부분은 불필요한 메모리 낭비가 동반되기 때문에 역시 반드시 해결되어야하는 부분이다. 따라서 이러한 문제점을 보완하고 해결하기위해서 Equinox Incubator 프로젝트로 Android-OSGi 솔루션이 개발되고 있다.
Prosyst OSGi on the Android
안드로이드 플랫폼위에 OSGi를 탑재하려는 벤더들의 노력들이 있는데, 그중 대표적인 업체가 바로 Prosyst이다. Prosyst는 독일이 본사인 유럽의 대표적인 OSGi 전문 벤더로서 다양한 상용화 솔루션을 보유하고 있다. 노키아 S60 스마트폰 플랫폼, BMW 텔레매틱스, 필립스 홈네트워크 컨트롤러 iPronto가 바로 Prosyst OSGi 솔루션을 탑재하여 서비스하고 있다. 그 외에도 미국의 스프린트사가 차세대 모바일 솔루션으로 Prosyst 솔루션을 그리고 최근에는 네트워크업계의 강자인 시스코가 자사의 차세대 라우터에 Prosyst의 OSGi 솔루션 mBS를 탑재하여 상용화하였다. OSGi Alliance, OSGi Developer Community 등의 행사들을 유럽에서 진행할 때 대부분 주관하는 것을 보면, 국내에는 다소 생소할뿐 유럽에서는 최고의 업체로 군림하고 있다. (OSGi에 관심이 있는 개발자라면 Prosyst는 누구나 알것이다) 이 업체에서도 역시 안드로이드 플랫폼에 자사의 OSGi 솔루션을 탑재하는 것을 목표로 다양한 연구개발을 진행하고 있는데, 대표적으로 mBS의 탑재와 Servo 솔루션이 있다. Prosyst에서 내세우는 Android-OSGi 장점은 다음과 같다.
1. Lack of class-sharing: 안드로이드는 각각의 VM에서 프로세스가 구동되는 구조이기 때문에, 클래스의 공유는 클래스를 복제하는 방법으로 지원한다. 이러한 구조는 심각한 메모리 누수를 가져오고, 성능의 저하를 예견한다. OSGi는 안드로이드에 비해서 직접적인 클래스 공유를 통해 작은 메모리 사용과 성능향상을 나타낸다.
2. Fine-grained components: 안드로이드는 구조적으로 컴포넌트간 IPC와 같은 추상화 레벨의 인터페이스를 통해서 통신하게된다. 컴포넌트간의 가장 효율적인 통신 방안은 Directly Method calls이다. 이러한 컴포넌트간 통신 모델은 이클립스의 RCP, eRCP와 같은 플러그인 아키텍쳐를 가능케하며, 훨씬 효율적인 컴포넌트 구성을 용이하게 한다.
3. Device Management: 원격 관리 및 지원 기능은 모바일 디바이스와 서비스업체의 서버간 중요한 기능으로 점차 부각되고 있다. 하지만, 아쉽게도 안드로이드는 원격 관리에 대한 기능이 지원되지 않는다. OSGi에서는 rOSGi를 비롯하여 OMA-DM을 통한 다양한 원격 모바일 솔루션을 이미 상용화하여 서비스하고 있다.
이러한 특징을 전면에 내세우고, Prosyst는 mBS와 Servo 솔루션을 상용화에 전력투구하고 있다. mBS가 전통적인 Android-OSGi 솔루션이라면, Servo는 보다 현실적으로 안드로이드에 접근하고 있다. 안드로이드를 채택한 휴대폰에서 구현되고 저정되는 다양한 데이터를 저장하고 관리하는데 초점을 두고있는 솔루션이다.
[그림 1] 안드로이드에 탑재된 Servo 아키텍쳐
특히 사용자의 다양한 형태의 자료를 저장하는 것을 UGD로(User Generated Data) 명명하고 기존의 안드로이드의 SQLite가 아닌 DB4O라는 OODB를 채택하여 사용하는데, DB4O 엔진이 OSGi 번들로 구성되어 있어서 다이나믹한 로드와 OSGi의 직접적인 관리를 받게된다. 한편 DB4O는 OSGi 번들용으로 구현되어 기존의 임베디드 DB 보다도 작은 코드 사이즈, 빠른 성능, 완벽한 SQL 지원으로 그리고 무엇보다 오픈 소스로서 SQLite를 채택하고 있는 안드로이드 플랫폼에 보다 적합한 OSGi용 DB 솔루션으로 주목받고 있다. Prosyst는 이러한 Servo 솔루션을 강력하게 모바일 서비스 업체와 제조업체에 드라이브하고 있으며, 그 결과로 중국의 차이나 모바일과 작년부터 개발에 들어가서 내년 안드로이드 휴대폰을 중국에 서비스하는 것을 목표로 하고 있다. 또한 국내의 모바일 서비스 업체와 제조업체와도 활발한 교류를 하고 있다.
