구글의 의도가 성공할 지는 알 수 없다. 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 연동은 크게 두가지로 이루어진다. 하나는 안드로이드 플랫폼에 프레임워크의 탑재하는 부분과 또 하나는 다이나믹한 번들의 수정 또는 개발이다.

[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 12월호에 실린 기사입니다]

[박스 기사] 차세대 모바일 리더는 여전히 노키아인가 ?

세계 1위의 휴대폰 업체 – 노키아 역시 모바일 서비스와 컨텐츠에 많은 연구개발을 수행하고 있다. 지금까지 설명한 새로운 J2ME의 기술 트랜드에는 모두 노키아가 선두에 서고 있는 실정이다. Eclipse, OSGi에는 IBM이 리더일지는 몰라도 모바일 서비스와 컨텐츠 마켓에 오면 노키아가 여전히 독보적으로 군림하고 있다. 차세대 모바일 웹 서비스 – 매쉬업에서도 여전히 노키아가 빠른 행보를 나타내 보여주고 있는데, 다음의 사례를 살펴보기도 한다. 현재 서비스중인 노키아의 N800 웹 타블렛 모델을 보면, OSGi 기반의 Servlet과 GPS, Map을 연동하여 매우 빠르고 정확하게 매쉬업 서비스를 수행하는 것을 보여주고 있다. 물론 현재도 기존의 방법으로 GPS 등의 서비스는 제공하고 있지만, 느리고 비싼 통신 요금에 그렇게 대중에게 강력하게 어필하고 있지못한 형편이다.

[그림 10] 현재 서비스되고 있는 노키아 위치추적 시스템

 

하지만 노키아는 OSGi와 모바일 매쉬업을 통한 빠른 위치정보 서비스를 개발하는데 성공했는데, 그 핵심에는 역시 J2ME, OSGi가 있다. MJSP 기반으로 외부의 애플리케이션 연동과 OSGi를 통한 다양한 컨텐츠 서비스의 효율적인 관리, 그리고 특이한 사항으로는 O/S 플랫폼을 임베디드 리눅스를 사용했다는 것이다. 노키아는 심비안이라는 강력한 스마트폰용 O/S가 있는데, 의외로 리눅스를 채택하여 MJSP 플랫폼을 구현하였다. 심비안 역시 편리하고 강력한 자바 개발/운영 환경으로 명성을 떨치고 있는 O/S 이다.

 

[그림 11] 차세대 모바일 매쉬업 서비스 구조

 

마지막으로 사업 전략적인 측면에서 살펴보면, 미국의 스프린트사와 유럽의 노키아는 3G에서 4G로 넘어가는 현재의 시점에서부터 강력한 연합전선을 펼칠 계획을 가지고 있다. 스프린트 사는 미국의 유력한 통신업체이면서, 노키아는 휴대폰 제조업체이다. 서로의 요구사항이 절묘하게 상충되고 있어서 양사는 향후 모바일 매쉬업 서비스 시장에서 공동 마케팅 및 서비스 개발을 할 가능성이 매우 크다. 또한 노키아사는 스프린트가 강력하게 드라이브하고 있는 4G의 WiMAX(Mobile WiMAX 포함)를 통한 매쉬업 서비스에 매우 흥미를 느끼고 있다. 지금보다 더욱 강력하고 빠른 무선의 브로드번드 마켓이 4G의 WiMAX를 통해서 열릴것으로 예상하면서 기존의 컨텐츠와 4G의 WiMAX를 통합하는 모바일 매쉬업 서비스를 양사가 공동으로 구상하고 있다. 그렇게 되면 현재 PC와 웹에서 매쉬업 서비스와 컨텐츠로 독보적으로 군림하고있는 구글을 제치고 모바일 웹으로 전세계의 IT시장을 장악할 날도 멀지않게 느껴진다. 우리가 상상한 시나리오가 맞든지 혹은 틀렸다 하더라도 현재의 웹2.0이 우리의 휴대폰으로 들오오는 모바일웹 2.0은 곧 아주 빠른 시기에 우리 곁으로 오게될것이다. 그러한 관점에서 본다면 OSGi는 우리 개발자들에게 또 다른 새로운 기회로 다가오고 있는 것이다.

 

[그림 12] 모바일 매쉬업 서비스 구현 과정

 

결국 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)에 대해서 살펴보자.

우연한 기회로 마이크로소프트웨어에 글을 기고하게 되었다. 마이크로소프트웨어(이하 마소)는 나뿐만 아니라 이 땅의 많은 개발자들과 프로그래밍을 좋아하는 엔지니어들에게 무엇보다 소중한 책이다. 매월 나오는 잡지이지만, 잡지 이상의 책이다. 책 타이틀도 1년이 지난후에도 볼수있는 잡지가 아니던가?

난 마소를 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

OSGi를 공부하고 싶은 분들에게 작은 도움이 되기를 바란다.

[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 8월호에 실린 기사입니다]

대부분의 IT기술은 미국에서 태동하고 선진업체들이 미국업체인데 반해서, OSGi는 유럽 업체들도 미국업체 못지않게 활발하게 활동을 벌이고 있다. 하지만 역시 OSGi를 이끌고 주도하는 업체는 IBM이다. OSGi 태동에 SUN이 자바로 영행력을 발휘했지만(?) 계속 버전업이 되고 활성화되면서 많은 솔루션을 구현하고 영향력을 확대한 것이 IBM이라는 것은 누구도 부인할수 없는 사실이다. IBM은 과거 OSGi의 자사 솔루션 SMF(Service Management Framework)을 시작으로 임베디드/모바일 자바환경인 J2ME, 오픈소스 개발툴에서 플랫폼으로 확장하고 있는 이클립스, 그룹웨어 협업솔루션 Expeditor에 이르기까지 지속적인 OSGi 솔루션으로 영향력을 확대해왔다.

