HttpLogService를 이용한 Bundle 구현
WSDD (WebSphere Studio Device Developer)를 이용하여 HttpLog라는 번들을 구현해보기로 한다. HttpLog번들은 특정한 HttpServlet에 의해 엑세스된 트랜젝션의 로그 메시지를 추적하고 기록하는 기능을 갖는다.
/// Step 1. Bundle skeleton 생성
WSDD에서 자바 프로젝트를 통해서 HttpLog라는 번들 스켈레톤을 만든다. 또한 Properties를 통해 OSGi framework library osgi.jar와 servlet.jar의 build path를 수정한다.
/// Step 2. OSGi BundleActivator interface 구현
이제 HttpLogBundleActivator 라는 자바 클래스를 작성하면서 OSGi BundleActivator interface를 구현해보기로 한다. BundleActivator interface는 두개의 메소드를 정의하는데 start()과 stop()이 바로 그것이다. start() method는 번들이 active될 때 OSGi System Framework로부터 invoke된다. 아래의 코드에서 BundleContext argument는 delegation object로 Framework로부터 invoke될때에 구동되는 Operation set이다.
|
//HttpLogBundleActivator.java public class HttpLogBundleActivator implements BundleActivator { … BundleContext bc; public void start(BundleContext context) throws Exception { bc=context; //to add initialization code here } public void stop(BundleContext context) throws Exception { } … } |
/// Step 3. Register custom service
이제 HttpLogService라는 로그기록을 관리하는 custom service를 구현하기로 한다. 총 3개의 자바 파일을 코딩하는데, 명칭은 각각 다음과 같다. HttpLogService.java, HttpLogServiceImpl.java, HttpLogServiceFacotry.java. 우리는 custom service를 위한 하나의 interface class와 implementation class를 구현하는데 예를 들어 HttpLogService interface의 경우 log() 라는 하나의 메소드를 정의한다.
|
//HttpLogService.java package httplog; public interface HttpLogService { void log(String message); } //HttpLogServiceImpl.java package httplog; public class HttpLogServiceImpl implements HttpLogService{ static public List messageArray = new ArrayList(); public void log(String message) { HttpLogServiceImpl.messageArray.add(message); } } |
일반적으로 어떤 custom services을 요청하는 번들이(hosting bundle) active될때에, 해당 custom services는 System Framework에 등록이 된다. 따라서 Step2에서 구현했던 HttpLogBundleActivator 클래스에 아래의 start() method를 추가한다.
|
//HttpLogBundleActivator.java public class HttpLogBundleActivator implements BundleActivator { static final String httpLogServiceName = HttpLogService.class.getName(); … public void start(BundleContext context) throws Exception { registerHttpLogService(); } private void registerHttpLogService(){ HttpLogServiceFactory sf = new HttpLogServiceFactory(); ServiceRegistration sr=bc.registerService(httpLogServiceName,sf,null); } } |
또한 registerService()가 호출될 때, 해당 번들은 정의된 custom service name과 OSGi ServiceFactory interface의 서비스 오브젝트 그리고 해당 서비스의 properties가 포함된 Dictionary object를 제공한다. 각각의 ServiceFactory subclass는 getService()와 ungetService()라는 두개의 메소드를 갖게된다. 우리가 작성하는 코드에서는 sf가 하나의 HttpLogServiceFactory 타입이면서 또한 HttpLogServiceImpl instances를 generate하는 역할을 한다.
|
//HttpLogServiceFactory.java package httplog; import org.osgi.framework.Bundle; import org.osgi.framework.ServiceFactory; import org.osgi.framework.ServiceRegistration; public class HttpLogServiceFactory implements ServiceFactory{ … public Object getService(Bundle bun, ServiceRegistration sr) { return new HttpLogServiceImpl(); } public void ungetService(Bundle bun, ServiceRegistration sr, Object obj) { } } |
/// Step 4. Consume external service
우리가 작성하는 HttpLog Bundle에 의해서 제공되는 외부서비스는 바로HttpService이다. 사용자는 localhost의 HttpServlet이 억세스한 기록들을 HttpLog bundle이 작성한 레코드를 통해서 추적할 수가 있다. 이러한 기능을 제공하기위해서 HttpLog bundle은 HttpService가 제공하는 인터페이스를 통해서 HttpService bundle을 servlet object로 등록해야만 한다. HttpLog bundle이 start될 때 위의 과정이 자동적으로 일어나게된다.
|
public class HttpLogBundleActivator implements BundleActivator { … static final String servletURI ="/httplog"; private void initialize(){ //Import HttpService attachToHttp(); //register HttpLogService registerHttpLogService(); } private void attachToHttp(){ httpContext = new HttpContext(){ public boolean handleSecurity(HttpServletRequest request, HttpServletResponse response) { return true; } public URL getResource(final String name) { return (URL) AccessController.doPrivileged(new PrivilegedAction() { public Object run() { String resource = name; if (resource.charAt(0) != '/') resource = "/".concat(resource); //$NON-NLS-1$ return getClass().getResource(resource); } }); } public String getMimeType(String name) { return null; } }; ServiceReference httpSR = bc.getServiceReference(HttpService.class.getName()); HttpService http = (HttpService)bc.getService(httpSR); try { http.registerServlet(servletURI, new HttpLogServlet(), null, httpContext); } catch (ServletException e) { e.printStackTrace(); } catch (NamespaceException e) { e.printStackTrace(); } } … } //HttpLogServlet.java package httplog; import java.io.IOException; import java.io.PrintWriter; import java.util.List; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.ServletException; public class HttpLogServlet extends HttpServlet{ protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html; charset=UTF-8"); PrintWriter out = res.getWriter(); out.print("<html><head><title>" + "Http Log Display" + "</title></head>"); out.print("<body text=\"#000000\" bgcolor=\"#C0C0C0\" link=\"#0000EE\" vlink=\"#551A8B\" alink=\"#FF0000\">"); List msgArray = HttpLogServiceImpl.messageArray; int len=msgArray.size(); for (int i=0;i<len;i++){ String msg= (String)msgArray.get(i); out.print(msg); } out.println("</body></html>"); } } |
위의 코드를 살펴보면 번들이 초기화될 때 특정한 HttpServlet object이 HttpService에 등록되게 된다. 일반적으로 external service가 구동되기전에 요청 번들은 OSGi System Framework로부터 external service instance가 어디에 위치해있는지 필요하게 된다. 이러한 일련의 과정은 BundleContext에서 getServiceReference()과 getService() 메소드를 제공하므로 수행된다. 두개의 메소드는 필요로 하는 정보들을 service registry에서 찾아서 리턴하는 역할을 한다.
/// Step 5. Migrate to bundle format
코드를 모두 작성하고나면 실제 번들을 패키지 형태로 작성하는 과정을 거치게된다. WSDD에서File->New->SMF를 하고 Bundle Folder를 선택하여 새로운 번들을 생성한다. target bundle folder에서HttpLog 를 선택한다. 나머지 옵션은 선택하지않는다. 다음 단계로 MANIFEST를 작성할 단계이다. MANIFEST.MF 파일은 번들들의 독립성과 정보 공유 및 협업을 위해서 매우 중요한 정보 파일이다. 반드시 일정한 OSGi specification에 의해서 작성되어야 한다. WSDD의 MANIFEST editor는 그림처럼 사용자가 쉽게 작성할수있도록 도움을 준다.
다음의 섹션을 필수적으로 정의해야하는 항목들이다. 다음은 우리가 작성한 예제파일의 경우이다.
- Bundle-Name : HttpLog.
- Bundle-Version : 1.0.0.
- Bundle-Activator : httplog.HttpLogBundleActivator
- Import Services : org.osgi.service.HttpService
- Import Packages : javax.servle, javax.servlet.http, org.osgi.framework, org.osgi.service.http.
OSGi은 하나의 JVM 환경에서 작동한다. 그러나 하나의 VM이라고 하나의 프로세스 또는 싱글 태스크라고 생각하면 잘못된것이다. 앞서도 이야기했지만, OSGi는 비록 하나의 VM위에서 구동하더라도 번들간의 독립성과 협업을 하기위해서 각 번들마다 서로 다른 클래스 로더가 구동하여 작동하게 되어있다. 따라서 각 번들은 MANIFEST file에서 자신의 클래스 패스와 버전, 기본적인 정보들을 레퍼런스 하게된다.
- Export Packages : httplog.
- Export Services : httplog.HttpLogService.
HttpLog project를 Export하면 된다.
/// Step 6. OSGi Server로 Bundle 배포
우리가 작성한 번들을 배포하려면 OSGi System Framework가 탑재된 시스템을 찾고 그곳에 추가하면 된다. WSDD에서는 이런 모든 과정을 매우 쉽게 접근할수있게 도와주는데, 다음의 방법을 사용한다. 우선 [Run] Window를 실행시켜서 OSGi 서버(SMF Server)를 생성하고 구동한다. 이렇게 SMF Server를 구동한후에, Project Explorer에서 [HttpLog project] 클릭하고 SMF->Submit Bundle을 선택하면 번들의 배포는 끝난다. SMF server 구동시에 서버가 되는 타겟에 대한 대화상자가 나오는데, 그곳에 아이디와 패스워드, 아이피등에 대한 기본적인 억세스 정보들을 적는다. 우리는 로컬PC에서 작업을 하기에 Admin@localhost:8080/smf로 기입한다. 이렇게 모든 서버의 구동과 번들의 배포가 마친후에 [SMF perspective]-[SMF Bundle Servers view]에서 HttpLog 번들이 SMF server에 배포된 것을 확인할 수가 있다. IBM 솔루션에서는 이러한 모든 과정들이 WSDD의 Dialog Box에서 자동적으로 이루어지지만, 다른 여타의 OSGi 솔루션에서는 각기 다른 방법으로 로컬 서버 및 원격 서버로(실제 OSGi가 설치된 PC 및 타겟 디바이스) 배포할 수가 있다.
/// Step 7. Bundle testing
이제 우리가 구현한 번들을 배포했고, 테스트하는 단계만 남았다. 이 역시도 테스트 번들을 구현하기로 한다. 테스트 번들을 HttpLogTester로 명명하고, 이 번들은 테스트용으로 HttpLogService를 invoke하는 것이 주된 기능이다. 이 번들이 HttpLogService을 invoke하면 그 다음 단계로 Http log가 화면에 정상적으로 나타난다면 우리가 만든 번들은 성공적으로 작성한것으로 본다. 이 번들 역시 우리가 거쳐왔던 step 1,2를 반복하여 bundle skeleton을 생성한다. 빌드 패스에 httplog.jar을 포함하며 아래의 코드와 같이 HttpLogTesterBundleActivator에 start() method를 코딩한다.
|
//HttpLogTesterBundleActivator.java class HttpLogTesterBundleActivator implements BundleContext{ … public void start(BundleContext context) throws Exception { bc=context; ServiceReference httpLogSR=bc.getServiceReference(httpLogServiceName); HttpLogService httpLog =(HttpLogService)bc.getService(httpLogSR); httpLog.log("Hello world!"); } … } |
step 2-6를 반복하며 마지막으로 역시 HttpLogTester 번들을 SMF server에 배포한다.
/// Step 8. Test HttpLog in SMF runtime
이제 우리는 배포된 HttpLogTester 번들을 실제 install – activate 시키는 과정을 거쳐서 우리가 만든 번들이 제대로 작동되는지 확인해야한다. SMF Runtime을 실행시키고 HttpLogTester를 install 한다. 이 모든 과정 역시 WSDD의 SMF Bundle Server view에서 지원된다. HttpLogTester 번들이 SMF Bundle Server에 install 되는 순간 필요한 번들을 요청하게되어 HttpLog와 HttpService는 자동적으로 함께 install 되고 ready하게 된다. 이제 로그 메시지를 확인하기위해서 웹브라우저에 http://localhost/httplog라고 타입하면 곧 우리는 브라우저에서 해당 로그 결과를 살펴볼수가 있게 된다.
이번호에서 우리는 OSGi bundle의 기본적인 구조와 코드를 통해서 구현과 배포, 실행에 대해서 살펴보았다. 예제 코드에서 로컬 서버와 번들간의 인터페이스들을 살펴보았지만, 실제 구현되는 코드에서는 DB와의 연동과 원격관리서버를 통한 업데이트와 관리 그리고 마지막으로 네이티브 코드(Native Code)와의 연동을 통해서 OSGi의 장점을 최적화하여 사용하고 있다. 특히 방금 이야기한 DB handling & Sync, Bundle Remote Management & Dynamic Update, JNI를 통한 Native code interface 등은 OSGi의 고급 핵심 기술들로 향후 더욱 많이 사용될 중요한 부분이다. 여타의 OSGi 솔루션들도 마차가지겠지만, 특히 IBM의 OSGi 솔루션은 Eclipse Plugin Framework – Equinox, Business Process Application – Expeditor등을 거쳐서 더욱 강력한 Middleware Framework로 부각되고 있다. 다음호에서는 RCP(Rich Client Platform)로 대변되는 Eclipse OSGi Framework “Equinox”를 통해서 임베디드에서 데스크탑 애플리케이션, 그리고 플랫폼의 일부분으로까지 확장되어가는 OSGi 사례를 살펴본다.
/// 참고문헌
1. Managed mobile clients with OSGi - http://www.ibm.com/developerworks/library/wi-osgi
2. IBM Workplace Client Technology, Micro Edition and Open Services Gateway Initiative (OSGi) –http://www.ibm.com/developerworks/websphere/library/techarticles/0606_salkosuo
/0606_salkosuo.html
3. IBM Service Management Framework - http://www-306.ibm.com/software/wireless/smf/index.html[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 10월호에 실린 기사입니다]
우리는 지난호에 OSGi Application 구현을 위한 실행과 개발 환경에 대하여 살펴보았다. 이번호에서는 OSGi Application (Bundle)을 직접 구현하고, OSGi Framework에 등록,수행,테스트 및 원격관리에 대한 일련의 번들 라이프 싸이클에 대해서 살펴보기로 한다. 많은 OSGi 관련 툴들이 나와있으나 이번호에서도 역시 IBM의 Websphere 솔루션을 사용하여 구현해보기로 한다. 구현할 내용은 다음과 같다.
1. HttpLogService를 이용한 Bundle 구현
2. OSGi Framework 상에서 Bundle Test
IBM에서는 OSGi 관련 솔루션들을 IBM Workplace Client Technology, Micro Edition 이라는 이름으로 One-stop 솔루션을 제공하는데, 이클립스 기반의 통합개발툴인 WSDD (WebSphere Studio Device Developer), OSGi 기반의 미들웨어 툴킷 Micro Environment Toolkit for WebSphere Studio, J2ME 런타임모듈과 DB2e 를 제공하는 WebSphere Everyplace Micro Environment으로 구성되어있다. SMF(Service Management Framework)은 IBM의 OSGi 솔루션의 명칭이면서 또한 Front-End Solution의 핵심 컴포넌트의 하나이다. IBM의 Front-End Solution을 Workplace Client Technology 이라고 통칭하기도 하는데, 주로 PC based Business Application, Device Control, Embedded & Mobile Device를 타겟으로 운용된다.
OSGi Bundle Architecture
OSGi에서는 모든 기능과 서비스들이 번들로 의해서 구현되고 서비스로 운영된다. 번들이 기본적인 구성요소인 이유로는 loosely-coupling과 reusability에 있는데, 번들은 Dependency static sharing과 dynamic services로 각각의 독립성(Dependency)을 유지하게 된다. 번들의 독립성이란 무슨 뜻일까? OSGi는 같은 번들이라고해도, 다른 버전의 번들을 동시에 사용할 수가 있다. 1.0의 A번들과 1.5의 번들이 함께 구동될수가 있다는 뜻이다. 그렇게 운영되는 것은 번들이 다음의 구성요소들로 구분되고, 요청하는 번들이나 서비스에 인터페이스로 제공되기에 가능하다.
- Bundle manifest file : 번들의 가장 기본적인 명칭, 버전, 제공 기능 및 다른 번들과의 static & dynamic interaction 방법들을 서술하고 있다.
- Bundle activator implementation : 우리는 번들이 OSGi System Framework로부터 install, update, start, stop되는 일련의 라이프 싸이클을 갖는다는 것은 알고있다. 이렇게 번들이 System Framework과 연동되고 컨트롤할수있게 해주는 것이 바로 OSGi BundleActivator interface이다.
- Custom service interface : Besides those OSGi defined services, bundle vendors can develop custom services. To do that, you should define a Java™ interface for each custom service (번들은 반드시 R3, R4의 규약에 나온 서비스들만 구현될수있는 것은 아니다. 각 벤더에서 독자적인 번들을 서비스 형태로 구현할 수가 있는데, 이렇게 각 벤더별 독자적으로 구현한 번들과 서비스를 사용하려고 할 때 필요한 것이 바로 Custom service interface 이다)
-
Custom service implementation : custom service interface를 정의한 Class 메소드
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 9월호에 실린 기사입니다] [그림 3] Java2 Platform 구성도 [그림 4] MSA 주요 제공 기능
J2ME 플랫폼은 사용되는 기계장치별로 Java플랫폼을 정의하는 프로파일을 제공하여 개발과 실행을 가능하게 한다. 프로파일은 컨피규레이션 위에 위치하는 기계장치별로 구분되는 API들로서 현재는 MIDP(Mobile Information Device Profile)만이 제공, 실행되며, 차후에 PDA profile, RMI profile 등이 포함될 것이다. SUN는 JCP(자바에 대한 License와 표준을 관장하는 기구로 Java Community Process의 약자)를 만들면서 전체 자바구조를 새로운 기틀로 재편성하였다. 업무/적용 영역에 따라 다음과 같은 세가지 section으로 나눈 것이다 .
① J2SE : 업무용 서버·시스템전용
② J2EE : 표준적인 구성으로, 데스크탑, 워크스테이션전용
③ J2ME : 적은 자원으로 동작하는 편입 기기용
J2ME 플랫폼은 J2SE, J2EE에 비해서 가장 늦게(?) SPEC이 정의되었으나 실은 그전부터 PersonalJava, PICOJava, eJava 등등의 솔루션으로부터 발전되어 온 개념이다.자바의 탄생 배경이 가전제품의 표준화된 제어와 네트워크 솔루션이라고 한다면 어쩌면 J2ME는 자바의 목적에 가장 잘 맞는 규격인지도 모르겠다. 최근 21세기 들어서 급격하게 임베디드, 모바일 기술이 발전되고 유비쿼터스 환경이 도래하면서 J2ME 플랫폼은 핸드폰, MP3, 디지털 카메라, 차량 네비게이션, 홈게이트웨이, 각종 디바이스 컨트롤러 등에서 많은 수요가 급증하고 있다. 또한 그렇게 인기가 올라가는 J2ME 환경에서 함께 OSGi도 수요가 급증한다는 것은 매우 고무적인 일이 아닐수가 없다.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 9월호에 실린 기사입니다]
Java 2 Platform, Micro Edition (J2ME)은 Java 플랫폼의 가장 작은 부분으로, 스마트 카드나 호출기와 같이 매우 작은 장치에서부터 TV 셋탑 박스와 컴퓨터 데스크탑과 같은 강력한 장치에 이르기까지 소비자용 내장형 장치에 사용된다.
J2ME의 주요 요소로는 소비자용 내장형 장치를 위한 Java 솔루션을 제공하는 여러 도구 및 기술과 함께 CDC(Connected Device Configurations) & CLDC(Connected Limited Device Configurations)라 불리우는 핵심 API Set, 각 디바이스 제품군에 맞는 API Set SPEC을 정의한 프로파일들 – F/P(Foundation Profile), P/P(Personal Profile), MIDP(Mobile Information Device Profile) 들로 구성되는데, 특히 소비자 가전(CE) 제품용으로 최적화된 Java Runtime Environment도 포함된다.
이렇듯 J2ME 기술은 다양한 범위의 극소형 제품에 사용되며, 스마트 카드, 호출기, 셋탑 박스 및 기타 소형 제품 내에서 보안, 연결 및 유용한 유틸리티 프로그램을 사용을 가능케 한다. 결국J2ME 기술은 Java 제품군의 일부로서 관련된 Java 플랫폼에는 J2SE (Java 2 Standard Edition) 및 J2EE (Java 2 Enterprise Edition)가 있다. J2ME 플랫폼은 실행, 개발환경으로 CVM & KVM, 애플리케이션 프로그래밍 API Library, Deployment와 Configuration tool 들을 제공한다.
J2ME 플랫폼이 지향하는 제품군들을 두개의 그룹으로 나누면, 첫번째로 개인의 휴대가 가능하며 네트워크를 통한 정보전달이 가능한 기기군들로 셀롤러 폰, 페이져 등을 말할 수 있으며(KVM-CLDC-MIDP), 두 번째로 구체적인 기능을 가지며, 고정되어 있는 정보전달 기기군들로 셑톱박스, 인터넷 TV, 자동차 네비게이션 시스템등으로(CVM-CDC-F&PP) 구분할수있다.
[그림 1] J2ME 플랫폼에서 운영되는 노키아 S60 핸드셋
셀롤러폰이나 페이져 등은 제품들의 모양,성능, 특성이 제각각이기 때문에 각각의 기계장치들의 공통되는 핵심부분을 모아 버츄얼머신의 configuration과 API들을 제공하고 있다. 실행환경 측면에서의 J2ME Configuration은 메모리 용량과 프로세스의 처리용량이 비슷한 것들을 같은 범주로한 API들로 CLDC를 정의하고 있다. Configuration의 스펙을 살펴보면, 프로그램 언어인 Java , Java Virtual Machine 실행환경, 개발 도구로 Java라이브러리와 API를 제공하고 있다. 하이-레벨 아키텍처는 기계장치의 OS위에 버츄얼머신이 존재하고 그 위에 컨피규레이션과 프로파일이 수직적 구조로 이루어져 있다.
현재J2ME 플랫폼에서는 CLDC(Connected Limited Device Configuration)와 CDC(Connected Device Configuration), 두가지의 표준 컨피규레이션이 있으나 최근 자바원 2007에서 발표된 CLDC의 로드맵은 MSA(Mobile Service Architecture) 1.0으로 발전하게 된다. 
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 8월호에 실린 기사입니다]
대부분의 IT기술은 미국에서 태동하고 선진업체들이 미국업체인데 반해서, OSGi는 유럽 업체들도 미국업체 못지않게 활발하게 활동을 벌이고 있다. 하지만 역시 OSGi를 이끌고 주도하는 업체는 IBM이다. OSGi 태동에 SUN이 자바로 영행력을 발휘했지만(?) 계속 버전업이 되고 활성화되면서 많은 솔루션을 구현하고 영향력을 확대한 것이 IBM이라는 것은 누구도 부인할수 없는 사실이다. IBM은 과거 OSGi의 자사 솔루션 SMF(Service Management Framework)을 시작으로 임베디드/모바일 자바환경인 J2ME, 오픈소스 개발툴에서 플랫폼으로 확장하고 있는 이클립스, 그룹웨어 협업솔루션 Expeditor에 이르기까지 지속적인 OSGi 솔루션으로 영향력을 확대해왔다.
특히 이클립스의 오픈소스 결정뿐만 아니라 이클립스 3.0대에 이르면서 OSGi가 이클립스 플랫폼에 탑재될 때 SMF를 지원하여 Equinox 솔루션을 탄생하기까지 많은 지원을 아까지 않았다. 이처럼 J2ME(J9), Expeditor, Equinox 등의 솔루션 라인업은 많은 업체들이 OSGi 솔루션으로 제품을 개발하거나 탐재할 때 가장 먼저 찾게되는 OSGi 선두업체로 자리매김하게 되는 결정적인 요인이 된다. 반면 유럽에서는 크게 솔루션 업체와 OSGi 개발 벤더로 나뉘어지는데, 대표적인 업체들이 바로 지멘스, 노키아, 필립스, BMW 등의 전통적인 제조업체와 Knopflerfish, Prosyst같은 전문 벤더이다. 지멘스-노키아는 모바일 솔루션 분야에서, 필립스는 홈네트워크 분야에서, BMW는 자동차 정밀제어 분야에서 각각 OSGi를 자사의 핵심 미들웨어 솔루션으로 탑재하여 제품 개발을 하고있다. 또한 Knopflerfish, Prosyst 등의 전문벤더들은 전통적인 제조업체들이 OSGi 솔루션을 신뢰성있는 제품으로 사용할수있도록 표준화 SPEC을 상용화, 공급하는 역할을 담당하고 있다.
OSGi - System Architecture
OSGi가 R4에 이르러서 OSGi 커뮤니티 전문 기술 그룹들이 모바일, 자동차, 임베디드, 엔터프라이즈 서버 환경으로 재편된것도 이러한 유럽 업체들의 영향력을 무시할수없기 때문이다. 미국이 IBM을 필두로 다양한 상용화 솔루션과 오픈소스 진영(Eclipse, Apache)으로 영향력을 확대하고 있다면 유럽은 오히려 다양한 기업들이 자동차, 모바일, 홈네트워크 분야의 상용화 솔루션에서 두각을 나타내고 있다. 그렇다면 국내 실정은 어떠할까? 국내에서도 많은 연구개발이 이루어지고 있는 것은 사실이나 상용화제품으로 이어져 지속적인 사업 매출로 연결되는 경우는 많지가 않다. 다만 최근 들어서 가정용 셋탑박스, 텔레매틱스 분야의 네비게이션등에서 눈에 띠는 성과를 거두고 있다.
/// 활용사례 - 삼성전자 빌딩용 공조시스템 컨트롤러 DMS
삼성전자 생활가전총괄은 사람들에게 꼭 필요한 의/식/주에 관련된 제품을 연구 개발하는 총괄이다. 생활가전총괄은 미래가전 및 신기술 개발에 꾸준한 노력을 기울이고 있으며 바이오(Bio), 나노(Nano), 디지털 IT 등 다양한 분야와의 디지털 융합을 통해 미래 디지털 가전 시장의 선두적인 기업으로 도약하고 있다. 건강과 편리함을 원하는 고객의 요구에 대비해 홈 네트워크 및 다양한 미래가전을 준비, 개발하고 있는 생활가전총괄은 생활의 중심에서 고객과 가장 가까운 곳에 서 있다. 또 건강과 행복을 만드는 제품을 통해 삶의 새로운 방향을 제시하는 Life Style Innovator 역할을 수행하고 있다. 생활가전총괄은 4개의 사업영역에서 사람들 삶의 질적 향상을 위해 노력하고 있다. 사업 부문은 △시스템 에어컨, Built-in, 홈 네트워크 등 떠오르고 있는 첨단 디지털 제품을 연구 개발하는 New-Biz △에어컨, 냉장고 등 Cooling △세탁기, 청소기, 공기청정기를 개발하는 Cleaning △전자렌지, 오븐을 연구하는 Cooking 등이다. 특히 공조시스템 개발은 고부가가치 제품 중심의 수익력 극대화 및 해외 운영 확대를 통해 세계 경쟁력을 강화하고 있다. 삼성전자 생활가전총괄은 최근 보다 효율적인 시스템 에어컨 관리를 위해 임베디드 컨트롤 서버 ‘DMS(Data Management Server)’ 개발을 진행해 최근 완료했다.
::::: Business Challenge
사업 확장에 따른 신규 시스템 필요
시스템 에어컨의 관리 체계는 최근 들어 고도의 높은 기술들이 적용되기 시작했다. 즉, 웹 기반으로 환경이 바뀌고 오픈 프로토콜, 임베디드 디바이스 등 최신 IT 기술이 공조시장에 접목되기 시작한 것이다. 전문화도 이뤄지기 시작했다. 학교, 병원, 사무실 빌딩 등 사이트 특성 및 규모별로 관리 시스템이 사이트에 알맞게 출시되기 시작했다. 서비스 대응 수준도 높아지고 있다. 일본에서는 원격 진단 서비스가 보편화되는 시점을 맞았다. BMS 시장도 변화되고 있다. 과거에 비해 원격 관리 시스템들도 오픈 프로트콜 기반으로 전환되고 있다. 오픈 프로토콜 적용 사례는 이미 국내 신규 대형 빌딩에서 나타나고 있다. 삼성전자도 기업, 대학, 병원 등 빌딩에 시스템 에어컨(DVM)을 공급, 구축해 운영하고 있다. 따라서 삼성전자도 시스템 에어컨 사업 확장에 따른 신규 시스템 아키텍처가 필요하게 됐다. 또 원격 관리 시장 진입을 위한 체계 구축도 필요했다. 삼성전자는 그동안 공급한 시스템 에어컨에 대해서는 PC를 활용, 원격관리를 해왔으나 문제점이 많았다. 그 문제점은 PC를 통한 시스템 에어컨 관리는 범용이 아니어서 활용도가 낮고 안정성과 확장성도 낮았다. 또 통신이 원활하게 이뤄지지 않고 보안상에도 문제점이 있는 것으로 지적돼 왔다. 이와 함께 기존 시스템과 연동이 쉽게 이뤄지지 않는 문제점과 24시간 365일 운영이 되지 못한다는 한계점을 갖고 있었다. 삼성전자는 이에 따라 중앙관리가 필요한 학교, 기업, 호텔의 빌딩 등을 주요 타깃으로 정하고 24시간 364일 지속적인 시스템 에어컨 운영통제 관리가 가능케 하는 솔루션을 개발하기로 했다. 이러한 결정으로 인해 삼성전자는 기존의 문제점과 한계점을 극복할 수 있는 시스템 에어컨 중앙관리를 위한 각 사이트별 운영을 총괄하는 임베디드 컨트롤 서버 ‘DMS’ 개발을 진행하기 시작한 것이다. DVM Solution Layout
J2ME(J9), SMF(OSGi), WSDD, DB2e 적용해 DMS 개발
삼성전자는 지난 2004년 3월부터 임베디드 기반의 컨트롤 서버인 ‘DMS’ 개발을 진행했다. 이번 개발을 통해 제품이 탄생되면 이 제품은 시스템 에어컨 기술 로드맵 상의 가장 근간이 되는 핵심 디바이스(Device)가 된다. 삼성전자는 DMS의 주요 기능으로 1) 통신 오픈 프로토콜 지원 (RS485, TCP/IP, LonWorks, BACnet) 2) DMS 1대당 최대 16대 중앙 제어기, 256대 실내외기 지원 3) 웹서버를 자체구동, 웹 제어 기능을 가능하게 했다. 삼성전자가 개발하는 임베디드 기반의 OS를 가지는 디바이스인 ‘DMS’는 시스템 에어컨 데이터를 485통신으로 수집하고 이더넷(Ethernet)을 통해 DVM 전용 제어기나 서비스 서버로 전송한다. 한편 DMS는 임베디드 DB 시스템 ‘DB2e’를 탑재하여 보다 효율적으로 시스템에어컨 데이터를 관리한다. 자체 메모리 용량을 고려해 에어컨의 상태 데이터를 일정기간 저장할 수 있으며 Web Configuration & Management, DI/DO 입출력 Port 내장, 년간?주간 일정 기능을 저장 및 수행 할 수 있다. Console Port(RS232C)를 이용한 구성으로 돼 있다. 이밖에 디바이스 모니터링 기능으로 고장정보, 상태정보, 운영정보를 모니터링하고 전력 관리 기능으로 전력분배, 피크 전력 제어 등의 기능을 갖고 있다. 이러한 기능은 과거 임베디드 컨트롤러의 경우 RTOS환경에 C/C++로 개발하는 경우가 대부분이었으나, OSGi 탑재로 모든 컨텐츠들을 번들로 처리하여 컨텐츠의 추가/수정/삭제/업데이트 등의 관리를 원격에서 실시하고, 확장성이 뛰어난 구조로 설계할 수가 있었다.
DMS 개발 환경은 애플리케이션 툴로는 WSDD(WebSphere Studio Device Developer) 등이 사용됐다. 플랫폼으로 OS는 Montavista 임베디드 리눅스, DB는 임베디드 DB ‘DB2e’, Middleware Framework은 OSGi가 채택되었으며, 개발환경은 J2ME & J9 & CDC-F/P이 적용되었다.
DMS System Architecture
::::: Benefit
DMS로 고객 만족 높여 매출 확대
삼성전자는 이번 프로젝트를 통해 시스템 에어컨 중앙관리를 위한 각 사이트별 운영을 총괄하는 임베디드 컨트롤 서버 ‘DMS’ 솔루션을 보유하게 됐다. 이를 통해 삼성전자는 시스템 에어컨 관리의 효율성이 증대될 것으로 전망하고 있다. 또 고객들은 새로 개발된 DMS 솔루션을 적용할 경우 기존 관리보다 편리성이 높아져 고객 만족도가 증대될 것으로 보인다. 이에 따라 매출 증가도 삼성전자는 기대하고 있다. 제어 솔루션 부문에서도 경쟁사와 비교할 경우 다소 열세였던 부분을 만회해 공조 중앙관리가 필요한 시장에서의 경쟁력을 강화할 수 있을 것으로 예측하고 있다. 이와 함께 이번 솔루션 개발로 온라인 서비스 체제 구축이 가능한 기반도 마련할 수 있게 됐다. 삼성전자는 향후 이번에 개발될 솔루션을 오픈 환경으로 전환해 어느 제품이든 사용이 가능하게 할 계획이다. 이번에 개발된 솔루션은 삼성전자 제품 적용에 용이하게 돼 있다.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 8월호에 실린 기사입니다]
1.3 OSGi의 주요 서비스
OSGi에서는 1.0부터 4.0에 이르기까지 수많은 서비스와 스펙들이 발표되어 사용되고 있다. 여기서는 그 가운데 핵심 서비스를 골라 살펴본다. OSGi를 구성하는 중요 구성요소는 다음과 같다.
- 서비스 : 특정 기능을 수행하는 자바 인터페이스와 실제 구현객체
- 번들 : 서비스를 제공하기 위한 기능적 배포 단위
- 프레임워크 : 번들의 라이프 사이클을 관리하는 번들 실행환경
서비스는 미리 정의된 서비스 인터페이스를 통해 접근이 가능한 컴포넌트이다. 하나의 애플리케이션은 여러 개 서비스의 협동 작업을 통해 구성되고 런타임시에 필요한 서비스를 요청할 수도 있다. 프레임워크는 각 서비스와 그 서비스에 해당하는 실제 구현에 대한 매핑을 가지고 있고, 간단한 쿼리 메커니즘을 통해 서비스의 실제 구현을 찾을 수 있다. 또한 프레임워크는 각 서비스간의 상호 의존관계를 관리한다. 번들은 여러 서비스의 구현을 하나의 패키지로 묶은 JAR 파일의 형태로 존재한다. JAR 파일에는 하나 이상 서비스의 구현 객체와 리소스 파일, 그리고 매니페스트(manifest) 파일이 포함되어 있다. 번들 컨텍스트는 프레임워크 내부의 번들 실행 환경이며 번들의 설치와 실행, 정지, 삭제 등의 번들 라이프 사이클을 관리한다. 이렇듯 서비스, 번들, 프레임워크는 항상 상호 작용하면서 OSGi를 구성하게 된다. OSGi 1.0 규격에서 명시한 패키지들은 <표 1>과 같다.
1) org.osgi.framework
OSGi 프레임워크는 소용량 메모리 디바이스에서 프로그래밍 하는 개발자들이 연속적으로 동작하는 애플리케이션을 작성할 수 있는 컨텍스트를 제공하는 것이 목적이다. 애플리케이션의 swap-in과 swap-out이 런타임시에 발생하는 이러한 환경에서는 런타임시에 다른 애플리케이션과 구조적이고 의존적인 방식으로 커뮤니케이션을 수행해야 할 필요가 있다. OSGi 프레임워크는 자바 프로그래밍 언어가 가진 코드의 네트워크 이동성을 이용해 컴포넌트 기반의 개발환경을 제공함으로써 보다 풍부하고 구조적인 서비스 개발을 가능하게 한다. org.osgi.framework 패키지는 10개의 인터페이스와 6개의 클래스, 2개의 예외 클래스로 구성되어 있다. OSGi 프레임워크가 제공하고자 하는 환경의 목표는 다음과 같다.
- 애플리케이션이 실행 중에도 동적 다운로드 및 업그레이드 가능
- 제한된 메모리 디바이스 사용 가능
- 효율적이고 통합된 컴포넌트 개발 환경 제공
- 애플리케이션간의 의존성에 대한 관리 기능 제공
- 확장 가능성(scalable)
2) org.osgi.service.device
디바이스 매니저는 OSGi 프레임워크에서 하나의 서비스 리스너로 등록(register)된다. 디바이스 매니저는 새롭게 추가되는 디바이스의 서비스를 탐지하고, 새로 추가된 디바이스의 드라이버 번들을 설치한다. 다음은 디바이스 매니저의 알고리즘이다.
- 디바이스 탐지(Device Detection) : 모든 새로운 디바이스 (org.osgi.service.device.Device 인터페이스 객체)를 검색
- 위치 단계(Location Phase) : 새로 추가된 모든 드라이버를 DriverLocator를 이용해 위치시킴
- 경선 단계(Bidding phase) : 각 드라이버를 디바이스 상에서 경선에 참여
- 추가 단계(Attach Phase) : 경선 단계에서의 최상위 드라이버 추가
- 청소 단계(Cleanup Phase) : idle 드라이버를 청소
각 드라이버 번들은 세계적으로 유일한 스트링 아이디를 가지고 있어야 하고, 이 아이디는 드라이버 매니저가 드라이버의 revision을 해석해 프레임워크의 위치 아이디로 사용된다. org.osgi.service.device 패키지는 3개의 인터페이스로 구성되어 있다.
3) org.osgi.service.http
HttpService는 프레임워크 내의 다른 번들이 리소스를 등록하고 HTTP를 통해 서블릿에 접근할 수 있게 한다. HttpService를 통해 등록할 수 있는 엔터티는 서블릿과 리소스이다. 서블릿은 Java Servlet API를 구현한 객체이며 서블릿의 등록은 URI 네임스페이스에 대한 서블릿 제어권을 부여한다. 리소스는 HTML 파일, GIF 파일, 클래스 파일 등을 포함하며 리소스의 등록은 이러한 리소스들을 URI 네임스페이스에서 사용 가능하게 한다. org.osgi.service.http 패키지는 2개의 인터페이스와 하나의 예외 클래스로 구성되어 있다
4) org.osgi.service.log
LogService는 번들로부터의 로그 요청을 받아들이고 LogReaderService는 다른 번들이 로그 항목을 읽을 수 있게 한다. LogService는 이벤트와 에러 상황에 대한 리포트를 주목적으로 하지만, 다른 용도로도 활용할 수 있다. org.osgi.service.log 패키지는 4개의 인터페이스로 구성되어 있다.
2. 실행 환경의 표준 권고, OSGi - R3
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)의 구성 요소와 새롭게 추가된 핵심 서비스는 다음과 같다.
- URL Handlers Service Spec 1.0 : 자바에 관련된 명세로서 새로운 URL 방식에 대한 URL 처리기를 등록 가능하도록 지원
- 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를 통해 제어
- 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로 찾는 방법만을 지원
- 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에 이르러서 임베디드, 모바일, 데스크탑은 물론이고 엔터프라이즈 서버 환경에서 적응하기 위한 새로운 시도들을 발견하게 된다. Preferences Service, XML Parser Service, Metatype Spec, Execution Environment Spec이 바로 대표적인 핵심 서비스들이다.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 8월호에 실린 기사입니다]
지난 시간에는 OSGi의 발전 배경과 기본 개념, 그리고 구조 등을 차례로 살펴봤다. 유니버설 미들웨어(Universal Middleware)라 불리는 OSGi는 초창기에 가정용 홈 게이트웨이의 임베디드 환경에서 출발해 지금은 모바일과 자동차, 엔터프라이즈 환경에 이르기까지 매우 폭 넓게 활용되고 있다. 이번 호에서는 OSGi의 다양한 활용 사례와 OSGi의 핵심인 서비스에 대해 집중적으로 소개한다.
OSGi의 현재 가장 큰 이슈는 RCP과 Enterprise Framework으로의 확장일것이다.
오픈소스로 출발하여 자바업계뿐만 아니라 S/W 개발자들의 기본적인 개발툴인 이클립스에 OSGi가 탑재된다는것 자체가 큰 이슈였으며, 지금까지 엔터프라이즈 서버 환경으로 적용은 감히 생각지못했다가 Spring 프레임워크와의 통합은 신선한 충격으로 IT업계에 다가왔다. 단순히 임베디드 또는 홈 게이트웨이정도로 치부되던 OSGi가 데스크탑 리치 클라이언트 플랫폼으로, 서버환경에서 프레임워크로 확장, 발전하게되는 이유는 뭇엇일까? 여러 이유들이 있겠지만, 가장 큰 이유로는 가벼운(Light-Weight) 그리고 동적인(Dynamic) 모듈(Module) 시스템 구조와 번들의 라이프 싸이클 관리시스템을 들수가 있다. 이외에도 버전업이 되면서 임베디드 환경에서 적용되기 시작하여 점차 기능별로 세분화된 SPEC과 다양한 서비스 컨텐츠들도 빼놓을수없는 이유일것이다. 이번호에서는 OSGi의 핵심 기능인 서비스와 실제 활용 사례를 살펴보고, 이제 더 이상 OSGi는 이론적으로 존재하는 그리고 임베디드에 국한된 시스템이 아닌 실제적이고 파워풀한 유니버셜 미들웨어라는 것을 보게될것이다.
OSGi의 가장 핵심적인 임무는 '다양하고 새로운 서비스의 제공'이다.
과거 OSGi가 처음 형성됐을 때는 전 세계를 잇는 네트워크를 홈 네트워크에 어떻게 연결하고 어떤 서비스를 제공할지를 도출하는 것이 OSGi 멤버들의 최대 관심사였다.
1. OSGi의 핵심 - 서비스
OSGi가 오픈 서비스 게이트웨이를 구성하는 아키텍처의 소프트웨어를 개발하는 것도 이 때문이다. OSGi 참여업체들은 이를 통해 '서비스 기반으로 제공할 수 있는 새로운 비즈니스 모델'을 찾고 있다. 이는 단순히 제품만을 판매하는 20세기 사업모델에서 탈피해 다양하고 새로운 서비스를 판매하는 21세기형 사업모델을 만드는 것이 OSGi의 주요 업무였기 때문이다.
특히 OSGi는 네트워크 환경이 구축된 일반 가정이 차세대 프론티어 역할을 할 것으로 판단함으로써 인터넷과 신기술이 일반 가정에 새로운 서비스를 제공할 수 있을 것으로 기대하고 있었다. 이를 통해 새로운 가치사슬도 형성된다는 판단인데, 이를 위해서는 반드시 관련 업계(컴퓨터, 가전, 통신 등)가 모두 수긍하는 표준화 작업이 선행되어야 한다. 특정 업체만 지원하는 서비스나 프로토콜은 오래 지속되지 않을 뿐더러, 대규모의 시장을 창출할 수 없기 때문이다. OSGi 서비스 제공업체들은 네트워크로 연결된 가정 내 각종 기기에 접속해 기기의 이상 유무에서부터 원격 제어 및 원격 수리 등의 다양한 부가서비스를 제공하고, 이를 통해 새로운 수익을 창출할 수 있기 때문이다.
이렇듯 초기의 OSGi 개발 및 참여업체들은 이처럼 다양한 서비스가 가능한 게이트웨이의 표준 소프트웨어 사양 개발 작업에 착수해 현재 그 버전이 4.0 대에 이르고 있다. 따라서 오늘날 OSGi에 참여해 개발을 주도한 업체들은 이미 다수의 구체적인 성과물을 제시하고 있다. OSGi가 차세대 IT 산업과 가전산업을 주도할 태풍의 핵으로 부상하고 있는 것도 바로 이 때문이다.
1.1 JES와 OSGi
OSGi는 자바 환경에서 구동되는 미들웨어이므로 자바와 매우 밀접한 관계를 나타낸다. 임베디드 자바 솔루션 중에서 자바 임베디드 서버(Java Embedded Server, 이하 JES)는 임베디드 디바이스를 위한 퍼스널 자바 기반의 런타임 환경이다. 그리고 JES는 네트워크를 통한 서비스의 제공과 서비스 라이프 사이클의 관리 기능을 제공하는 소용량 애플리케이션 서버라고 할 수 있다. 그렇다면, OSGi와 JES는 어떤 관계일까? OSGi의 표준화를 주도한 업체가 썬 마이크로시스템즈(이하 썬)라는 사실을 안다면 그 해답을 쉽게 찾을 수 있다. 즉 JES는 OSGi 표준을 구현한 임베디드 서버 솔루션 중의 하나인 것이다. JES의 구조 역시 프레임워크와 서비스로 구성되어 있다. 서비스는 JES 서버에서 동작하는 컴포넌트화된 애플리케이션이고, ServiceSpace 프레임워크는 서비스의 컨테이너이다. 프레임워크의 기본적인 기능은 서비스들의 설치와 업그레이드, 삭제 등과 같은 라이프사이클에 대한 제어이고, 서비스는 서비스 인터페이스에 구현되는 형태로 구성된다. 그리고 JAR(Java ARchive) 파일로 패키지화된 서비스를 ‘번들’이라고 부른다. 이런 개념들은 이미 우리가 살펴보았던 OSGi와 동일하다. JES 서버는 네트워크를 통한 서비스의 설치와 업그레이드, 삭제 등을 할 수 있지만, 처음 기동되는 경우에 몇 가지 기본적인 서비스를 포함하고 있다. 결국 OSGi의 개념과 구조는 새롭게 탄생된 것이 아니라 탄생을 주도한 썬의 영향력 아래에서 차분하게 성장한 것임을 알 수 있다. 다음은 JES에서 제공하는 기본 서비스 기능이다.
- HTTP 서비스 : 웹 서버 기능
- 로그 서비스 : 에러와 이벤트 등의 원격 로깅 기능
- 날짜 서비스
- 연결 관리 서비스 : 네트워크 서비스, 소켓 바인딩, 연결 요청 처리 등의 기능
- 스레드 매니저 서비스 : 스레드 풀의 최대치 등에 대한 스레드 관리 기능
- 스케줄러 서비스 : 향후의 이벤트에 대한 스케줄링 기능
- RMI(Remote Method Invocation) 서비스
- SNMP(Simple Network Management Protocol) 서비스
- 콘솔 서비스 : 애플릿을 통한 원격 관리 기능
이 중에서 OSGi 1.0 규격에 포함된 표준 서비스는 HTTP 서비스, 로그 서비스, 연결 관리 서비스(OSGi에서는 디바이스 액세스 서비스)이며 계속해서 다양한 분야의 스펙으로 확장해 가고 있다. 발표된 1.0 스펙은 주로 게이트웨이에 탑재되는 응용프로그램 인터페이스(API)에 대한 규정을 담고 있으며 자바(JAVA)용 API에 집중되어 있다. 이는 자바가 현재 가장 널리 사용되는 프로그래밍 언어인터라 개방형 서비스 게이트웨이에 유연하게 적용될 수 있었기 때문이다.
1.2 OSGi - SPEC
OSGi는 1.0부터 4.0 대에 이르기까지 버전을 업그레이드하면서 스펙 표준안을 마련하고, 또한 마련된 스펙은 플랫폼이나 응용소프트웨어 등에 전혀 구애받지 않는다고 발표했다. 또한 보안 기능이 우수할 뿐 아니라 다양한 서비스 제공업체들이 전달해주는 멀티 서비스를 각기 다른 장치나 설비에 제공하는 기능을 항상 염두에 두고 표준안을 마련하고 있다. 이러한 업계의 표준화 노력으로 OSGi의 스펙 표준안은 특히 블루투스(Bluetooth)와 HAVi, HomePNA, HomeRF, IEEE-1394, LonWorks, USB, VESA 등 다양한 유무선 네트워크 기술을 수용할 수 있어 가장 포괄적인 개방형 네트워크 기술로 인정받고 있다. 특히 OSGi는 완전히 새로운 개념의 장비들이 등장할 것에 대비해 JINI와 HAVi 등이 제공하는 기능도 전폭적으로 수용한다. 이는 셋톱박스와 케이블모뎀, 라우터, 경보시스템, 전력관리시스템, 가전제품, PC 등 모든 제품에 대한 관리 및 연결 기능을 제공하기 위한 것이다.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 7월호에 실린 기사입니다]
1.4 OSGi 핵심 - 번들(Bundle), 서비스(Services)
1.4.1 번들 (Bundle)
OSGi의 가장 기본적인 실행 단위인 번들은 OSGi Framework에서 수행되는 어떤 S/W component의 resources, 동작을 위한 Java classes, Bundle 정보를 담고 있는 Manifest file, service를 포함하는 JAR 파일이다. OSGi는 단 하나의 VM 인스턴스위에서 동작하고, 복수개의 클래스로더를 수행하여 독립된 namespace를 갖게됩니다. 또한 번들은 동적 라이프 싸이클을(dynamic Install, Start, Stop, Delete, Update) 갖고 수행하며(Without a JVM restart) 성능을 위해서 여러 리소스와 인터페이스를 지원한다. (Images, GUI look & Feel, Native-JNI) 자바 애플릿처럼 서버에서 다운로드하는 형식이 아니라 로컬 디바이스에 상주하는 것도 하나의 특징이다. 다음 그림은 번들의 동적 라이프 싸이클을 나타낸다.번들이 OSGi Framework에 등록되면(Active Status) Bundle Context가 생성되는데, OSGi Framework와 번들사이의 인터페이스 역할과 다른 서비스 검색과 서비스 등록에 사용된다.
[그림 6. OSGi Bundle - Dynamic Life Cycle]
1.4.2 서비스 (Service)
OSGi Service는 자바 오브젝트로서 하나의 번들에 의해서 등록되며 다른 번들에 의해서 사용되거나, 복수개의 번들이 연동/통합하여 독자적인 서비스를 만들어내기도 한다. 명시된 형태는 Java Interface 스타일로 표현되어, 서비스의 스펙과 구현이 완벽하게 분리되어 사용된다. 이렇게 되면, 동일한 서비스 기능을 갖고도 서로 다른 번들이 서로 다른 구현(Implementation)을 서비스 레지스트리에 등록할 수가 있게된다.
[그림 7. OSGi bundle과 Service 생성]
[그림 8. 다양한 OSGi Service Model]
특히 디바이스-디바이스 M2M 환경이나 센서 네트워크, 로봇 등의 새로운 솔루션과 서비스 등이 속속 등장하는 현재와 미래에는 서비스를 쉽게 생성하고 운영하고 관리할 수 있는 그리고 표준화된 스펙을 제공하는 OSGi가 더욱 더 그 영향력을 확장해 나갈것이라고 생각하게 된다. Mobile/Embedded에서 탄생하여 Desktop/RCP와 Enterprise의 확장, 그리고 다가올 새로운 M2M, Micro Sensor Networks 시대에서도 진정한 Universal Middleware Framework로 자리잡게될것을 기대해본다. 다음회에서는 실제 OSGi 솔루션과 성공적인 활용 사례 그리고 임베디드 개발 환경의 구축에 대해서 살펴본다.
/// 참고문헌
1. OSGi Service Platform Core SPEC R4 - http://www.osgi.org
2. About the OSGi Service Platform - http://www.osgi.org
3. IBM - SMF (Service Management Framework) - http://www.ibm.com/software/wireless/smf
4. The Fundamental of OSGi - 한국산업기술대학교, 서대영 교수
[작성 - 김석우, 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)에 의해 많은 영향을 받게 되었다.
Eclipse-Equinox를 포함한 OSGi의 요즘 새로운 이슈는 바로 JSR 277과의 대결이다. JSR 277은 Dynamic Component Model로서 JAVA 7의 주요 스펙중의 하나이다. 그 특징적인 요소가 OSGi와 많은 부분에서 비슷하거나 또는 다른 성격을 가지고 있어서 OSGi업계의 많은 관심을 불러일으키고 있다. 실제 JSR 291은 OSGi SPEC으로서 JSR 입장으로 본다면 277과 291 SPEC이 충돌하는 것처럼 비쳐지게된다.
OSGi Architecture 전문가 Peter Kriens의 블로그
[참고문헌]
1. Eclipse Equinox - http://www.eclipse.org/equinox
2. JSR 277 vs. 291 - http://underlap.blogspot.com/2007/06/comparison-of-jsr-277-and-jsr-291.html
3. Equinox Architecture - http://www.ibm.com/developerworks/opensource/library/os-ecl-osgiconsole
4. Equinox Future - http://theserverside.com/tt/articles/article.tss?l=EclipseEquinoxOSGi
5. Equinox Service Model - http://ibm.com/developerworks/opensource/library/os-ecl-osgi/?ca=dgr-lnxw07EclipseEvolution
