구글의 의도가 성공할 지는 알 수 없다. OS나 미들웨어 등 안드로이드와 직접 경쟁하는 사업영역의 메이커는 하루아침에 무너뜨릴 수 있을 정도로 휴대폰 시장이 간단하지는 않다고 주장한다. OHA에 가입한 기업 중에는 반신반의 하는 곳도 적지 않다. 구글이 호언장담 하는 구상이 순조롭게 진행되면 거기에 잘 편승하여 자사의 이익으로 연결시키고자 하는 의도가 엿보인다. 가령 구글이 실패하더라도 손실은 크지 않다. 하지만, 만약 구글이 예상한대로 일이 진행되면 모바일 사업자나 휴대폰 메이커에게도 결단코 희망적이지 않은 미래가 도래할 수도 있다. 지금까지 구글의 강점은 각 업체들의 전략을 뛰어넘는 앞선 미래의 전략을 주도해온 것이다. 무상화에 따른 광고나 인터넷 솔루션 서비스(이메일, 검색 등) 역시 이미 시행을 해오고 있었던 전략과 솔루션이었다. 그러나 구글은 그것을 다른 업체들과 같은 레벨에서 시행하지않고, 미래를 내다보며 과감하게 투자하고 계속해서 판도라의 상자들을 남들보다 더 빨리 열어서 유저들에게 고객들에게 다가갔다. 이번 안드로이드 플랫폼도 같은 연장선상에 있다. LiMO를 통해서 오픈 소스의 플랫폼 단체가 있었지만, 진정한 유니버셜 플랫폼과 무상화 솔루션으로 경쟁자보다 먼저 치고 나가기 시작했다. 물론 아직 출발선상에서 한두 발자국을 간신히 내딛었을뿐이다.
[그림 1] 모바일 사업자로서의 구글 성공 가능성
소비자, 단말기 메이커, 휴대전화 사업자, OS 등의 소프트웨어 메이커가 구글의 시장진출에 따라 어떠한 영향을 받을 것인지를 나타냈다. 당장은 단말기 메이커나 휴대전화 사업자는 구글의 무상 OS 등을 통해 제조비용이나 조달비용을 절감할 가능성이 있기 때문에 혜택을 받는다. 한편 OS 등 소프트웨어를 유상으로 제공하는 메이커에게는 커다란 위협이다. 그 후 안드로이드의 이용이 확산될 경우, 단말기 메이커나 휴대전화 사업자도 불리한 직면에 부닥치게 된다. 예를 들면 단말기 메이커는 단말기의 차별화가 지금까지 이상으로 어려워질 가능성이 있다. 휴대전화 사업자에게는 음악전송사업 등 자사에서 관리하는 서비스 사업에 대해 경쟁 사업자가 늘어날 위험이 있다. 구글이 안드로이드를 통해 실현하고자 하는 것은 지금까지 기기 메이커나 모바일 사업자가 중심이 되어 진행해 온 기기개발이나 서비스 제공에 제3자의 대폭적인 개입을 용납하는 것이라고 간주할 수 있다. 이른바 휴대폰의 PC화이다. 이에 따라 구글은 인터넷상의 서비스에 접속하는 비용을 대폭 낮추려는 목표를 달성할 수 있다. 그러나 모바일 사업자나 휴대폰 메이커는 불이익을 당할 수도 있다. 모바일 사업자는 현재 자사 경유로 제공 중인 컨텐츠 관련 서비스의 주도권을 타사에 뺏길 수도 있다. 휴대폰은 PC와 마찬가지로 누구라도 만들 수 있는 기기가 될 가능성이 있다.
인터넷과 모든 정보는 구글을 통한다
구글의 안드로이드는 이러한 모바일 세계를 실현하려고 하는 것은 미래 핵심 사업 전략이다. 구글이 시간을 가지고 차분히 준비하는 것은 모바일사업에 흥미를 나타내고 있는 것을 보더라도 알 수 있다. 구글이 노리는 '열린 세계'을 구축을 가로막는 커다란 벽이 모바일 사업자라는 것은 쉽게 상상할 수 있다. 음성이나 데이터 통신만으로는 수익에 한계가 있는 모바일 사업자 입장에서 컨텐츠 관련 서비스의 주도권을 뺏기는 것은 도저히 간과할 수 없는 사태이다. 이를 회피하기 위해서 모바일 사업자는 여러 가지 방법을 취할 것이다. 예를 들면 '서비스 품질'이나 '안전성 보증'이라는 명목으로 모바일에서 이용할 수 있는 서비스에 일정한 제한을 둘 가능성이 있다. 자사에서 이용하는 휴대폰 사양을 결정하는 특권을 행사하면 쉽게 제한할 수 있다. 구글은 이러한 저항을 미연에 방지할 대책을 강구하고 있다. 그 전략의 일부는 미국의 700MHz대의 주파수 경매에서 공개했다. 경매에서 구글은 주파수를 관할하는 미FCC(연방통신위원회)에 몇 가지 조건을 제안했다. 요약하면 '주파수대의 획득자는 소비자가 자유롭게 서비스나 단말기를 선택하여 이용할 권리를 보증하는 것'이다. FCC는 이에 대해 경매에 부치는 주파수 대역의 일부를 '옥션 플랫폼'이라 하고, 구글의 요구에 부합한 형태의 제한을 담았다. FCC의 결정은 미국의 모바일 사업자에게 벌써 영향을 미치고 있다. 미국에서 제2위 사업자인 Verizon Wireless사는 2008년 후반을 목표로 자사가 소유한 모바일망을 다른 서비스나 컨텐츠 사업자에게 개방할 방침을 발표했다. 자사가 소유한 네트워크나 주파수를 사용하여 다른 사업자가 서비스나 컨텐츠를 제공하거나 단말기를 판매하는 것을 인정한다. 그러나 기존의 사업자에 의한 노력은 그림의 떡이 될 가능성이 있다. 자사 경유의 서비스 밖에 받을 수 없는 단말기를 저가로 계속 판매하여 오픈된 단말기 효력을 떨어뜨릴지도 모른다. 구글은 거기까지 꿰뚫고 있는 듯하다. 비록 구글은 700MHz대의 경매에 탈락했지만, 계속해서 그러한 노력을 할것이며 자신이 주파수대를 억제함으로써 오픈된 서비스의 도화선 역할을 하려는 것이다.
구글, 모바일까지 승자가 될것인가
모바일 사업자의 폐쇄적인 사업 규제 장치가 작동하지 않게 되면 서비스나 단말 기기 개발의 오픈화는 단숨에 진행될 것이다. 그 때 단말기 메이커는 PC시장과 마찬가지로 격렬한 가격경쟁에 휩쓸리게 될 것이다. 구글의 목적은 휴대폰에 그치지 않는다. 네트워크로 연결되는 모든 기기가 대상이 될 수 있다. 당분간은 휴대폰의 얼굴인 안드로이드 궁극적인 목표는 "장래에는 PC에 가까워질 것이다. 우리는 카 네비게이션이나 셋톱박스에도 흥미가 있다". 물론 구글의 구상이 실패할 가능성은 있다. 그러나 구글이 연 기기와 서비스의 오픈화라고 하는 판도라의 상자가 닫힐 일은 없을 것이다. 기술은 탁월하지만, 독자적인 기술을 고집한 가까운 일본 모바일시장의 폐색감을 보면 알 수 있듯이 소프트웨어의 자사개발을 고집하더라도 새로운 것을 만들 수 없게 되어 있다. 만들면 팔린다는 행복한 시대는 끝났다. 더 이상 모든 것을 단독 개발하려고 하는 메이커는 없을 것이다. 완성된 것을 최대한 이용하여 유저에게 보이는 부분의 차별화에 추력하는 것이 메이커의 역할이다. 하지만 여전히 PC시장에서 살아남아 있는 메이커가 많이 있는 것처럼 오픈된 세계에서도 생존하는 방법은 있다. 중요한 것은 타사에는 없는 독자적인 특징이다. 특징을 표출시키는 방법은 여러 가지가 있을 수 있다. 사용의 편리함, 디자인, 견고함, 가격 등 일일이 열거할 수 없다. 각각의 방법으로 타사와의 간격을 벌이는 특징을 만들어 낼 수 있는 기업이 오픈된 시대의 승자가 될 것이다.
본 원고는 마이크로소프트 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 솔루션을 강력하게 모바일 서비스 업체와 제조업체에 드라이브하고 있으며, 그 결과로 중국의 차이나 모바일과 작년부터 개발에 들어가서 내년 안드로이드 휴대폰을 중국에 서비스하는 것을 목표로 하고 있다. 또한 국내의 모바일 서비스 업체와 제조업체와도 활발한 교류를 하고 있다.
본 원고는 마이크로소프트 2008년 5월에 기고한 기사입니다.참조시 출처만 밝히시면 됩니다
안드로이드를 사전에서 찾아보면, 그리스어가 어원이고 “인간을 닮은 것”이라고 나온다. 그렇다. 확실히 구글의 안드로이드는 자바 플랫폼을 많이 닮아있다. 하지만, 안드로이드가 인간이 아니듯 구글의 안드로이드 플랫폼은 정확하게 자바는 아니다. 오픈소스가 IT업계의 큰 트랜드로 자리잡은 이 시점에 나타나는 문제점들의 하나는 급격한 소스의 파생이다. fork라고도 하는데, 어쩌면 구글의 안드로이드는 Java의 Fork가 될수도 있겠다. 구글은 왜 모바일과 임베디드 업계에서 점차로 확산되는 J2ME를 채택하지 않았을까? 더 나아가서 채택하지 않았으면서 왜 J2ME의 아키텍쳐를 템플릿으로 참조하여 안드로이드 플랫폼을 탄생시켰을까? 아마도 그것은 SUN의 자바에 대한 극히 폐쇄적인 JCP 정책과 항상 뒤늦은 대응정책때문이었을것이다. SUN은 JCP를 통해서 자바의 로고와 스펙 그리고 업그레이드에 대한 독립적인 그리고 독자적인 권한을 가진다. 항상 남보다 빠르게 시대를 이끌어오고 오픈으로 마켓을 리딩하는 구글로서는 자바 환경에서 독립적인 그리고 무소불위의 권한을 가진 SUN이 자사의 모바일 전략에 큰 걸림돌로 여겨졌을것이다 (물론 뛰어난 자바의 기술력과 확장성은 탐이 났겠지만) 결국 자바와 극히 비슷한(J2ME의 CDC환경) 안드로이드 플랫폼은 일반적인 JVM이 아닌 독립적인 DALVIK이라는 VM을 탄생시켰고, DEX fille이라는 native Dalvik format을 개발자들에게 선물하였다.
[그림 1] 안드로이드와 OSGi 공통 분야
물론, 모바일 업계에서 아직 J2ME-CLDC/MIDP는 메인 스트림이 아직 아니다. 점차 스마트폰을 중심으로 확산은 되고 있지만, 제조업체마다 독립적인 API, 서로 다른 RMI 방식, 고급 UI를 지향하면서 무거워져만가는 GUI 모듈, manifest를 위한 거대한 XML 타입 등 다양한 모바일 실행 환경에 대한 문제점들이 나타나고 있다. 구글은 이러한 문제점들을 해결하고 더욱 고급화되는 UI, 멀티태스킹과 강력한 애플리케이션과 관리솔루션을 J2ME 벤치마킹을 통해서 개선하고자 했다. 하지만, 오픈된 안드로이드 아키텍쳐에는 구글이 플랫폼 구조와 애플리케이션 구동에는 많은 관심을 보여왔지만, J2ME-OSGi 플랫폼에 비해서 독립적인 모듈구조, 애플리케이션의 라이프 싸이클, 애플리케이션을 통합 관리할 수 있는 미들웨어 부분에서 약점을 드러내고 있다. 이러한 문제점들은 OSGi 프래임워크에서 장점으로 내세울수있는 부분이며, 따라서 안드로이드를 오픈한지 얼마되지않은 구글 입장에서는 OSGi를 안드로이드 플랫폼에 통합/연동하거나 안드로이드-OSGi 솔루션으로 확대될것을 기대하는 개발자들이 많이 나타나고 있다. 또한 이러한 개발자들의 요구에 맞춰서 몇몇 전문 벤더에서는 안드로이드-OSGi 솔루션을 이미 개발하여 시장에 진입하려고 하고 있다. 그렇다면, 안드로이드와 OSGi의 차이점과 서로의 연동이 우리에게 가져다주는 장점은 무엇인가? 우선 안드로이드와 OSGi는 크게 VM을 지원하는 방식이 다르다.
[그림 2] 안드로이드와 OSGi 차이
OSGi는 하나의 VM 위에서 구동되어, 각 서비스 또는 애플리케이션이 번들 타입으로 작동하게 된다. 따라서 리소스, 데이터 공유가 쉽고 각 번들의 결합을 통해서 서비스의 생성와 참조가 쉽다. 하지만, 안드로이드는 하나의 VM에서 하나의 프로세스가 애플리케이션으로 구동되어 작동된다. 따라서 프로세스간 데이터, 리소스 공유시 IPC, 메타포어 등을 통해야한다. 하지만, 안정성과 보안 측면에서는 OSGi 보다 우월하다고 할수있다. 그러나, PC 애플리케이션이나 서버급의 엔터프라이즈가 아닌 모바일, 임베디드 환경에서는 더 작은 메모리로 빠르게 서로를 공유하고 참조할 수 있는 그리고 번들, 서비스의 모듈성이 보장되는 OSGi 구조가 훨씬 더 효율적이다.
[그림 3] 효율적인 OSGi 컴포넌트의 참조와 공유
또한 안드로이드에서 오브젝트의 모듈성에 대해서 문제점이 노출되고 있는데, 그것은 바로 DexFile의 구성이다. 표준 클래스 로더가 바이트코드를 로드하기위해서 반드시 하나의 JAR파일과 함께 작성되어야 한다. 따라서 JAR 파일내에 위치한 번들을 찾기위해 번들-클래스패스(Bundle-Classpath) 같은 기능을 사용하기 위해서는 JAR 파일 전체를 핸들하는 불필요한 메모리 누수가 발생하게 된다. 이러한 문제점들은 하나 내지 소수의 애플리케이션을 작성하고 구동할때보다, 다수의 애플리케이션들이 구동될때에 치명적인 약점으로 나타날수가 있다. 그렇다면 OSGi와 안드로이드가 결합될때에 가져다주는 장점은 무엇인가? 그것은 단연 번들의 재사용성이다. J2ME, J2SE를 기반으로 하는 수많은 기존의 번들 코드를 그래도 사용할 수가 있고, 또한 기존의 코드를 이용하여 다양한 서비스의 참조 내지 생성을 통해 안드로이드용 애플리케이션을 빠르게 작성할 수가 있다. 또한 안드로이드 플랫폼에서 작성하는 애플리케이션에 비해서 OSGi 프래임워크에서 지원하는 다이나믹한 코드의 모듈성과 강력한 번들 라이프싸이클 관리시스템으로, 안드로이드 애플리케이션은 실제로 구현하는 Activity 코드와 GUI 부분에 집중해서 개발하기 때문에 코드를 기존의 애플리케이션에 비해서 작은 바이트 코드를 개발할 수가 있다. 마지막으로 강력한 개발툴의 지원이다. 이미 OSGi는 이클립스에 통합이 되어있고, RCP & eRCP라는 개발방법론으로 임베디드-모바일-데스크탑에 이르기까지 다양한 플랫폼에서 전세계 자바 개발자들에게 가광을 받고있다. 이러한 통합된 개발환경과 방법론으로 전세계 자바개발자들에게 안드로이드는 더욱 쉽게 다가갈수가 있을것이다. Android-OSGi 솔루션은 이러한 장점 때문에 기본의 OSGi 업계의 강자인 IBM과 Prosyst에서는 작년 구글에서 오픈된후부터 강력하게 드라이브하고 있다.
한편 Android-OSGi은 쉽게 통합되고 연동될수가 있는것인가? 이에 대한 답변으로 올해 3월 미국 캘리포이나에서 열린 Eclipse 개발자 컨퍼런스 “EclipseCON”에서 찾아볼수가 있었다. EclipseCON은 과거 이클립스라는 개발툴의 오픈소스 개발자들이 모여서 시작된 작은 컨퍼런스인데, 재작년부터 OSGi DevCON과 통합되어서 Eclipse 뿐만 아니라 RCP, OSGi, Server Framework 등 다양한 주제들로 꾸며진다. 이번 OSGi 개발자 세션 역시 별도로 열렸는데, 이번 컨퍼런스에서 IBM의 B.J Hargrave가 Android-OSGi 통합이라는 주제로 큰 호응을 받았다. 위에서 이야기했듯이 Android-OSGi 솔루션에는 IBM, Prosyst 등의 전문 벤더와 스프린트, 모토롤라, 노키아 등의 핸드셋 제조업체등이 큰 관심을 보이면서 드라이브를 하고 있는데, Hargrave는 이번 발표에서 Apache-Felix와 안드로이드 연동 사례, 그리고 실제 상용화 솔루션을 제공하고 있는 Prosyst 사례를 들면서 개발 방법론을 강의하였다. Android-OSGi 연동은 크게 두가지로 이루어진다. 하나는 안드로이드 플랫폼에 프레임워크의 탑재하는 부분과 또 하나는 다이나믹한 번들의 수정 또는 개발이다.
본 원고는 필자가 2008년 1월호 마이크로소프트웨어에 기고한 내용입니다. 자료를 옮기시거나 사용하시려면 출처를 밝혀주시면 됩니다.
자바의 플랫폼에 대한 부분과 표준화 방식에 대해서 이야기 한 것은 JSR 277에 대한 부분을 이야기하기 위함이다. 자바는 JSR, JCP, RI등을 통해서 스펙이 결정되고 발전하는 과정을 거쳐간다. 이미 자바는 JAVA7이라는 새로운 플랫폼 규격을 선보이고 있는데, 그중에서 눈에 띠는 부분이 바로 JSR 277이다. 자바 모듈 시스템이라는 새로운 규격은 자바의 모듈성을 강조하는 새로운 시스템이다. 다만 우리는 OSGi라는 미들웨어 프래임워크를 알고있기에 JSR 277이 OSGi라는 아키텍쳐를 그대로(?) 모방했음을 쉽게 짐작할 수가 있다. 썬에서도 JSR 277은 JSR 291-OSGi 규격과 서로 상호호환하고 경쟁하면서 발전해 나가야한다고 발표하기도 했는데, 여기에는 매우 복잡하고 미묘한 관계들이 엃혀져 있다. 우선 JSR 277이란 무엇인지 알아보기도 한다. 기존 자바에서는 지원하는 모듈방식을 결정하는 것들은 크게 두가지인데, 논리적인 모듈방식(Logical Modularity)과 실질적인 모듈방식(Physical Modularity)이 있다.
[그림1. Java Logical Module View]
논리적인 방식에는 Classes, Packages, Class Loaders 등이 있으며, 실질적인 모듈방식에는 class file과 JAR file 이 있다. 이러한 모듈방식에는 몇가지 문제가 있는데 다음과 같은 것들이다.
1) 제한된 Scoping Mechanisms
2) 기본적인 그리고 제한된 기능의 버전 관리
3) 모듈간 의존성(Implicit Dependency) 문제
4) 패키지에서의 단순한 Class path 관리
5) 불분명한 Class Space Consistency
결국 이러한 부분들은 자바 플랫폼에서 모듈이라는 실행단위가 명확하게 지원되지못하는 문제에서 기인한다고 결론낼수가 있다. 이에 썬에서는 한정적인 자바 플랫폼 위에서(J2ME) 운영되는 OSGi 모델을 자바 플랫폼내에서 구현하기로 결정한다. 하나의 자바 V M 인스턴스에서 운영되는 멀티 서비스, 번들로 구분되는 다이나믹 모듈 시스템, 번들단위로 실행되는 커스텀 클래스 로더에서 얻어지는 많은 장점 – 클래스 로더간의 연결성, 독립적인 Namespace, 패키지 레벨에서의 클래스 공유 – 등이 더 이상 자바 플랫폼에서 운영되는 하나의 OSGi 프래임워크가 아닌 모든 자바 플랫폼에서 운영되는 다이나믹 자바 모듈 시스템으로 확장되는 계기를 마련해주었다. JSR 277에서 중점은 두고 개발한 부분은 다음과 같다.
1) 버전관리 (Version Management)
2) 배포(Distribution) 및 패키징 (Packaging)
3) 새로운 저장소 (New Repository)
4) 모듈간 공유 및 연결성 (Module Interconnection)
이러한 특징들을 위해서 기존 JAR 포맷을 대신하여 JAM이라는 새로운 포맷을 탄생시켰으며, JSR 294와 연합하여 JSR 277 내부에 VM, Language들을 통합시켜버렸다. JAM이 탄생하기까지에는 기존의 JAR가 가져온 문제점들이 너무나 컸기 때문이다. 현재 자바에서 배포의 표준파일 타입은 JAR인데, 단순한 버전관리, 다른 JAR파일과의 레퍼런스 문제, 복수개의 JAR파일과 Native lib과의 연동 그리고 마지막으로 JAR는 배포와 실행 파일의 포맷을 모두 담당하고 있으면서 문제점들을 계속 노출시켜왔다. 결국 JAR가 내포하고 있는 문제점들이 우리가 위에서 살펴본 JSR 277의 탄생 이유이기도 하다. 또한 기존의 클래스 라이브러리들과 JDK 툴들도 통합시켜 확장된 하나의 플랫폼을 탄생시켰다. 이러한 새로운 플랫폼 규격에 가장 큰 특징은 역시 플러그인 스타일의 다이나믹 구조인데, OSGi 번들구조를 그대로 가져온것이라고해도 무방할정도이다. JSR 277에서는 OSGi의 번들을 모듈(Module)이라고 부르는데, JSR 277과 291(OSGi)간의 비교를 해보도록 하자. 우선 JSR 277, 291 모두에게 적용되는 특징은 다음과 같다. (Module는 Bundle로 생각하면 된다)
- Module name
- Module version
- Module attributes
- Module import
- Module re-export
- Version range
- Optional import
- Executable modules
- One class loader per module
- Platform dependencies
- Classes, native libraries, resources, 확장된 metadata가 포함된 Module
- JAR distribution format
- Reflective API
[그림 3. 모듈(번들)별 실행되는 클래스 로더]
반면 JSR277만의 고유한 특징도 있는데, 다음과 같다.
- Standard repository : 하나의 래포지터리에서 다양한 복수개의 모듈을 관리한다
- JAM distribution format : 기존 JAR 보다 더욱 강력한 배포 파일 포맷이다.
- Import override policy
- Part of the Java SE platform
결국 JSR 277 자바 모듈 시스템은 자바 파일의 배포와 실행 그리고 버전관리에 보다 중점을 두고 설계된 시스템이며 이러한 시스템은 OSGi의 번들이 다이나믹하게 플러그인 되고 수행되는 구조를 자바에 맞게 최적화된 구조방식이라고 볼수가 있다. 그러나 자바의 한계를 넘지못한 부분도 여전히 눈에 보이는데, 그것은 독자적인 OSGi만의 특징이기도 하다. 이번에는 JSR 277에 포함되지 못한 JSR 291(OSGi)의 고유 특징을 살펴보자
- Dynamic lifecycle support (번들, 서비스) : 다이나믹한 기능은 여전히 OSGi가 탁월하다
- Package import
- Dynamic package import
- Package attributes
- Mandatory attributes
- Module classpath
- Fragment modules
- Extension modules
- Pure Java implemented on top of Java SE
- Compatible with Java ME (JSR 232)
결국 특징들을 살펴보면 새로운 배포파일의 포맷(JAM)이나 모듈간의 연결성, Repository의 지원등 각자 고유한 부분이 있으나, 플랫폼에서의 다이나믹한 모듈 구조의 설계방식은 같다고 볼수가 있다.
본 원고는 필자가 2008년 1월호 마이크로소프트웨어에 기고한 내용입니다. 자료를 옮기시거나 사용하시려면 출처를 밝혀주시면 됩니다.
요즘 임베디드 혹은 모바일 S/W 개발자들사이에 회자되는 이슈는 아마도 구글폰의 안드로이드 플랫폼이 아닌가 싶다. 구글폰에 대한 루머들은 예전부터 나오고 심지어 상상한 모델 디자인까지도 인터넷에서 떠돌기도 했다. 애플 아이폰이 성공적으로 런칭한 뒤에는 더욱 궁금증이 깊어졌는데, 공개된 구글폰은 하드웨어가 탑재된 하나의 디바이스라기보다는 웹2.0을 이끄는 플랫폼의 리더답게 안드로이드(Android) 라는 OHA를 표방한 모바일 플랫폼이었다. 안드로이드 역시 VM 기반의 자바 애플리케이션을 구동한다. 우리가 지난 호에서 살펴본것처럼 이제 모바일 환경에서도 자바 애플리케이션이 실행되면서 지금보다 훨씬 더 다양하고 강력한 서비스들이 우리들을 찾아오게 된것이다.
결국 모바일 시스템에도 본격적인 플랫폼의 시대가 도래된 것이다. J2ME, J2SE, J2EE로 구분되어 있는 자바 플랫폼은 J2SE만 보더라도 1.1에서 1.2로 현대화된 이후로 1.4와 1.5에 이르면서 상당히 큰 변화가 있었음에도 불구하고 계속 1.x의 버전 번호를 고수해왔다. J2SE 1.4는 코어 플랫폼에 있어 가장 많고 중요한 API 추가가 있었고, J2SE 1.5는 자바 언어 자체에 심대한 발전이 있었다. J2EE도 상황은 마찬가지여서 1.2로 시작하여 1.3에서 EJB 2.0으로 크게 도약한 분산 컴포넌트 기술은 1.4에서 웹 서비스 지원의 추가로 날개를 달았지만 여전히 1.x라는 빈약한 버전을 가지고 있었다. 이러한 상황은 J2SE 1.6과 J2EE 1.5부터는 J2라는 약자를 버리고 자바라는 완전한 이름으로 돌아옴과 동시에 1.6대신 6, 1.5대신 5라는 과감한 버전 업그레이드를 단행하게 되었다. 그리고 Java 7으로 또다른 도약을 꿈꾸고 있다. 물론 아직도 여전히 J2SE와 J2EE라는 말은 자바 플랫폼의 대명사로 많이 쓰이고 있지만, 새 술을 새 부대에 담듯이 자바SE 6와 자바EE 5는 그 새로운 이름과 함께 ‘2’라는 굴레를 벗어나 도약의 로드맵을 사용자에게 제시하는 첫걸음을 디디게 된다.
한편, 자바 ME는 지난 호에서 다루었듯이 버전 번호의 큰 변경은 없지만 내부적으로는 아키택쳐의 큰 변화를 가져왔다. 제약이 많던 CLDC(connected Limited Device Configuration)에서 거의 PC급인 CDC(connected Device Configuration)로 빠른 이전 현상을 보이며 새로운 아키텍쳐 MSA(Mobile Service Architecture)의 실질적인 변화가 일어나고 있다. 자바2 버전이 기존의 버전에 비해서 갖는 가장 큰 중요한 전략은 바로 플랫폼으로서의 자바(Approach to Java Platform)에서 찾을 수 있다. MS라는 한 기업이 내부적인 절차에 의해 개발하는 방식에 비해, 자바는 매우 일찍부터 많은 개발사 혹은 개발자들과 함께 시장을 키워왔다. 또한 이런 기술 주도와 사업 성공의 독립성은 전체 시장의 활성화에 매우 중요하다. 하지만, JCP의 표준화가 아무리 투명한 절차로 진행되더라도, 자바는 여전히 100% 오픈 플랫폼이라는 평가를 받기 어려웠다. 이는 오픈 소스의 대명사인 리눅스와 비교해보면 더욱 확연히 드러난다. 리눅스라는 OS적 오픈 플랫폼에 이은 자바라는 애플리케이션적 오픈 플랫폼의 등장이 장애로 여겨지기도 했다.
물론, 여기에는 두 가지 측면이 있다. 하나는 썬이라는 한 회사가 자바 기술에서 차지하는 비중이며, 또 하나는 그 동안 표준을 강제하며 변종을 억제해 온 통제 시장 구조이다. 물론 이러한 다소 폐쇄적인 구조속에서도 꾸준히 오픈 플랫폼이라는 노력들은 계속 되어져왔다. 자바EE 5의 참조 구현체(Reference Implementation, 이하 RI)가 글래스피시(GlassFish)라는 오픈 소스 프로젝트로 진행되었고, 사용상의 라이선스도 CDDL(Common Development and Deployment License)로 OSI(Open Source Initiative)가 인증한 라이선스이며 GPL(GNU Public License)보다도 쓰기가 편하다. 또한 그 유명한 자바SE 6의 RI도 머스탱(Mustang)이라는 오픈 소스 프로젝트로 공개되어 있다. 물론 여전히 라이선스는 매우 제한적이고 실제 내부 코드 개발 및 사용도 어렵지만, 올해 2007 자바원 컨퍼런스에서 썬의 CEO인 조나단 슈왈츠가 조만간 글래스피시처럼 될 것이라고 공식 발표했다.
이러한 오픈 플랫폼으로 발전하려는 자바의 노력은 시장상황에 어느정도 유리하게 작용하고 있는데, 단적으로 개별적으로 존재하던 많은 기술들이 자바EE와 자바SE라는 구도하에 모여들고 있는 것을 보면 잘 알수가 있다. <그림 3>을 과거 J2EE 1.4와 비교해보면 점점 더 포함되는 JSR이 많아짐을 느낄 수 있다.
한편으로는 비대해지는 듯 보이지만(실제로 플랫폼 자체의 배포판 크기도 늘고 있다), 자바를 지탱해주는 하드웨어의 발전(CPU, 메모리, 하드 디스크, IO 버스 대역폭 등)에 비하면 오히려 하드웨어를 제대로 활용하기 위한 방향이라고 할 수 있다. 특히 자바SE 6의 포용력은 경이롭다. 자바EE 5에도 포함된 XML과 웹 서비스 관련 기술(JSR 109과 JAXR을 제외한 JAXP, StAX, JAXB, SAAJ, JAX-WS)을 모두 포함하고 있다. 심지어 자바 DB라는 100% 자바 기반 RDBMS까지 내장하게 되었다. 이제 Java SE 6 하나만 설치하면 네트워크, XML 처리, 그래픽, 그리고 DB의 저장까지 가능하게 되는 것이다. 그렇다면 어떤 일이 가능해지는 것일까? 사용자가 XML을 주면 그것으로부터 일정 정보를 뽑아 DB에 유지하는 프로그램을 짜야 한다고 생각해보자. 전에는 자바SE뿐만 아니라, XML 처리를 쉽게 하기 위해 JAXB도 따로 깔고(단순히 라이브러리뿐만 아니라 스키마를 처리하는 툴도 필요하다), MySQL과 같은 DBMS와 거기에 맞는 JDBC 드라이버도 구해 넣어야 했다. 그런데 이제 그런 인프라 구축 과정이 일체 필요 없게 되는 것이다. 여기에 자바 퍼시스턴스(Java Persistence) API까지 가미되면, XML 처리와 DB 처리에 XML 이해와 SQL 쿼리가 전혀 필요 없는 자바 지향적 프로그래밍까지 가능해진다. 달리 말하면, 자바 2.0의 컨버전스는 단순히 API의 수집이 아니라 개발 방식에 있어서도 통합을 의미한다고 할 수 있다. 새로운 자바 플렛폼 JAVA7에 탑재되는 새로운 신기술들은 다음과 같다.
● Java SE 7
- JSR 277 Java Module System
- JSR 292 Supporting Dynamically Typed Languages on the Java Platform
- JSR 294 Improved Modularity Support in the Java Programming Language
- JSR 295 Beans Binding
- JSR 296 Swing Application Framework
● Java EE 6
- JSR 208 Java Business Integration (JBI)
- JSR 225 XQuery API for Java (XQJ)
- JSR 235 Service Data Objects (SDO)
- JSR 283 Content Repository for Java Technology API (JCR) 2.0
- JSR 286 Portlet Specification 2.0
- JSR 299 Web Beans
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 12월호에 실린 기사입니다]
[박스 기사] 차세대 모바일 리더는 여전히 노키아인가 ?
세계 1위의 휴대폰 업체 – 노키아 역시 모바일 서비스와 컨텐츠에 많은 연구개발을 수행하고 있다. 지금까지 설명한 새로운 J2ME의 기술 트랜드에는 모두 노키아가 선두에 서고 있는 실정이다. Eclipse, OSGi에는 IBM이 리더일지는 몰라도 모바일 서비스와 컨텐츠 마켓에 오면 노키아가 여전히 독보적으로 군림하고 있다. 차세대 모바일 웹 서비스 – 매쉬업에서도 여전히 노키아가 빠른 행보를 나타내 보여주고 있는데, 다음의 사례를 살펴보기도 한다. 현재 서비스중인 노키아의 N800 웹 타블렛 모델을 보면, OSGi 기반의 Servlet과 GPS, Map을 연동하여 매우 빠르고 정확하게 매쉬업 서비스를 수행하는 것을 보여주고 있다. 물론 현재도 기존의 방법으로 GPS 등의 서비스는 제공하고 있지만, 느리고 비싼 통신 요금에 그렇게 대중에게 강력하게 어필하고 있지못한 형편이다.
하지만 노키아는 OSGi와 모바일 매쉬업을 통한 빠른 위치정보 서비스를 개발하는데 성공했는데, 그 핵심에는 역시 J2ME, OSGi가 있다. MJSP 기반으로 외부의 애플리케이션 연동과 OSGi를 통한 다양한 컨텐츠 서비스의 효율적인 관리, 그리고 특이한 사항으로는 O/S 플랫폼을 임베디드 리눅스를 사용했다는 것이다. 노키아는 심비안이라는 강력한 스마트폰용 O/S가 있는데, 의외로 리눅스를 채택하여 MJSP 플랫폼을 구현하였다. 심비안 역시 편리하고 강력한 자바 개발/운영 환경으로 명성을 떨치고 있는 O/S 이다.
마지막으로 사업 전략적인 측면에서 살펴보면, 미국의 스프린트사와 유럽의 노키아는 3G에서 4G로 넘어가는 현재의 시점에서부터 강력한 연합전선을 펼칠 계획을 가지고 있다. 스프린트 사는 미국의 유력한 통신업체이면서, 노키아는 휴대폰 제조업체이다. 서로의 요구사항이 절묘하게 상충되고 있어서 양사는 향후 모바일 매쉬업 서비스 시장에서 공동 마케팅 및 서비스 개발을 할 가능성이 매우 크다. 또한 노키아사는 스프린트가 강력하게 드라이브하고 있는 4G의 WiMAX(Mobile WiMAX 포함)를 통한 매쉬업 서비스에 매우 흥미를 느끼고 있다. 지금보다 더욱 강력하고 빠른 무선의 브로드번드 마켓이 4G의 WiMAX를 통해서 열릴것으로 예상하면서 기존의 컨텐츠와 4G의 WiMAX를 통합하는 모바일 매쉬업 서비스를 양사가 공동으로 구상하고 있다. 그렇게 되면 현재 PC와 웹에서 매쉬업 서비스와 컨텐츠로 독보적으로 군림하고있는 구글을 제치고 모바일 웹으로 전세계의 IT시장을 장악할 날도 멀지않게 느껴진다. 우리가 상상한 시나리오가 맞든지 혹은 틀렸다 하더라도 현재의 웹2.0이 우리의 휴대폰으로 들오오는 모바일웹 2.0은 곧 아주 빠른 시기에 우리 곁으로 오게될것이다. 그러한 관점에서 본다면 OSGi는 우리 개발자들에게 또 다른 새로운 기회로 다가오고 있는 것이다.
결국 JSR 232 – MOM (Mobile Operational Management)은 MJSP(Mobile Java Service Platform)을 설명하는 개념이며, MJSP 역시 OSGi 기술을 바탕으로 구현되었다고 보면 맞을것이다. 또한 MJSP는 SOA 개념을 바탕으로 컨텐츠 서비스들을 수행할것이며, 미들웨어와 애플리케이션 그리고 플랫폼까지 모든 분야의 핵심을 모바일 환경으로 변화시킬것이다. 한편 우리의 관점을 좀 더 넑게 본다면 지금까지 자바 애플리케이션과 웹서버를 통해서 구현되었던 많은 기업용 IT 시스템과 엔터프라이즈 환경들이 모바일 플랫폼을 통해서 실시간 서비스되고, 그것을 바탕으로 재구성되는 시대가 다시 오게 될것이라는 것을 예측해볼수가 있다. 다이나믹하게 컨텐츠나 컴포넌트들을 관리하고 모니터링되는 웹 컨텐츠 서버와 자바 서블렛은 기본으로 모바일에서 운영될것이고 엔터프라이즈 환경에서 사용되던 프래임워크들이 모바일과 연동되어 빠르고 작은 분산 서비스들을 관리하게 될것이다. 향후의 모바일 플랫폼과 서비스들에 대해서 결론을 내려보자. 제3세대로 불리는 MJSP는 그동안 제한적이었던 모바일 플랫폼에 매쉬업 서비스를 바탕으로 하는 다양한 컨텐츠, SOA를 기반으로 하는 애플리케이션 확장성, 컴포넌트 기반의 효율적인 관리 구조를 본격적으로 가져올것이다. 또한 이러한 기술의 발달은 기존의 구매와 다운로드의 단순한 모바일 비즈니스 모델에서 다이나믹 원격관리로 서비스되는 모바일 애프터마켓을 새롭게 창출해 나갈것이다. 그리고 여전히 휴대폰 제조업체와 몇몇 벤더에 의해서 좌우되었던 고유의 폐쇄적인 플랫폼 중심의 핸드셋 마켓이 컨텐츠, 서비스 중심의 업체들로 중요성이 옮겨가게 될것이다. 그렇기에 노키아와 같은 세계 최대의 휴대폰 제조업체와 플랫폼 업체가 모바일 매쉬업 서비스 개발에 매진하고 있고, 스프린트, 보다폰과 같은 통신 서비스 업체들도 차세대 모바일 웹서비스 시장을 차지하기 위해서 MJSP, OSGi와 같은 기술에 눈을 돌리고 있는 것이다. 이제 OSGi는 임베디드에서 PC, 엔터프라이즈로 확장되고 있지만, 다른 한편으로는 더욱 작은 모바일 시스템에 탑재되어 지금까지 나타난 그 어떤 시장보다 거대한 모바일 웹 마켓의 핵심 기술 요소로 떠오르고 있는 것이다. 이러한 현실은 OSGi 개발자들인 우리에게 또다른 새로운 기회를 가져다 줄것임에는 틀립없는 사실일것이다. 다음 호에는 J2ME 기술 트랜드 두번째 시간으로 자바와 OSGi 진영에서 가장 큰 이슈로 떠오른 자바 모듈 시스템(JSR 277)에 대해서 살펴보자.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 12월호에 실린 기사입니다]
SOA(Service Oriented Architecture), Web 2.0으로 대변되는 웹 플랫폼과 서비스는 과거 인터넷 빅뱅을 능가하는 새로운 비즈니스의 기회와 그에 따른 마켓을 형성하기 시작했다. 그러한 변화는 기존의 엔터프라이즈 및 PC 애플리케이션 비즈니스뿐만 아니라 모바일 시스템에까지 영향을 미치게 되는데, 전세계 유수의 통신사업자들은 기존의 모바일 서비스보다 훨씬 더 빠르고 다양한 컨텐츠들을 고객들에게 제공하기 시작했다. 그러한 새로운 모바일 서비스는 빠른 컨텐츠 서비스 사이클 대체와 저렴한 가격을 전면에 내세우고 있다. 따라서 기존의 모바일 서비스 및 컨텐츠 개발 방법론과 운영환경을 고집하는 벤더들은 도저히 이길 수 없는 싸움을 하게될것이다. 이러한 급변하는 모바일 컨텐츠 서비스에 대응하고자 태어난 기술이 바로 MJSP(Mobile Java Service Platform)이다. MJSP는 하나의 모바일 플랫폼 기술로 운영환경의 구조와 개발방법론, 배포/운영/관리 등의 모든 절차들을 담고있는 포괄적인 아키텍쳐링 기술인데, JSR 232에 의해서 스펙이 제정되었고 현재도 계속해서 발전되고 있다. JSR 232 홈페이지에는 이 기술을 MJSP로 바로 소개하지 않고 Mobile Operational Management 라고 표기가 되어있는데, 그것은 바로 플랫폼의 구조와 운영환경이 다양한 컨텐츠들을 운영하고 관리하는데 초점을 맞췄다는 것을 보다 확실하게 나타내려 했다는 것을 우리는 알 수가 있다. MJSP는 웹2.0을 대응하는 새로운 모바일 자바기술로 휴대폰이 네트워크 환경이나 엔터프라이즈 환경에 연결되었을 때 (Network Connected) 다양하고 다이나믹한 서비스를 제공하는 것을 그 목적으로 한다. 이를 간단히 줄여서 모바일 매쉬업(Mash-up) 서비스라고도 하는데, 우리가 기존의 웹이나 PC 환경에서 제공받던 다양한 서비스들을 그대로 모바일 환경으로 가져왔다고 생각하면 될 것이다.
그렇다면 어떻게 모바일 환경에서 그런 다양하고 다이나믹한 서비스들을 구현할 수가 있었을까? 우리는 모바일 환경이 하드웨어와 리소스의 제한으로 멀티미디어 서비스조차 제대로 구현하기 힘든 조건임을 잘 알고 있다. 위에서 이야기한 모바일 매쉬업 서비스는 다양한 서비스들의 결합으로 이루어져서 제공되는 컨텐츠 서비스인데, 과연 그러한 복잡한 애플리케이션들이 모바일 환경에서 가능할까? 다양한 컴포넌트나 컨텐츠들을 연동하고 찾고 보여주고 관리하려면 리소스의 관리나 상당히 가볍고 빠른 컴포넌트 구조가 필수적이어야 한다. 이러한 요구사항에 적합한 구조가 바로 OSGi 서비스이다. JSR 232의 구조는 실제 OSGi구조와 거의 비슷하다. OSGi의 기본 구조를 더욱 가볍게 슬림하게하여 모바일 환경에 적용했다고 보면 정확한 표현일 것이다. JSR 232 Draft에 보면 MJSP는 멀티 벤더의 모바일 운영 환경을 구현을 목적으로 구현되었으며 일련의 공통적인 모바일 자바 컴포넌트 운영 프로세스 – 개발, 배포, 수행, 관리를 다양한 통신 서비스업체, 개발자들의 요구에 의해서 구현한 자바 애플리케이션과 서비스 플랫폼이라고 정의하고 있다. 또한 JavaOne Conference 2006, 2007 에서는 JSR 232를 소개하는 세션에서 MJSP를 제 3세대 터미널 혁명이라고까지 표현하고 있다. 1세대의 기본적인 API 형태의 표현 서비스를 거쳐 2세대 Native Platform을 통한 독자 API 서비스를 현재의 각 벤더들의 상황으로 진단하고 차세대의 모바일 웹2.0은 3세대 MJSP를 통해서 서비스되고 표현될것을 예측하고 있다.
MJSP의 핵심 개념은 역시 SOA와 OSGi이다. 하드웨어와 리소스의 제한으로 핸드셋에 다양한 애플리케이션들을 인스톨하여 서비스하기는 여전히 어려운 부분이 있다. 따라서 방대한 서비스들을 제공하는 엔터프라이즈 네트워크에 연결되어서 빠르게 서비스들을 찾고 그 서비스들의 결과값만을 나의 휴대폰에서 보여주고 서비스하는 모델로 진화하고 있는 것이다. 또한 그렇게 나의 핸드셋으로 표현되기위해서 다운로드받은 컨텐츠 내지 컴포넌트들을 일괄적으로 관리 수행하는 기능을 OSGi가 담당하고 있게된다. SOA는 종종 웹서비스와 같은 개념으로 혼돈되고 있는데, 정확히 말하면 SOA는 개념적인 요소로서 간단하고 확장 가능한 구조, Self-contained 서비스 그리고 Loose Coupling을 기본으로 하고 있다. 따라서 번들과 서비스로 구현되는 OSGi 구조는 SOA 개념을 충실하게 구현한 Intra-VM 모델로 볼수가 있는 것이다. JSR 232의 구조는 레이어로 구분된 핵심 프래임워크와 서비스로 구성되고 있으며, 컴포넌트 모델은 바로 번들이다.
MJSP 구조를 살펴보면 거의 OSGi와 같다는 것을 볼수가 있다. 다른 것이 있다면 일반적인 OSGi 실행환경이 CDC 기반의 임베디드 환경인데, 여기서는 CLDC 기반의 모바일 환경이라는 것이 다르다. 그것을 가능케 하는 것이 바로 JSR 248 – MSA 규격이다. 이렇듯 JCP는 다양한 JSR을 로드맵에 의해서 점차로 발전시켜나가고 있는 것을 볼수가 있다. 기본적인 구조와 번들 운영환경은 기존의 OSGi와 같으며, 특이한 부분은 바로 Management Architecture와 외부 애플리케이션 연동부분이다. 기존의 OSGi가 하나의 독립적인 실행 환경에서 모든 것들이 대부분 수행된 구조였다면, MJSP은 모바일 매쉬업으로 외부와 연결된 네트워킹된 상태에서 다양한 서비스들을 연동하고 표현하는 것이 가장 큰 차이점이라고 할 수가 있다. 따라서 외부의 네트워크와 연결되어 서비스들을 관리하는 아키텍쳐가 중요한 핵심요소중의 하나이다. OSGi에서도 외부와 연동되어 관리하는 원격관리모듈들과 프로토콜들이 개발되었다. OMA-DM과 SOAP을 사용하는 웹서비스등이 그것인데, MJSP에서도 동일하게 사용된 것을 볼수가 있다. 과거 통신서비스업체들이 자사의 서버에 휴대폰을 접속할경우에는 독립적인 프로토콜이나 좀더 발전된 경우에는 Native Platform에서 제공되는 API 레벨에서 접속을 허용했다. 이러한 폐쇄적인 연결구조로는 오픈된 모바일 매쉬업 서비스를 수행하기가 매우 어렵다. 따라서 MJSP에서는 보다 진보된 모델을 구현했는데, 바로 OMA-DM을 기본으로 채택하여 사용한것이다. 이 모델은 기존의 프로토콜과 API를 모두 혼용하여 구현한 모델로서 오픈된 모바일 접속 환경을 제공하게 된다.
또 하나의 기존 OSGi와 차이가 있는 부분이 바로 외부 애플리케이션 연동부분이다. MSA, MJSP을 지원하지 않는 기존의 모델이나 외부의 애플리케이션일 경우 상호호환성을 위해서 열어놓은 일종의 인터페이스 게이트웨이인 셈이다. 그러나 지켜야 할 규약이 있는데, 그것은 바로 OSGi 기본정책인 것이다. 애플리케이션 타입은 JAR이며, 해당 JAR 파일은 번들로 인스톨될 수가 있다. 또한 인스톨된 번들은 핵심 프레임워크를 통해서 번들 라이프사이클 형태를 통해서 관리를 받게 된다. 마지막으로 외부 애플리케이션은 공용의 패키지로 사용될수있어야하며 (Import-Package 사용) 서비스의 등록과 사용은 XML을 통해서 구현해야 한다. 이러한 외부 애플리케이션 역시 모바일 매쉬업 서비스의 한 축을 담당하게 되는데, 현재의 모든 서비스들이 MSA, MJSP을 지원하지 않는 상황에서 적절한 구조이기도 하다. 현재 MJSP를 이용하여 제공되는 서비스들이 하나둘씩 생겨나고 있는데, 노키아와 스프린트의 매쉬업 서비스가 대표적이다. 미국의 대표적인 통신업체인 스프린트 사는 JSR 232, OSGi를 이용한 Titan Platform Project로 차세대 모바일 매쉬업 서비스에 박차를 가하고 있다. 2007년 4/4분기에는 PDA을 기반으로 하는 서비스를 런칭하고, 내년 2/4분기에는 자사의 모든 휴대폰에 플랫폼을 탑재하여 서비스 할 계획을 가지고 있다. 이에 따라서 현재 스프린트 사는 자사의 모든 개발자들에게 JSR 232, OSGi, 그리고 OMA-DM을 핵심 컴포넌트로 규정하고 그것들을 이용하여 개발하는 기술들을 습득하도록 권장하고 있을 정도이다. 또한 스프린트 사는 전미의 광역 커버리지를 보유한 몇안되는 업체로서 자사의 강점을 살려서 GPS, 지리정보 등의 특화된 매쉬업 서비스를 구상하고 있다. 또한 MJSP 기반의 OSGi 구조와 기존의 MIDP 연동 서비스, Servlet/JSP/AJAX를 통한 다이나믹 웹서비스, eRCP/eSWT를 통한 수려한 UX 서비스, OMA-DM을 통한 원격 실시간 모니터링, 다이나믹 업그레이드, 컨텐츠 배포 서비스들을 핵심 컨텐츠로 정하고 개발을 진행하고 있다.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 12월호에 실린 기사입니다]
JSR 248/249에 나와있는 MSA는 바로 J2ME의 미래이다. 과거 J2ME는 보다 파워풀한 임베디드 환경의 CDC와 모바일 환경의 CLDC로 구분되어 운영되었다. 그러나 두개의 운영환경은 바로 하나의 모델로 통합되는데, 그것이 바로 MSA (Mobile Service Architecture)이다. MSA는 급격하게 발전하고 변화하는 모바일 환경에 적절하게 대응하기위한 하나의 방안으로 출발하게 된다. 최근 3-4년간 J2ME를 중심으로 모바일 애플리케이션의 시장은 매우 빠른 기술 발전을 하게된다.
지난 2006년 4월, 컨설팅 회사 Strategy Analytics는 Nokia, SUN사와 공동으로 다음과 같은 자료를 발표한다. 전세계적으로 자바 기술을 이용하여 서비스하는 수행하는 모바일 통신 회사는 220개 넘고, 임베디드/모바일 자바가 탑재된 디바이스는 4억개가 넘는다. 35개가 넘는 벤더에 의해서 650개가 넘는 자바 휴대폰 모델들이 지금까지 출시가 되었으며, 모바일 환경에서 자바를 이용하여 개발하는 모바일/휴대폰 관련 엔지니어는 35만명이 넘는다. 또한 모바일 환경에서 구동되는 모바일 자바용 애플리케이션은 5만개가 넘으며, 지금까지 J2ME 관련 툴킷(SDK)은 1백만개가 넘게 전세계 개발자들에게 다운로드되고 배포되었다. 이렇게 급격하게 발전하는 J2ME 환경에서 CDC/CLDC로 구분되는 운영/개발환경을 보다 효율적으로 관리/발전시키기위해서 MSA가 탄생하게 되는데, 더 이상 CDC/CLDC로 구분하여 각각 프로파일들을 올려서 실행하는 것이 아닌 공동의 서브셋(Subset)과 컴포넌트 API로 통일하여서 개발자들에게 보다 통일된 애플리케이션 구조를 갖게 한다.
그렇다면 JSR 248/249 – MSA로의 발전은 개발자와 업체, 서비스 운영자, 그리고 최종적으로 사용하는 고객들에게는 어떠한 장점을 가져다줄것인가? 자바 진영에서는 그것을 다음과 같이 표현하였다. 우선 개발자들에게는 Interoperability가 가장 큰 장점으로 다가오게 된다. 과거 CDC, CLDC 환경에서는 해당 프로파일 – F/P, P/P, MIDP 등 양분된 개발환경을 통해서 개발된 애플리케이션은 서로 상호호환성이 매우 약했으나, MSA 환경에서 개발된 애플리케이션은 상호 운영성과 호환성면에서 매우 강력한 힘을 발휘하게 된다. 또한 임베디드/모바일 자바환경에서 개발과 다른 플랫폼으로의 포팅이 과거보다 쉽고 효율적이 되며, 임베디드와 모바일 애플리케이션으로 양분화된 시장을 하나의 마켓으로 통합하고 개발비용 측면에서 더욱 효율적으로 운영할 수가 있게된다. 개발 및 제조업체에서도 개발자들에게 가져다 준 장점을 그대로 계승하게 되는데, 점차 효율적이고 편한 개발환경에서 자바 개발자들이 보다 높은 생산성과 다양한 애플리케이션을 개발하게되면 보다 다양한 고객들로부터 수많은 요구사항들을 빠르게 다양한 디바이스에서 최적화되고 특성이 나타난 애플리케이션 개발로 대응할 수가 있게된다. 마지막으로 최종적인 사용자 고객들은 다양한 고객의 요구사항에 맞게 개발된 컨텐츠와 향상된 사용자 편의성(UX, GUI)등을 통해 고객의 서비스 품질이 향상됨을 느끼게 될 것이다.
이제 JSR 248 – MSA에 대해서 좀 더 자세히 살펴보자. JSR 248 – MSA의 개발 타겟은 무엇보다 대중화된 CD(Consumer Devices)와 해당 애플리케이션이었다. 그렇다면 대중화된 CD란 무엇인가? 대표적으로 우리가 사용하는 휴대폰을 생각하면 된다. 현재 우리가 사용하고 있는 휴대폰의 특징은 다소 제한된 하드웨어와 리소스를 가지고 있으며, 단순한 비즈니스 모델 즉, 원하는 애플리케이션을 바로 사서 나의 휴대폰으로 다운로드하는 단순한 구조를 가지고 있다. 웹이나 일반적인 애플리케이션에서 사용하는 컴포넌트 기반의 구조나 다이나믹한 실시간 업그레이드등은 현재 수행하기가 불가능하다. 또한 멀티태스킹 기능도 매우 미약하며, 보안적인 측면에서도 미비한 부분이 나타난다. 이러한 일반적인 휴대폰의 환경에서 보다 효율적이고 빠른 개발과 애플리케이션 수행을 위해서 MSA는 탄생하게 된다. 일단 MSA 환경하에서 개발되고 운영되는 애플리케이션은 다운로드된후에 자바의 보안 모델인 Sandbox에서 수행되며 하나의 완전 독립적인 애플리케이션 모델로 실행된다. 다른 수행중인 애플리케이션과 API를 공유할 수가 없고, 오직 하나의 애플리케이션만을 지원하게 된다. 또한 MSA는 모바일 미디어, 메시징, 파일처리, 3D그래픽, 블루투스, 웹서비스, 지불결재 등의 필수적인 기능을 정의한 17개의 컴포넌트 JSR을 포함하고 있다. 이러한 공통의 정의된 컴포넌트 규약들은 모바일 자바 환경에서 통일된 개발환경과 보다 높은 서비스 품질을 보장하면서 많은 애플리케이션을 개발을 예고하고 있다. 다음 버전에는 약 20개의 새로운 컴포넌트 JSR들이 표준화 승인을 기다리고 있는데 UI/UX 개인화, 탤레포니, 센서, 디바이스 관리 등등 보다 세련되고 멀티미디어의 요소가 가미된 휴대폰과 임베디드 모바일 디바이스의 컨텐츠들을 나타내고 있다.
JSR 248 – MSA에 이어서 JSR 249 – MSAA (MSA Advanced)가 있는데, JSR 248 – MSA이 일반적인 모바일 디바이스에 초점을 두었다면 JSR 249 – MSAA (MSA Advanced)은 제목에서도 나타난바와 같이 보다 강력하고 파워풀한 모바일 디바이스용으로 구현되었다. 모바일 디바이스 관점에서 본다면 일반적인 휴대폰보다 더욱 강력한 기능들과 향상된 하드웨어 스팩을 보유한 디바이스일것이다. 이러한 기기들에서는 단순하게 구매해서 다운로드하는 방식보다 실시간으로 업그레이드가 되거나 아니면 교체/대체할 수 있는 향상된 비즈니스 모델을 사용하며 내부적으로는 애플리케이션, 컨텐츠 서비스 그리고 미들웨어 등의 다양화된 계층(Layer)들이 존재하게 된다. 따라서 MSA가 하나의 애플리케이션에 집중하는 고정적인 방식이었다면, MSAA는 다양하고 다이나믹한 애플리케이션 확장성에 초점을 둔 개발/운영 환경이다. 애플리케이션 수행환경도 MSA와는 매우 다른데, MSA가 애플리케이션 하나에 중점을 두었다면 MSAA는 서비스, 애플리케이션, 그리고 라이브러리 등 다양한 객체를 수용하는 운영환경으로 되어있다. MSAA는 애플리케이션/패키징 모델, 다이나믹 관리환경, 보안 관리 모델, 애플리케이션 협업 관리, 다양한 멀티테스킹 환경을 지원하게 된다.
이상으로 우리는 MSA, MSAA에 대해서 살펴보았다. 현재 2007년 1/4분기에 MSA 기반의 휴대폰들이 노키아, 소니 에릭슨등의 제조업체를 통해서 판매되고 있으며, 내년초 1/4분기중 MSAA 기반의 스마트폰과 PMP, 셋탑박스등이 벤더들을 통해서 일반인들에게 서비스될것으로 기대하고 있다. MSA는 과거 CLDC 기반에서, MSAA는 CDC 기반에서 성장하고 확장하는 구조로 진행되고 있다. 보다 효율적이고 빠른 개발환경과 통일된 운영환경을 제공하기 위해서 발전하는 MSA 구조는 향후 모바일, 임베디드 자바의 표준으로 확산될것으로 예상되며, 또한 MSAA의 애플리케이션, 컨텐트, 라이브러리에 대한 관리 모델로 OSGi가 많은 지원을 하고 있다. 임베디드, 가정용 기기의 상호 호환성을 위해서 탄생한 OSGi는 이제 모바일 휴대폰에서도 확고한 미들웨어로 자리매김하는 시대가 도래한 것이다.
기본적으로 OSGi Framework은 자바환경에서 운영된다. 따라서 자바의 개발환경과 실행환경은 매우 중요한 요소이며, OSGi Framework의 탄생 근거가 되기도 한다. 현재 자바의 개발/실행환경은 JSRs(Java Specification Requests), JCP(Java Community Process)를 통하여 스펙이 정해지고 또한 발전하고 있다. 한편 임베디드 자바(J2ME) 진영에서는 OSGi Framework을 자바 환경위에서 운영되는 하나의 Framework이 아닌 자바실행환경에 구체적으로 명시하기도 한다. 따라서 자바의 실행환경의 트랜드는 OSGi Framework 입장에서는 매우 중요한 로드맵과 전략이기도 한다. 이번 호에서는 점차 다양해지고 발전해나가는 임베디드 자바(J2ME)의 기술 트랜드에 대해서 살펴본다.
자바의 실행환경은 크게 J2ME, J2SE, J2EE로 구분된다. 그중에서 J2ME는 임베디드/모바일을 위한 자바 환경으로 OSGi Framework에서 주로 탑재되는 운영환경이기도 하다. Java 2 Platform, Micro Edition (J2ME)은 Java 플랫폼의 가장 작은 부분으로, 스마트 카드나 호출기와 같이 매우 작은 장치에서부터 TV 셋탑 박스와 컴퓨터 데스크탑과 같은 강력한 장치에 이르기까지 소비자용 내장형 장치에 사용된다. J2ME의 주요 요소로는 소비자용 내장형 장치를 위한 Java 솔루션을 제공하는 여러 도구 및 기술과 함께 CDC(Connected Device Configurations) & CLDC(Connected Limited Device Configurations)라 불리우는 핵심 API Set, 각 디바이스 제품군에 맞는 API Set SPEC을 정의한 프로파일들 – F/P(Foundation Profile), P/P(Personal Profile), MIDP(Mobile Information Device Profile) 들로 구성되는데, 특히 소비자 가전(CE) 제품용으로 최적화된 Java Runtime Environment도 포함된다.
이렇듯 J2ME 기술은 다양한 범위의 극소형 제품에 사용되며, 스마트 카드, 호출기, 셋탑 박스 및 기타 소형 제품 내에서 보안, 연결 및 유용한 유틸리티 프로그램을 사용을 가능케 한다. 결국J2ME 기술은 Java 제품군의 일부로서 관련된 Java 플랫폼에는 J2SE (Java 2 Standard Edition) 및 J2EE (Java 2 Enterprise Edition)가 있다. J2ME 플랫폼은 실행, 개발환경으로 CVM & KVM, 애플리케이션 프로그래밍 API Library, Deployment와 Configuration tool 들을 제공한다. J2ME 플랫폼이 지향하는 제품군들을 두개의 그룹으로 나누면, 첫번째로 개인의 휴대가 가능하며 네트워크를 통한 정보전달이 가능한 기기군들로 셀롤러 폰, 페이져 등을 말할 수 있으며(KVM-CLDC-MIDP), 두 번째로 구체적인 기능을 가지며, 고정되어 있는 정보전달 기기군들로 셑톱박스, 인터넷 TV, 자동차 네비게이션 시스템등으로(CVM-CDC-F&PP) 구분할 수 있다. 셀롤러폰이나 페이져 등은 제품들의 모양, 성능, 특성이 제각각이기 때문에 각각의 기계장치들의 공통되는 핵심부분을 모아 버츄얼머신의 configuration과 API들을 제공하고 있다. 실행환경 측면에서의 J2ME Configuration은 메모리 용량과 프로세스의 처리용량이 비슷한 것들을 같은 범주로한 API들로 CLDC를 정의하고 있다. Configuration의 스펙을 살펴보면, 프로그램 언어인 Java , Java Virtual Machine 실행환경, 개발 도구로 Java라이브러리와 API를 제공하고 있다. 하이-레벨 아키텍처는 기계장치의 OS위에 버츄얼머신이 존재하고 그 위에 컨피규레이션과 프로파일이 수직적 구조로 이루어져 있다. 현재J2ME 플랫폼에서는 CLDC(Connected Limited Device Configuration)와 CDC(Connected Device Configuration), 두가지의 표준 컨피규레이션이 있으나 최근 자바원 2007에서 발표된 CLDC의 로드맵은 MSA (Mobile Service Architecture) 1.0으로 발전하게 된다. 자바의 실행/개발환경을 정의한 스펙은 JCP와 JSRs를 통해서 매우 다양하게 전개가 된다. 그 많은 JSR중에서 OSGi와 직접적으로 관련된것들은 다음과 같다.
1. JSR 248 - MSA (Mobile Service Architecture)
2. JSR 249 - MSAA (
3. JSR 232 - MOM (Mobile Operational Management)
4. JSR 277 - Java Module System
5. JSR 291 - Dynamic Component Support for Java SE (OSGi)
이중에서 JSR 248/249는 과거 CDC/CLDC에 대한 스펙이며, 특히 OSGi가 대부분 CDC환경에서는 운영되고 CLDC환경에서는 운영되기가 어려웠음을 볼 때 OSGi가 모바일 환경에서도 구현될수있는 가능성을 나타내준다. 또한 JSR 232-MOM은 OSGi의 번들 관리 싸이클과 비슷한 형태의 관리 환경에 대한 스펙이며, JSR277은 자바의 다이나믹 모듈 시스템으로 OSGi의 번들 형태 구조를 자바에서 직접 구현하려는 의도를 볼수가 있다. 이러한 JSR들은 OSGi와 직접적으로 연관이 되어서 매우 중요한 스펙이 된다. OSGi가 자바 실행환경에서 운영되기에 JSR의 발전 방향에 따라서 영향을 받을 수밖에 없기때문이다. 이제 하나하나 살펴보기로 한다.
난 마소를 83년 5월호인가? 부터 사서 보기 시작했다. 그 당시 난 애플IIe를 가지고 있었는데... 10인치 그린 모니터에 64KB 확장 램카드, 허큘레스 카드 등을 꽂고 신나게 게임만 했던 기억이 난다. 엑스리온인가? 뭐 그런 게임과 카라데, 올림픽, 그리고 불후의 명작인 미스테리 하우스(어드벤쳐)... 그러다가 정말이지... 세운상가에서 놀라운 충격을 받는 게임을 본다. 바로 울티마 III 였다... 4명이서 팀을 이루어서 다니는.. RPG라는 놀라운 게임... 암튼 그런 게임을 하기위해서 플로피 디스크 드라이브를 샀었고... 가끔 가다가 마소에서 연재가 된 BSD C를 코딩했던(?) 기억이 난다. 물론 기계어와 6502 어셈블러는 마소지를 보면서 밤새 쳤던 기억도 많고...
암튼... 그렇게 20여년이 흘러도 여전히 내 곁에는 마소지가 있다... ㅋㅋㅋ 우연한 기회에 센서 네트워크에 대한 글도 스페셜 리포트 코너에 기고하기도 하고... 이번에 OSGi는 6회분으로 지난 2007년 7월부터 기고하기 시작했다. 그런데, 마지막에 2회분이 더 늘었다. 역시나... 할말이 많은 그리고 놀랍게 빠르게 확산되는 OSGi 이다.
기자님의 도움을 받아서 지난 7월호부터 기고한 글의 pdf 파일을 싣는다. OSGi를 공부하기 원하는 분들께 작은 도움이 되기를 바란다. 하나의 작은 꿈이 있다면... 내년 2월호까지 OSGi 기사를 모두 쓰고, 책을 만드는 것이다. 위에서도 이야기했지만... OSGi는 이제 Universal Framework이다. 향후 핵심적인 미들웨어이면서 프래임워크로 매우 중요한 플랫폼이 될것으로 믿어 의심치 않는다.
아까 내년 EclipseCon 2008의 Agenda에 보니까... OSGi 업계에서 매우 유명한 IBM Lotus그룹의 B.J Hargrave가 구글의 안드로이드(Android) 플랫폼에 OSGi가 함께 운영된다고 이슈를 쓴것을 보았다. 사실 Android Platform은 OHA로 오픈 소스 플랫폼이 되지만... SUN과는 원수가 될 지경이다. JCP, JSR로 운영되는 자바의 라이센스 개념을 아파치 오픈소스 라이센스로 변경하여 독자적인 규격으로 세를 확산시킬 모양이다. 당장 VM도 일반적인 VM이 아니다. 그런 상황에서 구글폰에 OSGi가 올라간다니... 더 궁금할수밖에... B.J에게 메일을 보냈으니 답장이 오겠지...
사실 이번 12월호 마소에 보면, J2ME Technical Trend를 기고하였다. 현재 J2ME 위에서 돌아가는 OSGi는 자바와 매우 밀접하다. 그러나 어떻게 보면 물과 기름이 만난 격이다. 자세한 내용은 마소 책을 보기 바란다. 노키아와 스프린트가 CDC위에서 돌아가는 OSGi를 CLDC기반위에 운영하고 싶어한다. OSGi가 드디어 파워 임베디드에서 모바일로 확장하려는 시기가 도래했다. 그런 판에 구글마저 Android Platform에 OSGi를 올린다? 매우 굿 뉴스~
[연재 순서]
1회 | 2007. 07 | 임베디드를 넘어 엔터프라이즈로!
2회 | 2007. 08 | OSGi 서비스와 활용 사례
3회 | 2007. 09 | OSGi 개발 환경 구현 1 - J2ME & OSGi
4회 | 2007. 10 | OSGi 개발 환경 구현 2 - OSGi Bundle 구현
5회 | 2007. 11 | 이클립스의 핵심, Equinox
6회 | 2007. 12 | J2ME - 테크놀로지 트렌드 1
7회 | 2008. 01 | J2ME - 테크놀로지 트렌드 2
8회 | 2008. 02 | 엔터프라이즈로의 확장, Spring-OSGi
invalid-fileOSGi를 공부하고 싶은 분들에게 작은 도움이 되기를 바란다.
