본 원고는 필자가 2008년 1월호 마이크로소프트웨어에 기고한 내용입니다. 자료를 옮기시거나 사용하시려면 출처를 밝혀주시면 됩니다.

자바의 플랫폼에 대한 부분과 표준화 방식에 대해서 이야기 한 것은 JSR 277에 대한 부분을 이야기하기 위함이다. 자바는 JSR, JCP, RI등을 통해서 스펙이 결정되고 발전하는 과정을 거쳐간다. 이미 자바는 JAVA7이라는 새로운 플랫폼 규격을 선보이고 있는데, 그중에서 눈에 띠는 부분이 바로 JSR 277이다. 자바 모듈 시스템이라는 새로운 규격은 자바의 모듈성을 강조하는 새로운 시스템이다. 다만 우리는 OSGi라는 미들웨어 프래임워크를 알고있기에 JSR 277이 OSGi라는 아키텍쳐를 그대로(?) 모방했음을 쉽게 짐작할 수가 있다. 썬에서도 JSR 277은 JSR 291-OSGi 규격과 서로 상호호환하고 경쟁하면서 발전해 나가야한다고 발표하기도 했는데, 여기에는 매우 복잡하고 미묘한 관계들이 엃혀져 있다. 우선 JSR 277이란 무엇인지 알아보기도 한다. 기존 자바에서는 지원하는 모듈방식을 결정하는 것들은 크게 두가지인데, 논리적인 모듈방식(Logical Modularity)과 실질적인 모듈방식(Physical Modularity)이 있다.

[그림1. Java Logical Module View]

논리적인 방식에는 Classes, Packages, Class Loaders 등이 있으며, 실질적인 모듈방식에는 class file과 JAR file 이 있다. 이러한 모듈방식에는 몇가지 문제가 있는데 다음과 같은 것들이다.

1) 제한된 Scoping Mechanisms

2) 기본적인 그리고 제한된 기능의 버전 관리

3) 모듈간 의존성(Implicit Dependency) 문제

4) 패키지에서의 단순한 Class path 관리

5) 불분명한 Class Space Consistency

결국 이러한 부분들은 자바 플랫폼에서 모듈이라는 실행단위가 명확하게 지원되지못하는 문제에서 기인한다고 결론낼수가 있다. 이에 썬에서는 한정적인 자바 플랫폼 위에서(J2ME) 운영되는 OSGi 모델을 자바 플랫폼내에서 구현하기로 결정한다. 하나의 자바 V M 인스턴스에서 운영되는 멀티 서비스, 번들로 구분되는 다이나믹 모듈 시스템, 번들단위로 실행되는 커스텀 클래스 로더에서 얻어지는 많은 장점 – 클래스 로더간의 연결성, 독립적인 Namespace, 패키지 레벨에서의 클래스 공유 – 등이 더 이상 자바 플랫폼에서 운영되는 하나의 OSGi 프래임워크가 아닌 모든 자바 플랫폼에서 운영되는 다이나믹 자바 모듈 시스템으로 확장되는 계기를 마련해주었다. JSR 277에서 중점은 두고 개발한 부분은 다음과 같다.

1) 버전관리 (Version Management)

2) 배포(Distribution) 및 패키징 (Packaging)

3) 새로운 저장소 (New Repository)

4) 모듈간 공유 및 연결성 (Module Interconnection)

이러한 특징들을 위해서 기존 JAR 포맷을 대신하여 JAM이라는 새로운 포맷을 탄생시켰으며, JSR 294와 연합하여 JSR 277 내부에 VM, Language들을 통합시켜버렸다. JAM이 탄생하기까지에는 기존의 JAR가 가져온 문제점들이 너무나 컸기 때문이다. 현재 자바에서 배포의 표준파일 타입은 JAR인데, 단순한 버전관리, 다른 JAR파일과의 레퍼런스 문제, 복수개의 JAR파일과 Native lib과의 연동 그리고 마지막으로 JAR는 배포와 실행 파일의 포맷을 모두 담당하고 있으면서 문제점들을 계속 노출시켜왔다. 결국 JAR가 내포하고 있는 문제점들이 우리가 위에서 살펴본 JSR 277의 탄생 이유이기도 하다. 또한 기존의 클래스 라이브러리들과 JDK 툴들도 통합시켜 확장된 하나의 플랫폼을 탄생시켰다. 이러한 새로운 플랫폼 규격에 가장 큰 특징은 역시 플러그인 스타일의 다이나믹 구조인데, OSGi 번들구조를 그대로 가져온것이라고해도 무방할정도이다. JSR 277에서는 OSGi의 번들을 모듈(Module)이라고 부르는데, JSR 277과 291(OSGi)간의 비교를 해보도록 하자. 우선 JSR 277, 291 모두에게 적용되는 특징은 다음과 같다. (Module는 Bundle로 생각하면 된다)