특히 이클립스의 오픈소스 결정뿐만 아니라 이클립스 3.0대에 이르면서 OSGi가 이클립스 플랫폼에 탑재될 때 SMF를 지원하여 Equinox 솔루션을 탄생하기까지 많은 지원을 아까지 않았다. 이처럼 J2ME(J9), Expeditor, Equinox 등의 솔루션 라인업은 많은 업체들이 OSGi 솔루션으로 제품을 개발하거나 탐재할 때 가장 먼저 찾게되는 OSGi 선두업체로 자리매김하게 되는 결정적인 요인이 된다. 반면 유럽에서는 크게 솔루션 업체와 OSGi 개발 벤더로 나뉘어지는데, 대표적인 업체들이 바로 지멘스, 노키아, 필립스, BMW 등의 전통적인 제조업체와 Knopflerfish, Prosyst같은 전문 벤더이다. 지멘스-노키아는 모바일 솔루션 분야에서, 필립스는 홈네트워크 분야에서, BMW는 자동차 정밀제어 분야에서 각각 OSGi를 자사의 핵심 미들웨어 솔루션으로 탑재하여 제품 개발을 하고있다. 또한 Knopflerfish, Prosyst 등의 전문벤더들은 전통적인 제조업체들이 OSGi 솔루션을 신뢰성있는 제품으로 사용할수있도록 표준화 SPEC을 상용화, 공급하는 역할을 담당하고 있다.

OSGi - System Architecture

OSGi가 R4에 이르러서 OSGi 커뮤니티 전문 기술 그룹들이 모바일, 자동차, 임베디드, 엔터프라이즈 서버 환경으로 재편된것도 이러한 유럽 업체들의 영향력을 무시할수없기 때문이다. 미국이 IBM을 필두로 다양한 상용화 솔루션과 오픈소스 진영(Eclipse, Apache)으로 영향력을 확대하고 있다면 유럽은 오히려 다양한 기업들이 자동차, 모바일, 홈네트워크 분야의 상용화 솔루션에서 두각을 나타내고 있다. 그렇다면 국내 실정은 어떠할까? 국내에서도 많은 연구개발이 이루어지고 있는 것은 사실이나 상용화제품으로 이어져 지속적인 사업 매출로 연결되는 경우는 많지가 않다. 다만 최근 들어서 가정용 셋탑박스, 텔레매틱스 분야의 네비게이션등에서 눈에 띠는 성과를 거두고 있다.

/// 활용사례 - 삼성전자 빌딩용 공조시스템 컨트롤러 DMS

삼성전자 생활가전총괄은 사람들에게 꼭 필요한 의/식/주에 관련된 제품을 연구 개발하는 총괄이다. 생활가전총괄은 미래가전 및 신기술 개발에 꾸준한 노력을 기울이고 있으며 바이오(Bio), 나노(Nano), 디지털 IT 등 다양한 분야와의 디지털 융합을 통해 미래 디지털 가전 시장의 선두적인 기업으로 도약하고 있다. 건강과 편리함을 원하는 고객의 요구에 대비해 홈 네트워크 및 다양한 미래가전을 준비, 개발하고 있는 생활가전총괄은 생활의 중심에서 고객과 가장 가까운 곳에 서 있다. 또 건강과 행복을 만드는 제품을 통해 삶의 새로운 방향을 제시하는 Life Style Innovator 역할을 수행하고 있다. 생활가전총괄은 4개의 사업영역에서 사람들 삶의 질적 향상을 위해 노력하고 있다. 사업 부문은 △시스템 에어컨, Built-in, 홈 네트워크 등 떠오르고 있는 첨단 디지털 제품을 연구 개발하는 New-Biz △에어컨, 냉장고 등 Cooling △세탁기, 청소기, 공기청정기를 개발하는 Cleaning △전자렌지, 오븐을 연구하는 Cooking 등이다. 특히 공조시스템 개발은 고부가가치 제품 중심의 수익력 극대화 및 해외 운영 확대를 통해 세계 경쟁력을 강화하고 있다. 삼성전자 생활가전총괄은 최근 보다 효율적인 시스템 에어컨 관리를 위해 임베디드 컨트롤 서버 ‘DMS(Data Management Server)’ 개발을 진행해 최근 완료했다.

::::: Business Challenge

사업 확장에 따른 신규 시스템 필요

시스템 에어컨의 관리 체계는 최근 들어 고도의 높은 기술들이 적용되기 시작했다. 즉, 웹 기반으로 환경이 바뀌고 오픈 프로토콜, 임베디드 디바이스 등 최신 IT 기술이 공조시장에 접목되기 시작한 것이다. 전문화도 이뤄지기 시작했다. 학교, 병원, 사무실 빌딩 등 사이트 특성 및 규모별로 관리 시스템이 사이트에 알맞게 출시되기 시작했다. 서비스 대응 수준도 높아지고 있다. 일본에서는 원격 진단 서비스가 보편화되는 시점을 맞았다. BMS 시장도 변화되고 있다. 과거에 비해 원격 관리 시스템들도 오픈 프로트콜 기반으로 전환되고 있다. 오픈 프로토콜 적용 사례는 이미 국내 신규 대형 빌딩에서 나타나고 있다. 삼성전자도 기업, 대학, 병원 등 빌딩에 시스템 에어컨(DVM)을 공급, 구축해 운영하고 있다. 따라서 삼성전자도 시스템 에어컨 사업 확장에 따른 신규 시스템 아키텍처가 필요하게 됐다. 또 원격 관리 시장 진입을 위한 체계 구축도 필요했다. 삼성전자는 그동안 공급한 시스템 에어컨에 대해서는 PC를 활용, 원격관리를 해왔으나 문제점이 많았다. 그 문제점은 PC를 통한 시스템 에어컨 관리는 범용이 아니어서 활용도가 낮고 안정성과 확장성도 낮았다. 또 통신이 원활하게 이뤄지지 않고 보안상에도 문제점이 있는 것으로 지적돼 왔다. 이와 함께 기존 시스템과 연동이 쉽게 이뤄지지 않는 문제점과 24시간 365일 운영이 되지 못한다는 한계점을 갖고 있었다. 삼성전자는 이에 따라 중앙관리가 필요한 학교, 기업, 호텔의 빌딩 등을 주요 타깃으로 정하고 24시간 364일 지속적인 시스템 에어컨 운영통제 관리가 가능케 하는 솔루션을 개발하기로 했다. 이러한 결정으로 인해 삼성전자는 기존의 문제점과 한계점을 극복할 수 있는 시스템 에어컨 중앙관리를 위한 각 사이트별 운영을 총괄하는 임베디드 컨트롤 서버 ‘DMS’ 개발을 진행하기 시작한 것이다.

