osgi 상의 서비스 이동 관리 시스템 · framework to connect various devices in a local...
TRANSCRIPT
工學碩士學位論文
유비쿼터스 컴퓨팅 환경을 위한
OSGi 상의 서비스 이동 관리 시스템
Service Mobility Management System on OSGi
for Ubiquitous Computing Environment
2006年 02月
仁荷大學校 大學院
컴퓨터 • 情報工學科
李 慶 模
工學碩士學位論文
유비쿼터스 컴퓨팅 환경을 위한
OSGi 상의 서비스 이동 관리 시스템
Service Mobility Management System on OSGi
for Ubiquitous Computing Environment
2006年 02月
指導敎授 李 楨 賢
이 論文을 碩士學位論文으로 提出함
仁荷大學校 大學院
컴퓨터 • 情報工學科
李 慶 模
이 論文을 李 慶 模의 碩士學位論文으로 認定함
2006年 02月
主審 _________________________
副審 _________________________
委員 _________________________
요 약
OSGi 는 홈, 오피스, 자동차와 같은 로컬 네트워크 상에서 다양한 디바
이스들을 연결하며, 관리 가능한 확장성 있는 프레임워크를 제공함으로써,
유비쿼터스 컴퓨팅 환경에 적합한 기술이다. 또한, OSGi는 표준적인 실행 환
경과 서비스 인터페이스를 정의함으로써, 서로 다른 다양한 종류의 리소스들
로부터 서비스와 디바이스들의 동적인 발견과 협력을 가능하게 하는 장점으
로 인해 유비쿼터스 컴퓨팅 환경에서 서비스 게이트웨이 기술로 널리 이용
되고 있다. 그러나, OSGi 프레임워크에서는 서비스의 배포 및 설치 단위인
번들 코드의 다운로드를 통한 원격 설치를 지원하지만, 실행 중인 서비스의
이동을 지원하지 못한다. 따라서 OSGi 프레임워크 상에서 실행 중인 서비스
를 다른 OSGi 프레임워크 상으로 이동할 수 있는 서비스 이동 관리 시스템
이 필요하며, 이러한 서비스 이동성을 지원하는 시스템은 번들 형태로 지원
이 가능하다.
본 연구는 OSGi 프레임워크들간 서비스의 이동성을 보장하기 위해서
번들의 프레임워크들간 이동성 관리 방법을 제안한다. 이를 위해서 번들의
라이프 사이클과 이동 관리 기능을 위한 서비스 이동 관리 시스템을 설계한
다. 설계한 서비스 이동 관리 시스템은 OSGi 프레임워크에서 동작될 수 있
기 위해서 OSGi 표준 스펙에 맞게 설계 및 구현하며, 이동성을 갖는 서비스
에 대한 관리를 가능하게 함으로써 유비쿼터스 컴퓨팅 환경에서 서비스의
이동성을 보다 효과적으로 지원할 수 있다.
i
Abstract
The Open Services Gateway Initiative (OSGi) attempts to meet the
ubiquitous computing environment by providing a managed, extensible
framework to connect various devices in a local network such as in a home,
office, or automobile. By defining a standard execution environment and service
interface, the OSGi promotes the dynamic discovery and collaboration of
devices and services from different sources. The OSGi offers a unique
opportunity for ubiquitous computing as a potential framework for achieving
interoperability between various sensors, home appliances, and networked
devices. The OSGi framework supports a remote installation of a bundle, which
is a unit that installs and deploys services. However, in order for the service in
execution to move, a specific form of bundle such a mobile service manager is
needed, one which is able to move through a heterogeneous network.
This paper proposes a method that can manage bundles for supporting
dynamic service’s mobility between frameworks, in order to ensure the mobility
of services in a multiple the OSGi framework environment. For our purposes,
we have designed the mobile service management system for managing the
lifecycle of the bundle and for the mobility of services in the OSGi framework.
The mobile service management system we are proposing implements a bundle
form which can perform in an OSGi framework as well as manage the mobile
services. As a result, mobility in a ubiquitous computing environment will be
supported more efficiently.
ii
목 차
요 약 ................................................................................................................................... i
Abstract.............................................................................................................................. ii
제 1장 서 론......................................................................................................................1
제 2장 OSGi에 관한 고찰 ..............................................................................................3
2.1 OSGi 개요............................................................................................................3
2.2 기존 OSGi의 문제점.......................................................................................11
제 3장 서비스 이동 관리 시스템 설계 및 구현 ......................................................12
3.1 서비스 이동 관리 시스템 개요 ....................................................................12
3.2 서비스의 라이프 사이클 ................................................................................16
3.3 서비스의 이동 객체 생성 ..............................................................................17
3.4 서비스의 이동 ..................................................................................................21
3.5 서비스의 복원 ..................................................................................................22
제 4장 실험 및 평가......................................................................................................27
4.1 실험 환경 및 시나리오 ..................................................................................27
4.2 음악 서비스 개발 ............................................................................................29
4.3 평가 ....................................................................................................................34
제 5장 결 론....................................................................................................................36
참고 문헌..........................................................................................................................37
iii
제 1장 서 론
유비쿼터스 컴퓨팅 환경을 위해서 물리적인 센서와 가전제품들을 상호
연결할 수 있는 DLNA, UPnP, Jini, HAVi, OSGi 등의 개방형 표준 인터페이
스에 대한 많은 연구들이 진행되고 있으며, 이러한 연구는 유비쿼터스 컴퓨
팅을 실제적으로 구현하는데 초점을 맞추고 있다[Dobr02][Stra03]. 특히,
OSGi(Open Services Gateway Initiative)는 센서, 임베디드 디바이스, 가전제품
들을 인터넷에 접속하는 표준방식에 관한 산업계의 계획으로 서비스 제공업
체와 가정 및 소규모 기업망 내에 있는 장치들 사이에서 통신 및 제어를 할
수 있게 하기 위한 자바 기반의 개방형 표준 프로그래밍 인터페이스를 제공
한다[Gong01][Marp01]. 이와 유사한 이전의 기술들은 디바이스들 간의 상호
운용성에 집중한 반면에, OSGi 는 디바이스에 관한 서비스의 전달, 배치, 관
리 등에 초점을 맞춘다[Hall04a]. 또한, OSGi 기반의 어플리케이션 개발을 통
한 Jini 나 UPnP 등의 기술에 관한 연결 서비스를 배치할 수 있거나 상호 작
용이 가능하다[Dobr02]. 이미 OSGi 는 홈, 사무실, 자동차와 같은 로컬 네트
워크 상에서 다양한 디바이스들을 연결하며, 관리 가능한 확장성 있는 프레
임워크를 제공함으로써, 유비쿼터스 컴퓨팅 환경에 한발 앞서 다가가고 있다.
또한, 표준적인 실행 환경과 서비스 인터페이스를 제공함으로써, 서로 다른
다양한 종류의 리소스들로부터 서비스와 디바이스들의 동적인 발견과 협력
을 증진시킨다[Lee03][Take04].
유비쿼터스 공간에서 사용자, 디바이스 및 센서 등의 개체는 이동성을
갖고 있으며, 자신의 실행 상태를 유지한 채로 진행 중인 서비스는 개체의
이동에 따른 공간 간의 이동성을 지원할 필요가 있다.
OSGi 기반의 시스템에서는 새로운 서비스를 분배할 수 있는 구조를
가지고 있으며, 그 구조가 로컬 네트워크 상의 구성 요소들만으로 이루어져
있어서 비교적 폐쇄적인 특성을 갖는다. 하지만, 하나의 OSGi 프레임워크 내
에서의 서비스 관리와 분배가 동적으로 수행될 수 있는 반면에, 복수의
OSGi 프레임워크들 간의 이동성을 갖는 응용들에 대한 지원은 부족한 실정
이다. 그래서 유비쿼터스 공간에서의 복수의 OSGi 프레임워크들 간의 사용
자, 디바이스 및 센서들의 이동성에 관한 충분한 고려가 이루어져야 하며,
그에 따른 이동성을 지원하는 서비스에 관한 연구가 필요하다.
본 연구에서는 유비쿼터스 컴퓨팅 환경에서 서비스의 상태 정보을 포
함하는 서비스 객체의 OSGi 프레임워크간 자유로운 이동을 위한 OSGi 상의
서비스 관리 시스템을 설계한다. 설계한 시스템은 OSGi 상의 서비스의 이동
을 관리할 수 있는 OSGi 프레임워크의 번들 형태로서 구현되며, OSGi 프레
임워크 간의 서비스의 자유로운 이동을 지원한다. 따라서, 특정 컴포넌트나
사용자를 위한 서비스, 디바이스 드라이버 등 다양한 형태의 개체들의 이동
성을 지원할 수 있다. 제안한 OSGi 상의 서비스 이동 관리 시스템의 평가를
위해서, 설계, 구현된 서비스 이동 관리 번들을 이용하여 OSGi 프레임워크를
구현한 오픈 소스인 Knopflerfish 1.3.3 을 이용해서 OSGi R3 표준 스펙에 맞
게 설계 및 구현되었는지를 실험하였다.
본 연구의 구성은 다음과 같다. 2 장에서 관련 기술인 OSGi 에 대해서
설명하고, 3 장에서 본 연구에서 제안하는 OSGi 상의 서비스 이동 관리 시스
템의 설계 및 구현에 대해서 설명한다. 4 장에서 실험을 통한 제안한 시스템
을 평가하며, 마지막 5장에서 결론을 맺는다.
제 2장 OSGi에 관한 고찰
이 장에서는 홈 네트워크 상의 서비스를 관리하는 OSGi(Open Services
Gateway Initiative)에 관하여 기술하고, 유비쿼터스 컴퓨팅 환경에서 OSGi
프레임워크 상에서의 서비스 이동성을 위해 필요한 기능들에 대해서 기술한
다.
2.1 OSGi 개요
개방형 서비스 게이트웨이란 전 세계적으로 퍼져 있는 컴퓨터 위주의
인터넷을 가전제품, 조명기기, 계량기 등 집에서 사용하는 모든 가전 제품과
설비까지 연결시켜 홈 네트워크를 인터넷의 한 부분으로 편입시켜주는 역할
을 한다[Cond99]. Open Services Gateway initiative(OSGi)는 인터넷 기반의 네
트워크 환경에서 서비스를 전달하고 배치, 관리하기 위한 표준 명세를 정의
하는 비영리 단체이다. OSGi 에는 도이치 텔레콤, 프랑스 텔레콤, 노키아 등
의 통신업체들과 월풀, 삼성전자, 샤프, 지멘스, 도시바 등의 가전업체들, 그
리고 컴팩, HP, 프로시스 소프트웨어, 썬마이크로시스템즈 등 컴퓨터 관련업
체들 및 인터넷 서비스 제공업체(ISP) 등 75 개 이상의 업체들이 참여하고 있
다. 각 산업 분야별 선두업체들로 구성된 OSGi 는 개방형 구조인 “자바 임베
디드 서버(JES)” 기반의 게이트웨이 아키텍쳐용 소프트웨어를 만드는 것이
주요 임무이다[Gong01]. 이처럼 OSGi 의 역할은 서비스를 로컬 네트워크나
장비에 전달하고 전달된 서비스가 운용되는 개방적 표준을 만드는데 있다
[Hofr01].
유비쿼터스 컴퓨팅 환경의 대표적인 응용 환경인 홈 네트워크는 정보
네트워크, A/V 네트워크, 제어 네트워크로 구성된다. 각각의 네트워크에 속
한 단말에 접근하기 위해서는 디바이스에 대한 연결 기술인 이더넷, 블루투
스, 무선랜, IEEE 1394, 전력선 통신 기술 등이 필요하다. 그리고, 디바이스 들
간의 좀 더 원할한 상호 작용을 위한 UPnP, HAVi, Jini 등의 미들웨어 기술
이 있다[Dobr02]. 홈 네트워크에 연결된 디바이스 들간의 제어 및 통신으로
얻을 수 있는 서비스로는 [그림 1]과 같이 다양한 서비스들이 있으며, 이러한
서비스의 배포 문제와 서비스가 작동하기 위한 기반 환경 제공을 목표로 하
는 것이 바로 OSGi라고 할 수 있다[Valt02].
[그림 1] OSGi 개요
OSGi 는 초기에 홈 내의 서비스를 관리하는 게이트웨이에 집중되었지
만, 최근에는 특정 네트워크 환경에 국한하지 않고 유비쿼터스 환경까지 확
장해 가고 있다. 따라서, 다양한 임베디드 디바이스와 이를 이용하는 사용자
를 위한 범용적인 서비스 게이트웨이 구축을 목표로 하고 있다[Ditz04].
OSGi 서비스 플랫폼은 크게 세 가지의 관심 대상을 갖는다. 첫째는 서
비스들간의 연결 및 제어이며, 둘째는 서비스와 OSGi 프레임워크 간의 연결
및 제어이다. 마지막으로 OSGi 프레임워크와 외부 서비스 관리 시스템과의
연결 및 제어이다. 따라서 OSGi 서비스 플랫폼은 초고속통신망과 같은 외부
네트워크와 댁내의 디바이스들을 연결하는 네트워크 사이에 위치하게 된다.
외부 네트워크 환경에 존재하는 서비스 제공자는 서비스의 제공 및 관리를
수행하고, 홈 네트워크 환경에서는 수 많은 디바이스들과 상이한 프로토콜이
존재하여 이들을 원활하게 연결하고 제어하여야 한다. 결국 OSGi 서비스 플
랫폼은 외부 네트워크 환경과 홈 네트워크 환경의 중재자의 역할을 담당한
다[Chem02].
OSGi 서비스는 모두 번들(Bundle)이라는 물리적인 단위로 묶여진다.
복수개의 OSGi 서비스가 하나의 번들에 포함될 수도 있으며, 번들은 배포와
관리의 기본 단위를 형성한다. 이러한 번들들을 관리해 주는 OSGi 프레임워
크는 서비스에 대한 등록 및 관리를 위한 서비스 레지스트리를 가지며, 서비
스에 대한 등록, 조회, 실행, 삭제 등을 수행한다[Hall04a].
[그림 2]의 OSGi 서비스 플랫폼은 OSGi 프레임워크와 표준 서비스들
로 구성된다. OSGi 프레임워크는 이러한 서비스들을 위한 실행 환경을 의미
하며 최소한의 컴포넌트 모델, 컴포넌트를 위한 관리 서비스, 서비스 레지스
트리 등을 포함한다. OSGi 프레임워크는 번들이라고 부르는 OSGi 컴포넌트
를 설치하고, 서비스 등록 및 실행을 위한 프로그래밍 모델을 지원한다.
[그림 2] OSGi 서비스 플랫폼
(1) OSGi 프레임워크
OSGi 프레임워크는 다운로드가 가능한 서비스 어플리케이션인 번들의
설치 및 배포를 지원하는 자바 기반의 프레임워크이다. OSGi 호환 디바이스
들은 OSGi 번들을 서비스 제공자로부터 다운로드 받아 설치할 수 있고, 필
요가 없어지면 제거할 수 있다. 설치된 번들은 OSGi 프레임워크의 제어 아
래에서 다른 번들과 공유할 수 있는 여러 서비스들을 등록한다
[Gu04][Hall04b][Li04].
OSGi 프레임워크는 번들의 설치 및 업데이트를 관리하며 번들과 서비
스 간의 의존성을 관리한다. 그리고 OSGi 프레임워크는 서비스 인터페이스
를 구현과 분리함으로써 서비스의 개발과 배포를 간단하게 하고, 번들 개발
자들을 위한 간결하고 일관성이 있는 모델을 제공한다. 다양한 하드웨어 특
성들은 서비스 구현에 많은 영향을 미치는데, OSGi 프레임워크는 일관된 프
로그래밍 모델을 제공함으로써, 개발자에게 이러한 디바이스의 다양성을 해
결할 수 있도록 한다. 이것은 이종성을 갖는 다양한 디바이스들로 구성된 유
비쿼터스 컴퓨팅 환경에서의 서비스 확장성(scalability) 문제를 해결할 수 있
도록 한다. 일관성이 있는 인터페이스는 소프트웨어 컴포넌트들이 조합되어
안정된 서비스를 제공할 수 있도록 보장한다. 어플리케이션 개발자들은 번들
이 배포될 때 어떤 서비스 구현이 사용되든지 상관없이 정의된 서비스 인터
페이스를 사용하여 번들을 개발할 수 있으며, OSGi 프레임워크는 번들이
OSGi 프레임워크의 서비스 레지스트리를 통하여 실행 시간에 하나의 사용
가능한 서비스를 선택할 수 있게 한다. OSGi 프레임워크는 이러한 면에서 설
치된 번들의 배포 후에도 여전히 확장성을 지원하며, 새로운 번들이 추가된
내용을 갖고 재설치 될 수 있도록 한다. 또한, 기존의 번들이 시스템의 재시
작 없이도 수정되거나 업데이트 될 수 있게 한다.
OSGi 프레임워크 자신도 번들로 표현되며, 이러한 번들을 시스템 번들
이라고 한다. 번들을 위한 호스팅 환경을 제공하는 OSGi 프레임워크의 역할
을 정리하면 다음과 같다.
• 번들의 라이프 사이클 관리 • 번들들 간의 상호 독립성 해결 • 서비스들에 관한 레지스트리 관리 • 번들의 상태 변화, 서비스 등록 및 해제 • 프레임워크의 동작에 관한 이벤트 처리
OSGi 프레임워크에서 제공하는 번들의 라이프 사이클 관리와 클래스
로딩에 대한 지원은 다른 번들이나 외부로부터의 코드를 이용할 수 있도록
설계된 구조이다. 이러한 특징으로 인하여 번들의 생성부터 소멸까지의 상태
정보가 관리되며, 자바 클래스 파일로부터 새로운 인스턴스를 생성할 수 있
는 기능을 제공할 수 있다.
(2) 번들
OSGi 서비스 플랫폼에서 번들은 자바 기반의 어플리케이션을 내포하
는 개체이다. 하나의 번들은 자바 클래스와 사용자에게 어떤 기능을 제공할
수 있는 다른 리소스들을 포함하며, 다른 번들에게 서비스라고 불리는 컴포
넌트들 제공한다. 즉, 번들은 서비스 레지스트리에 등록된 서비스를 이용하
는 서비스 집합인 동시에 컴포넌트 단위이다. 서비스 구현은 물리적이며 논
리적인 단위인 번들을 통해서 프레임워크에 전달되고 배치 된다.
물리적으로, 번들은 실행 코드, 리소스, manifest 파일 등을 포함하는
Java Archive(JAR) 파일 형태로 배포된다. 특히, 번들의 manifest 파일은 프레
임워크에게 번들 클래스의 실행 경로를 알려주며, 다른 번들과 공유하게 될
자바 패키지를 선언한다. 또한, 번들의 activator 클래스에 대한 정보를 갖고
있다. 예를 들어, manifest 헤더는 Import-Package, Export-Package, Bundle-
Activator 등을 포함한다. Import-Package 와 Export-Package 는 임포트 되거
나 익스포트 될 패키지 이름을 명시함으로써 OSGi 프레임워크가 다른 번들
과의 패키지 의존성을 해결하도록 유도하는 것이다. Bundle-Activator 헤더는
번들을 시작하거나 정지하도록 프레임워크에 의해 호출되는 start 와 stop 메
소드를 명시한다. 논리적으로, 하나의 번들은 운영 체제에서의 하나의 프로
세스와 유사한 개념으로, 어떤 서비스를 제공하는 서비스 제공자(provider)이
거나 실행 시간에 프레임워크 내에 어떤 서비스를 이용하려는 서비스 요청
자(requester)이다.
OSGi 프레임워크는 번들의 라이프 사이클을 관리하는 메커니즘을 제
공하는데, 만약 번들이 인스톨되어 프레임워크 상에서 실행이 되면 자신의
서비스를 제공할 수 있게 된다. 또한 프레임워크 상에서 실행 중인 다른 서
비스를 발견하여 이용할 수 있으며, 프레임워크의 서비스 레지스트리를 통해
서 다른 번들들의 서비스들과 협력될 수 있다. 번들은 OSGi 프레임워크의
서비스 레지스트리에 서비스를 등록할 때, 서비스에 관한 속성-값(attribute-
value) 쌍의 형태로 그 서비스의 특성을 함께 저장하는데, 이러한 서비스 특
성은 동일한 서비스를 제공하는 여러 서비스 제공자들 사이에서 구분될 수
있도록 사용된다. 하나의 서비스를 발견 하기 위해서, 번들은 올바른 구문적
형식을 갖춘 서비스 인터페이스 이름과 서비스 특성에 관한 추가적인
LDAP(Lightweight Directory Access Protocol) 질의 선택 필터를 사용한다. [그
림 3]은 서비스를 발견하거나 제공하는데 서비스 레지스트리가 어떻게 사용
되는지를 보여 준다.
[그림 3] 서비스 레지스트리를 이용한 번들의 협력 과정
JAR 파일로 배포된 번들은 인스톨 후 시작되면 activator 클래스에 의
해 동작하게 된다. 번들의 라이프 사이클은 [그림 4]와 같으며, 대부분의 경
우 프레임워크의 관리 메커니즘에 의해 직접적인 영향을 받는다. 번들은 인
스톨된 후 사용되기 전 반드시 resolved 상태로 준비되어야 하는데, 프레임
워크는 외부의 자바 패키지들에 관한 의존성을 체크함으로써 번들을
resolved 상태로 만든다. 이것은 만약 어떠한 의존성이 존재한다며, 프레임워
크는 요구되는 번들이 사용 가능한지 또는 번들에 대해서 접근 가능한지를
확인하는 것이다. 번들은 activator 클래스의 BundleActivator 인터페이스를
구현함으로써 개발자에 의해 구현된 특정 작업을 수행하게 된다. 프레임워크
에 의해 호출되는 activator 클래스는 Start 와 Stop 메소드와 함께 구현된다.
이러한 메소드들은 일단 호출되면, 다른 번들로의 접근, 번들 관리 작업 수
행, 서비스 등록, 다른 서비스 검색, 서로 다른 이벤트들에 대한 리스너 등록
등과 같은 프레임워크 기능들을 가능하게 하는 실행 환경인 Bundle Context
을 얻게 되고 번들은 이를 통해서 간접적으로 OSGi 프레임워크의 기능들에
접근할 수 있다[Lian02].
[그림 4] 번들의 라이프 사이클
번들이 deactivate 될 경우, 그 번들이 제공하는 서비스는 서비스 레지
스트리에서 해제되어야 하며, 그 번들이 사용하고 있는 모든 서비스들은
released 상태가 되어야만 한다. 번들은 수동적으로 이러한 작업들을 수행할
수도 있으며, OSGi 프레임워크는 deactivate 되는 동안에 자동적으로 관리할
수도 있다. 즉, 어떤 서비스가 시작되는 경우 그 서비스에 관한 참조가 이루
어져야만 하며, 그 서비스가 정지되는 경우 그 서비스를 대체할 수 있는 서
비스 제공자를 발견하는 것과 같은 필수적인 기능이 정확하게 이루어져야만
한다. OSGi 프레임워크는 서비스의 시작과 정지를 알려주는 이벤트 처리 메
커니즘을 제공한다[Chen01].
2.2 기존 OSGi의 문제점
OSGi 기반의 서비스 플랫폼에서는 새로운 서비스를 제공받아 분배하
고 관리할 수 있는 구조를 갖고 있다. 그리고 그 구조가 네트워크로 연결된
구성 요소들만으로 이루어져 있어서 비교적 폐쇄적인 특성을 갖는다. 이렇게
하나의 공간적 특성을 바탕으로 OSGi 프레임워크의 서비스 관리는 충분히
동적으로 원할하게 수행될 수 있다. 하지만, 유비쿼터스 공간은 복수 개의
OSGi 프레임워크를 탑재하는 서비스 게이트웨이로 구성될 수 있다. 이 때
서비스 게이트웨이 간에 서비스의 자유로운 이동을 고려해 보면, 다수의
OSGi 프레임워크 들간의 이동성을 갖는 응용들에 대한 지원은 부족한 실정
이다. 그래서 복수의 OSGi 프레임워크들 간의 사용자, 디바이스, 센서 등의
이동성을 갖는 개체들을 위한 동적인 서비스에 대한 관리가 필요하게 된다.
OSGi 프레임워크 상에서 이러한 개체들의 이동성에 관한 충분한 고려가 이
루어져야만 하며, 진행 중인 서비스의 실행 상태를 유지시킬 수 있는 서비스
에 대한 효과적인 지원은 기존 OSGi 프레임워크에 서비스 이동성과 같은 추
가적인 기능을 제공함으로써 유비쿼터스 컴퓨팅 환경을 동적으로 구성할 수
있게 한다.
제 3장 서비스 이동 관리 시스템
설계 및 구현
이 장에서는 OSGi 프레임워크 상에서의 서비스 이동을 관리할 수 있
는 OSGi 상의 서비스 이동 관리 시스템을 설계한다. 본 연구에서 제안한 서
비스 이동 관리 시스템은 OSGi 스펙에 맞게 OSGi 프레임워크 상의 번들 형
태로 구현되어, 사용자를 위한 서비스나 디바이스 드라이버 등 다양한 형태
의 서비스 개체들의 이동성을 지원한다.
3.1 서비스 이동 관리 시스템 개요
서비스 이동 관리 시스템은 이동성 관리를 위한 Mobility Interface, 직
렬화 및 비직렬화를 처리하는 Service Serializer, SOAP 메시지 송/수신을 위
한 SOAP Manager로 구성되며, 전체 시스템의 구조는 [그림 5]와 같다.
[그림 5] OSGi 상의 서비스 이동 관리 시스템의 구조
OSGi 프레임워크 상에서 수행되는 번들의 기존 라이프 사이클에 영향
을 주지 않고 서비스의 이동성을 지원하기 위해서 새로운 라이프 사이클을
정의하며, [그림 6]은 새로운 번들의 라이프 사이클을 도식화한 것이다. OSGi
에서 정의하는 번들의 기본 상태인 Resolved, Starting, Active, Stopping 부분
이외에 DEAD, Movable, Moved 상태를 추가한다. DEAD 인 경우 번들이 자
동적으로 Unistalled 되는 것과는 다른 의미를 가진다. Uninstalled 는 번들을
종료하는 것이지만, DEAD 는 이동성을 갖는 서비스가 MOVE 요청을 받기
전에 서비스의 정보를 검증하는 과정이 추가되기 때문에 별도로 존재한다.
이동 요청을 받은 서비스를 위해서 번들의 상태는 Movable 상태에서 자동적
으로 Moved 상태로 전환된다. Moved 상태는 서비스가 이동하는 과정으로
수행하고 있던 OSGi 프레임워크에서 데이터를 정리하고 새로운 OSGi 프레
임워크로의 이동을 위한 작업을 수행하는 과정이다. Moved 를 수행한 후에
OSGi 프레임워크는 번들의 상태를 Uninstalled 로 변경하고, 서비스가 이동
한 OSGi 프레임워크에서 해당 번들은 Installed 상태로 변경된다.
[그림 6] 서비스 이동을 위한 번들의 라이프 사이클
[그림 7] Service Mobility Manager의 클래스 다이어그램
서비스 이동 관리 시스템은 OSGi 프레임워크 간의 서비스를 이동을
지원하기 위해서 객체 이동 방법을 이용한다. OSGi 프레임워크 상의 서비스
가 이동하기 위해서 자신의 상태 정보를 포함하여 객체 직렬화 과정을 거치
고, 직렬화된 객체 정보는 네트워크 전송을 위해서 SOAP 메시지로 변환된다.
SOAP 메시지는 Apache AXIS 를 이용한 SOAP 통신으로 다른 OSGi 프레임
워크로 전송된다. 전송된 SOAP 객체는 파싱되어 다운로드할 클래스의 위치
정보와 서비스의 동작 상태 정보, 서비스 레지스트리에 등록된 서비스 기술
내용으로 해석된다. 해석된 정보를 바탕으로 이동하는 서비스의 클래스 파일
을 다운로드 받아 새로운 OSGi 프레임워크 상에 설치하고, 서비스의 동작
상태 정보는 비직렬화 과정을 거쳐서 이동하기 전의 서비스 상태로 복원된
다. [그림 7]은 Service Mobility Manager를 위한 클래스 다이어그램이다.
서비스 이동을 위해서 Service Mobility Manager 는 해당 번들의 이동
요청을 받으면 Mobility Interface 를 통해서 서비스의 라이프 사이클을 관리
한다. 우선 현재 수행되고 있던 서비스와 관련된 모든 작업을 중지시키거나
현재의 서비스 상태를 저장하는 것과 같은, 서비스가 이동하기 전에 수행될
필요가 있는 모든 작업을 할 수 있도록 Service Mobility Manager 는
“MOVE” 요청을 해당 서비스에 전달한다. 이러한 과정을 처리하기 위해서
번들은 Mobility Interface를 상속받아 구현되도록 한다. Mobility Interface는
OSGi 프레임워크 들간의 서비스 이동을 위해서, 어떤 프레임워크에서 실행
되고 있던 서비스의 이동 전에 수행되어야 하는 작업들과 서비스의 이동 후
에 수행되어야 하는 작업들을 구현해 주는 두 개의 메소드로 구성이 된다.
다음은 프레임워크 들간의 이동성이 요구되는 서비스가 구현해야 하는
Mobility Interface의 메소드들이다.
interface Mobility {
bool beforeMoving() {}; //called by Framework before moving
bool after Moving() {}; //called by Framework after moving
}
Service Mobility Manager 는 서비스가 이동하기 전의 상태 정보를
Service Serializer 에 의해 XML 로 직렬화한다. 이렇게 직렬화된 XML 은
OSGi 프레임워크로부터 얻은 해당 서비스의 등록 정보와 번들의 클래스 위
치 정보인 URL 등과 함께 SOAP 메시지로 변환된 후, 네트워크를 통해 전
송된다. 이러한 작업을 수행하는 SOAP Manager 컴포넌트는 위와 같이 변환
된 SOAP 객체를 전송할 뿐만 아니라 다른 프레임워크로부터 SOAP 객체를
전송 받는 역할을 담당한다.
SOAP 메시지를 전송 받은 OSGi 프레임워크는 SOAP 메시지에 포함되
어 있는 해당 번들의 위치 정보인 URL 를 이용하여 필요한 클래스를 다운로
드 한다. 다음으로, Service Mobility Manager의 Service Installer은 해당 서비
스의 번들을 다운로드하여 설치하는데, 이때에 서비스의 등록 정보와 직렬화
된 XML 정보는 Service Serializer 에 의해 비직렬화된 후 설치될 번들의 서
비스 상태를 이동하기 전의 서비스 상태 정보로 복원할 수 있도록 이용된다.
3.2 서비스의 라이프 사이클
OSGi 프레임워크에서 동작되는 이동 가능한 서비스는 서비스 생성부
터 종료까지 5가지의 상태로 정의되며, [그림 8]은 서비스의 라이프 사이클을
상태전이도로 나타낸 것이다. 서비스가 서비스 레지스트리에 등록되면 초기
화 상태인 INIT 상태가 되며 서비스 시작과 동시에 RUNNING 상태로 전환
된다. 다음 수행 할 액션이 있는 경우 RUNNING 상태를 유지시키고, 더 이
상 수행할 액션이 없는 경우 서비스 타입에 따라 두 가지 형태로 상태를 전
환하게 된다. 첫째, 일반적인 상태(TYPE=NORMAL)인 경우 더 이상 수행하
지 못하는 STOP 상태로 전환되고 서비스 레지스트리에서 등록을 해제한다.
또 다른 형태인 데몬 상태(TYPE=DAEMON)인 경우 다음에 수행할 액션이
추가될 때까지 WAIT 상태를 유지한다. RUNNING 상태 또는 WAIT 상태에
서 이동하라는 요청을 받은 경우 MOVABLE 상태로 전환된다. RUNNING
상태에서 이벤트를 받은 경우 현재 처리 중인 액션을 다 처리한 후
MOVABLE 상태로 전환되며, WAIT 상태에서는 바로 전환된다.
[그림 8] 서비스의 상태 전이도
3.3 서비스의 이동 객체 생성
서비스 이동 관리 시스템은 서비스의 이동성을 지원하기 위해서 서비
스를 이동 가능한 객체로 만든다. 다른 OSGi 프레임워크로 서비스를 이동시
키기 위해서 Service Mobility Manager는 서비스의 상태를 XML 형태로 직렬
화하여 전송하며, 이동된 서비스가 OSGi 프레임워크에서 실행되기 위해서는
전송 받은 XML 형태의 상태 정보를 비직렬화하여 원래의 서비스 상태를 복
원시킨다. 이렇게 XML 형태로 변환된 서비스의 상태 정보는 서비스가 수행
할 상태 정보를 포함한다. Service Mobility Manager는 서비스 객체를 Service
Serializer에게 전달하고, Service Serializer는 [리스트 1]의 XML 스키마에 의
해 서비스의 상태를 XML 형태로 직렬화한다.
[리스트 1] 서비스 직렬화를 위한 XML 스키마
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://hci.inha.ac.kr/ema">
<xsd:complexType name="MObject">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="status" type="xsd:int" minOccurs="1"
maxOccurs="1"/>
<xsd:element ref="actionScheduler" minOccurs="1"
maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="actionScheduler">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="action" type="action" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType abstract="true" name="action">
</xsd:complexType>
</xsd:schema>
</xsd:schema>
서비스 객체의 직렬화를 위해서 Castor 프로젝트(www.castor.org)의
Marshaller 클래스를 이용하며, 다음의 [알고리즘 1]은 서비스의 상태 정보를
저장하여 객체를 직렬화하는 알고리즘이다.
[알고리즘 1] 서비스의 객체 직렬화 알고리즘
Input
obj : 서비스의 상태 정보를 갖는 (직렬화할) 객체
Variables
sw : 스트링 처리 객체
marshaller : XML 직렬화 객체
Algorithm getXML(Serializable obj)
Begin Algorithm
01 : sw = new StringWriter()
02 : marshaller = new Marshaller(sw)
03 : marshaller.setMapping(mapping)
04 : marshaller.marshal(obj) //전달 받은 객체를 XML로 직렬화
05 : return sw.toString() //스트링 객체로 리턴
End Algorithm
Service Serializer 에 의해 생성된 XML 형태의 서비스의 상태 정보는
SOAP Manager에게 전달되어, SOAP 메시지로 변환된 후 다른 프레임워크로
전달된다.
SOAP 메시지에는 서비스의 상태 정보 이외에도 서비스 레지스트리에
등록된 그 서비스의 기술 정보와 그 서비스가 위치하는 URL 정보도 함께
포함된다. 이것은 서비스가 이동하게 될 OSGi 프레임워크에서 해당 서비스
의 클래스를 다운로드 받기 위해서 그 URL 정보를 필요로 하기 때문이다.
[알고리즘 2]는 SOAP 메시지를 생성하는 알고리즘이다.
[알고리즘 2] SOAP 메시지의 생성 알고리즘
Input
objXml : XML로 직렬화된 객체
url : 서비스가 위치하는 URL 정보를 포함하는 객체
desc : 서비스의 기술 정보를 포함하는 객체
Variables
msg : SOAP 메시지 객체
sp : envelope을 포함하는 SOAP 메시지로의 접근을 위한 SOAPPart 객체
Algorithm createMessage(String objXml, String url, String desc)
Begin Algorithm
01 : MessageFactory = MessageFactory.newInstance()
02 : SOAPMessage msg = msgFactory.createMessage()
03 : SOAPPart sp = msg.getSOAPPart()
04 : SOAPEnvelope envelope = sp.getEnvelope()
05 : SOAPBody bdy = envelope.getBody() //SOAPBody 엘리먼트를 가져옴
06 : SOAPBodyElement service = bdy.addBodyElement(envelope.
createName(“service”,“ns1”,“http://hci.inha.ac.kr/service/ema”))
07 : SOAPElement objNode =
service.addChildElement(envelope.createName(“obj”))
08 : objNode.addTextNode(XMLEncoder.encode(objXml))
//XML에 TextNode로 포함시킬 수 있도록 인코딩한 후 노드를 추가
09 : SOAPElement urlNode =
service.addChildElement(envelope.createName(“url”)
10 : urlNode.addTextNode(url) //번들이 있는 URL 정보 노드 추가
11 : SOAPElement descNode =
service.addChildElement(envelope.createName(“desc”)
12 : descNode.addTextNode(XMLEncoder.encode(desc))
//번들의 description 정보 노드 추가
13 : return msg
End Algorithm
3.4 서비스의 이동
이동할 필요성이 있는 서비스는 다른 OSGi 프레임워크로 이동해야 하
는 경우, Service Mobility Manager에게 “MOVE” 요청을 전달한다. 이렇게 전
송을 필요로 하는 “MOVE” 요청에는 그 프레임워크의 URL 정보와 그 서비
스의 ID 를 포함한다. Service Mobility Manager 는 “MOVE” 요청에 포함된
서비스의 ID 를 이용해서 beforeMoving() 메소드를 호출한다. 이처럼
“MOVE” 요청을 받은 Service Mobility Manager 는 현재 처리 중인 작업을
마친 후 리턴한다.
Service Mobility Manager는 해당 서비스의 상태가 이동 가능한 상태로
전환된 경우, 그 서비스의 객체를 Service Serializer 에게 전달하여 서비스의
상태 정보를 XML 형태로 직렬화시킨 후, SOAP Manager 를 통해 직렬화된
XML 과 함께 서비스의 등록 정보 및 프레임워크의 URL 정보를 포함하여
SOAP 메시지를 생성한다. SOAP Manager 는 이동하고자 하는 프레임워크를
확인하고 생성된 SOAP 메시지를 해당 프레임워크로 전송한다. 서비스의 이
동이 성공했다면 현재 수행 중이던 서비스를 서비스 레지스트리에서 삭제한
다. [알고리즘 3]은 서비스 객체의 전송을 위한 알고리즘이다.
[알고리즘 3] 서비스 전송 알고리즘
Input
ServiceID : 서비스 레지스트리에 등록된 서비스의 ID
Variables
ServiceRef : 서비스의 레퍼런스 값
ServiceDes : 서비스 기술 정보
ServiceStatus : 서비스의 상태 정보
SOAPMessage : 전송하기 위해 생성된 SOAP 메시지
Algorithm SendingServiceObject(ServiceID)
Begin Algorithm
01 : ServiceRef =
ServiceManager.ServiceFinder.GetServiceRef(ServiceID)
02 : ServiceDes =
ServiceManager.ServiceFinder.GetServiceDes(ServiceID)
03 : res = ServiceRef.beforeMoving()
04 : If (res is true)
05 : ServiceStatus = ServiceSerializer.serializer(res)
06 : SOAPMessage = SOAPService.makeSOAPMessage(URL,
ServiceStatus, ServiceDes)
07 : sendMessage(TargetURL, SOAPMessage)
08 : End If
End Algorithm
3.5 서비스의 복원
이동되는 서비스를 전송 받는 프레임워크에서 SOAP 메시지를 기다리
고 있던 SOAP Manager 는 SOAP 객체 내에 포함된 클래스 위치 정보인
URL과 직렬화된 데이터를 수신하고 이를 Service Mobility Manager에게 전
달한다. Service Mobility Manager 는 전송 받은 객체를 비직렬화하기 전에
Service Installer 를 통해 원격지로부터 번들을 다운로드 하여 설치하고, 설치
가 성공된 후에 XML을 비직렬화하여 이동 전의 상태로 해당 서비스를 복구
시킨다. 마지막으로 해당 서비스의 상태를 실행 가능 상태로 전환한 후 서비
스 레지스트리에 등록한다. [알고리즘 4]는 서비스의 이동 후에 서비스 객체
를 복원하는 알고리즘이다.
[알고리즘 4] 서비스의 복원 알고리즘
Input
SOAPMessage : 전송 받은 SOAP 메시지
Variables
URL : SOAP 객체 내에 포함된 클래스 위치 정보
ServiceDes : 서비스의 기술 정보
ServiceStatus : 서비스의 상태 정보
ServiceClass : 해당 서비스에 대한 번들의 클래스 파일
ServiceRef : 서비스의 설치 및 등록에 관한 레퍼런스 값
Algorithm RestoreServiceObject(SOAPMessage)
Begin Algorithm
01 : URL = SOAPService.getAttribute(SOAPMessage, URL)
02 : ServiceDes =
SOAPService.getAttribute(SOAPMessage, ServiceDes)
03 : ServiceStatus =
SOAPService.getAttribute(SOAPMessage, ServiceStatus)
04 : ServiceClass = ServiceInstaller.getClass(URL)
05 : ServiceRef = ServiceInstaller.serviceInstalling
(ServiceClass, ServiceDes)
06 : ServiceRef.afterMoving(ServiceDeserializer.deserializer
(ServiceStatus))
End Algorithm
전송 받은 SOAP 메시지를 파싱하여 해당 서비스의 복원에 필요한 정
보를 얻는다. 전송 받은 SOAP 메시지에는 XML 객체와 함께 해당 서비스의
등록 정보 및 다운로드 할 URL 정보가 포함된다. 다음의 [알고리즘 5]는
SOAP 메시지를 파싱하는 알고리즘이다.
[알고리즘 5] SOAP 메시지 파싱 알고리즘
Input
req : HTTP 요청에 관련된 정보
resp : HTTP 응답에 관련된 정보
Variables
headers : 요청헤더를 만듦
is : 전송 받는 입력 스트림 객체
body : SOAP 메시지의 Body 부분을 저장
iter : SOAP 메시지 객체 포인터
objElement : SOAP 엘리먼트의 객체 데이터 저장
urlElement : SOAP 엘리먼트의 URL 데이터 저장
descElement : SOAP 엘리먼트의 서비스 기술 데이터 저장
obj : 서비스의 상태 정보를 갖는 객체 저장
url : 서비스의 URL 정보 저장
desc : 서비스의 기술 정보 저장
Algorithm doParser(HttpServletRequest req, HttpServletResponse resp)
Begin Algorithm
01 : Mimeheaders headers = getHeaders(req)
02 : InputStream is = req.getInputStream()
03 : SOAPMessage message =
msgFactory.createMessage(headers, is)
//전송 받은 데이터로부터 SOAP 메시지 생성
04 : SOAPBody body = message.getSOAPBody()
05 : Iterator iter =
body.getChildElements(envelope.createName(“service”,
“ns1”, “http://hci.inha.ac.kr/service/ema”))
06 : If (iter.hasNext() is true)
07 : SOAPElement element = (SOAPElement)iter.next()
08 : Iterator objElements =
element.getChildElements(envelope.createName(“obj”))
09 : Iterator urlElements =
element.getChildElements(envelope.createName(“url”))
10 : Iterator descElements =
element.getChildElements(envelope.createName(“desc”))
11 : SOAPElement objElement =
(SOAPElement)objElements.next()
12 : SOAPElement urlElement =
(SOAPElement)urlElements.next()
13 : SOAPElement descElement =
(SOAPElement)descElements.next()
14 : obj = XMLEncoder.decode(objElement.getValue())
15 : url = XMLEncoder.decode(urlElement.getValue())
16 : desc = XMLEncoder.decode(descElement.getValue())
17 : End If
End Algorithm
SOAP 메시지를 파싱하여 얻어진 정보 중 클래스의 다운로드에 이용되
는 URL 정보를 Service Installer에게 전달하여 해당 서비스의 클래스 파일을
다운로드하여 OSGi 프레임워크에 설치한다. 이 때, BundleContext 의
installBundle 메소드를 이용하여 설치한다. 설치된 서비스는 이동하기 전의
상태로 복원되어야 한다. XML 형태로 변화되어 SOAP 메시지에 포함된 서비
스의 상태 정보는 비직렬화 과정을 거쳐서 서비스의 복원에 사용된다. 이 과
정에서 직렬화 과정과 마찬가지로 Castor 프로젝트의 Unmarshaller 클래스
를 이용하여 서비스의 비직렬화 과정을 수행한다. 다음의 [알고리즘 6]은 서
비스 객체의 비직렬화하는 코드의 일부분이다.
[알고리즘 6] 서비스 비직렬화 알고리즘
Input
objXml : 전달 받은 XML 문자열
Variables
Unmarshaller : XML 비직렬화 객체
obj : 비직렬화한 객체
Algorithm getMObject(String objXml)
Begin Algorithm
09 : unmarshaller = new Unmarshaller(mapping)
10 : MObject obj =
(MObject)unmar.unmarshal(new java.io.StringReader(objXml)
11 : return obj
End Algorithm
제 4장 실험 및 평가
이 장에서는 본 연구에서 제안한 OSGi 상의 서비스 이동 관리 시스템
의 평가를 위해서 OSGi 프레임워크 상의 음악 서비스를 개발한다.
Knopflerfish 1.3.3 상에 서비스 이동 관리자를 설치/운용함으로써, OSGi R3
표준 스펙을 준수하고 관리자의 기능이 적합하게 동작되는지를 실험한다.
4.1 실험 환경 및 시나리오
본 연구에서 제안하는 서비스 이동 관리 시스템을 실험하기 위해서 음
악 서비스를 구현한다. 이 음악 서비스는 OSGi 프레임워크 상에서 MP3 파
일을 재생하는 서비스이며, MP3 파일과 파일 목록을 포함하는 번들로 설치
된다. 이러한 음악 서비스의 이동성을 실험하기 위해서 PDA 단말기와 PC에
구현한 서비스 이동 관리 번들을 OSGi 프레임워크에 설치한다. 음악 서비스
의 이동에 관한 예로서 사용자가 PDA 단말기로부터 음악 서비스를 제공받
아 음악을 들으면서 댁내에 들어온 경우를 생각해 볼 수 있다. 이때 사용자
는 이어폰으로 듣던 음악을 PC 스피커를 통해 듣기를 원할 수 있다.
본 연구의 실험을 위한 음악 서비스는 MP3 음악 파일을 플레이하여
사용자에게 음악을 제공하는 OSGi 프레임워크 상의 서비스로서 MP3 파일과
파일 목록을 포함한다. 이러한 음악 서비스의 이동에 따른 서비스 이동성을
실험하기 위해서 PDA 단말기와 PC에 OSGi 프레임워크인 Knopflerfish 1.3.3
과 함께 본 연구에서 구현한 서비스 이동 관리 번들을 함께 설치한다. 앞서
언급한 것처럼, 음악 서비스에 관한 서비스 이동의 한 예로서 사용자가 PDA
단말기로부터 음악 서비스를 제공받아 음악을 들으면서 댁내로 들어온 경우
를 생각해 볼 수 있다. 이때, 사용자에게 연속적인 서비스를 제공하기 위해
서 음악 서비스는 PDA 단말기에서 PC 상의 OSGi 프레임워크로로 이동되어
야 할 필요성이 있다. 그리고 PDA 단말기에서 연주 중이던 MP3 파일의 목
록과 함께 사용자가 듣고 있던 음악을 이어서 들을 수 있도록 연속적으로
제공해야 한다.
[그림 9] 음악 서비스의 이동
본 연구에서는 윈도우 XP 환경에서의 OSGi 프레임워크인 Knopflerfish
1.3.3을 사용하였고, Eclipse 3.0과 Knopflerfish Eclipse Plug-in 0.7을 이용하여
실험에 쓰이는 음악 서비스를 개발한다. 그리고 이 실험에 사용한 PDA 단말
기는 HP iPAQ Pocket PC h2210 모델로서, 400MHz 인텔 XScale 프로세서와
64MB 램으로 구성된 사양을 갖는다. 그리고 OSGi 프레임워크인
Knopflerfish 1.3.3은 IBM J9 컴파일러를 이용하여 PDA 단말기에 포팅한다.
4.2 음악 서비스 개발
OSGi 상의 서비스 이동 관리 시스템은 OSGi 프레임워크 간의 서비스
의 이동성을 지원하기 위해서는 서비스 객체를 이동시킨다. 서비스가 이동하
기 전에 서비스의 상태 정보는 직렬화 과정을 거쳐서 XML 형태로 생성되고,
네트워크 전송을 위한 SOAP 메시지로 다시 변환된다.
[그림 10]은 서비스 이동 전의 시퀀스 다이어그램이다. PDA 에서 사용
자에게 제공되고 있던 음악 서비스가 PC 상의 OSGi 프레임워크로 이동해야
하는 경우, Service Mobility Manager에게 “MOVE” 요청을 전달한다.
[그림 10] 서비스 이동 전의 시퀀스 다이어그램
다음으로, 음악 서비스가 수행하고 있는 현재의 상태 정보를 Service
Serializer 를 통해서 XML 로 직렬화한 형태는 [리스트 2]와 같으며, MP3 파
일 재생 목록과 현재 재생하는 MP3 파일의 offset 정보를 포함한다.
[리스트 2] 음악 서비스를 직렬화한 XML
<mplayer>
<description> mp3 music player </description>
<status> 3 </status>
<option>
<repeat> false </repeat>
</option>
<current>
<offset> 132 </offset>
<id> 2 </id>
</current>
<item id="1">
<title> pop1 <title>
<location> music/first.mp3 </location>
</item>
<item id="2">
<title> dance1 <title>
<location> music/second.mp3 </location>
</item>
<item id="3">
<title> classic1 <title>
<location> music/third.mp3 </location>
</item>
</Mplayer>
XML 로 직렬화된 데이터는 네트워크 전송을 위해서 SOAP Service 에
의해서 SOAP 메시지를 생성하고 PC 상의 OSGi 프레임워크로 전송한다. [리
스트 3]은 SOAP Service에서 생성한 SOAP 메시지의 구조를 보여준다.
[리스트 3] 음악 서비스의 이동을 위한 SOAP 메시지
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:service xmlns:ns1="http://hci.inha.ac.kr/ema/service">
<obj xsi:type="xsd:string">
<mplayer><description> mp3 music player
</description><status> 3
</status><option> <repeat> false
</repeat></option><current>
<offset> 132 </offset> <id> 2
</id></current><item
id="1"> <title> pop1
<title> <location>music/first.mp3
</location></item><item
id="2"> <title> dance1
<title> <location>music/second.mp3
</location></item><item
id="3"> <title> classic1
<title> <location>music/third.mp3
</location></item></mplayer>
</obj>
<url xsi:type="xsd:string">
http://hci.inha.ac.kr/webservice/bundlerepository/mobject.jar
</url>
</ns1:service>
</soapenv:Body>
</soapenv:Envelope>
[그림 11]은 서비스가 이동하기 전에 PDA 에서 음악 서비스가 OSGi
프레임워크에서 동작되는 화면이다. [MPlayer] 번들이 인스톨 과정을 거쳐 시
작되고, 서비스가 등록되면서 프레임워크는 음악 서비스를 시작한다.
first.mp3 파일 재생을 마친 후, 두 번째 곡인 second.mp3 파일이 재생되는
도중에 MPlayer 서비스의 이동을 요청 받은 [Mobile Manager]는 MPlayer
서비스에게 “MOVE” 이벤트를 전달한다. “MOVE” 이벤트를 받은 MPlayer
서비스는 현재의 상태 정보를 저장하고 서비스를 중지한다. [Mobile Manager]
는 MPlayer 서비스를 직렬화하여 지정된 URL의 PC로 전송한다.
[그림 11] 음악 서비스의 이동 전 화면
[그림 12]는 음악 서비스 이동 후의 시퀀스 다이어그램이다. 서비스의
복원을 위해서 전송된 SOAP 객체로부터 그 서비스에 해당하는 클래스의
URL 정보와 함께 서비스의 상태 정보 및 등록 정보를 얻어 낸다. Bundle
Installer 에 의해 음악 서비스에 해당하는 번들의 클래스 파일을 다운로드 한
후 OSGi 프레임워크에 설치하고, Service Deserializer 는 전송 받은 서비스의
상태 정보를 비직렬화한다. 비직렬화 과정을 거쳐 얻어진 서비스의 상태 정
보인 재생 목록과 재생하고 있던 MP3 파일의 offset 정보로 이동하기 전의
서비스 상태로 복원시킨다.
[그림 12] 서비스 이동 후의 시퀀스 다이어그램
[그림 13]은 서비스가 이동한 후에 PC 에서 음악 서비스가 동작하는 화
면이다. PDA 로부터 MPlayer 서비스가 전송된 후, [Mobile Manager]는
[MPlayer] 번들을 다운로드 하여 설치한다. MPlayer 서비스를 전송 받은
[Mobile Manager]는 비직렬화 과정을 거쳐 MPlayer 번들을 인스톨한 후, 번
들을 시작한다. 시작된 [MPlayer]가 서비스를 등록하면, 이동 전에 중지한
132 offset부터 second.mp3 파일을 재생한다.
[그림 13] 음악 서비스의 이동 후 화면
4.3 평가
본 연구에서 제안한 OSGi 상의 서비스 이동 관리 시스템은 OSGi 프레
임워크를 구현한 오픈 소스인 Knopflerfish 1.3.3 상에 설치되어 무리없이 작
동하였다. 그리고 이를 통해 구현한 시스템이 OSGi 표준 스펙에 맞게 구현
되었는지를 확인하였다.
PDA 상의 OSGi 프레임워크에서 MP3 파일을 플레이하는 서비스가 자
신의 서비스 상태를 유지한 채 PC 상의 OSGi 프레임워크로 이동하여 연속
된 음악 서비스를 제공해 주었다. 이 실험을 통해서 본 연구에서 제안한
OSGi 상의 서비스 이동 관리 시스템은 서비스의 현재 상태 정보를 함께 이
동시킴으로써, 복수 개의 OSGi 프레임워크가 존재하는 유비쿼터스 컴퓨팅
공간에서의 서비스에 대한 이동성을 지원할 수 있음을 보였다.
제 5장 결 론
홈 네트워크 등 유비쿼터스 컴퓨팅 환경을 구성하는 OSGi 프레임워크
들간의 개체의 이동을 보장하기 위해서는 서비스 이동에 대한 관리가 필요
하다. 본 연구에서는 OSGi 프레임워크 상에서 이동이 요구되는 서비스에 관
한 번들 형태의 관리 시스템을 제안하였고, 이를 위해서 OSGi 스펙에 맞는
서비스 이동 관리 시스템을 설계하고 구현하였다.
설계한 서비스 이동 관리 시스템은 번들 형태로 구현되어 OSGi 프레
임워크에서 동작된다. 서비스 이동 관리 시스템은 OSGi 프레임워크 들간의
서비스의 이동을 지원하기 위해서 서비스 객체의 직렬화 과정을 통해 얻어
진 서비스의 상태 정보를 서비스의 등록 정보와 함께 SOAP 메시지 방식으
로 전송한다. 다른 OSGi 프레임워크로 이동한 서비스는 이전의 서비스의 상
태 정보와 등록 정보를 전송받아 비직렬화 과정을 거쳐서 이동 전에 수행하
고 있던 서비스의 상태로 복원하여 그 서비스가 재시작될 수 있도록 한다.
이처럼 이동성을 갖는 서비스에 대한 동적 관리를 가능하게 함으로써 서비
스의 이동성을 보다 효과적으로 지원할 수 있었다.
향후 지능형 서비스를 제공하기 위해서 상황 정보를 고려한 OSGi 상
의 상황 인식 프레임워크에 대한 연구와 서비스의 이동에 따른 보안에 관한
연구가 이루어져야할 것이다.
참고 문헌
[Chem02] S. Chemishkian, “Building Smart Services for Smart Home,”
Proceeding of the IEEE 4th International Workshop on Networked
Appliances, pp. 215-224, 2002.
[Chen01] K. Chen and L. Gong, Programming Open Service Gateways with Java
Embedded ServerTM Technology, Addison Wesley, 2001.
[Cond99] M. Condry, U. Gall and P. Delisle, “Open Service Gateway
Architecture Overview,” Proceeding of the 25th Annual Conference of the
IEEE Industrial Electronics Society, Vol. 2, pp. 735-742, 1999.
[Ditz04] M. Ditze, G. Kamper, I. Jahnich and R. Bernhardi-Grisson, “Service-
based Access to Distributed Embedded Devices through the Open Service
Gateway,” Proceeding of the Second IEEE International Conference on
Industrial Informatics, pp. 493-498, 2004.
[Dobr02] P. Dobrev, D. Famolari, C. Kurzke and B. A. Miller, “Device and
Service Discovery in Home Networks with OSGi,” IEEE Communications
Magazine, Vol. 40, Issue 8, pp. 86-92, 2002.
[Gong01] L. Gong, “A Software Architecture for Open Service Gateways,” IEEE
Internet Computing Magazine, Vol. 5, Issue 1, pp. 64-70, 2001.
[Gu04] T. Gu, H. K. Pung and D. Q. Zhang, “Towards an OSGi-based
Infrastructure for Context-Aware Applications,” IEEE Pervasive Computing
Magazine, Vol. 3, Issue 4, pp. 66-74, 2004.
[Hall04a] R. S. Hall and H. Cervantes, “Challenges in Building Service-Oriented
Applications for OSGi,” IEEE Communications Magazine, Vol. 42, Issue 5,
pp. 144-149, 2004.
[Hall04b] R. S. Hall and H. Cervantes, “An OSGi Implementation and
Experience Report,” Proceeding of IEEE Consumer Communications and
Networking Conference, pp. 394-399, 2004.
[Hofr01] K. Hofrichter, “The Residential Gateway as Service Platform,”
Proceeding of 2001 International Conference on Consumer Electronics, pp.
304-305, 2001.
[Lee03] C. Lee, D. Nordstedt and S. Helal, “Enabling Smart Spaces with OSGi,”
IEEE Pervasive Computing Journal, Vol. 2, Issue 3, pp. 89-94, 2003.
[Li04] X. Li and W. Zhang, “The Design and Implementation of Home Network
System using OSGi Compliant Middleware,” IEEE Transactions on
Consumer Electronics, Vol. 50, Issue 2, pp. 528-534, 2004.
[Lian02] L. Liang and A. J. A. Wang, “Bundle Dependency in Open Service
Gateway Initiative Framework Initialization,” Proceeding of the IEEE 5th
International Workshop on Networked Appliances, pp. 122-126, 2002.
[Marp01] D. Marples and P. Kriens, “The Open Services Gateway Initiative: An
Introductory Overview,” IEEE Communications Magazine, Vol. 39, Issue 12,
pp. 110-114, 2001.
[Stra03] T. Strang, Service Interoperability in Ubiquitous Computing Environments,
PhD Thesis, Ludwig-Maximilians University, 2003.
[Take04] M. Takemoto et al., “A Service-Composition and Servie-Emergence
Framework for Ubiquitous-Computing Environments,” Proceeding of
International Symposium on Applications and the Internet Workshops, pp.
313-318, 2004.
[Valt02] D. Valtchev and I. Frankov, “Service Gateway Architecture for a Smart
Home,” IEEE Communications Magazine, Vol. 40, Issue 4, pp. 126-132, 2002.