[작성 - 김석우, 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의 기본 목표라고 할 수 있다.
[그림 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)가 구성되어 활동을 할것이라고 선언하였다.
[그림 2. OSGi - Release Version]
1.2 OSGi 특징
OSGi는 서비스가 작동하고 운영되는 서비스 환경에 관한 표준 기술이다. 과거 OSGi R1.0이 발표될때만 하더라도 OSGi는 홈네트워크의 네트워크 표준에 국한된 부분이 많았으나, 현재 4.0에 이르러서는 기존의 홈네트워크 외에 모바일, 임베디드, 텔래매틱스, PC 애플리케이션 (Eclipse 기반의 RCP)는 물론 엔터프라이즈 환경의 프래임워크에까지 확장하고있다. 그만큼 기존의 미들웨어에 비해서 많은 장점을 가지고있다는 방증이다. 또한 과거 초기 단계의 홈 네트워킹 및 빌딩 제어, 자동화 시장에서 디바이스 제어 기술이 주로 사용되고 있지만 현재는 그보다 훨씬 다양한 디바이스간의 상호작용을 요구하게 되고 더 나아가 컨텐츠 및 솔루션 서비스가 점차적으로 고도화되어 질수록 OSGi와 같은 서비스 플랫폼 환경이 꼭 필요하게 될 것이다. 현재 다양한 디바이스들간의 상호운용성을 위해서 UPnP, HAVi, JINI같은 표준이 만들어지고 주로 장비의 제어나 데이터 전달 등을 처리하게 되므로 OSGi 기술과 상호 보완적인 위치에 있는 셈이다. OSGi를 사용하거나 구현하는 쪽에서는 이러한 미들웨어의 지원이 또 다른 고려 사항임에 유의해야 한다. 그럼 OSGi의 주요 특징을 살펴보자.
1.2.1 S/W Component Management
OSGi는 자바 기반의 Component 구조로 설계되어 있다. 따라서 OSGi는 자바 런타임 환경하에서(J2ME, J2SE, J2EE) 작동하게 만들어진 표준이다. 자바VM은 이질적인 Embedded OS와 Embedded CPU에서 오는 차이점들에 대한 완충 역할을 수행한다. 또한 OSGi는 서비스 기반의 구조 지향한다. 서비스는 모두 번들(Bundle)이라 불리우는 물리적 묶음에 포함된다. 복수개의 OSGi 서비스가 하나의 번들에 포함되어질 수도 있으며, 번들은 배포와 관리의 기본 단위를 형성한다. 이 번들들을 관리해 주는 것이 바로 프레임워크(Framework)이다. 프레임워크는 서비스에 대한 등록/관리기(Service Registry)를 가지고 있어서 서비스에 대한 등록/조회/실행/삭제 등을 수행한다. 또한 이벤트와 그에 따른 이벤트 탐지 및 대응 처리도 하게 된다. 여기서 말하는 이벤트는 장비에서 생성된 물리적 이벤트와는 관계가 없고 서비스/번들/프레임워크의 세가지 이벤트 산출자를 근간으로 하는 논리적 이벤트라는 점에 유의할 필요가 있다. OSGi의 가장 기본적인 그리고 중요한 요소인 Bundle, Service, Framework는 뒤편에서 좀더 자세하게 다룬다.
[그림 3. OSGi 구조 다이어그램]
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]
많은 자바 애플리케이션 서버 환경에서 구동하는 자바 애플리케이션들은 독립성을 보장하기 위해서 극히 폐쇄적인 컨테이너 환경에서 작동된다. 만약 다른 자바 애플리케이션과의 연동 및 통합을 위해서는 라이브러리 코드를 각각 가져와서 구동해야하는 오버헤드가 필수적으로 생긴다. 예를 들어 엔터프리이즈 환경에서 사용되는 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)에 의해 많은 영향을 받게 되었다.