• Module name
• Module version
• Module attributes
• Module import
• Module re-export
• Version range
• Optional import
• Executable modules
• One class loader per module
• Platform dependencies
• Classes, native libraries, resources, 확장된 metadata가 포함된 Module
• JAR distribution format
• Reflective API

반면 JSR277만의 고유한 특징도 있는데, 다음과 같다.

• Standard repository : 하나의 래포지터리에서 다양한 복수개의 모듈을 관리한다
• JAM distribution format : 기존 JAR 보다 더욱 강력한 배포 파일 포맷이다.
• Import override policy
• Part of the Java SE platform

결국 JSR 277 자바 모듈 시스템은 자바 파일의 배포와 실행 그리고 버전관리에 보다 중점을 두고 설계된 시스템이며 이러한 시스템은 OSGi의 번들이 다이나믹하게 플러그인 되고 수행되는 구조를 자바에 맞게 최적화된 구조방식이라고 볼수가 있다. 그러나 자바의 한계를 넘지못한 부분도 여전히 눈에 보이는데, 그것은 독자적인 OSGi만의 특징이기도 하다. 이번에는 JSR 277에 포함되지 못한 JSR 291(OSGi)의 고유 특징을 살펴보자

• Dynamic lifecycle support (번들, 서비스) : 다이나믹한 기능은 여전히 OSGi가 탁월하다
• Package import
• Dynamic package import
• Package attributes
• Mandatory attributes
• Split package support
• Module classpath
• Fragment modules
• Extension modules
• Pure Java implemented on top of Java SE
• Compatible with Java ME (JSR 232)

결국 특징들을 살펴보면 새로운 배포파일의 포맷(JAM)이나 모듈간의 연결성, Repository의 지원등 각자 고유한 부분이 있으나, 플랫폼에서의 다이나믹한 모듈 구조의 설계방식은 같다고 볼수가 있다.

본 원고는 필자가 2008년 1월호 마이크로소프트웨어에 기고한 내용입니다. 자료를 옮기시거나 사용하시려면 출처를 밝혀주시면 됩니다.

요즘 임베디드 혹은 모바일 S/W 개발자들사이에 회자되는 이슈는 아마도 구글폰의 안드로이드 플랫폼이 아닌가 싶다. 구글폰에 대한 루머들은 예전부터 나오고 심지어 상상한 모델 디자인까지도 인터넷에서 떠돌기도 했다. 애플 아이폰이 성공적으로 런칭한 뒤에는 더욱 궁금증이 깊어졌는데, 공개된 구글폰은 하드웨어가 탑재된 하나의 디바이스라기보다는 웹2.0을 이끄는 플랫폼의 리더답게 안드로이드(Android) 라는 OHA를 표방한 모바일 플랫폼이었다. 안드로이드 역시 VM 기반의 자바 애플리케이션을 구동한다. 우리가 지난 호에서 살펴본것처럼 이제 모바일 환경에서도 자바 애플리케이션이 실행되면서 지금보다 훨씬 더 다양하고 강력한 서비스들이 우리들을 찾아오게 된것이다.

결국 모바일 시스템에도 본격적인 플랫폼의 시대가 도래된 것이다. J2ME, J2SE, J2EE로 구분되어 있는 자바 플랫폼은 J2SE만 보더라도 1.1에서 1.2로 현대화된 이후로 1.4와 1.5에 이르면서 상당히 큰 변화가 있었음에도 불구하고 계속 1.x의 버전 번호를 고수해왔다. J2SE 1.4는 코어 플랫폼에 있어 가장 많고 중요한 API 추가가 있었고, J2SE 1.5는 자바 언어 자체에 심대한 발전이 있었다. J2EE도 상황은 마찬가지여서 1.2로 시작하여 1.3에서 EJB 2.0으로 크게 도약한 분산 컴포넌트 기술은 1.4에서 웹 서비스 지원의 추가로 날개를 달았지만 여전히 1.x라는 빈약한 버전을 가지고 있었다. 이러한 상황은 J2SE 1.6과 J2EE 1.5부터는 J2라는 약자를 버리고 자바라는 완전한 이름으로 돌아옴과 동시에 1.6대신 6, 1.5대신 5라는 과감한 버전 업그레이드를 단행하게 되었다. 그리고 Java 7으로 또다른 도약을 꿈꾸고 있다. 물론 아직도 여전히 J2SE와 J2EE라는 말은 자바 플랫폼의 대명사로 많이 쓰이고 있지만, 새 술을 새 부대에 담듯이 자바SE 6와 자바EE 5는 그 새로운 이름과 함께 ‘2’라는 굴레를 벗어나 도약의 로드맵을 사용자에게 제시하는 첫걸음을 디디게 된다.

