[2기 강북 송석호] OSGi(Open Services Gateway initiative)란?

안녕하세요.

강북 멤버십 20-2기 송석호입니다.

제가 개발 하면서 접하게 된 OSGi란 부분을 소개 하도록 하겠습니다.

OSGi 프레임 워크를 이해하면 eclipse를 이해 할 수 있고,

또한 eclipse plug-in 개발 하실 때 많은 도움이 될 것이라 생각합니다.

1. What is OSGi?

 

< 그림 1. OSGi Alliance Supporter >

 

OSGi는 wiki 에서 아래와 같이 정의 되어 있다.

* OSGi(Open Service Gateway initiative) Alliance는 1999년에 썬 마이크로시스템즈, IBM, 에릭손 등이 구성한 개방형 표준 단체이다. (OSGi Alliance는 처음에 Connected Alliance라고 불렸음) 그 뒤 여러 해 동안 OSGi Alliance는 원격 관리 될 수 있는 자바 기반의 서비스 플랫폼을 제정해왔다.

이 표준 사양의 핵심은 응용 프로그램의 생명주기(Life cycle) 모델과 서비스 레지스트리(Service Registry)를 정의하는 프레임워크(Framework)이다. OSGi 표준 사양에는 이 프레임워크에 기반하여 매우 다양한 OSGi 서비스가 정의되어 있다.

OSGi는 Embeddable(응용 프로그램 내부로 포함될 수 있는) SOA를 구현하고 있다. 이를 통해 응용 프로그램 개발에서 가장 복잡하고 관리하기가 어려운, 모듈간의 동적(Dynamic) 관계와 의존을 매우 효과적으로 관리할 수 있게 한다. (Web service based SOA가 네트워크를 중심으로 하는 SOA라면 OSGi는 Java Object based SOA이다.)

 

요약하여 다시 한번 설명 하면

- OSGi 는 네크워트상에 연결된 디바이스들이 다양한 서비스를 공유 할 수 있도록 하는 자바 언어 기반의 동적인 플랫폼을 만들기 위해 시작되었고, 동적인 컴포넌트 모델을 지원하는 프레임워크 이다.

- OSGi Alliance 1999년 3월 처음 설립 홈 네트워크를 지원하기 위한 플랫폼으로 처음 만들어졌으며, 다양한 로컬 네트워크 장치 간의 표준화된 명세를 제공함으로써, 상호 호환성을 보장하고, 이를 통해 외부와의 외부와의 연결이나 다양한 클라이언트, 관리자를 지원할수 있다.

- OSGi 번들(Bundle)라는 모듈 단위를 기반으로 동작 한다. OSGi 는 한 개의 번들 또는 여러 개의 번들로 이루어진 애플리케이션 자체를 언제든지 동적으로 프레임워크 상에 설치, 실행, 업데이트, 중단, 제거 하는 것을 가능하게 하는 매우 우연한 라이프 사이클(Life Cycle, 생명주기) 모델을 지원하는 프레임워크 이다.

 

OSGi의 특징은 다음과 같다.

 - ByteCode와 가상머신 기술을 이용하여 코드 호환성을 보장하는 자바 플랫폼 위에, 각 애플리세이션들이 번들이라 불리는 작고 재사용 가능한 컴포넌트로부터 조립될 수 있도록 도와준다.

- 조합된 애플리케이션들은 시스템의 재시작 없이 컴포넌트의 연결구조를 동적으로 변경할 수 있다.
- 동적으로 연결구조가 변경될수 있도록, OSGi는 서비스 지향 아키텍처 Service Oriented Architecture, SOA 를 사용한다.

- 동적으로 번들이 추가/ 삭제되고 서로 간에 호출이 일어날 수 있음.

- OSGi에서 제공하는 Service Registry 에 자신의 서비스를 등록; 서비스를 export / import 할 수가 있다.

2. OSGi Service Platform Release

현재 OSGi Service platform은 Release 4 까지 나왔습니다.

* Specification version

- OSGi Release 1 (R1): May 2000

- OSGi Release 2 (R2): Oct. 2001

- OSGi Release 3 (R3): Mar. 2003

- OSGi Release 4 (R4): Sep. 2006

- OSGi Release 4.2 (R4.2): Sep. 2009

- OSGi Release 4.3 (R4.3): Apr. 2011

 

< 그림 2. OSGi Release Version >

 