::::: Solution

J2ME(J9), SMF(OSGi), WSDD, DB2e 적용해 DMS 개발

삼성전자는 지난 2004년 3월부터 임베디드 기반의 컨트롤 서버인 ‘DMS’ 개발을 진행했다. 이번 개발을 통해 제품이 탄생되면 이 제품은 시스템 에어컨 기술 로드맵 상의 가장 근간이 되는 핵심 디바이스(Device)가 된다. 삼성전자는 DMS의 주요 기능으로 1) 통신 오픈 프로토콜 지원 (RS485, TCP/IP, LonWorks, BACnet) 2) DMS 1대당 최대 16대 중앙 제어기, 256대 실내외기 지원 3) 웹서버를 자체구동, 웹 제어 기능을 가능하게 했다. 삼성전자가 개발하는 임베디드 기반의 OS를 가지는 디바이스인 ‘DMS’는 시스템 에어컨 데이터를 485통신으로 수집하고 이더넷(Ethernet)을 통해 DVM 전용 제어기나 서비스 서버로 전송한다. 한편 DMS는 임베디드 DB 시스템 ‘DB2e’를 탑재하여 보다 효율적으로 시스템에어컨 데이터를 관리한다. 자체 메모리 용량을 고려해 에어컨의 상태 데이터를 일정기간 저장할 수 있으며 Web Configuration & Management, DI/DO 입출력 Port 내장, 년간?주간 일정 기능을 저장 및 수행 할 수 있다. Console Port(RS232C)를 이용한 구성으로 돼 있다. 이밖에 디바이스 모니터링 기능으로 고장정보, 상태정보, 운영정보를 모니터링하고 전력 관리 기능으로 전력분배, 피크 전력 제어 등의 기능을 갖고 있다. 이러한 기능은 과거 임베디드 컨트롤러의 경우 RTOS환경에 C/C++로 개발하는 경우가 대부분이었으나, OSGi 탑재로 모든 컨텐츠들을 번들로 처리하여 컨텐츠의 추가/수정/삭제/업데이트 등의 관리를 원격에서 실시하고, 확장성이 뛰어난 구조로 설계할 수가 있었다.

DMS 개발 환경은 애플리케이션 툴로는 WSDD(WebSphere Studio Device Developer) 등이 사용됐다. 플랫폼으로 OS는 Montavista 임베디드 리눅스, DB는 임베디드 DB ‘DB2e’, Middleware Framework은 OSGi가 채택되었으며, 개발환경은 J2ME & J9 & CDC-F/P이 적용되었다.

이번 개발 환경에 대해 삼성전자 생활가전총괄 김영수 책임은 “빠르게 발전해 나가는 임베디드 환경에서 최대 이슈는 임베디드 리눅스와 모바일 자바의 결합, 그에 따른 시너지 효과”라며 “임베디드 리눅스와 자바 플랫폼에서 가져올 수 있는 장점은 시스템 유연성, 하이엔드 임베디드 시스템 구현, 벤더의 기술 지원 등”이라고 말했다. 이번 개발에 도입된 IBM 애플리케이션 툴에 대해 “BMT(벤치마킹테스트)를 통해 소프트웨어를 선정한 것”이라며 “BMT 실시 결과 IBM 소프트웨어가 속도면에서 높은 평가를 받았다”고 덧붙였다.

::::: Benefit

DMS로 고객 만족 높여 매출 확대

삼성전자는 이번 프로젝트를 통해 시스템 에어컨 중앙관리를 위한 각 사이트별 운영을 총괄하는 임베디드 컨트롤 서버 ‘DMS’ 솔루션을 보유하게 됐다. 이를 통해 삼성전자는 시스템 에어컨 관리의 효율성이 증대될 것으로 전망하고 있다. 또 고객들은 새로 개발된 DMS 솔루션을 적용할 경우 기존 관리보다 편리성이 높아져 고객 만족도가 증대될 것으로 보인다. 이에 따라 매출 증가도 삼성전자는 기대하고 있다. 제어 솔루션 부문에서도 경쟁사와 비교할 경우 다소 열세였던 부분을 만회해 공조 중앙관리가 필요한 시장에서의 경쟁력을 강화할 수 있을 것으로 예측하고 있다. 이와 함께 이번 솔루션 개발로 온라인 서비스 체제 구축이 가능한 기반도 마련할 수 있게 됐다. 삼성전자는 향후 이번에 개발될 솔루션을 오픈 환경으로 전환해 어느 제품이든 사용이 가능하게 할 계획이다. 이번에 개발된 솔루션은 삼성전자 제품 적용에 용이하게 돼 있다.

[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 8월호에 실린 기사입니다]

1.3 OSGi의 주요 서비스

OSGi에서는 1.0부터 4.0에 이르기까지 수많은 서비스와 스펙들이 발표되어 사용되고 있다. 여기서는 그 가운데 핵심 서비스를 골라 살펴본다. OSGi를 구성하는 중요 구성요소는 다음과 같다.