한편, 자바 ME는 지난 호에서 다루었듯이 버전 번호의 큰 변경은 없지만 내부적으로는 아키택쳐의 큰 변화를 가져왔다. 제약이 많던 CLDC(connected Limited Device Configuration)에서 거의 PC급인 CDC(connected Device Configuration)로 빠른 이전 현상을 보이며 새로운 아키텍쳐 MSA(Mobile Service Architecture)의 실질적인 변화가 일어나고 있다. 자바2 버전이 기존의 버전에 비해서 갖는 가장 큰 중요한 전략은 바로 플랫폼으로서의 자바(Approach to Java Platform)에서 찾을 수 있다.  MS라는 한 기업이 내부적인 절차에 의해 개발하는 방식에 비해, 자바는 매우 일찍부터 많은 개발사 혹은 개발자들과 함께 시장을 키워왔다. 또한 이런 기술 주도와 사업 성공의 독립성은 전체 시장의 활성화에 매우 중요하다. 하지만, JCP의 표준화가 아무리 투명한 절차로 진행되더라도, 자바는 여전히 100% 오픈 플랫폼이라는 평가를 받기 어려웠다. 이는 오픈 소스의 대명사인 리눅스와 비교해보면 더욱 확연히 드러난다. 리눅스라는 OS적 오픈 플랫폼에 이은 자바라는 애플리케이션적 오픈 플랫폼의 등장이 장애로 여겨지기도 했다.

물론, 여기에는 두 가지 측면이 있다. 하나는 썬이라는 한 회사가 자바 기술에서 차지하는 비중이며, 또 하나는 그 동안 표준을 강제하며 변종을 억제해 온 통제 시장 구조이다. 물론 이러한 다소 폐쇄적인 구조속에서도 꾸준히 오픈 플랫폼이라는 노력들은 계속 되어져왔다. 자바EE 5의 참조 구현체(Reference Implementation, 이하 RI)가 글래스피시(GlassFish)라는 오픈 소스 프로젝트로 진행되었고, 사용상의 라이선스도 CDDL(Common Development and Deployment License)로 OSI(Open Source Initiative)가 인증한 라이선스이며 GPL(GNU Public License)보다도 쓰기가 편하다. 또한 그 유명한 자바SE 6의 RI도 머스탱(Mustang)이라는 오픈 소스 프로젝트로 공개되어 있다. 물론 여전히 라이선스는 매우 제한적이고 실제 내부 코드 개발 및 사용도 어렵지만, 올해 2007 자바원 컨퍼런스에서 썬의 CEO인 조나단 슈왈츠가 조만간 글래스피시처럼 될 것이라고 공식 발표했다.

이러한 오픈 플랫폼으로 발전하려는 자바의 노력은 시장상황에 어느정도 유리하게 작용하고 있는데, 단적으로 개별적으로 존재하던 많은 기술들이 자바EE와 자바SE라는 구도하에 모여들고 있는 것을 보면 잘 알수가 있다. <그림 3>을 과거 J2EE 1.4와 비교해보면 점점 더 포함되는 JSR이 많아짐을 느낄 수 있다.

한편으로는 비대해지는 듯 보이지만(실제로 플랫폼 자체의 배포판 크기도 늘고 있다), 자바를 지탱해주는 하드웨어의 발전(CPU, 메모리, 하드 디스크, IO 버스 대역폭 등)에 비하면 오히려 하드웨어를 제대로 활용하기 위한 방향이라고 할 수 있다. 특히 자바SE 6의 포용력은 경이롭다. 자바EE 5에도 포함된 XML과 웹 서비스 관련 기술(JSR 109과 JAXR을 제외한 JAXP, StAX, JAXB, SAAJ, JAX-WS)을 모두 포함하고 있다. 심지어 자바 DB라는 100% 자바 기반 RDBMS까지 내장하게 되었다. 이제 Java SE 6 하나만 설치하면 네트워크, XML 처리, 그래픽, 그리고 DB의 저장까지 가능하게 되는 것이다. 그렇다면 어떤 일이 가능해지는 것일까? 사용자가 XML을 주면 그것으로부터 일정 정보를 뽑아 DB에 유지하는 프로그램을 짜야 한다고 생각해보자. 전에는 자바SE뿐만 아니라, XML 처리를 쉽게 하기 위해 JAXB도 따로 깔고(단순히 라이브러리뿐만 아니라 스키마를 처리하는 툴도 필요하다), MySQL과 같은 DBMS와 거기에 맞는 JDBC 드라이버도 구해 넣어야 했다. 그런데 이제 그런 인프라 구축 과정이 일체 필요 없게 되는 것이다. 여기에 자바 퍼시스턴스(Java Persistence) API까지 가미되면, XML 처리와 DB 처리에 XML 이해와 SQL 쿼리가 전혀 필요 없는 자바 지향적 프로그래밍까지 가능해진다. 달리 말하면, 자바 2.0의 컨버전스는 단순히 API의 수집이 아니라 개발 방식에 있어서도 통합을 의미한다고 할 수 있다. 새로운 자바 플렛폼 JAVA7에 탑재되는 새로운 신기술들은 다음과 같다. 

● Java SE 7
 - JSR 277 Java Module System
 - JSR 292 Supporting Dynamically Typed Languages on the Java Platform
 - JSR 294 Improved Modularity Support in the Java Programming Language
 - JSR 295 Beans Binding
 - JSR 296 Swing Application Framework