초기의 OSGi R1.0에서는 기초적인 정보기기의 연동과 상태 모니터링의 기능을 탑재하고, 표준화에 주력했고 2.0에서는 운영자와 관리, 보안의 기능이 추가되었다. 본격적인 컨텐츠 서비스 플랫폼으로의 모습은 R3.0에 이르러 나타나게 된다. 외부의 오픈소스를 이용하여 처리하던 XML Parsing, Wire Admin, URL Handler 등의 기능이 표준 서비스로 채택되어 탑재되고, UPnP와 JINI 표준이 기본 시스템 서비스로 올라오면서 OSGi는 명싱상부한 모바일/임베디드/데스크탑 애플리키이션/클라이언트&서버 환경에서 미들웨어 프레임워크로 자리매김하게 된다.

R4.0에 이르러서는 좀더 분야가 세분화되어 카테고리별로 디바이스 특성에 맞는 컨텐츠, 시스템 서비스들이 발전하게 된다. 특히 휴대폰, 스마트홈 컨트롤러, 빌딩 자동화 컨트롤러, 자동차에 탑재되는 네비게이션과 탤레매틱스 솔루션 등의 폭발적인 성장에 힘입어 모바일/임베디드 시스템에 대한 많은 요구 사항들이 직접 기본 서비스에 채택되고, 탑재되게 된다. 여기서 나오는 시스템 기본 서비스는 OSGi Alliance에서 승인/채택되어 기본 OSGi Framework에 탑재되는 것이며, 여기에 빠져있다하더라도 벤더가 자신의 원하는 기능을 OSGi SPEC에 맞춰서 개발하여 얼마든지 OSGi Framework에 탑재하여 사용할 수가 있다. 이를테면 노키아에서 개발한 응용 서비스 번들과 서비스등을 모토롤라나 소니에릭슨의 휴대폰에 탑재하여 사용할 수가 있다.

 

제가 공부하면서 몇몇 서비스들과 저의 프로젝트에게 맞도록 사용 목적을 정리해 본 표 입니다.

혹시 나중에 공부를 하시게 된다면 참조 해보셔도 좋을 것 같습니다 : )

서비스 이름	설명	버전	예상 사용
Framework	OSGi를 제공하는 기본 프레임워크	R1 (2000)	기본 사용중
Remote	서비스를 원격 장치에서 사용하기 위한 방법을 제공하는 서비스	R4.2 (2010)	서비스 공유
HTTP	외부로부터의 접속을 위해 자바 서블릿(Java Servlet)과 리소스 파일들(html, image)에 기반한 HTTP 서비스	R1	서버 동적 웹 페이지
Log	로그 메시지를 기록하고 읽어 올 수 있도록 하는 표준 서비스	R1	기본 사용
Devices Access	동적으로 추가 되는 USB, IEEE 1394 같은 장치들에 대한 자동 감지 및 연결을 지원하기 위한 서비스	R1	장치 호환
Package Admin	번들 간에 패키지를 익스포트할 수 있도록 해주는 서비스 (Manifest의 Import-Package, Required Budle)	R2	기본 사용중
Service Tracker	프레임워크의 Service Registry에 등록,수정,삭제 되는 서비스들을 손쉽게 트래킹 할 수 있도록 해주는 서비스	R2	기본 사용 번들 검색
Configuration Admin	각 번들의 설정 정보를 저장하고 변경 정보를 전달받을 수 있도록 해주는 서비스	R2	기본 사용 번들 관리
Preferences	번들에서 사용자별로 저장이 필요한 데이터를 저장하고 읽어올 수 있도록 해주는 서비스	R2	데이터 저장
Start Level	각 번들의 실행 순서를 조정 할 수 있게 해주는 서비스	R3	기본 사용중
Execution Environment	OSGi 실행 환경을 기술하여, OSGi 서비스 플랫폼 간의 호환성을 제공. (번들Manifest에 JRE의 Symbolic Name로 최소한 의존성 지원)	R3	플랫폼 호환성
Name Space	OSGi 내부에서 실행되는 모든 번들을 Naming할수 있는 방식 제공	R3
Jini	Jini 장치들을 발견 및 제어하고 OSGi 서비스를 jini 서비스로 제공	R3	장비 호환
Upnp	Upnp 장치들과 상호 동작할 수 있도록 하는 서비스	R3	장비 호환
Initial Provisioning	OSGi 서비스 플랫폼을 원격에서 제어하는 관리자 에이전트를 구현 할 수 있도록 하는 서비스	R3	원격 제어
Conditional PermissionAdmin	특정 조건에 따라 퍼미션을 부여 해주는 서비스 R2의 Permission Admin을 대체 가능!	R4	번들 퍼미션 관리
Event Admin	번들 간의 Publish/Subscribe 모델 방식의 이벤트 전달 메커니즘	R4	이벤트
Monitor Admin	번들의 상태를 확인 할 수 있도록 제공하는 서비스	R4	차후
Deployment Admin	번들 단위 설치 방식보다 큰 패키지 단위의 설지 방식 지원 서비스	R4	차후
Auto Admin	Deployment Admin 설정을 자동으로 도와줌	R4	차후
Application Admin	다른 애플리케이션 관리	R4	차후
Foreign Application Access	OSGi 서비스 모델이 아닌 MIDP, Xlets, Applets 같은 애플리케이션 모델과의 연동을 지원	R4	차후
Declarative Services	서비스를 등록하고 조회하는 작업을 XML을 통해 선언적으로 지원하여 코드 양을 줄이고 필요할 때만 서비스를 찾도록 지원하는 서비스	R4