- 서비스 : 특정 기능을 수행하는 자바 인터페이스와 실제 구현객체
- 번들 : 서비스를 제공하기 위한 기능적 배포 단위
- 프레임워크 : 번들의 라이프 사이클을 관리하는 번들 실행환경
 
서비스는 미리 정의된 서비스 인터페이스를 통해 접근이 가능한 컴포넌트이다. 하나의 애플리케이션은 여러 개 서비스의 협동 작업을 통해 구성되고 런타임시에 필요한 서비스를 요청할 수도 있다. 프레임워크는 각 서비스와 그 서비스에 해당하는 실제 구현에 대한 매핑을 가지고 있고, 간단한 쿼리 메커니즘을 통해 서비스의 실제 구현을 찾을 수 있다. 또한 프레임워크는 각 서비스간의 상호 의존관계를 관리한다. 번들은 여러 서비스의 구현을 하나의 패키지로 묶은 JAR 파일의 형태로 존재한다. JAR 파일에는 하나 이상 서비스의 구현 객체와 리소스 파일, 그리고 매니페스트(manifest) 파일이 포함되어 있다. 번들 컨텍스트는 프레임워크 내부의 번들 실행 환경이며 번들의 설치와 실행, 정지, 삭제 등의 번들 라이프 사이클을 관리한다. 이렇듯 서비스, 번들, 프레임워크는 항상 상호 작용하면서 OSGi를 구성하게 된다. OSGi 1.0 규격에서 명시한 패키지들은 <표 1>과 같다.

1) org.osgi.framework

OSGi 프레임워크는 소용량 메모리 디바이스에서 프로그래밍 하는 개발자들이 연속적으로 동작하는 애플리케이션을 작성할 수 있는 컨텍스트를 제공하는 것이 목적이다. 애플리케이션의 swap-in과 swap-out이 런타임시에 발생하는 이러한 환경에서는 런타임시에 다른 애플리케이션과 구조적이고 의존적인 방식으로 커뮤니케이션을 수행해야 할 필요가 있다. OSGi 프레임워크는 자바 프로그래밍 언어가 가진 코드의 네트워크 이동성을 이용해 컴포넌트 기반의 개발환경을 제공함으로써 보다 풍부하고 구조적인 서비스 개발을 가능하게 한다. org.osgi.framework 패키지는 10개의 인터페이스와 6개의 클래스, 2개의 예외 클래스로 구성되어 있다. OSGi 프레임워크가 제공하고자 하는 환경의 목표는 다음과 같다.

- 애플리케이션이 실행 중에도 동적 다운로드 및 업그레이드 가능
- 제한된 메모리 디바이스 사용 가능
- 효율적이고 통합된 컴포넌트 개발 환경 제공
- 애플리케이션간의 의존성에 대한 관리 기능 제공
- 확장 가능성(scalable)

2) org.osgi.service.device

디바이스 매니저는 OSGi 프레임워크에서 하나의 서비스 리스너로 등록(register)된다. 디바이스 매니저는 새롭게 추가되는 디바이스의 서비스를 탐지하고, 새로 추가된 디바이스의 드라이버 번들을 설치한다. 다음은 디바이스 매니저의 알고리즘이다.

- 디바이스 탐지(Device Detection) : 모든 새로운 디바이스 (org.osgi.service.device.Device 인터페이스 객체)를 검색
- 위치 단계(Location Phase) : 새로 추가된 모든 드라이버를 DriverLocator를 이용해 위치시킴
- 경선 단계(Bidding phase) : 각 드라이버를 디바이스 상에서 경선에 참여
- 추가 단계(Attach Phase) : 경선 단계에서의 최상위 드라이버 추가
- 청소 단계(Cleanup Phase) : idle 드라이버를 청소
 
각 드라이버 번들은 세계적으로 유일한 스트링 아이디를 가지고 있어야 하고, 이 아이디는 드라이버 매니저가 드라이버의 revision을 해석해 프레임워크의 위치 아이디로 사용된다.  org.osgi.service.device 패키지는 3개의 인터페이스로 구성되어 있다.

3) org.osgi.service.http

HttpService는 프레임워크 내의 다른 번들이 리소스를 등록하고 HTTP를 통해 서블릿에 접근할 수 있게 한다. HttpService를 통해 등록할 수 있는 엔터티는 서블릿과 리소스이다. 서블릿은 Java Servlet API를 구현한 객체이며 서블릿의 등록은 URI 네임스페이스에 대한 서블릿 제어권을 부여한다. 리소스는 HTML 파일, GIF 파일, 클래스 파일 등을 포함하며 리소스의 등록은 이러한 리소스들을 URI 네임스페이스에서 사용 가능하게 한다. org.osgi.service.http 패키지는 2개의 인터페이스와 하나의 예외 클래스로 구성되어 있다

4) org.osgi.service.log

LogService는 번들로부터의 로그 요청을 받아들이고 LogReaderService는 다른 번들이 로그 항목을 읽을 수 있게 한다. LogService는 이벤트와 에러 상황에 대한 리포트를 주목적으로 하지만, 다른 용도로도 활용할 수 있다. org.osgi.service.log 패키지는 4개의 인터페이스로 구성되어 있다.

2. 실행 환경의 표준 권고, OSGi - R3