● Java EE 6
 - JSR 208 Java Business Integration (JBI)
 - JSR 225 XQuery API for Java (XQJ)
 - JSR 235 Service Data Objects (SDO)
 - JSR 283 Content Repository for Java Technology API (JCR) 2.0
 - JSR 286 Portlet Specification 2.0
 - JSR 299 Web Beans

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

SOA(Service Oriented Architecture), Web 2.0으로 대변되는 웹 플랫폼과 서비스는 과거 인터넷 빅뱅을 능가하는 새로운 비즈니스의 기회와 그에 따른 마켓을 형성하기 시작했다. 그러한 변화는 기존의 엔터프라이즈 및 PC 애플리케이션 비즈니스뿐만 아니라 모바일 시스템에까지 영향을 미치게 되는데, 전세계 유수의 통신사업자들은 기존의 모바일 서비스보다 훨씬 더 빠르고 다양한 컨텐츠들을 고객들에게 제공하기 시작했다. 그러한 새로운 모바일 서비스는 빠른 컨텐츠 서비스 사이클 대체와 저렴한 가격을 전면에 내세우고 있다. 따라서 기존의 모바일 서비스 및 컨텐츠 개발 방법론과 운영환경을 고집하는 벤더들은 도저히 이길 수 없는 싸움을 하게될것이다. 이러한 급변하는 모바일 컨텐츠 서비스에 대응하고자 태어난 기술이 바로 MJSP(Mobile Java Service Platform)이다. MJSP는 하나의 모바일 플랫폼 기술로 운영환경의 구조와 개발방법론, 배포/운영/관리 등의 모든 절차들을 담고있는 포괄적인 아키텍쳐링 기술인데, JSR 232에 의해서 스펙이 제정되었고 현재도 계속해서 발전되고 있다. JSR 232 홈페이지에는 이 기술을 MJSP로 바로 소개하지 않고 Mobile Operational Management 라고 표기가 되어있는데, 그것은 바로 플랫폼의 구조와 운영환경이 다양한 컨텐츠들을 운영하고 관리하는데 초점을 맞췄다는 것을 보다 확실하게 나타내려 했다는 것을 우리는 알 수가 있다. MJSP는 웹2.0을 대응하는 새로운 모바일 자바기술로 휴대폰이 네트워크 환경이나 엔터프라이즈 환경에 연결되었을 때 (Network Connected) 다양하고 다이나믹한 서비스를 제공하는 것을 그 목적으로 한다. 이를 간단히 줄여서 모바일 매쉬업(Mash-up) 서비스라고도 하는데, 우리가 기존의 웹이나 PC 환경에서 제공받던 다양한 서비스들을 그대로 모바일 환경으로 가져왔다고 생각하면 될 것이다.

그렇다면 어떻게 모바일 환경에서 그런 다양하고 다이나믹한 서비스들을 구현할 수가 있었을까? 우리는 모바일 환경이 하드웨어와 리소스의 제한으로 멀티미디어 서비스조차 제대로 구현하기 힘든 조건임을 잘 알고 있다. 위에서 이야기한 모바일 매쉬업 서비스는 다양한 서비스들의 결합으로 이루어져서 제공되는 컨텐츠 서비스인데, 과연 그러한 복잡한 애플리케이션들이 모바일 환경에서 가능할까? 다양한 컴포넌트나 컨텐츠들을 연동하고 찾고 보여주고 관리하려면 리소스의 관리나 상당히 가볍고 빠른 컴포넌트 구조가 필수적이어야 한다. 이러한 요구사항에 적합한 구조가 바로 OSGi 서비스이다. JSR 232의 구조는 실제 OSGi구조와 거의 비슷하다. OSGi의 기본 구조를 더욱 가볍게 슬림하게하여 모바일 환경에 적용했다고 보면 정확한 표현일 것이다. JSR 232 Draft에 보면 MJSP는 멀티 벤더의 모바일 운영 환경을 구현을 목적으로 구현되었으며 일련의 공통적인 모바일 자바 컴포넌트 운영 프로세스 – 개발, 배포, 수행, 관리를 다양한 통신 서비스업체, 개발자들의 요구에 의해서 구현한 자바 애플리케이션과 서비스 플랫폼이라고 정의하고 있다. 또한 JavaOne Conference 2006, 2007 에서는 JSR 232를 소개하는 세션에서 MJSP를 제 3세대 터미널 혁명이라고까지 표현하고 있다. 1세대의 기본적인 API 형태의 표현 서비스를 거쳐 2세대 Native Platform을 통한 독자 API 서비스를 현재의 각 벤더들의 상황으로 진단하고 차세대의 모바일 웹2.0은 3세대 MJSP를 통해서 서비스되고 표현될것을 예측하고 있다.

