[이현규의 홈 네트워킹 대해부 - 8] 미들웨어 - JINI

UPnP가 마이크로소프트 진영의 작품이라면, 자바(JAVA) 진영에서 유사한 기능으로 내놓은 미들웨어가 JINI이다. 이번 호에서는 객관성 유지를 위해 JAVA 기술 기반의 미들웨어인 JINI에 대해서 알아보도록 하겠다.

JINI는 선마이크로시스템스가 제안할 당시에는 홈 네트워크 시장을 염두에 둔 기술이었다. 하지만 현재는 이 시장보다는 오히려 서버 애플리케이션 시장에서 영향력을 얻고 있다.

그렇다면 JINI는 이제 홈 네트워크와는 관계가 없는 것일까? 혹시 JAVA가 가전제품(Interactive TV)를 위해서 개발되었다가 서버 컴퓨팅 환경으로 무대를 옮겨 기술적 발전을 이룬 후, 다시 가전제품에 적용되는 과정이 JINI에서도 반복되지 않을까? 여러가지 불확실한 의문이 있고 이 글이 여기에 대한 답이 되지는 못할 것이다.

하지만 JINI가 여전히 많은 투자자들과 개발자들의 마음을 사로잡는 무언가를 가지고 있다면 그 실마리는 분명히 이제 언급할 JINI의 구조와 철학에서 찾을 수 있을 것이다.

본격적인 JINI 이야기에 앞서 잠시 자바에 대해서 살펴보고자 한다. JINI의 특징들이 거의 자바에서 오거나 확장된 것들이어서 JAVA에 대한 이해가 이후의 설명에 도움이 되리라 생각한다.

JAVA 기술은 JAVA 언어와 자바 플랫폼으로 으로 구성된다. JAVA 언어는 JAVA 플랫폼에서 실행되는 프로그램을 작성하는 언어이다[그림 1]. 자바 플랫폼은 자바 프로그램이 실행되는 환경인 JAVA VM(Virtual Machine: JAVA 문법 해석 및 수행 모듈)과 이 VM에 대한 interface인 JAVA api로 구성되는데, hardware, firmware, software 어느 형태로든 구현이 가능하여 현재 가전장비의 내장형 시스템에서 대형서버에 이르기까지 다양한 방식으로 운용되고 있다.

JAVA의 장점은 VM을 통해 똑 같은 프로그램을 별도의 수정이나 사용자 개입 없이도 임의의 기기에서 동일한 실행결과를 얻을 수 있다는 점이다. JINI는 바로 이 장점을 네트워크를 통해서 확장시킨 것으로 볼 수 있다. 그럼 이제 JINI 이야기를 시작해보자.

JINI 시스템은 사용자들과 그 사용자들이 이용하려고 하는 장비와 같은 자원의 유기적인 결합(YES federation, NO collection)을 지원하는 분산 시스템이다. JINI의 역할은 이전 호에서 언급한 UPnP처럼 네트워크를 통해 사람이나, 기기, 프로그램이 특정 자원을 찾거나 사용하고자 할 때, 관리자의 개입 없이 유연하게 동작하는 것을 목표로 한다.

그러나 자원으로 참여하기 위한 조건과 자원을 다루는 방법에서는 다른 유사기술과 확연한 차이를 가지고 있는데, 무엇보다 JINI의 자원은 JAVA machine 이어야 한다는 점이다. 아마도 이점이 JINI의 확산에 가장 큰 걸림돌이리라 생각한다. 점차 고가가전이나 정보가전제품에 JAVA VM을 내장하는 경우가 늘어나고는 있지만 여전히 소수에 불과하다.

물론 JAVA VM이 없거나 아예 컴퓨팅 파워가 없는 장비가 JINI 네트워크에 참여하는 방법도 마련되어 있으나 이것은 브릿지와 같은 다른 기능의 도움을 받아야 하므로 여기서는 언급하지 않겠다. 일단 자원이 JAVA machine 이라면 다른 제약사항은 없다. JAVA VM을 가진 컴퓨터, 가전제품, JAVA 플랫폼에서 동작 가능한 소프트웨어 컴포넌트 그 어떤 것이든 가능하다. 이제 JINI가 이 자원들을 어떻게 다루며 이를 통해 무엇이 가능한지 살펴보자.

JINI의 동작은 크게 장비와 같은 자원 자체가 홈 게이트웨이와 같은 자원을 관리하는 서비스 서버를 찾는 과정(Discovery), JINI 네트워크에 합류하는 과정(Join), 서비스 사용을 위한 프로그램을 제어용 client에 전송하는 과정(Lookup), 사용자의 요구에 의한 서비스 수행과정(Service Invocation)으로 나눠 볼 수 있다.

자원은 사용자가 사용하고자 하는 서비스의 공급자이다. 이 자원이 JINI 네트워크에 참가할 때는 Discovery 프로토콜을 사용해서 사용자와 자신을 매개해 줄 자원관리 서비스(Lookup Service)를 찾는다.