2003년 4월에는 OSGi 서비스 플랫폼 릴리즈 3(OSGi R3)가 발표되었다. 필히 구현되어야 하는 표준 명세에는 가장 중심이 되는 프레임워크 명세를 포함해 모두 19개의 명세가 있고 선택적 구현이 가능하다. 또한 피드백을 위한 권고명세에는 총 4개가 포함되어 있다. OSGi R3의 가장 큰 특징은 권고명세에 포함되어 있는 JINI와 UPnP 지원일 것이다. 오디오/비디오 쪽 미들웨어 표준인 HAVi나 전력선 제어 쪽의 미들웨어와 OSGi가 연계된다면 OSGi의 활용성이 더욱 높아질 것으로 예상되었으므로, 실제 이런 시도들이 LonWorks와 같은 전력선 통신 관련 업체에서나 또는 HAVi 측과의 협력에 의해 가시화됐다. 또한 기존의 OSGi R2까지는 OSGi 서비스 플랫폼들간의 호환성이 문제였다. OSGi R3에서는 포함된 실행 환경 표준으로 인해 보다 엄격한 호환성 제공을 권고해 다양한 환경과 버전 가운데서도 유연한 실행 환경을 제공한다. OSGi R3 표준 명세(Normative Specification)의 구성 요소와 새롭게 추가된 핵심 서비스는 다음과 같다.

- URL Handlers Service Spec 1.0 : 자바에 관련된 명세로서 새로운 URL 방식에 대한 URL 처리기를 등록 가능하도록 지원
- User Admin Service Spec 1.0 : 사용자의 인증(Authentication)을 처리하며 역할 정보(Role Repository)를 이용해 접근 권한에 대한 확인(Authorization) 지원
- IO Connector Service Spec 1.0 : J2ME의 Connector 프레임워크를 채용. URI(Uniform Resource Indicator) 형태로 임의의 리소스에 접근할 수 있게 해주며 리소스 접근 후에는 동일한 IO Connector Service API를 통해 제어
- Preferences Service Spec 1.0 : 데이터를 지속적으로 저장/조회/변경하는 기능 제공
- Wire Admin Service Spec 1.0 : 임의의 두 서비스를 서로 연결시켜 데이터를 주고받을 수 있게 함. Producer-Consumer 모델 형태로 서비스간의 통신을 지원
- XML Parser Service Spec 1.0 : OSGi 서비스 등록기(Registry)에 JAXP를 준수하는 XML Parser를 등록할 수 있게 함. 다른 번들에서는 서비스 등록기를 통해 등록된 XML Parser를 사용
- Metatype Spec 1.0 : LDAP과 같이 데이터를 담고 있는 통의 역할을 하는 서비스를 정의. 데이터 구조 또한 LDAP과 흡사하고 객체가 있어 그 밑에 여러 속성들을 담을 수 있다. 한편 LDAP처럼 다양한 쿼리(Query)는 불가능하고 ID로 찾는 방법만을 지원
- Measurement and State Spec 1.0 : 나라와 문화에 따라 상이한 측정 및 상태 단위에 대한 표준을 제공
- Position Spec 1.0 : GPS 시스템을 지원하기 위해 제안되었으며 WGS(World Geodetic System) 84를 지원
- Execution Environment Spec 1.0 : 여기에는 두 가지 실행 환경이 기술되어 있다 하나는 Foundation Profile의 부분집합과 Framework/표준 명세 구현 환경을 포함하는 최소한의 실행 환경이고, 다른 하나는 CDC와 Foundation Profile 환경을 더한 것. 이 명세가 OSGi R3에 추가됨으로써 OSGi 서비스 플랫폼간의 호환성이 획기적으로 높아졌다.

앞의 서비스에 나타난 것처럼 OSGi는 R3에 이르러서 임베디드, 모바일, 데스크탑은 물론이고 엔터프라이즈 서버 환경에서 적응하기 위한 새로운 시도들을 발견하게 된다. Preferences Service, XML Parser Service, Metatype Spec, Execution Environment Spec이 바로 대표적인 핵심 서비스들이다.

[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 8월호에 실린 기사입니다]

지난 시간에는 OSGi의 발전 배경과 기본 개념, 그리고 구조 등을 차례로 살펴봤다. 유니버설 미들웨어(Universal Middleware)라 불리는 OSGi는 초창기에 가정용 홈 게이트웨이의 임베디드 환경에서 출발해 지금은 모바일과 자동차, 엔터프라이즈 환경에 이르기까지 매우 폭 넓게 활용되고 있다. 이번 호에서는 OSGi의 다양한 활용 사례와 OSGi의 핵심인 서비스에 대해 집중적으로 소개한다.

OSGi의 현재 가장 큰 이슈는 RCP과 Enterprise Framework으로의 확장일것이다.

오픈소스로 출발하여 자바업계뿐만 아니라 S/W 개발자들의 기본적인 개발툴인 이클립스에 OSGi가 탑재된다는것 자체가 큰 이슈였으며, 지금까지 엔터프라이즈 서버 환경으로 적용은 감히 생각지못했다가 Spring 프레임워크와의 통합은 신선한 충격으로 IT업계에 다가왔다. 단순히 임베디드 또는 홈 게이트웨이정도로 치부되던 OSGi가 데스크탑 리치 클라이언트 플랫폼으로, 서버환경에서 프레임워크로 확장, 발전하게되는 이유는 뭇엇일까? 여러 이유들이 있겠지만, 가장 큰 이유로는 가벼운(Light-Weight) 그리고 동적인(Dynamic) 모듈(Module) 시스템 구조와 번들의 라이프 싸이클 관리시스템을 들수가 있다. 이외에도 버전업이 되면서 임베디드 환경에서 적용되기 시작하여 점차 기능별로 세분화된 SPEC과 다양한 서비스 컨텐츠들도 빼놓을수없는 이유일것이다. 이번호에서는 OSGi의 핵심 기능인 서비스와 실제 활용 사례를 살펴보고, 이제 더 이상 OSGi는 이론적으로 존재하는 그리고 임베디드에 국한된 시스템이 아닌 실제적이고 파워풀한 유니버셜 미들웨어라는 것을 보게될것이다.

OSGi의 가장 핵심적인 임무는 '다양하고 새로운 서비스의 제공'이다.