3. OSGi Framework Architecture

1. OSGi framework Architecture

 

< 그림 3. OSGi Architecture >

 

1. Module : OSGi의 근간이 되는 번들을 정의하는 레이어

2. Life Cycle : 번들이 어떻게 동적으로 설치되고 관리될 수 있는지를 정의하는 레이어번들 내에서 어떻게 외부의 OSGi Context에 접근할 수 있는지를 정의한다.

3. Service : 서비스 레지스트리를 통해 서비스를 등록하고 찾을 수 있도록 지원하는 레이어

4. Security Layer : 자바의 보안 구조에 기반하고 있으며, 패키지나 서비스에 대한 권한을 관리하거나 Digitally Signed JAR파일에 대한 지원을 해주는 레이어

5. JVM(Execution Environment) : 번들이 실행될 수 있는 환경을 말하는 것으로 J2ME, J2SE등과 같은 환경들을 의미한다.

6. Bundles : 왼쪽 위에 있는 Bundles는 레이어 개념이 아닌 OSGi의 레이어를 통하여 작성되고, 프레임워크에 올려진 실제 번들을 의미하는 것으로, 개발자가 개발해서 프레임워크에 올리는 번들이 이 범주에 들어간다.

 

 

< 그림 4. OSGi & System - Layering >

 

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

 

2. OSGi Core framework

Bundle 을 위한 표준화된 기본 환경을 제공한다.

 

< 그림 5. OSGi Core Framework >

 Framework 은 다음과 같은 Layer 로 나뉜다.

 

L0: Execution 환경은 Java 런타임에서 Bundle 이 실행에 대한 실행환경 규약이다. 애초에 Java ME 에만 초점이 맞춰져 있었지만, 이제는 Java SE 나 Java EE 로 확대되었다. 애초의 실행환경은 다음과 같이 규정되었었다.

- Small Devices

- Collaboration model

- Continously up and running VM

- Life cycle management

·       

L1: Modules 레이어는 클래스 로딩 정책을 정의한다. Java 를 하위레이어로 두고 있으면서 기본 클래스패스 외에모듈간의 상호조율에 대한 고려가 되어 있는 내부 클래스패스를 추가로 정의한다. 이것은 보안시스템, 공개되지 않은 시스템에 대한 배포등을 지원한다.  

L2: Life Cycle Management 레이어는 Bundle 들을 동적으로 설치, 시작, 중지, 갱신, 제거시킨다. Bundle 은 기본적으로 Modules 레이어의 클래스 로딩에 의존하지만, 여기에 추가해서 Life Cycle Management 에서 실행중의 관리를 위한 기능을 Bundle 에 추가시킨다. Life Cycle 은 광범위한 의존성 메커니즘을 사용하며, 보안시스템으로 보호되어서 가상적으로 바이러스의 공격으로 부터
안전하게 한다.

·         L3: Service Registry 는 계정기반으로 클래스들을 bundle 간에 안전하게 동적으로 공유할 수 있게 해서 설치와     제거를 안전하게 지원한다

·          

3. Bundle

 Bundle 을 위한 표준화된 기본 환경을 제공한다 OSGi는 번들(Bundle)이라는 모듈단위를 기반으로 동작. 실제로 jar파일과 같은 형식이지만 몇가지 추가정보 가진다.

 번들은 OSGi의 기본기능에 의해 동적으로 설치, 실행, 업데이트, 중단, 제거가 가능하다. 즉 새로운 기능이 추가될 수 있고, 애플리케이션 재시작 없이 기존의 번들을 새로운 버전을 업데이트 할 수 있다.

 

