[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 11월호에 실린 기사입니다] Eclipse-Equinox를 탑재한 IBM Solution 라인업 IBM - Tivoli Provision Manager IBM - Lotus Expeditor Adobe - VersionCue Front View
1) IBM : IBM은 Eclipse-Equinox가 존재하는 가장 큰 근거를 남진 업체이다. 또한 반대로 IBM이 추구하는 전략 – Pervasive Computing, Business On-Demand에 가장 큰 수확을 거둔 업체이기도하다. IBM은 자사가 개발에 착수하여 키운 두개의 제품(Eclipse, SMF-OSGi)를 오픈소스로 공개하였고, 그것에 그치는 것이 아니라 오픈소스 업계에 막강한 영향력을 발휘하여 Eclipse-Equinox를 하나의 거대한 플랫폼으로 발전시키는 쾌거를(?) 이루어 내었다.
2) Adobe : Phoitoshop으로 유명한 아도브사는 얼마전 Macromedia를 인수하여 Web, Mobile, PC 환경을 통합하여 Imaging, Document, Publishing을 포함한 Digital Content Solution Provider로서의 가치를 한껏 높이고 있는 업체이다. 따라서 IBM과는 다른 각도에서 Eclipse-Equinox를 활용하고 있는데, 중점을 두고 적용하는 분야는 바로 Content Management System이다. 다양한 포맷의 컨텐츠들을 관리하고, 공유하고, 컨텐츠 작업들을 효율적으로 팀내에서 협업하는데 중점을 둔 솔루션에 Eclipse-Equinox을 적용하여 시장에 선보이고 있다. 대표적인 솔루션으로는 Adobe Version Cue가 있다. 
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 11월호에 실린 기사입니다]
Equinox OSGi는 향후 어떻게 발전되어 나갈것인가? 현재 OSGi Alliance의 개발 로드맵을 살펴보면 Equinox OSGi는 임베디드에서 모바일과 PC환경을 넘어 엔터프라이즈 환경으로 성공적인 확장과 발전을 목표로 하고 있다. 우선적으로 Equinox OSGi는 Eclipse에 탑재됨으로써 PC 환경으로 확장해 나가는데에는 성공하고 있는듯하지만, 궁극적으로 Univesal Framework 또는 Platform으로 발전하기위해서는 Eclipse-Equinox가 Server-side Platform으로 자리매김해야 가능하다. 현재 이러한 흐름에는 IBM, BEA, Apache, Spring 등의 업체가 참여하여 자사의 제품에 Eclipse Equinox를 탑재하는 프로젝트가 진행중이거나 이미 부분적으로 상용화되어 서비스되고 있다.
지난 3월에 열린 EclipseCon 컨퍼런스의 기조연설에서 Eclipse Foundation 디렉터로 활동하는 마이크 밀린코비치(Mike Milinkovich)는 “이제 OSGi를 둘러싼 IT업계의 지각변동과 S/W업계의 흐름은 올해 2007년을 기점으로 변화될것이라고 생각하고 있다. 이제 Eclipse-Equinox는 신기술의 하나의 중요한 요소로 작용할것이며 향후에는 .Net을 견제하는 가장 이상적인 런타임 환경으로 성장할것으로 확신한다” 라고 말했다. 계속해서 “지난 1999년에 태어난 OSGi는 계속해서 성장하고 있다. 그리고 최근에는 더욱 빠르게 성장하고 있다. 그 증거로 OSGi는 Embedded, Mobile에서 Server Platform으로 급격하게 개발 중심이 변화하고 있으며 최근 1-2년사이에 BEA(mSA, SOA360), IBM(Lotus. WebSphere, Tivoli), Oracle(Fusion), Red Hat(JBoss), Spring(Interface21) 등의 업체에서 다양한 OSGi 기반의 솔루션이 출시되고 있는 것이 그 사실을 증명해주고 있다”
한편 Eclipse-Equinox 개발의 주역 Jeff McAffer은 “Eclipse-Equinox를 굳이 중요하다고 말하고 싶지않다. 그러나 생각해보라. 지금 현재에도 전세계 수백만대의 PC에서 Eclipse가 구동되고 Eclipse를 통해서 많은 개발자들이 S/W를 개발하고 있다. Eclipse가 구동될때마다, 로딩될때마다 Equinox OSGi는 실행되고 있다. 불과 1-2년사이에 벌어진 일이다. 과거 OSGi가 이렇게 수많은 PC에서 실행되리라고는 아무도 생각을 하지못했다” 그는 향후 Eclipse-Equinox의 중요한 개발 이슈를 Provisioning system을 꼽았다.
“향후에는 원격에서 다양한 컨텐츠들과 서비스 기능들을 쉽게 업데이트하거나 관리, 운영하려는 요구사항들이 나올것입니다. 시공간을 초월해서 다양한 서비스들을 플랫폼과 하드웨어 디바이스에 무관하게 즉각적으로 제공할 수 있는 기능이 반드시 필요합니다” 현재 이러한 Provisiong 기능은 Eclipse의 Update Manager 가 있고, 상용화 솔루션으로는 IBM사의 Tivoli Manager를 통해서 서비스되고있다. 하지만 Update Manager 기능을 넘어서는 Provisioning Framework로서의 확장성이 요구되고 있고, 이러한 신규 개발 프로젝트는 Eclipse-Equinox Incubator를 통해서 진행중이라고 하였다.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 11월호에 실린 기사입니다]
5. Equinox Server
Equinox OSGi는 일반적으로 임베디드 시스템이나 PC 애플리케이션에서 사용되지만, 점차 서버로서의 기능을 확장해 나가고 있다. 대표적으로 http같은 웹서버, JSP 또는 Servlet 컨테이너들이 있으며 점차 그 영역을 확장하여 Application Server로서의 가능성을 보여주고 있다. 많은 애플리케이션 서버들이 Equinox 상에서 구현되고 있으며, 대표적으로 Jetty, Jasper들이 있고, 그 외에도 다앙한 API 패키지로 구현되어 수행된다. 이렇게 처음부터 설계되고 구현된 번들이 아닌, 다른 서드파티에서 구현된 서버들을 API 패키지로 구현할경우에는 별도의 전용 repository가 존재하여 모든 관리를 담당하게 된다. 바로 Orbit 프로젝트가 그것이다. Orbit 프로젝트의 목적은 다양한 번들의 버전 관리를 담당하는 것인데, 일반적으로 다른 서드파티의 API 라이브러리들을 Equinox의 번들화시켜서 관리하는 경우를 뜻한다. 이렇게 별도의 번들 관리가 필요한 것은 원본격이 되는 다른 서드파티에서 API 라이브러리들을 업데이트하게되면 함께 같이 버전에 대한 관리가 필요하기 때문이다.
5.1 Equinox Server Architecture
일반적으로 Equinox Server의 기능은 http 서버와 Servlet, JSP를 수행하는 컨테이너 기능이 있으며, 두가지 방법으로 서버를 구동할 수가 있다.
1) Servlet Container와 Equinox 연동 : servletbridge를 통하여 Equinox Bundle과 기존의 서블렛 컨테이너간의 연동으로 서블렛 수행
2) Equinox에 내장된 http Server 구동 : 우선적으로 권장하는 방법이다. Equinox에 최적화된 http service 번들을 활용하는 방법으로 가장 적은 메모리를 사용하여 서비스한다. 우선 Equinox에서는 2개의 서비스 번들을 제공하는데, org.eclipse.equinox.http 과 org.eclipse.equinox.http.jetty 이다.
Equinox.http는 Servlet API 2.1까지 지원하지만 안정적이면서 가장 작은 메모리를 사용하는 장점이 있고, Equinox.http.jetty는 다소 많은 메모리를 사용하지만 Servlet API 2.4까지 지원하는 장점이 있다.
Equinox server에서 JSP, Servlet을 사용하려면 2가지 방법이 있는데...
1) org.eclipse.equinox.http, 2) javax.servlet, 3) org.eclipse.equinox.http.registry 3개의 번들을 실행하거나
Jetty를 활용하여 1) org.eclipse.equinox.http.jetty, 2) org.eclipse.equinox.http.servlet, 3) org.mortbay.jetty, 4) org.apache.commons.logging 5) javax.servlet, 6) org.eclipse.equinox.http.registry 6개의 번들을 로딩하면 된다.
따라서 메모리와 하드웨어 성능이 여유가 있다면 jetty를 이용하면되고 그렇치않다면 일반적으로 http를 이용하여 서버 서비스를 수행하면 된다.
5.2 주요 Server-Side Bundles
대부분 HTTP service와 JSP, Servlet을 구동하기위한 Container 기능을 제공하고 있다.
HTTP service, HTTP registry, Servlet Bridge, HTTP Servlet, HTTP ServletBridge, Servlet API, Servlet JSP API, Jetty, HTTP Jetty 등이 있으며 특별히 ServletBridge 기능을 통하여 기존의 애플리케이션 서버와 인터페이스할 수 있는 확장된 기능을 선보이게 되었다
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 11월호에 실린 기사입니다]
4. Equinox Incubator
Equinox Incubator를 실시하는 가장 큰 목적은 Eclipse Platfrom의 확장과 신기술 확보에 대한 실험적 프로젝트 구현이다. 또한 실질적인 프로젝트 수행의 세부적인 가이드라인은 개발하고자하는 프로젝트의 결과물이 실제 개발자들이 Eclipse Platform상에서 개발시 유용성에 도움이 되거나 또는 다양한 수행환경을 테스트할 수 있는 것이어야 한다. 무엇보다 신기술의 습득이라고해서 실제 적용되는 환경에 너무 무관할수 없다는 이야기이다. 가장 큰 이슈는 Equinox Incubator 를 통해서 나온 결과물이 실제적이고(Practical) 유용하게(Applicable) 적용가능한 솔루션이나 서비스 기능이 제공되어야 한다. 여기에서 수행되는 모든 프로젝트 결과물은 반드시 Equinox OSGi에서만 사용되는 것은 아니다. 오픈 소스이기에 다른 OSGi 환경에서도 사용할 수가 있다.
4.1 주요 프로젝트
1) AspectsJ : AOP(Aspect-Oriented Programming)를 자바 환경에 적용하는 연구 프로젝트
2) Resource Monitoring : Equinox OSGi 환경에서 수행되는 모든 번들들의 상태, 메모리, 통신 들의 모니터링하는 Framework을 구현하는 프로젝트
3) Security : Eclipse Equinox OSGi 하에서 자바 보안 모델과의 유연한 통합을 목표로 하는 프로젝트이다. 지금까지 OSGi 환경에서는 보안 모델을 자바의 메커니즘에 전적으로 의존했는데, Framework을 넘어서 RCP 또는 Server Platform으로 확장을 하는 경우에는 보다 강력한 보안모델이 필요하게 되었다.
4) Server Side OSGi : Equinox OSGi를 Enterprise 환경으로 확장하기 위한 다양한 시도들중의 하나이다. 기존의 서버에 탑재된 Framework과의 유연한 연동 및 통합 방안을 이슈로 하고 있다. 그들중의 하나가 바로 Spring/OSGi 이다.
5) Provisioning : 실시간으로 다양한 컨텐츠를 하드웨어 디바이스와 플랫폼에 독립적으로 관리할 수 있는 기능을 목표로 한다. 기존의 Update Manager를 대체하면서 보다 강력한 기능으로 선보일 예정이다. IBM에서 Tivoli Update Manager를 이미 서비스하고 있다.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 11월호에 실린 기사입니다]
3. Equinox Bundles
Equinox Bundles Component들은 OSGi의 다양한 서비스와 기능을 제공하는 모듈로서 가장 기본적인 실행 단위이다. 과거 Eclipse의 다양한 플러그인 형태의 모듈들이 번들 형태로 변환되어 개발되거나 제공된다. 현재 Equinox Bundles에 대한 SPEC 제정과 관리는 OSGi Alliance의 MEG(Mobile Expert Group)와 VEG(Vehicle Expert Group)에서 각각 기능별로 구분하여 담당한다.
3.1 주요 Bundles
1) Application Container (org.eclipse.equinox.app)
가장 기본적인 애플리케이션 번들로, MEG에서 제정한 애플리케이션 컨테이너 서비스이다.
2) Common Utility Bundle (org.eclipse.equinox.common)
Eclipse에 의해서 자주 호출되어 사용되는 상태 모니터링, Asset 체크 등의 유틸리티 클래스 라이브러리이다.
3) Config Admin (org.eclipse.equinox.config)
OSGi R4 스펙에 의해서 구현되는 Configuration Admin service 이다.
4) Device Access Service (org.eclipse.equinox.device)
OSGi R4 스펙에 의해서 구현되는 Device Access service이다. 자동적으로 추가 및 삭제되는 하드웨어 디바이스 탐지 및 그에 해당하는 디바이스 드라이버를 자동적으로 탐색하고 다운로드하는 기능을 제공한다.
5) Event Admin Service (org.eclipse.equinox.event)
번들간의 커뮤니케이션 통신 메커니즘을 제공한다. 구독과 발행의 이벤트 모델을 따라서 수행
7) HTTP Service (org.eclipse.equinox.http)
OSGi R4 HTTP service. HTML 및 Java servlets을 실행한다.
8) Log Service (org.eclipse.equinox.log)
OSGi 환경에서 일어나는 모든 로그인 상태 분석 및 관리 기능
그 외에 Metatype Service, Preferences Service, Extension Registry, Supplemental Bundle/JAR, User Admin Service, OSGi Services API, OSGi Utilities 기능의 번들들이 제공된다
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 11월호에 실린 기사입니다]
2. Equinox Framework
Equinox Framework Component는 OSGi Core Framework R4 spec에 충실하게 구현된 코드이다. 크게 3가지로 구분되는데, 번들을 실행하는 Launcher와 bootstrap infrastructure를 수행하는 Boot support 그리고 마지막으로 번들을 수행하고 관리하는 system framework로 이루어져 있다. 아래의 Framework code들은 모두 Eclipse CVS repository에 정리되어 있다.
- OSGi R4 Framework (org.eclipse.osgi) : Eclipse Equinox의 가장 기본이 되는 main framework이다. 본 framework를 빌드하면 org.eclispe.osgi.jar가 생성된다.
- Boot Support (org.eclipse.equinox.boot) : Eclipse가 구동될 때 framework classloader이 셋업되고 개발 및 운영환경이 안정적으로 수행하는 것을 지원한다. 현재까지는 org.eclipse.osgi 이나 org.eclipse.equinox가 아닌 org.eclipse.platfrom 프로젝트에 속해있고, 수행파일은 startup.jar 이다.
- Native Launcher (platform-launcher) : 실제 수행하는 환경으로 startup.jar 파일을 수해ㅑㅇ시키고 그 결과로 framework이 로딩되어 수행된다. 본 모듈은 C로 작성되어 있으며 Windows, Unix, Linux, MacOS 등의 다양한 플랫폼과 하드웨어의 사양에 맞게 각각의 버전이 존재한다.
Equinox Framework 파일은 Eclipse에서 직접 Import하여 패치하거나 수정할 수가 있는데, Eclipse 메뉴에서 Import > CVS > Projects from CVS를 선택하여 CVS에 있는 코드들을 불러올수가 있다.
[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 11월호에 실린 기사입니다]
1.4 도약하는 Equinox OSGi
한편 OSGi Alliance 입장에서 OSGi 발전 가능성과 미래를 예측해 본다면 Eclipse가 OSGi를 선택하면서 가져다 준 장점이 있다면 무엇일까? 우리는 지금까지 Eclipse가 OSGi를 탑재하면서 갖게되는 장점들만을 살펴봤다. 그러나 Eclipse가 OSGi를 탑재해서 과거와는 완전히 다른 아키텍쳐를 가지고 하나의 플랫폼으로 확장한 것은 사실이지만, OSGi Alliance 입장에서 본다면 Eclipse 못지않게 많은 장점을 가져다 준 것 또한 사실이다. 가장 큰 장점은 바로 브랜드 파워, 마켓에서의 힘이다. 과거 OSGi가 임베디드 시스템에서 안정적인 Dynamic Module 시스템으로 명성을(?) 날렸던 것은 사실이다. 그러나 그것은 어디까지나 한정된 분야 – 홈게이트웨이, 셋탑박스, 그리고 소수의 스마트폰 였고 또한 임베디드 시스템 전체에서 보면 자바가 탑재되는 일부에 지나지 않았다. 사실 임베디드 시스템에서는 여전히 RTOS에 C 개발환경에 API Library, Device Driver 그리고 프로세스로 작동되는 구조가 다수인 현실에서 OSGI는 시스템 전체에서 본다면 그야말로 소수의 선택된 개발자들만의 Framework였던 것이다. 그러나 Eclipse는 다르다. 모바일, 임베디드 등의 다양한 디바이스와 플랫폼이 탄생했다할지라도 여전히 개발환경에서 Main Stream은 Server-side와 PC client 인것은 사실이다. PC에서 개발하는 개발자들에게 Visual Studio를 사용하지 않고도 C/C++, Java등의 개발환경과 PHP, Perl, Python 등의 스크립트 통합 환경을 제공하고 컴파일-디버깅-버그 트랙킹-소스관리 등의 개발 프로세스를 Eclipse라는 툴에서 제공한다는 것은 매우 강력한 어필임에는 틀림없고(더구나 무료이다), OSGi와는 비교하지못하는 충성스러운 수백만명의 개발자와 브랜드 파워를 가지고 있는 것이다. 그런 Eclipse가 대대적으로 변하는 새로운 버전 3.0에 핵심으로 탑재된 런타임 환경이었으니 OSGi를 몰랐던 개발자들에게 다가왔던 충격과 관심은 가히 폭발적이었다. 물론 개발자들이 갖는 관심과 실제 Equinox OSGi를 사용하여 구현하는 것으 다르지만, 이제 Equinox OSGi는 단순히 Ecliupse에 탑재된 하나의 기능이 아니라 Equinox OSGi를 몰라서는 더 이상 Eclipse 플렛폼에서 개발할 수 없는 단계에 까지 이르게 된것이다.
[그림 7. Eclipse-Equinox Target Service Model]
단순히 임베디드의 특수한 환경에서 인정받았던 하나의 OSGi Framework이 단번에 S/W 업계의 Main Stream으로 진출하는 계기와 브랜드 파워를 갖게된것이다. 이로 인해서 OSGi Alliance는 전문가 그룹이 3개에서 4개로 확장되고, SPEC 또한 R3에서 R4로 급격하게 업그레이드 되게 된다. 이렇게 OSGi가 임베디드에서 모바일, PC, Server 환경에 까지 확장되고 급속하게 발전하는 기술의 트랜드에 적절하게 버전 업그레이드로 대응되는 이러한 일련의 과정들이 Equinox OSGi가 탄생하고 Eclipse에 탑재되면서 나타나게 된 대표적인 장점일것이다. 또 다른 장점은 OSGi가 가지고 있던 시스템 아키텍쳐와 개발 프로세스들이 S/W업계에 널리 펴져나가게 된것이다. 이제 이클립스가 보유하고 있었던 다양한 오픈소스 기반의 플러그인들은 Equinox OSGi 번들 형태로 개발되게 된다. Equinox OSGi의 가장 큰 장점인 가볍고(light) 동적인(dynamic) 모듈 시스템 형태의 번들로 개발되면서 Equinox OSGi가 구현된 OSGi R4 SPEC은 S/W 업계의 대표적인 표준 요구사항이면서 개발 프로세스의 트랜드를 주도하게 될것이다. 물론 Equinox OSGi가 완전한 Framework은 아니다. 여전히 발전해야 할 부분이 많이 남아있다. 대표적으로 핸드셋으로 대표되는 Mobile 시스템 지원과 Enterprise 환경에서 Server-side Framework로 자리잡는 부분이 현재 가장 큰 이슈이다. 이러한 부분은 J2ME의 CLDC 환경의 발전과 또한 대표적인 Server Framework “Spring”과의 OSGi 통합등으로 현재도 계속해서 발전해 나가고 있다.
[그림 8. Eclipse-Equinox 실행환경]
Equinox OSGi를 살펴보면서 자주 등장하는 인물들이 있다. BJ Hargrave, Jeff McAffer, Thomas Watson이 바로 그들인데, 모두 IBM 출신이면서 Eclipse Foundation, Equinox Project 그리고 OSGi Alliance 에 이르기까지 많은 영향력을 끼치는 사람들이다. 하나 아쉬운 것은 모두 IBM 사람들이라는 것인데, Eclipse Foundation, Equinox Project, OSGi Alliance 모두 IBM이 막강한 영향력을 끼친다는 사실은 개발자로서는 썩 기분이 좋은 일만은 아닌 것 같다. 물론 위의 단체에는 ORACLE, SUN, HP, BEA, MS등의 IT 업체와 삼성, LG, 필립스, 소니, 마쓰시다, 지멘스 등의 전자업체들도 많이 있지만, 그럼에도 불구하고 가장 막강한 영향력을 IBM이 끼친다는 것은 부인할수 없는 사실이다.
1. Jeff McAffer (IBM Rational Software – Senior Staff Member, Head of the Eclipse Equinox Project) Equinox 탄생의 주역. Equinox 프로젝트의 총책임자면서 개발 리더였으며, 또한 Eclipse 설계와 개발에도 초기부터 참여해왔다. Eclipse, Equinox 세미나와 컨퍼런스의 단골 강사이기도 한 그는 캐나다 온타리오에 있는 IBM 연구소에서 근무하였고 현재 Equinox를 통한 Eclipse Platform 확장에 노력하고 있다. 일본 동경대학에서 박사학위를 받은 특이한 경력의 소유자이기도 하다.
2. Thomas Watson (IBM Lotus - System Architect, Lead Developer of the Eclipse Equinox Project) 미국 텍사스의 IBM 오스틴 연구소에서 근무하고 있는 그는 Eclipse Equinox 프로젝트에 참가하기전 IBM OSGi의 과거 버전인 SMF 개발 주역이다. Jeff McAffer과 함께 Eclipse Equinox OSGi 전도사임을 자청하고 있으며, Jeff McAffer가 개발 리더 겸 Staff로 활동하는 것과는 달리 S/W 아키텍트이면서 엔지니어링 파트에 더 힘을 기울이고 있다. Eclipse Equinox 프로젝트에서 Eclipse 환경에 맞는 최적화된 OSGi 디자인을 담당하기도 한 그는 현재 Eclipse Platfrom을 활용하여 신규 시스템을 개발하였다. 바로 그것이 IBM 협업환경 Expeditor인데 그의 대표적인 작품이기도 하다. IBM Expeditor는 Lotus Notes를 Eclipse Platform에 결합하여 개발한 새로운 비즈니스 애플리케이션으로 IBM에서 차세대 솔루션으로 가장 기대를 많이 하고 있는 실시간 기업용 솔루션이다. 위에서도 이야기했듯이 Eclipse 또는 Equinox OSGi 세미나나 컨퍼런스에 가면 항상 볼수있는 인물들이다.
3. BJ Hargrave (IBM Software Group - Senior Staff Member, CTO of OSGi Alliance) 미국 텍사스의 IBM 오스틴 연구소에 근무하면서 동시에 2002년부터 OSGi Alliance에도 Lead 엔지니어로 일하다가 현재는 CTO의 중직을 담당하고 있다. 과거 IBM에서 18년간 S/W 아키텍트와 엔지니어로 근무한 경력이 있으며 주로 임베디드 시스템의 커널과 운영환경에 관심을 갖고 일해왔다. 위의 두 사람과는 다르게 OSGi 자체에 많은 관심을 가져왔는데, Eclipse에 OSGi가 탑재되면서부터 자연스럽게 OSGi Alliance와 Eclipse Foundation 모두에 영향력을 끼치게 되었다.
/// 본 원고는 2007년 마이크로소프트웨어 11월호에 실린 원고입니다. 참조하실때에는 출처를 밝혀주시기바랍니다
PART-I. Equinox Overview
일반적으로 OSGi Framework를 이야기하면 주로 홈네트워크 게이트웨이, 셋탑박스등의 임베디드 시스템을 떠올리곤 한다. 그러나 그것은 이제 옛날 이야기가 되어버렸다. 홈게이트웨이의 임베디드 시스템에서의 Middleware Framework로서 입지를 다지면서 이제는 그 영역을 Platform으로 확장해 나가고 있다. 그 중심에는 바로 Eclipse-Equinox가 자리하고 있다. 무엇이 OSGi를 Mobile-Embedded-PC Platform-Enterprise에 이르는 포괄적인 영역으로 확장을 가능케 했는지, 그리고 Eclipse-Equinox가 무엇인지 이제부터 살펴보기로 한다.
1.1 Equinox란 무엇인가?
Equinox는 단순히 구현의 관점에서 본다면, OSGi R4 core framework specification을 근간으로 구현된 코드이다. 이러한 점은 여타의 다른 OSGi 제품들과 다를 바가 없다. 그러나 곧 Equinox가 다른 여타의 OSGi와 다른 점이 무엇인지 알게되는데, 그것은 바로 플랫폼으로 확장된 OSGi라는 점이다. Equinox는 (이쿼넉스-라고 발음된다) 기본적으로 다른 OSGi처럼 Framework, Bundle이 존재하지만 또한 Incubator, Server-Side Project로 통한 다양한 서비스 아키텍쳐, 서버, 서버 프래임워크 모듈로 확장되어 Eclipse 기반의 개발 플랫폼 일부분으로 사용된다. 혹시 여러분은 IBM의 Expeditor, Adobe의 VersionCue, Rational의 S/W 개발툴을 본 적이 있는가? 더 나아가 사용해본적이 있는가? 그들 모두 Eclipse-Equinox 기반의 플랫폼에서 최적화된 컨텐츠와 가능들을 가지고 태어난 제품들이다. 마치 윈도우 기반의 애플리케이션과 시스템 아키텍쳐가 .Net Fremework위에서 COM모듈로 쉽게 개발되고 하나의 고유한 프로세스와 GUI위에서 운영되는것처럼 이제 Eclipse Platform은 MS .Net Fremework에 맞서 하나의 플랫폼으로 발전해 나가고 있으며(물론 아직 .Net Framework에 비해서 미진한 부분이 많은 것이 사실이다) 그 핵심에는 바로 Equinox OSGi가 자리잡고 있다. [그림 1. Eclipse-Equinox Architecture]
1.2 Equinox의 역사
Equinox는 2004년 Eclipse Foundation의 요청에 의해서 Eclipse 3.0에 탑재되어 세상에 처음으로 선보이게 된다. 이때의 Eclipse는 버전 2.1에서 3.0으로 업그레이드가 되었는데 단순히 1.0이 버전업되는 것보다 훨씬 더 많은 변화를 가져왔으며, 바로 그것이 Equinox의 탑재였다. 이전에는 수많은 기능들이나 모듈들이 플러그인 형태로 다운로드 되거나 인스톨되었는데, OSGi기반의 번들 형식으로 변경되어 재설계되고 Dynamic Module 시스템으로 제공된것이다. 이미 2003년초 Eclipse Foundation은 단순히 Eclipse를 통합된 하나의 IDE가 아닌 RCP(Rich Client Platform)로의 확장을 목표로 전체적인 시스템 아키텍쳐의 재설계를 가져가게 된다. 그때 바로 OSGi Framework 기반의 구조가 논의끝에 설계되었고, 탑재된 제품은 IBM의 SMF 3.x를 근간으로 Eclipse에 최적화된 Equinox가 탄생하게 된다. Eclipse 최적화 기간은 약 18개월정도였으며 이때 하나의 Framework로 선택된 SMF-OSGi가 Equinox로 재탄생하여 RCP, JDT, PDE 기반의 Eclipse Platform의 핵심 컴포넌트로 탄생하게 되었다. 초기 Equinox는 OSGi R3를 기반으로 하고 있었으나 현재 R4 SPEC으로 버전업되었고, 현재에도 OSGi Alliance의 VEG(Vehicle Expert Group), MEG(Mobile Expert Group)와 협의하에 지속적으로 발전해 나가고 있다. Eclipse Equinox Project에는 몇가지 특징적인 요소들이 있었는데, 프로젝트의 산실인 Incubator 활용, Open Source Community 지원, 그리고 마지막으로 신기술의 개념 도입 등이 그것이다. 우선 Equinox를 구현하기위해서 많은 OSGi 및 Eclipse 오픈소스 단체 및 동호회에 개발인력을 구하였고 SPEC을 선정하면서 요구사항에 도움받았으며, 이러한 개발의 집합체 및 통로로 Incubator를 활용하였다. Incubator는 말그대로 산실의 의미를 가지게 되는데, 현재 Equinox가 개발된 이후에도 여전히 Incubator를 통해서 많은 서비스 번들과 프로젝트들이 수행되고있다. 한편 신기술과 신개념 도입은 AOP(Aspect Oriented Programming)를 Java에 접목한 AspectJ와 Security 부분을 Incubator를 통하여 동시에 추진하였다. 이러한 특징들은 하나의 회사나 벤더가 독립적으로 개발할 때 나타나는 현상과는 다른 측면으로 공동의 광범위한 오픈소스의 지원과 빠르게 변하는 신기술의 적극적인 대응에 부합된다고 볼수있다.
[그림 2. OSGi 개발 로드맵]
1.3 Eclipse의 선택
Eclipse는 무엇 때문에 OSGi를 선택하게 되었을까? 아니 어쩌면 그보다 왜 Eclipse는 2.1에서 3.0으로 급격한 변화를 해야했으며 그 당시 가지고 있었던 고민들이 무엇인지 살펴볼필요가 있다.
지난 2006년 10월 덴마크에서 열린 JAOO Conference에서 “The OSGi Foundation for Eclipse” 라는 주제로 발표했던 Jeff McAffer는 “그 당시 Eclipse Foundation에서는 전세계 S/W Market의 흐름을 눈여겨 보고 있었다. Eclipse의 발전을 신기술의 도입에 초점을 둔 것이 아니라 시장의 흐름과 고객의 요구에 모든 우선순위를 두고 있었다” 라고 하였다. 과연 Eclipse에서 보았던 S/W 시장의 문제점과 고객들의 불만, 요구사항은 무엇이었을까? 그것은 다음과 같이 몇가지로 요약할 수가 있다.
1) The Limited Binary Software Portability Problem (이식성 또는 재사용성의 문제점) : 이식성과 재사용성은 이전부터 많이 회자되는 이슈였고, 또한 그것을 해결하기위해서 컴포넌트, 재사용성에 대한 도구, 툴들이 많이 시장에 발표되었으나, 여전히 그것에 대한 시장은 크지않았고 사용자들은 재사용성과 이식성에 대한 불만을 가지고 있었다. 더욱이 과거 PC기반의 S/W가 대부분이던 시절에서 모바일-임베디드-PC-서버에 이르는 다양한 하드웨어와 플랫폼 환경이 나타나기 시작하였으며 사용자 환경도 윈도우에서 리눅스, 웹이라는 환경들이 점차 확산되는 실정이었다. 이러한 개발 및 사용자 환경에서 향후 개발된 S/W의 이식성과 재사용성, 다양한 플랫폼의 지원은 더욱 더 중요한 요소로 작용할것이 분명하다고 예측하였다. [그림 3. 증가하는 S/W 복잡도]
2) The Complexity of Building Heterogeneous Software Systems (소프트웨어의 복잡성) : 날로 증가하는 S/W 코드는 매우 심각할정도이다. 일반적인 DVD 플레이어는 백만라인의 코드를 가지고 있고, BMW의 신규 차량은 50여개의 디바이스가 네트워킹되어 제어 및 관리가 되고있으며(그것 모두 S/W로 구현되어있지 않은가?) 심지어 Eclipse 2.x 에도 2백5십만 라인의 코드가 담겨져있다. 어떻게 보면 이러한 코드의 급격한 증가는 OOAD, OOP의 한계에서 찾을 수가 있을 것 같다. Object 개념은 심플하고, 재사용성에 분명 장점이 있으나 최근 두드러지게 나타나는 네트워크를 통해 연동되고, 함께 운영되는(Collaboration) 환경에서는 오히려 그 장점이 퇴색되게된다. 다양한 서비스들은 요구하게되는 시스템에서는 Loose-coupled 된 인터페이스가 더욱 효율적이나 현재의 OOP에서는 오히려 오브젝트간의 복잡성을 증가하고 그 결과로 자연히 코드의 수가 늘어나게 된다. 또한 오브젝트간의 유연한 Flexibility도 Plug-in 형태의 구조로 개발자가 직접 정의하고 구현해야하는 상황에 이르게 되었다.
3) Managing the Software Life-Cycle (효율적인 소프트웨어 관리의 문제점) : 최근 오픈소스와 인터넷의 발달로 과거와는 비교할수없을정도로 빠르게 버전업과 디버깅, 그리고 패치가 이루어지며, 다양한 플랫폼에서 인터넷을 통하여 실시간으로 요구사항과 기능들이 추가되고 수정된다. 따라서 과거의 업그레이드 방식과는 다르게 원격에서 실시간으로 동적인 시스템 업그레이드 및 관리 형태가 요청되는 시대가 되었다.
이러한 문제점들과 사용자들의 요구사항을 분석한 Eclipse Foundation에서는 해결방안으로 몇가지 특징과 솔루션, 아키텍쳐들을 설계하게 되는데, 그 당시 새로운 시스템으로 설계시 필요한 요구사항은 크게 4가지였다. 가장 중요한 요소로 Reliability, Large Scale Distribution, Wide Range of devices, Collaborative 등을 정의하고 이것을 구현하기 위한 기술적인 대안으로 SOA, Framework, Dynamic Module를 선택하게 된다.
그렇다면 그것은 과연 무엇을 뜻하는가? 바로 OSGi의 특징과 일치한 부분이 매우 많지않은가? 이러한 분석과 결과로 Eclipse Foundation은 1999년부터 개발되고 발전되어 온 OSGi를 Eclipse의 기본 Framework로 탑재할것을 결정하게 된다. 그 후로 SMF를 통해서 OSGi 솔루션에서 선두주자인 IBM에 기술 지원을 요청하게 되고 자연스럽게 Eclipse로의 통합이 이루어지게 된다 (물론 어쩌면 이것은 당연한 결과였는지도 모른다. Eclipse 역시 IBM에서 개발되어 오픈소스로 공개한 개발툴이고 오픈소스로 공개되었다할지라도 여전히 Eclipse Foundation에서 가장 강력한 힘을 발휘하고 있는 것 역시 사실이다. 마치 SUN에서 Java를 오픈소스로 공개하고 JCP를 통하여 관리하고 있지만 여전히 SUN이 Java 세계에서 가지고 있는 무소불위의 힘은 무시할 수가 없는 것과 마찬가지 이치인것이다) 암튼 이렇게해서 IBM은 Eclipse에서 Equinox까지 이르는 개발툴과 Framework를 자연스럽게 통합하여 하나의 거대한 Platform으로 발전시키는 중요한 역할을 담당하게 된다.
[그림 4. Eclipse-Equinox Service Architecture]
한편 좀 더 자세하게 Eclipse에서 OSGi를 탑재한 이유들을 살펴보면 위에서의 문제점을 분석하고 그 해결방안으로 제시하게 되는 데, 지난 2005년 IBM Systems Journal에 실린 “The Eclipse 3.0 Platform – Adopting OSGi Technology” (O.Gruber, B.J. Hargrave, J.McAffer, T.Watson) 에서는 다음과 같이 설명하였다. Reliability, Large Scale Distribution, Wide Range of devices, Collaborative의 요구사항에 SOA, Framework, Dynamic Module의 기본적인 아키텍쳐를 제시하고, 이제는 확실하게 OSGi 입장에서 기능과 장점들을 기술해놓고 있다.
[그림 5. Eclipse-Equinox System Architecture]
1) Extensible : 확장성을 가장 높은 우선순위에 두고 있다. 대단히 정확한 지적이다. 단순히 하나의 개발툴에서 개발환경(PDE), 플랫폼(RCP)으로 발전하기위해서는 단순히 플러그인을 다운로드하여 기능을 추가하는 것에 그쳐서는 안된다. 새로운 Application, Framework 심지어 Server로서 확장이 가능해야 할것이다.
2) Light, Dynamic Module : 빠르고 다양한 기능과 컨텐츠 심지어 서버들을 실시간으로 원격에서시스템의 중단없이 추가, 업데이트 할 수 있는 관리 기능이 필요하며 가능해야 할것이다. 또한 네트워크도 유/무선 통합된 환경이어야하므로, 가볍고 코드가 작아야 한다.
3) Platform Independence : 단순히 윈도우, 리눅스 환경의 문제가 아니다. 모바일-임베디드-PC-서버에 이르는 다양한 하드웨어와 O/S가 있기에 그 위에서 운영되는 플랫폼에 독립적으로 컨텐츠가 운영되고 서비스가 사용되어야 한다.
[그림 6. Eclipse-Equinox Platform Build]
4) Rich Eco Systems – Open Source Community : 오픈소스 단체와 지원을 최대한 빠르고 정확하게 수용할 수 있는 구조와 프로세스가 정립되어 있어야 한다. 빠르게 발전하는 기술과 트랜드를 적절히 대응하기 위해서는 오픈소스의 활용을 최적 극대화 해야만 한다.
5) Native Look and Feel – 윈도우만의 환경이 아니기에, 다양한 플랫폼과 디바이스에 적용될수있는 그리고 직관적으로 사용자들에게 경험되고 다가갈수있는 GUI가 필요하게 될것이다. 하나의 프로세스와 직관적인 경험이 플랫폼과 디바이스에 독립적으로 사용하게 해야할것이다