과거 OSGi가 처음 형성됐을 때는 전 세계를 잇는 네트워크를 홈 네트워크에 어떻게 연결하고 어떤 서비스를 제공할지를 도출하는 것이 OSGi 멤버들의 최대 관심사였다.

1. OSGi의 핵심 - 서비스

OSGi가 오픈 서비스 게이트웨이를 구성하는 아키텍처의 소프트웨어를 개발하는 것도 이 때문이다. OSGi 참여업체들은 이를 통해 '서비스 기반으로 제공할 수 있는 새로운 비즈니스 모델'을 찾고 있다. 이는 단순히 제품만을 판매하는 20세기 사업모델에서 탈피해 다양하고 새로운 서비스를 판매하는 21세기형 사업모델을 만드는 것이 OSGi의 주요 업무였기 때문이다.

특히 OSGi는 네트워크 환경이 구축된 일반 가정이 차세대 프론티어 역할을 할 것으로 판단함으로써 인터넷과 신기술이 일반 가정에 새로운 서비스를 제공할 수 있을 것으로 기대하고 있었다. 이를 통해 새로운 가치사슬도 형성된다는 판단인데, 이를 위해서는 반드시 관련 업계(컴퓨터, 가전, 통신 등)가 모두 수긍하는 표준화 작업이 선행되어야 한다. 특정 업체만 지원하는 서비스나 프로토콜은 오래 지속되지 않을 뿐더러, 대규모의 시장을 창출할 수 없기 때문이다. OSGi 서비스 제공업체들은 네트워크로 연결된 가정 내 각종 기기에 접속해 기기의 이상 유무에서부터 원격 제어 및 원격 수리 등의 다양한 부가서비스를 제공하고, 이를 통해 새로운 수익을 창출할 수 있기 때문이다.

이렇듯 초기의 OSGi 개발 및 참여업체들은 이처럼 다양한 서비스가 가능한 게이트웨이의 표준 소프트웨어 사양 개발 작업에 착수해 현재 그 버전이 4.0 대에 이르고 있다. 따라서 오늘날 OSGi에 참여해 개발을 주도한 업체들은 이미 다수의 구체적인 성과물을 제시하고 있다. OSGi가 차세대 IT 산업과 가전산업을 주도할 태풍의 핵으로 부상하고 있는 것도 바로 이 때문이다.

1.1 JES와 OSGi

OSGi는 자바 환경에서 구동되는 미들웨어이므로 자바와 매우 밀접한 관계를 나타낸다. 임베디드 자바 솔루션 중에서 자바 임베디드 서버(Java Embedded Server, 이하 JES)는 임베디드 디바이스를 위한 퍼스널 자바 기반의 런타임 환경이다. 그리고 JES는 네트워크를 통한 서비스의 제공과 서비스 라이프 사이클의 관리 기능을 제공하는 소용량 애플리케이션 서버라고 할 수 있다. 그렇다면, OSGi와 JES는 어떤 관계일까? OSGi의 표준화를 주도한 업체가 썬 마이크로시스템즈(이하 썬)라는 사실을 안다면 그 해답을 쉽게 찾을 수 있다. 즉 JES는 OSGi 표준을 구현한 임베디드 서버 솔루션 중의 하나인 것이다. JES의 구조 역시 프레임워크와 서비스로 구성되어 있다. 서비스는 JES 서버에서 동작하는 컴포넌트화된 애플리케이션이고, ServiceSpace 프레임워크는 서비스의 컨테이너이다. 프레임워크의 기본적인 기능은 서비스들의 설치와 업그레이드, 삭제 등과 같은 라이프사이클에 대한 제어이고, 서비스는 서비스 인터페이스에 구현되는 형태로 구성된다. 그리고 JAR(Java ARchive) 파일로 패키지화된 서비스를 ‘번들’이라고 부른다. 이런 개념들은 이미 우리가 살펴보았던 OSGi와 동일하다. JES 서버는 네트워크를 통한 서비스의 설치와 업그레이드, 삭제 등을 할 수 있지만, 처음 기동되는 경우에 몇 가지 기본적인 서비스를 포함하고 있다. 결국 OSGi의 개념과 구조는 새롭게 탄생된 것이 아니라 탄생을 주도한 썬의 영향력 아래에서 차분하게 성장한 것임을 알 수 있다. 다음은 JES에서 제공하는 기본 서비스 기능이다.

- HTTP 서비스 : 웹 서버 기능
- 로그 서비스 : 에러와 이벤트 등의 원격 로깅 기능
- 날짜 서비스
- 연결 관리 서비스 : 네트워크 서비스, 소켓 바인딩, 연결 요청 처리 등의 기능
- 스레드 매니저 서비스 : 스레드 풀의 최대치 등에 대한 스레드 관리 기능
- 스케줄러 서비스 : 향후의 이벤트에 대한 스케줄링 기능
- RMI(Remote Method Invocation) 서비스
- SNMP(Simple Network Management Protocol) 서비스
- 콘솔 서비스 : 애플릿을 통한 원격 관리 기능

이 중에서 OSGi 1.0 규격에 포함된 표준 서비스는 HTTP 서비스, 로그 서비스, 연결 관리 서비스(OSGi에서는 디바이스 액세스 서비스)이며 계속해서 다양한 분야의 스펙으로 확장해 가고 있다. 발표된 1.0 스펙은 주로 게이트웨이에 탑재되는 응용프로그램 인터페이스(API)에 대한 규정을 담고 있으며 자바(JAVA)용 API에 집중되어 있다. 이는 자바가 현재 가장 널리 사용되는 프로그래밍 언어인터라 개방형 서비스 게이트웨이에 유연하게 적용될 수 있었기 때문이다.

1.2 OSGi - SPEC