MJSP의 핵심 개념은 역시 SOA와 OSGi이다. 하드웨어와 리소스의 제한으로 핸드셋에 다양한 애플리케이션들을 인스톨하여 서비스하기는 여전히 어려운 부분이 있다. 따라서 방대한 서비스들을 제공하는 엔터프라이즈 네트워크에 연결되어서 빠르게 서비스들을 찾고 그 서비스들의 결과값만을 나의 휴대폰에서 보여주고 서비스하는 모델로 진화하고 있는 것이다. 또한 그렇게 나의 핸드셋으로 표현되기위해서 다운로드받은 컨텐츠 내지 컴포넌트들을 일괄적으로 관리 수행하는 기능을 OSGi가 담당하고 있게된다. SOA는 종종 웹서비스와 같은 개념으로 혼돈되고 있는데, 정확히 말하면 SOA는 개념적인 요소로서 간단하고 확장 가능한 구조, Self-contained 서비스 그리고 Loose Coupling을 기본으로 하고 있다. 따라서 번들과 서비스로 구현되는 OSGi 구조는 SOA 개념을 충실하게 구현한 Intra-VM 모델로 볼수가 있는 것이다. JSR 232의 구조는 레이어로 구분된 핵심 프래임워크와 서비스로 구성되고 있으며, 컴포넌트 모델은 바로 번들이다.

MJSP 구조를 살펴보면 거의 OSGi와 같다는 것을 볼수가 있다. 다른 것이 있다면 일반적인 OSGi 실행환경이 CDC 기반의 임베디드 환경인데, 여기서는 CLDC 기반의 모바일 환경이라는 것이 다르다. 그것을 가능케 하는 것이 바로 JSR 248 – MSA 규격이다. 이렇듯 JCP는 다양한 JSR을 로드맵에 의해서 점차로 발전시켜나가고 있는 것을 볼수가 있다. 기본적인 구조와 번들 운영환경은 기존의 OSGi와 같으며, 특이한 부분은 바로 Management Architecture와 외부 애플리케이션 연동부분이다. 기존의 OSGi가 하나의 독립적인 실행 환경에서 모든 것들이 대부분 수행된 구조였다면, MJSP은 모바일 매쉬업으로 외부와 연결된 네트워킹된 상태에서 다양한 서비스들을 연동하고 표현하는 것이 가장 큰 차이점이라고 할 수가 있다. 따라서 외부의 네트워크와 연결되어 서비스들을 관리하는 아키텍쳐가 중요한 핵심요소중의 하나이다. OSGi에서도 외부와 연동되어 관리하는 원격관리모듈들과 프로토콜들이 개발되었다. OMA-DM과 SOAP을 사용하는 웹서비스등이 그것인데, MJSP에서도 동일하게 사용된 것을 볼수가 있다. 과거 통신서비스업체들이 자사의 서버에 휴대폰을 접속할경우에는 독립적인 프로토콜이나 좀더 발전된 경우에는 Native Platform에서 제공되는 API 레벨에서 접속을 허용했다. 이러한 폐쇄적인 연결구조로는 오픈된 모바일 매쉬업 서비스를 수행하기가 매우 어렵다. 따라서 MJSP에서는 보다 진보된 모델을 구현했는데, 바로 OMA-DM을 기본으로 채택하여 사용한것이다. 이 모델은 기존의 프로토콜과 API를 모두 혼용하여 구현한 모델로서 오픈된 모바일 접속 환경을 제공하게 된다.

또 하나의 기존 OSGi와 차이가 있는 부분이 바로 외부 애플리케이션 연동부분이다. MSA, MJSP을 지원하지 않는 기존의 모델이나 외부의 애플리케이션일 경우 상호호환성을 위해서 열어놓은 일종의 인터페이스 게이트웨이인 셈이다. 그러나 지켜야 할 규약이 있는데, 그것은 바로 OSGi 기본정책인 것이다. 애플리케이션 타입은 JAR이며, 해당 JAR 파일은 번들로 인스톨될 수가 있다. 또한 인스톨된 번들은 핵심 프레임워크를 통해서 번들 라이프사이클 형태를 통해서 관리를 받게 된다. 마지막으로 외부 애플리케이션은 공용의 패키지로 사용될수있어야하며 (Import-Package 사용) 서비스의 등록과 사용은 XML을 통해서 구현해야 한다.  이러한 외부 애플리케이션 역시 모바일 매쉬업 서비스의 한 축을 담당하게 되는데, 현재의 모든 서비스들이 MSA, MJSP을 지원하지 않는 상황에서 적절한 구조이기도 하다. 현재 MJSP를 이용하여 제공되는 서비스들이 하나둘씩 생겨나고 있는데, 노키아와 스프린트의 매쉬업 서비스가 대표적이다. 미국의 대표적인 통신업체인 스프린트 사는 JSR 232, OSGi를 이용한 Titan Platform Project로 차세대 모바일 매쉬업 서비스에 박차를 가하고 있다. 2007년 4/4분기에는 PDA을 기반으로 하는 서비스를 런칭하고, 내년 2/4분기에는 자사의 모든 휴대폰에 플랫폼을 탑재하여 서비스 할 계획을 가지고 있다. 이에 따라서 현재 스프린트 사는 자사의 모든 개발자들에게 JSR 232, OSGi, 그리고 OMA-DM을 핵심 컴포넌트로 규정하고 그것들을 이용하여 개발하는 기술들을 습득하도록 권장하고 있을 정도이다. 또한 스프린트 사는 전미의 광역 커버리지를 보유한 몇안되는 업체로서 자사의 강점을 살려서 GPS, 지리정보 등의 특화된 매쉬업 서비스를 구상하고 있다. 또한 MJSP 기반의 OSGi 구조와 기존의 MIDP 연동 서비스, Servlet/JSP/AJAX를 통한 다이나믹 웹서비스, eRCP/eSWT를 통한 수려한 UX 서비스, OMA-DM을 통한 원격 실시간 모니터링, 다이나믹 업그레이드, 컨텐츠 배포 서비스들을 핵심 컨텐츠로 정하고 개발을 진행하고 있다.

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