자원관리 서비스는 매개를 위한 서비스이므로 대개 홈 게이트웨이나 장비제어를 위한 클라이언트에 포함되어 있다. JINI 네트워크에 참가하는 자원은 자신이 제공하는 서비스를 위한 JAVA 프로그램(Service Object)을 저장하고 있는데, 이 프로그램은 서비스 제공자에 의해서 구현되므로 서비스에 대한 명세를 해석하는 과정에 오류가 생길 가능성을 원천적으로 해소했다.

또한 이 프로그램은 JAVA 언어의 표준 연동방식을 이용하여 구현함으로써 서비스 제공자의 서비스 구현방식에 관계없이, 표준 연동방식을 이용하여 어떤 물리적 환경에 존재하는 JAVA VM에서든 이 프로그램을 실행시킬 수 있도록 해준다.

일단 자원관리 서비스를 발견한 자원은 서비스에 대한 속성정보(Service Attributes)와 서비스 수행을 위한 JAVA 프로그램인 Service Object를 네트워크 합류를 위한 Join 프로토콜을 사용하여 자원관리 서비스에 등록한다.

사용자가 서비스를 사용하고자 할 때는 Lookup 프로토콜을 사용해서 자원관리 서비스에 요청한다.

이 요청은 자신이 사용하고자 하는 서비스의 인터페이스 형식이나 서비스에 대한 속성정보를 보내고 자원관리 서비스는 등록된 Service Object들의 인터페이스 형식과 서비스 속성정보들을 이용하여 적절한 Service Object를 사용자 클라이언트에 전송한다.

이러한 Service Object 탐색방식은 자원관리 서비스 개발자나 사용자 서비스 개발자, 자원 프로그램 개발자가 각자 구현하여 사용하는 것이 아니라 JAVA 언어에 내재된 탐색방식을 그대로 이용하므로 잘못된 속성이나 인터페이스 형식의 적용으로 생기는 문제를 원천적으로 해결할 수 있다.

마지막 단계로 사용자는 자신이 적용한 인터페이스 형식을 통해 자원이 자원관리 서비스에 등록해 놓은 Service Object를 실행한다.

Service Object는 완전한 JAVA 프로그램으로 사용자가 보유하고 있는 client의 JAVA VM에서만 실행될 수 있으며, 자원 자체에서 일부 기능의 수행을 위해서는 JAVA의 RMI(Remote Method Invocation: 원격 프로그램 수행방식)를 이용한다. RMI는 사용자의 client에서 자원의 제어 등을 위한 호출을 하면 자원에 있는 기능을 수행시킬 수 있도록 해준다.

어떤 경우이든 Service Object는 JAVA 플랫폼에 의해서 동일한 실행결과가 보장된다. 또 Service Object는 서비스 제공자 자신이 직접 개발한 프로그램이므로 가장 정확한 내부 구현이 가능하며, UPnP와 같이 기능이나 속성의 명세만을 전달하는 프로토콜에서 생길 수 있는 해석상의 실수나 악의에 의한 오동작을 방지할 수 있다.

또한 Service Object에는 자바 플랫폼의 독자적인 보안, 자원관리 방식이 적용되므로 사용자나 자원의 운영체제 보유 유무나 특성과는 관계없이 사용자에 대한 인증(authentication), 접근권한에 대한 관리(authorization) 등을 안정적으로 지원받을 수 있다.

위의 설명처럼 JINI는 절차라는 관점에서 보면 Discovery, Join, Lookup이라는 단계들이 UPnP와 같은 유사 기술들과 큰 차이가 없다. 그러나 그 내면을 들여다 보면 JINI 시스템이 프로토콜과 데이터로 연결된 개별적인 프로그램이나 장비의 집합이 아니라 단일한 보안, 자원, 실행 환경을 가지고 전 네트워크가 동일기능에 동일 프로그램을 사용하는 마치 한대의 컴퓨터 안에서 일어나는 일을 네트워크로 펼쳐놓은 듯한 모습을 하고 있음을 알 수 있다.

그러나 JINI는 이론적인 우수성에도 불구하고 JAVA 플랫폼의 부담 때문에 홈 네트워크 시장에서는 큰 역할을 차지하지 못하고 있으며, 오히려 JAVA 진영의 대표적인 서비스 플랫폼인 OSGi에서도 UPnP를 장비검색과 네트워크 자동구성을 위한 미들웨어로 채택하고 있는 실정이다.

그럼에도 불구하고 JINI와 같은 일체화된 방식의 네트워크 구성방식 자체는 관련된 개발자들간의 오해로 인한 오류를 원천적으로 제거시킬 수 있기 때문에 계속적인 필요성이 대두될 것으로 예상된다.

/이현규 아이크로스테크놀러지 대표 hklee@icrosstech.com