OSGi는 1.0부터 4.0 대에 이르기까지 버전을 업그레이드하면서 스펙 표준안을 마련하고, 또한 마련된 스펙은 플랫폼이나 응용소프트웨어 등에 전혀 구애받지 않는다고 발표했다. 또한 보안 기능이 우수할 뿐 아니라 다양한 서비스 제공업체들이 전달해주는 멀티 서비스를 각기 다른 장치나 설비에 제공하는 기능을 항상 염두에 두고 표준안을 마련하고 있다. 이러한 업계의 표준화 노력으로 OSGi의 스펙 표준안은 특히 블루투스(Bluetooth)와 HAVi, HomePNA, HomeRF, IEEE-1394, LonWorks, USB, VESA 등 다양한 유무선 네트워크 기술을 수용할 수 있어 가장 포괄적인 개방형 네트워크 기술로 인정받고 있다. 특히 OSGi는 완전히 새로운 개념의 장비들이 등장할 것에 대비해 JINI와 HAVi 등이 제공하는 기능도 전폭적으로 수용한다. 이는 셋톱박스와 케이블모뎀, 라우터, 경보시스템, 전력관리시스템, 가전제품, PC 등 모든 제품에 대한 관리 및 연결 기능을 제공하기 위한 것이다.

[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 7월호에 실린 기사입니다]

OSGi는 운영체제, 플랫폼에 독립적으로 운영되는 미들웨어 프레임워크이다. 또한 표준화된 스펙, 컴포넌트 구조 그리고 분산 네트워크 서비스에 최적화된 컴퓨팅 환경을 제공해주는 서비스 플랫폼이기도하다. 이러한 특성으로 최초 적용모델인 모바일, 임베디드 시스템에서 점차 확장되어 클라이언트/서버, 데스크탑 애플리케이션의 RCP(Rich Client Platform), 더 나아가 엔터프라이즈 환경의 프레임워크에(Spring-OSGi) 이르기까지 점차 그 영역을 넓혀 나가고 있다. 무엇이 모바일/임베디드 환경의 OSGi를 엔터프라이즈까지 확장시키게 했을까? 이제부터 Universal Middleware, Service Platform으로 자리매김한 OSGi에 대해서 알아보기로 한다.

1.1 OSGi 탄생과 배경

OSGi는 Open Service Gateway Initiatives의 약어로서, 일종의 Middleware Framework이다. 또한 OSGi는 기본적으로 자바환경에서 구현되며, 자바를 위한 Dynamic Module System이라고 불리기도 한다. OSGi가 탄생하게 된 배경은 다음과 같다. 지난 90년대 중반을 지나면서 나타난 인터넷의 폭발적인 성장세는 IT뿐만 아니라 우리 생활 곳곳에 여러 부분을 변화시키기 시작했다. 이러한 변화 가운데 새롭게 각광받는 분야가 바로 홈네트워크이다. 홈네트워크는 기존의 전통적인 가정과 주거환경을 인터넷과 결합하여 우리들에게 보다 더 편리하고 쾌적한 주거 및 가정환경을 제공해줄 것이라고 생각했고 이에 많은 사람들과 기업들이 주목하기 시작했다. 또한 수많은 기업들이 홈네트워크에 많은 투자를 감행했고, 여기에는 기존 IT 기업뿐만 아니라 통신, 가전, 주택/건설, 환경 업체들까지 뛰어들게 된다. 이렇게 많은 업체들이 홈네트워크에 뛰어들면서 인터넷에 연결되는 정보 및 가전기기들의 호환성 문제가 대두되게 된다. 이에 IT, 가전, 통신, 주택/환경 분야의 대표적인 업체들이 모여서 Local Network상에서 상호 호환성을 보장하고, 각 Device에서 관리되는 Service들의 배포 및 공유에 대한 공개 SPEC을 제정하게 된다. 이러한 배경을 갖고 탄생하게 된 것이 바로 OSGi 기술이다. OSGi는 SPEC이 공개된 기술이며, 모든 개발 및 스펙 제정 활동은 OSGi Alliance에 의해서 승인되고 진행된다. 국내에서는 삼성전자가 OSGi Alliance 창립때부터 주요 이사 멤버로 활동하였으며, 현재는 KT, ETRI에서도 참여하고있다. 현재 홈네트워크의 기능을 크게 가전기기의 상태 정보/모니터링, 기기의 원격 제어컨트롤, A/V 및 주방가전의 홈솔루션의 통합으로 구분하고 있는데, 가정의 구성된 네트워크에 속한 단말 또는 가전에 접근하기 위해서는 디바이스에 대한 표준화된 네트워킹(Ethernet, Bluetooth, Wireless LAN, IEEE1394, PLC)과 범용 미들웨어(Universal Middleware)가 필요하다. 이로 인해 나온 것이 바로 UPnP, HAVi, JINI등의 표준이다. 이러한 장비 연결 및 제어로 얻을 수 있는 유효한 서비스로는 [그림 1]과 같이 다양한 서비스들이 있으며, 이러한 서비스의 배포문제와 서비스가 작동하기 위한 제반 환경 제공을 목표로 하는 것이 바로 OSGi의 기본 목표라고 할 수 있다.

* OSGi Alliance

1. 설립 : 1999년 3월, 비영리 단체
2. 목적 : OSGi 공개 표준 SPEC 제정 (2000년 5월 OSGi 1.0 Release 후에 현재 4.x까지 제정)
3. 멤버 : 통신 (노키아, 모토롤라, 도이치텔레콤, 프랑스텔레콤, KT, 보다폰), 가전 (삼성전자, 필립스, 월풀, 지멘스, 샤프, 도시바, 히다치), IT (IBM, SUN, Intel, Oracle, HP, ETRI, Prosyst), BMW 등의 자동차 업체 현재 80여개 업체 참여.
4. 전문가 그룹 : CPEG(Core Platform Expert Group), VEG(Vehicle Expert Group), MEG(Mobile Expert Group), EEG(Enterprise Expert Group) 크게 4개로 구성되어 해당 분야의 요구사항 분석과 그에 따른 스펙 제정. 최근 2007년 10월 제주도에서 열린 OSGi User Forum KOREA 2007에서 OSGi Alliance 의장을 맡고있는 독일 ProSyst 사의 Kai는 GEG(Gateway Expert Group)가 구성되어 활동을 할것이라고 선언하였다.