JSR 248/249에 나와있는 MSA는 바로 J2ME의 미래이다. 과거 J2ME는 보다 파워풀한 임베디드 환경의 CDC와 모바일 환경의 CLDC로 구분되어 운영되었다. 그러나 두개의 운영환경은 바로 하나의 모델로 통합되는데, 그것이 바로 MSA (Mobile Service Architecture)이다. MSA는 급격하게 발전하고 변화하는 모바일 환경에 적절하게 대응하기위한 하나의 방안으로 출발하게 된다. 최근 3-4년간 J2ME를 중심으로 모바일 애플리케이션의 시장은 매우 빠른 기술 발전을 하게된다.

지난 2006년 4월, 컨설팅 회사 Strategy Analytics는 Nokia, SUN사와 공동으로 다음과 같은 자료를 발표한다. 전세계적으로 자바 기술을 이용하여 서비스하는 수행하는 모바일 통신 회사는 220개 넘고, 임베디드/모바일 자바가 탑재된 디바이스는 4억개가 넘는다. 35개가 넘는 벤더에 의해서 650개가 넘는 자바 휴대폰 모델들이 지금까지 출시가 되었으며, 모바일 환경에서 자바를 이용하여 개발하는 모바일/휴대폰 관련 엔지니어는 35만명이 넘는다. 또한 모바일 환경에서 구동되는 모바일 자바용 애플리케이션은 5만개가 넘으며, 지금까지 J2ME 관련 툴킷(SDK)은 1백만개가 넘게 전세계 개발자들에게 다운로드되고 배포되었다. 이렇게 급격하게 발전하는 J2ME 환경에서 CDC/CLDC로 구분되는 운영/개발환경을 보다 효율적으로 관리/발전시키기위해서 MSA가 탄생하게 되는데, 더 이상 CDC/CLDC로 구분하여 각각 프로파일들을 올려서 실행하는 것이 아닌 공동의 서브셋(Subset)과 컴포넌트 API로 통일하여서 개발자들에게 보다 통일된 애플리케이션 구조를 갖게 한다.

그렇다면 JSR 248/249 – MSA로의 발전은 개발자와 업체, 서비스 운영자, 그리고 최종적으로 사용하는 고객들에게는 어떠한 장점을 가져다줄것인가? 자바 진영에서는 그것을 다음과 같이 표현하였다. 우선 개발자들에게는 Interoperability가 가장 큰 장점으로 다가오게 된다. 과거 CDC, CLDC 환경에서는 해당 프로파일 – F/P, P/P, MIDP 등 양분된 개발환경을 통해서 개발된 애플리케이션은 서로 상호호환성이 매우 약했으나, MSA 환경에서 개발된 애플리케이션은 상호 운영성과 호환성면에서 매우 강력한 힘을 발휘하게 된다. 또한 임베디드/모바일 자바환경에서 개발과 다른 플랫폼으로의 포팅이 과거보다 쉽고 효율적이 되며, 임베디드와 모바일 애플리케이션으로 양분화된 시장을 하나의 마켓으로 통합하고 개발비용 측면에서 더욱 효율적으로 운영할 수가 있게된다. 개발 및 제조업체에서도 개발자들에게 가져다 준 장점을 그대로 계승하게 되는데, 점차 효율적이고 편한 개발환경에서 자바 개발자들이 보다 높은 생산성과 다양한 애플리케이션을 개발하게되면 보다 다양한 고객들로부터 수많은 요구사항들을 빠르게 다양한 디바이스에서 최적화되고 특성이 나타난 애플리케이션 개발로 대응할 수가 있게된다. 마지막으로 최종적인 사용자 고객들은 다양한 고객의 요구사항에 맞게 개발된 컨텐츠와 향상된 사용자 편의성(UX, GUI)등을 통해 고객의 서비스 품질이 향상됨을 느끼게 될 것이다.

