[이현규의 홈 네트워킹 대해부 - 10] 서비스 플랫폼 - OSGi

OSGi(www.osgi.org)는 Open Service Gateway Initiative의 약자로, 1999년 3월에 성립된 비영리 표준화 단체이다. 40개사 이상이 회원사로 가입해 있으며, 가전/전자, 자동차, 통신, IT 등 다양한 분야의 회원사들이 활발하게 활동하고 있다. 그 역할은 서비스를 로컬 네트워크나 장비에게 전달하고 전달된 서비스가 운용되는 개방적 표준을 만드는데 있다.

우리는 지금까지 홈 네트워크를 정보 네트워크, A/V 네트워크, 제어 네트워크의 세가지 네트워크로 분류하고 있다. 각각의 네트워크에 속한 단말에 접근하기 위해서는 장비에 대한 연결 기술(Ethernet, Bluetooth, 무선랜, IEEE 1394, 전력선 통신기술 등)이 필요하다. 좀 더 섬세한 조절과 장비간의 상호작용을 원활히 하기 위해서는 미들웨어가 필요한데 이것이 UPnP, HAVi, JINI등인 것이다.

이러한 장비 연결 및 제어로 얻을 수 있는 유효한 서비스로는 [그림 1]과 같이 다양한 서비스들이 있으며, 이러한 서비스의 배포문제와 서비스가 작동하기 위한 제반 환경 제공을 목표로 하는 것이 바로 OSGi라고 할 수 있다.

OSGi 서비스 플랫폼은 크게 세가지 분야를 관심대상으로 한다. 첫째는 서비스들간의 연결 및 제어, 둘째는 서비스와 OSGi 프레임워크간의 연결 및 제어, 셋째는 OSGi 프레임워크와 외부 서비스 관리 시스템과의 연결 및 제어이다. 따라서 OSGi 서비스 플랫폼은 초고속통신망과 같은 외부 네트워크와 댁내의 장비들을 연결하는 네트워크의 사이에 위치하게 된다 ([그림2]의 빨간줄).

외부 네트워크 환경에서는 서비스 제공자가 서비스 제공 및 관리를 수행하고, 댁내 네트워크 환경에서는 수많은 장비들과 상이한 프로토콜들이 이들을 원활히 연결하고 제어해야 한다. 결국 OSGi 서비스 플랫폼은 외부 네트워크 환경과 댁내 네트워크 환경의 중재자인 셈이다.

OSGi는 자바 VM(Virtual Machine) 기반 하에서 작동하게 만들어진 표준이다. 자바 VM은 이질적인 Embedded OS와 Embedded CPU에서 오는 차이점들에 대한 완충 역할을 수행한다. OSGi 서비스는 모두 번들(Bundle)이라 불리우는 물리적 묶음에 포함된다. 복수개의 OSGi 서비스가 하나의 번들에 포함되어질 수도 있으며, 번들은 배포와 관리의 기본 단위를 형성한다 [그림 3].

이 번들들을 관리해 주는 것이 바로 프레임워크(Framework)이다. 프레임워크는 서비스 등록/관리기(Service Registry)를 가지고 있어서 서비스에 대한 등록/조회/실행/삭제 등을 수행한다. 또한 이벤트와 그에 따른 이벤트 탐지 및 대응 처리도 하게 된다. 여기서 말하는 이벤트는 장비에서 생성된 물리적 이벤트와는 관계가 없고 서비스/번들/프레임워크의 세가지 이벤트 산출자를 근간으로 하는 논리적 이벤트라는 점에 유의할 필요가 있다.

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)의 구성요소는 다음과 같다.

· Framework Spec 1.2 : 번들/서비스 관리, 이벤트 처리

· Package Admin Service Spec 1.1 : 번들에서 사용하는 패키지 관리

· Start Level Service Spec 1.0 : start level이 각 번들마다 할당되며 번들의 상대적인 시작과 종료 순서를 조절

- Permission Admin Service Spec 1.1 : 번들에 대해서는 권한이 할당되며 해당 번들은 주어진 권한내의 작업만을 수행 가능

