[작성 - 김석우, dolbi / 본 원고는 마이크로소프트웨어 2007년 11월호에 실린 기사입니다]

1) IBM : IBM은 Eclipse-Equinox가 존재하는 가장 큰 근거를 남진 업체이다. 또한 반대로 IBM이 추구하는 전략 – Pervasive Computing, Business On-Demand에 가장 큰 수확을 거둔 업체이기도하다. IBM은 자사가 개발에 착수하여 키운 두개의 제품(Eclipse, SMF-OSGi)를 오픈소스로 공개하였고, 그것에 그치는 것이 아니라 오픈소스 업계에 막강한 영향력을 발휘하여 Eclipse-Equinox를 하나의 거대한 플랫폼으로 발전시키는 쾌거를(?) 이루어 내었다.

Eclipse-Equinox를 탑재한 IBM Solution 라인업

일단 이렇게 S/W 업계에 하나의 커다란 흐름을 만든 IBM은 그 흐름을 빠르게 자사의 솔루션에 흡수하여 시장과 기술 모두 선두업체로서의 입지를 곤고하게 다지는 결과를 만들어 내었다. IBM은 Eclipse-Equinox을 기반으로 협업 솔루션 Lotus Domino를 Sametime, Expeditor로 새롭게 변신하여 선보였고, 대표적인 WAS – WebSphere에 적용하여 Websphere Application Server로, 시스템 운영 솔루션인 Tivoli Provising Manager, 그리고 S/W 개발툴과 프로세스 솔루션인 Rational 전체 S/W Platform에 적용하여 고객들에게 제공하였다. 전세계 IT, S/W 개발업체를 모두 통틀어서 이렇게 자사의 전체 솔루션 라인업체 적용한 사례는 매우 드물다.

IBM - Tivoli Provision Manager

이러한 사례는 IBM이라는 업체가 오픈소스와 그를 지원하는 많은 커뮤니티들을 단순히 신기술 발표의 장으로, 아니면 하나의 트랜드로 보는 것이 아니라 자사의 비지니스 전략에 핵심요소로 작용하고 있음을 보여주는 대표적인 사례인것이다.

IBM - Lotus Expeditor

IBM의 이러한 솔루션 사업 전략은 결과적으로 Eclipse-Equinox의 Universal Platform의 확장에 큰 기여를 할것으로 예상된다. Embedded 및 Mobile 환경에서는 Eclipse-Equinox run-time 모듈로 별도 공급하고 있고, PC 애플리케이션과 RCP 에서는 Eclipse-Equinox를 기반으로 하는 솔루션을, 비즈니스 애플리케이션과 협업, 메시징 시스템에서는 Lotus Expeditor를, Enterprise 환경에서는 Websphere Server와 Tivoli Solution을 제공하고, 전 개발 프로세스에서는 Rational 솔루션을 지원하는 전 분야에 걸친 방대한 Eclipse-Equinox 기반의 솔루션과 시스템을 제공하고 있다. Eclipse-Equinox의 발전과 확장에 가장 큰 기여를 한 업체가 IBM인 것은 사실이지만, 그 결과로 오픈소스인 Eclipse-Equinox를 통해서 가장 큰 이득과 수혜를 본 업체 역시 IBM이라는 것을 부인할 수는 없다.

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가 있다.

Adobe - VersionCue Front View

3) Apache : 웹서버로 유명한 오픈소스 단체 아파치는 Eclipse-Equinoxfmf 활용하는 것이 아니아 직접 OSGi SPEC를 구현하고 또한 주로 서버 환경에 적용하고 있다. 대표적으로 OSGi 구현 시스템인 Apache-Felix가 있으며 JSE 5.0기반의 Harmony, Cocoon, James, Geronimo 등이 있는데, 상용화 솔루션으로 개발되기보다는 오픈소스의 성격에 맞게 서버환경에 적용하거나 신기술 도입 측면에서 구현되는 성격이 강하다. 따라서 Apache 단체에서 성공적으로 구현된 프로젝트들은 다른 서비스 업체들에게 모듈이나 런타임 기반으로 제공되는 경우가 많다. 여기서 짚고 넘어갈 부분은 Apache 단체가 무엇 때문에 Eclipse-Equinox 같은 플랫폼 또는 런타임 환경에 관심을 가지고 많은 프로젝트들과 성과물을 개발했는지 전략들을 주의깊게 살펴볼 필요가 있다.

[작성 - 김석우, 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 기능을 제공하고 있다.

[작성 - 김석우, 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]

[그림 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 모두에 영향력을 끼치게 되었다.