이제 JSR 248 – MSA에 대해서 좀 더 자세히 살펴보자. JSR 248 – MSA의 개발 타겟은 무엇보다 대중화된 CD(Consumer Devices)와 해당 애플리케이션이었다. 그렇다면 대중화된 CD란 무엇인가? 대표적으로 우리가 사용하는 휴대폰을 생각하면 된다. 현재 우리가 사용하고 있는 휴대폰의 특징은 다소 제한된 하드웨어와 리소스를 가지고 있으며, 단순한 비즈니스 모델 즉, 원하는 애플리케이션을 바로 사서 나의 휴대폰으로 다운로드하는 단순한 구조를 가지고 있다. 웹이나 일반적인 애플리케이션에서 사용하는 컴포넌트 기반의 구조나 다이나믹한 실시간 업그레이드등은 현재 수행하기가 불가능하다. 또한 멀티태스킹 기능도 매우 미약하며, 보안적인 측면에서도 미비한 부분이 나타난다. 이러한 일반적인 휴대폰의 환경에서 보다 효율적이고 빠른 개발과 애플리케이션 수행을 위해서 MSA는 탄생하게 된다. 일단 MSA 환경하에서 개발되고 운영되는 애플리케이션은 다운로드된후에 자바의 보안 모델인 Sandbox에서 수행되며 하나의 완전 독립적인 애플리케이션 모델로 실행된다. 다른 수행중인 애플리케이션과 API를 공유할 수가 없고, 오직 하나의 애플리케이션만을 지원하게 된다. 또한 MSA는 모바일 미디어, 메시징, 파일처리, 3D그래픽, 블루투스, 웹서비스, 지불결재 등의 필수적인 기능을 정의한 17개의 컴포넌트 JSR을 포함하고 있다. 이러한 공통의 정의된 컴포넌트 규약들은 모바일 자바 환경에서 통일된 개발환경과 보다 높은 서비스 품질을 보장하면서 많은 애플리케이션을 개발을 예고하고 있다. 다음 버전에는 약 20개의 새로운 컴포넌트 JSR들이 표준화 승인을 기다리고 있는데 UI/UX 개인화, 탤레포니, 센서, 디바이스 관리 등등 보다 세련되고 멀티미디어의 요소가 가미된 휴대폰과 임베디드 모바일 디바이스의 컨텐츠들을 나타내고 있다.  

JSR 248 – MSA에 이어서 JSR 249 – MSAA (MSA Advanced)가 있는데, JSR 248 – MSA이 일반적인 모바일 디바이스에 초점을 두었다면 JSR 249 – MSAA (MSA Advanced)은 제목에서도 나타난바와 같이 보다 강력하고 파워풀한 모바일 디바이스용으로 구현되었다. 모바일 디바이스 관점에서 본다면 일반적인 휴대폰보다 더욱 강력한 기능들과 향상된 하드웨어 스팩을 보유한 디바이스일것이다. 이러한 기기들에서는 단순하게 구매해서 다운로드하는 방식보다 실시간으로 업그레이드가 되거나 아니면 교체/대체할 수 있는 향상된 비즈니스 모델을 사용하며 내부적으로는 애플리케이션, 컨텐츠 서비스 그리고 미들웨어 등의 다양화된 계층(Layer)들이 존재하게 된다. 따라서 MSA가 하나의 애플리케이션에 집중하는 고정적인 방식이었다면, MSAA는 다양하고 다이나믹한 애플리케이션 확장성에 초점을 둔 개발/운영 환경이다. 애플리케이션 수행환경도 MSA와는 매우 다른데, MSA가 애플리케이션 하나에 중점을 두었다면 MSAA는 서비스, 애플리케이션, 그리고 라이브러리 등 다양한 객체를 수용하는 운영환경으로 되어있다. MSAA는 애플리케이션/패키징 모델, 다이나믹 관리환경, 보안 관리 모델, 애플리케이션 협업 관리, 다양한 멀티테스킹 환경을 지원하게 된다.

이상으로 우리는 MSA, MSAA에 대해서 살펴보았다. 현재 2007년 1/4분기에 MSA 기반의 휴대폰들이 노키아, 소니 에릭슨등의 제조업체를 통해서 판매되고 있으며, 내년초 1/4분기중 MSAA 기반의 스마트폰과 PMP, 셋탑박스등이 벤더들을 통해서 일반인들에게 서비스될것으로 기대하고 있다. MSA는 과거 CLDC 기반에서, MSAA는 CDC 기반에서 성장하고 확장하는 구조로 진행되고 있다. 보다 효율적이고 빠른 개발환경과 통일된 운영환경을 제공하기 위해서 발전하는 MSA 구조는 향후 모바일, 임베디드 자바의 표준으로 확산될것으로 예상되며, 또한 MSAA의 애플리케이션, 컨텐트, 라이브러리에 대한 관리 모델로 OSGi가 많은 지원을 하고 있다. 임베디드, 가정용 기기의 상호 호환성을 위해서 탄생한 OSGi는 이제 모바일 휴대폰에서도 확고한 미들웨어로 자리매김하는 시대가 도래한 것이다.

