Akashic Records

OSGi Alliance 본문

Infrastructure

OSGi Alliance

Andrew's Akashic Records 2018. 4. 18. 14:53
728x90

OSGi Alliance

OSGi(Open Service Gateway initiative) Alliance 1999년 선 마이크로시스템즈, IBM, 에릭손 등에 의해 구성된 개방형 표준 단체이다. (OSGi Alliance 처음에 Connected Alliance라고 불렸음) 동안 OSGi Alliance 원격 관리 있는 자바 기반의 서비스 플랫폼을 제정해왔다. 표준 사양의 핵심은 어플리케이션의 생명주기(Life cycle) 모델과 서비스 레지스트리(Service Registry) 정의하는 프레임워크(Framework)이다. OSGi 표준 사양에는 프레임워크에 기반하여 매우 다양한 OSGi 서비스가 정의되어 있다.

OSGi 프레임워크는 독립적인 Java/VM 환경에서 제공하고 있지 못한 세련되고, 완전하며 동적인 컴포넌트 모델을 구현한다. 어플리케이션 또는 컴포넌트(번들, Bundle) 재부팅 없이 원격지를 통해 설치(installed), 시작(started), 정지(stopped), 업데이트(updated) 그리고 제거(uninstalled) 있다

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


OSGi 탄생과 배경

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등의 표준이다. 이러한 장비 연결 제어로 얻을 있는 유효한 다양한 서비스들이 있으며, 이러한 서비스의 배포문제와 서비스가 작동하기 위한 제반 환경 제공을 목표로 하는 것이 바로 OSGi 기본 목표라고 있다.

OSGi Release Version

OSGi Release 1 (R1): May 2000

OSGi Release 2 (R2): October 2001

OSGi Release 3 (R3): March 2003

OSGi Release 4 (R4): October 2005 / September 2006

- Core Specification (R4 Core): October 2005

- Mobile Specification (R4 Mobile / JSR-232): September 2006

OSGi Release 4.1 (R4.1): May 2007 (AKA JSR-291)

초기의 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 탑재하여 사용할 수가 있다. 이를테면 노키아에서 개발한 응용 서비스 번들과 서비스등을 모토롤라나 소니에릭슨의 휴대폰에 탑재하여 사용할 수가 있다.


OSGi 특징

과거 OSGi R1.0 발표될때만 하더라도 OSGi 홈네트워크의 네트워크 표준에 국한된 부분이 많았으나, 현재 4.0 이르러서는 기존의 홈네트워크 외에 모바일, 임베디드, 텔래매틱스, PC 애플리케이션 (Eclipse 기반의 RCP) 물론 엔터프라이즈 환경의 프래임워크에까지 확장하고있다. 그만큼 기존의 미들웨어에 비해서 많은 장점을 가지고있다는 방증이다. 또한 과거 초기 단계의 네트워킹 빌딩 제어, 자동화 시장에서 디바이스 제어 기술이 주로 사용되고 있지만 현재는 그보다 훨씬 다양한 디바이스간의 상호작용을 요구하게 되고 나아가 컨텐츠 솔루션 서비스가 점차적으로 고도화되어 질수록 OSGi 같은 서비스 플랫폼 환경이 필요하게 것이다. 현재 다양한 디바이스들간의 상호운용성을 위해서 UPnP, HAVi, JINI같은 표준이 만들어지고 주로 장비의 제어나 데이터 전달 등을 처리하게 되므로 OSGi 기술과 상호 보완적인 위치에 있는 셈이다. OSGi 사용하거나 구현하는 쪽에서는 이러한 미들웨어의 지원이 다른 고려 사항임에 유의해야 한다.


1. S/W Component Management

OSGi 자바 기반의 Component 구조로 설계되어 있다. 따라서 OSGi 자바 런타임 환경하에서(J2ME, J2SE, J2EE) 작동하게 만들어진 표준이다. 자바VM 이질적인 Embedded OS Embedded CPU에서 오는 차이점들에 대한 완충 역할을 수행한다. 또한 OSGi 서비스 기반의 구조 지향한다. 서비스는 모두 번들(Bundle)이라 불리우는 물리적 묶음에 포함된다. 복수개의 OSGi 서비스가 하나의 번들에 포함될 수도 있으며, 번들은 배포와 관리의 기본 단위를 형성한다. 번들들을 관리해 주는 것이 바로 프레임워크(Framework)이다. 프레임워크는 서비스에 대한 등록/관리기(Service Registry) 가지고 있어서 서비스에 대한 등록/조회/실행/삭제 등을 수행한다. 또한 이벤트와 그에 따른 이벤트 탐지 대응 처리도 하게 된다. 여기서 말하는 이벤트는 장비에서 생성된 물리적 이벤트와는 관계가 없고 서비스/번들/프레임워크의 세가지 이벤트 산출자를 근간으로 하는 논리적 이벤트라는 점에 유의할 필요가 있다.


2. Remote Component ManagementOSGi 원격관리를 지원한다. 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 활용하여 컨텐츠 번들을 관리하고 업그레이드하는 대표적인 제품들이다.


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 솔루션으로 나타나게 된다.


OSGi 구조

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) 의해 많은 영향을 받게 되었다.


728x90

'Infrastructure' 카테고리의 다른 글

PAN (personal area network)  (0) 2018.04.18
OWL(Web Ontology Language)  (0) 2018.04.18
NAT [Network Address Translation]  (0) 2018.04.18
Middle Ware  (0) 2018.04.18
MEAP: Mobile Enterprise Application Platform  (0) 2018.04.18
Comments