1.2.2 Remote Component Management

OSGi는 원격관리를 지원한다. OSGi는 번들 단위로 서비스를 형성하고 운영되는데, 번들을 업데이트하거나 업그레이드를 원격에서 관리하고, 제어할 수가 있다. 자바VM를 재부팅할 필요 없이 사용 중에 원격으로 업데이트/업그레이드할 수 있는 것은 매우 큰 특징이 된다. 이를 위해서 OSGi는 원격관리표준 프로토콜을 제정하였으며, OSGi가 탑재되고 운영되는 환경에 맞게 사용하면 된다. 원격관리 프로토콜로는 대표적으로 OMA-DM, SNMP, CMISE 그리고 Telnet/SSH 등이 사용된다. OSGi가 탑재된 컨트롤러나 디바이스가 인터넷이나 로컬 네트워크에서 운영된다면, 주로 과거에는 SNMP, Telnet/SSH 등을 사용했다. 그러나 최근에 무선환경이 급격하게 확산되고 모바일/무선 디바이스들의 사용이 늘어나면서 새롭게 탄생한 프로토콜이 바로 OMA-DM이다. OMA-DM은 Open Mobile Alliance for Device Management의 약어로서 모바일 디바이스를 위한 유/무선 통합 관리 프로토콜이다. Physical Layer에서 유선모드라면 USB, RS-232C를 사용하고, 무선모드에서는 GSM, CDMA, IrDA, Bluetooth를 사용하여 데이터를 전송한다. 또한 Transport Layer에서는 HTTP, WAP, OBEX(Object Exchange)를 사용하며, 데이터 전송언어로는 SyncML를 사용하여 데이터 호환 및 규격을 통일하였다. 마지막으로 Binary transmissions과 Session Management를 통하여 SyncML의 Text format을 압축/암호화하고 HTTP/WAP의 세션을 관리한다. 필립스의 가정용 컨트롤러 iPronto, 노키아의 스마트폰, BMW 5/6 시리즈에 탑재된 텔래매틱스 등이 OMA-DM을 활용하여 컨텐츠 번들을 관리하고 업그레이드하는 대표적인 제품들이다.

[그림4. 필립스의 홈컨트롤러 iPronto]

1.2.3 Cooperation Between Applications

많은 자바 애플리케이션 서버 환경에서 구동하는 자바 애플리케이션들은 독립성을 보장하기 위해서 극히 폐쇄적인 컨테이너 환경에서 작동된다. 만약 다른 자바 애플리케이션과의 연동 및 통합을 위해서는 라이브러리 코드를 각각 가져와서 구동해야하는 오버헤드가 필수적으로 생긴다. 예를 들어 엔터프리이즈 환경에서 사용되는 JMS 서비스 API는 백앤드 서버 라이브러리에 위치하며, 대략 크기가 30-40KB정도이다. 만약 MIDP 애플리케이션이 JMS를 이용하여 메시징 서비스를 하려한다면, 백엔드 서버의 라이브러리 코드를 사용해야하며, 다수의 MIDP 애플리케이션이 구동할경우 n개의 JMS-API가 구동하는 오버헤드가 생기게 된다. 이런 문제점들을 해결하기 위해서 나온 솔루션 서비스가 바로 SOA (Service Oriented Architecture)이다. OSGi는 이러한 SOA의 기본적인 구조 즉, 공통적으로 사용되기위한 서비스 또는 라이브러리API를 서버나 공간의 어느 디바이스에 등록하여(Registry) 배포, 공유하면(Contribute) 접근가능한 어떤 애플리케이션이라도 사용할 수 있는 연결 구조를(Loosely Coupled) 지향하고 있다. 특히 OSGi는 엔터프라이즈 서버 환경보다 매우 가볍고, 빠르게 접근하고 바인딩할 수 있는 OSGi Framework Service Registry 구조를 가지고 있다. 이러한 OSGi 서비스간의 협업 구조는 리소스가 한정적인 모바일, 임베디드 환경에서 매우 강력한 위력을 발휘하였고, 현재는 데스크탑 애플리케이션 영역까지 확장되어 이클립스 기반의 RCP와 IBM Expeditor 솔루션으로 나타나게 된다.

1.3 Architecture

OSGi 구조는 다음과 같이 몇 개의 계층으로 구성되어있다. OSGi는 우선 자바 런타임 환경에서 구동된다. 자바 런타임은 하드웨어 환경에 의해서 J2ME(CDC/CLDC), J2SE, J2EE로 구성되며, 하나의 VM에서 서로 다른 복수개의 클래스 로더들에 의해서 각각의 OSGi 애플리케이션이 작동된다. 자바 런타임 환경위에 OSGi Framework이 실행된다. OSGi Framework은 크게 번들의 실행주기(설치/시작/중단/제거/업데이트), OSGi 기본 실행 단위인 번들(Bundle)과 서비스에 대한 운영 관리 및 리소스와 서비스 레지스트리를 담당하게 된다. 복수개의 클래스로더에 의해 각각 서로 다른 OSGi 애플리케이션이 독립성을 가지고 실행되지만, OSGi Framework Service Registry에 등록된 Sharing Code와 Address에 의해 서로 다른 번들간의 리소스 공유와 연동/통합으로 무수한 서비스들을 생성하고 실행하게 된다. 이러한 OSGi Framework 구조는 JES (Java Embedded Server)에 의해 많은 영향을 받게 되었다.