기본적으로 OSGi Framework은 자바환경에서 운영된다. 따라서 자바의 개발환경과 실행환경은 매우 중요한 요소이며, OSGi Framework의 탄생 근거가 되기도 한다. 현재 자바의 개발/실행환경은 JSRs(Java Specification Requests), JCP(Java Community Process)를 통하여 스펙이 정해지고 또한 발전하고 있다. 한편 임베디드 자바(J2ME) 진영에서는 OSGi Framework을 자바 환경위에서 운영되는 하나의 Framework이 아닌 자바실행환경에 구체적으로 명시하기도 한다. 따라서 자바의 실행환경의 트랜드는 OSGi Framework 입장에서는 매우 중요한 로드맵과 전략이기도 한다. 이번 호에서는 점차 다양해지고 발전해나가는 임베디드 자바(J2ME)의 기술 트랜드에 대해서 살펴본다.

자바의 실행환경은 크게 J2ME, J2SE, J2EE로 구분된다. 그중에서 J2ME는 임베디드/모바일을 위한 자바 환경으로 OSGi Framework에서 주로 탑재되는 운영환경이기도 하다. 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) 구분할 수 있다. 셀롤러폰이나 페이져 등은 제품들의 모양, 성능, 특성이 제각각이기 때문에 각각의 기계장치들의 공통되는 핵심부분을 모아 버츄얼머신의 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으로 발전하게 된다. 자바의 실행/개발환경을 정의한 스펙은 JCP와 JSRs를 통해서 매우 다양하게 전개가 된다. 그 많은 JSR중에서 OSGi와 직접적으로 관련된것들은 다음과 같다.

1. JSR 248 - MSA (Mobile Service Architecture)

2. JSR 249 - MSAA (Mobile Service Architecture Advanced)

3. JSR 232 - MOM (Mobile Operational Management)

4. JSR 277 - Java Module System

5. JSR 291 - Dynamic Component Support for Java SE (OSGi)

이중에서 JSR 248/249는 과거 CDC/CLDC에 대한 스펙이며, 특히 OSGi가 대부분 CDC환경에서는 운영되고 CLDC환경에서는 운영되기가 어려웠음을 볼 때 OSGi가 모바일 환경에서도 구현될수있는 가능성을 나타내준다. 또한 JSR 232-MOM은 OSGi의 번들 관리 싸이클과 비슷한 형태의 관리 환경에 대한 스펙이며, JSR277은 자바의 다이나믹 모듈 시스템으로 OSGi의 번들 형태 구조를 자바에서 직접 구현하려는 의도를 볼수가 있다. 이러한 JSR들은 OSGi와 직접적으로 연관이 되어서 매우 중요한 스펙이 된다. OSGi가 자바 실행환경에서 운영되기에 JSR의 발전 방향에 따라서 영향을 받을 수밖에 없기때문이다. 이제 하나하나 살펴보기로 한다.

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

J2ME 플랫폼은 사용되는 기계장치별로 Java플랫폼을 정의하는 프로파일을 제공하여 개발과 실행을 가능하게 한다. 프로파일은 컨피규레이션 위에 위치하는 기계장치별로 구분되는 API들로서 현재는 MIDP(Mobile Information Device Profile)만이 제공, 실행되며, 차후에 PDA profile, RMI profile 등이 포함될 것이다. SUN는 JCP(자바에 대한 License와 표준을 관장하는 기구로 Java Community Process의 약자)를 만들면서 전체 자바구조를 새로운 기틀로 재편성하였다. 업무/적용 영역에 따라 다음과 같은 세가지 section으로 나눈 것이다 .

[그림 3] Java2 Platform 구성도

J2ME 플랫폼은 J2SE, J2EE에 비해서 가장 늦게(?) SPEC이 정의되었으나 실은 그전부터 PersonalJava, PICOJava, eJava 등등의 솔루션으로부터 발전되어 온 개념이다.자바의 탄생 배경이 가전제품의 표준화된 제어와 네트워크 솔루션이라고 한다면 어쩌면 J2ME는 자바의 목적에 가장 잘 맞는 규격인지도 모르겠다. 최근 21세기 들어서 급격하게 임베디드, 모바일 기술이 발전되고 유비쿼터스 환경이 도래하면서 J2ME 플랫폼은 핸드폰, MP3, 디지털 카메라, 차량 네비게이션, 홈게이트웨이, 각종 디바이스 컨트롤러 등에서 많은 수요가 급증하고 있다. 또한 그렇게 인기가 올라가는 J2ME 환경에서 함께 OSGi도 수요가 급증한다는 것은 매우 고무적인 일이 아닐수가 없다.

[그림 4] MSA 주요 제공 기능

[작성 - 김석우, 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) 구분할수있다.

셀롤러폰이나 페이져 등은 제품들의 모양,성능, 특성이 제각각이기 때문에 각각의 기계장치들의 공통되는 핵심부분을 모아 버츄얼머신의 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으로 발전하게 된다.