· URL Handlers Service Spec 1.0 : 자바에 관련된 명세로서 새로운 URL 방식에 대한 URL 처리기 를 등록시킬 수 있도록 지원

· Log Service Spec 1.2 : 업무 처리에 대한 이력관리를 위해 로그(log) 데이터를 저장하고 저장된 로그 데이터을 볼 수 있게 함

· Configuration Admin Service Spec 1.1 : 각 번들마다 구성 정보를 관리할 수 있게 함

· Device Access Spec 1.1 : 장비 관리자를 정의. 장비 관리자는 새로운 장비의 출현을 인식하고 해당 장비에 맞는 드라이버를 탐색

· 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를 통해 제어

· Http Service Spec 1.1 : 서비스는 웹을 통해 사용자와 통신할 필요가 많으므로 서비스에서 Servlet이나 화상 등의 웹 리소스를 등록할 수 있는 기능을 제공

· 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로 찾는 방법만을 지원

· Service Tracker Spec 1.2 : 서비스가 수행되면 상호 호출 등을 통하여 다른 서비스와의 의존관계가 생기게 된다. 이때 관리자에 의해 번들이 정지 등의 상황이 생기면 번들에 속하는 모든 서비스가 정비되어야 하는데 의존관계에 있는 모든 다른 서비스들은 이처럼 정지된 서비스를 실행시킬 수가 없게 된다. 이러한 경우 특정 서비스에 대한 추적을 쉽게 해주는 기능에 관련된 명세가 Service Tracker Spec이다.

· 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 권고명세(Recommended Specification)의 구성요소는 다음과 같다.

· Name-space Spec 1.0 : OSGi 네트워크에 참여하는 모든 entity들을 지칭할 수 있는 포괄적인 name-space를 정의.

· Jini Driver Service Spec 1.0 : 외부의 Jini 서비스 탐색(Discovery)과 제어(Control)를 담당하며 외부에 대해 OSGi 서비스를 Jini 서비스로 포장해 주기도 함.

· UPnP Device Service Spec 1.0 : UPnP 장비와 상호작용할 수 있는 API 제공

· Initial Provisioning 1.0 : Management Agent를 원격에서 관리하는 명세.

OSGi는 서비스가 작동하고 관리되는 서비스 환경 표준이다. 현재와 같이 초기단계의 홈 네트워킹 시장에서는 아직까지 장비제어 정도의 기술이 주로 사용되고 있지만 많은 장비들이 상호작용할 시점에 이르면 미들웨어 시장이 활성화될 것이다.

더 나아가 서비스가 점차적으로 고도화되어 질수록 OSGi와 같은 서비스 환경이 꼭 필요하게 될 것이다. 홈 네트워크상의 UPnP, HAVi, JINI와 같은 미들웨어가 주로 장비의 제어나 데이터 전달 등을 처리하게 되므로 OSGi는 상호 보완적인 위치에 있는 셈이다. OSGi를 사용하거나 구현하는 쪽에서는 이러한 미들웨어의 지원이 또 다른 고려 사항임에 유의해야 한다.

필자가 생각하는 OSGi의 가장 큰 문제점 중의 하나는 OSGi가 JAVA지향이라는 점에서부터 온다. JAVA VM을 채택하면서부터 비용증가가 예상되고 동적 실행환경의 오버헤드 또한 무시할 수 없는 요소이다. 그러나 JAVA를 채택함으로써 오는 관리나 개발의 편이성 등의 이득이 만만치 않으므로 이러한 문제점을 어느 정도는 상쇄시킬 수 있을 것이다. 결론적으로 OSGi는 고도화된 서비스 환경에 알맞는 경쟁력있는 서비스 플랫폼 중의 하나임에 틀림없을 것이다.

지금까지 홈 네트워킹에 필요한 미들웨어와 서비스 플랫폼에 대해 개별적으로 알아보았다. 이 분야는 기술에 대한 전문성이 필요하여 다음과 같이 필자의 회사 동료들에게 부탁하여 게제하였음을 알려드리며, 동료들에게 감사의 말씀을 전하고자 한다. 다음 호부터는 홈 네트워킹 시장에 대해 알아보고자 한다.

/이현규 아이크로스테크놀러지 대표 hklee@icrosstech.com