- Bundle Life Cycle

OSGi는 다이내믹 플랫폼으로, 프레임워크가 동작하고 있는 도중에 번들을 설치, 시작, 업데이트, 멈춤, 제거 할 수 있다. 

< 그림 6. Bundle Life Cycle >

INSTALLED	최초 번들이 설치된 상태
RESOLVED	번들의 검증이 정상적으로 수행된 상태
STARTING	번들이 서비스 레지스트리에 등록되고 시작중인 상태
ACTIVE	번들이 서비스 가능하게 활성화된 상태
STOPPING	번들이 중지중인 상태
UNINSTALLED	번들이 제거된 상태

- 설치하면 INSTALLED 상태 -> 사용하기 위해 연동과 준비가 되면 RESOLVED

-> 번들이 해당 서비스를 수행하기 위해 필요 자원을 획득하는 동안이 STARTING

-> 모든 사전 준비 작업이 끝나고 서비스를 제공할 수 있는 상태가 되면 ACTIVE

- 중지 시키면 STOPPING 상태 -> 해당 자원을 모두 반납하게 되면 RESOLVED

- 번들을 업데이트 하면 다시 INSTALLED -> RESOLVED

- 번들을 제거 하면 UNINSTALLED

 

4. Service

 OSGi 서비스는 서비스 대상으로 자사의 서비스 인터페이스에 의해 의미적으로 정의 및 구현되어 있다.
 OSGi는 일반적인 요구에 맞는 다양한 서비스 인터페이스를 지정했으며 앞으로 더 지정한다.

 

- 서비스 인터페이스는 서비스의 공개 방법의 사양

• 번들 개발자는 서비스 인터페이스를 구현하여 서비스 객체를 생성하며, 프레임 워크 서비스 레지스트리와 서비스를 등록한다.

• 또한 서비스 레지스트리를 통해서 등록된 서비스를 찾고 Interact 할수가 있다.

< 그림 7. Service Registry 구조 >

4. Popular OSGi Implementations

- Open Source로 구현한 OSGi 프레임 워크들 중 많이 사용 되는 Open Source 입니다.

§  Eclipse Equinox : Eclipse PDE(Plug-in Development Environment)

§  Knopflerfish OSGi : Knopflerfish 3 (OSGi R4 v4.2) is the latest stable version of Knopflerfish

§  Ubiserv

§  Apache Felix

제가 구현 해본 Open Source OSGi 개발 환경 및 각각 실행한 화면입니다.

1. Equinox

- 개발 환경

Eclipse for RCP Developers PDE(Plug=in Developmet Environment)

 

< 그림 8 Equinox 실행 화면 >

2. Knopflerfish

- 개발 환경

Knopflerfish_osgi_sdk_3.2.0 (2011-08-17 최신버전) - OSGi R4 v4.2

 

< 그림 9. Knopflerfish 실행 화면 >

3. Felix

- 개발 환경

Apache Felix 20110902 - (org.apache.felix.main.distribution-3.2.2.tar.gz)

 

< 그림 10. Felix 실행 화면 >

5. Reference

§  “OSGi Service Platform Core Specification Release 4, Version 4.3”, The OSGi Alliance, Apr. 2011.

§  Song J.H., “Design and Implementation of Management Bundle for OSGi Framework”, Soongsil Univ., 2008.

§  권정혁, “실전 OSGi & Spring DM”, 위키북스, 2009.

§  Etc.,

§  OSGi Alliance site, www.osgi.org

§  SERI.org, http://www.seri.org

§  Open OSGi middleware project site, www.knopflerfish.org

§  Gatespace Telematics Inc., www.gatespacetelematics.com

§  NEMOsoft Inc., www.nemosoft.co.kr

 

6. finish 

OSGi 프레임 워크가 제공하고자 하는 환경의 목표는 다음과 같다고 합니다.

• 애플리케이션이 실행 중에도 동적으로 다운로드 및 업그레이드가 가능 

• 제한된 메모리 디바이스 사용 가능 

• 효율적이고 통합된 컴포넌트 개발환경 제공 

• 애플리케이션 간의 의존성에 대한 관리 기능 제공

여기까지 OSGi에 대한 간단한 소개를 마치며, 다음 달에는 Equinox를 이용하여 OSGi 번들 및 서비스를 구현해 보도록 하겠습니다.